Re: [FUG-BR] Falha no carregamento de lista de pacotes - "Unable to retrieve package information."
2018-03-15 16:30 GMT-03:00 Paulo Henrique: > Saudações a todos, > > Estou deparando-me com um problema no PFsense, onde o Package manager não > carrega a lista de pacotes disponíveis. > Através de pesquisa na internet, observei que o problema é recorrente e > entre os fatores que faz o problema ocorrer é o pkg não conseguir acesso ao > endereço srv:pkg.pfsense.org que redireciona para os servidores > files01.netgate.com e files00.netgate.com informando que não há rota para o > mesmo. > Entre as recomendações sugeriram usar os DNS da google porém mesmo > efetuando as alterações o problema persisti. > Já testei com os dois brasch disponiveis, a versão 2.4.2 e a 2.3.5 e ambas > as versões o problema acontece. > Já editei a opção System / Advanced / Networking / Prefer to use IPv4 even > if IPv6 is available para usar preferencialmente o IPv4 sobre o IPv6. > Usando o comando host, tanto usando os servidores DNS da empresa como da > google resolve e retorna a resposta, como se segue abaixo. > > Usando os DNS da empresa > bash-4.3$ host -t srv _https._tcp.pkg.pfsense.org > _https._tcp.pkg.pfsense.org has SRV record 10 10 443 files00.netgate.com. > _https._tcp.pkg.pfsense.org has SRV record 10 10 443 files01.netgate.com. > > Usando os DNS da google. > bash-4.3# host -t srv _https._tcp.pkg.pfsense.org > _https._tcp.pkg.pfsense.org has SRV record 10 10 443 files01.netgate.com. > _https._tcp.pkg.pfsense.org has SRV record 10 10 443 files00.netgate.com. > > Alguma sugestão que possa resolver esse problema ? ou alguém mais está > passando por estas mesmas dificiuldades. > Isso só acontece comigo quando eu estou na minha rede de testes onde o IPv6 não tem conexão upstream. Como geralmente estou no console, eu faço assim: $ ifconfig xxxN inet6 ifdisabled Eu ainda não testei com a opção de preferir ipv4 sobre ipv6, mas deveria funcionar também. Quanto ao DNS, não há qualquer problema, o pkg.pfsense.org não tem um registro A (ou ) apenas SRV. Você não vai conseguir pingar ou conectar mas o pkg vai funcionar. Como você esta rodando o pkg ai ? Já tentou no console ? -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] Bind.
2016-10-30 3:11 GMT-02:00 Nenhum_de_Nos:
>
>
> On October 28, 2016 4:27:05 PM GMT-03:00, Luiz Otavio O Souza wrote:
>>2016-10-28 15:15 GMT-02:00 Ricardo Ferreira:
>>> Aqui deixei o BIND apenas como autoritativo. Como recursivo vá de
>>unbound e
>>> se possível implemente DNS Anycast distribuindo-os ao longo de sua
>>rede. O
>>> usuário vai ficar grato. Estou tentando construir uma versão
>>embarcada
>>> usando Cubieboard apenas para levar o DNS o mais próximo possível do
>>> usuário.
>>
>>Cubieboard2 (com ethernet gigabit) ou algo como a ODROID-C1+
>>
>>Foge de fast ethernet. A fast ethernet na rpi é um adaptador
>>usb->ethernet ('nuff said), na cubieboard1 a performance é terrivel...
>>
>>A Cubieboard[1|2] (e a maioria dos SoCs da Allwinner) tem um suporte
>>excelente no FreeBSD, muitos inclusive com imagens oficiais.
>>
>>Luiz
>
> Luiz,
>
> Tem recomendação de placa desse tipo mas com 2 ou 3 eth decentes?
>
> Tentei migrar meu roteador soekris pra rpi2. Se não fosse as eth usb, teria
> dado certo blz.
>
Matheus,
No momento só MIPS, ERL (principalmente, com 3 portas giga) e outros
roteadores mais baratos, mas no caso dos roteadores normalmente são
menos interfaces físicas e uma das portas conectadas a um switch (como
você já conhece).
ARM tem a BPi-R1 mas ainda sem suporte ao switch, tem a clearfog
também, mas nem driver de rede tem...
Alguém pode tentar convencer o manu ou o jmcneil a finalizar o suporte
da BPi-R1. Eles comem os SoCs Allwinner de café da manhã.
Luiz
-
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Bind.
2016-10-28 15:15 GMT-02:00 Ricardo Ferreira:
> Aqui deixei o BIND apenas como autoritativo. Como recursivo vá de unbound e
> se possível implemente DNS Anycast distribuindo-os ao longo de sua rede. O
> usuário vai ficar grato. Estou tentando construir uma versão embarcada
> usando Cubieboard apenas para levar o DNS o mais próximo possível do
> usuário.
Cubieboard2 (com ethernet gigabit) ou algo como a ODROID-C1+
Foge de fast ethernet. A fast ethernet na rpi é um adaptador
usb->ethernet ('nuff said), na cubieboard1 a performance é terrivel...
A Cubieboard[1|2] (e a maioria dos SoCs da Allwinner) tem um suporte
excelente no FreeBSD, muitos inclusive com imagens oficiais.
Luiz
-
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Pfsense virou uma senzala..
2016-08-27 3:30 GMT-03:00 Gustavo Freitas: > Queria entender onde foi a falta de respeito no tópico uFW para galera > ser excluída.. > Será que foi vc Luiz ou Jim ? diz ai.. É proibido discordar agora do > projeto pfsense > e da netgate ? Nem eu e nem nem o Jim. Houve sim um erro naquela thread que afetou alguns usuários do grupo, um colega de trabalho, achou nossa discussão acalorada demais, longa demais e perdeu o 'final feliz' na tradução e acabou banindo vários usuários (a paciência no antigo continente não é tão grande quanto aqui...). Eu vou restaurar o acesso dos usuários afetados. Agora dai, pessoas que nem estavam banidas postarem alusões ao nazismo, a senzalas, sinto muito... não posso acreditar que é dessa forma que queremos resolver o problema. Luiz PS: A FUG-BR não é o local adequado para tratar essa questão, que é no mínimo off-topic aqui - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Pfsense virou uma senzala..
2016-08-26 21:40 GMT-03:00 Thiago Gomes: > Amigos, > > Junto com capitão do mato, estão excluindo do grupo vários colegas. > Inclusive eu fui banido do grupo do facebook Pfsense Sysadmin e > Pfsense BR por apenas discordar de certas atitudes.. Colegas como > Marcio Antunes, Gustavo Freitas, Paulo Bandeira e Daniel Carvalho.. > > Acho muito interessante é membros aqui brasileiros deixar esse Jim > fazer isso... Será que eles concorda ou se abrir a boca é demissão ? Tiago, Você pode conversar, contribuir, ajudar, pode discordar a vontade, pode argumentar, pode solicitar suas alterações e features, mas tente demonstrar algum respeito. Seu email (assim como vários comentários desnecessários nesses últimos tempos e não apenas o seu) é um insulto por si... senzala ? capitão do mato ? Sinto muito, mas nesses casos eu não só concordo como faço questão. Luiz PS: opnião pessoal > > Segue o link do qual foi excluidos os colegas e tire suas conclusões. > > http://imgur.com/a/jG7LH > - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] BSDCon Brasil 2015
2015-10-12 13:59 GMT-03:00 Danilo Egea Gondolfo: > Galera, a BSDCon Brasil foi fantástica! Foi ótimo poder conhecer > pessoalmente os camaradas depois de mais de 10 anos participando da > comunidade FreeBSD. > > Queria agradecer de coração ao pessoal que organizou o evento. Já fui > organizador de alguns pequenos eventos de software livre aqui no Paraná > (FLISOL) e sei que dá muito trabalho. Eu sei que organizar a BSDCon Brasil > não foi fácil. Então, novamente, agradeço de coração o empenho dos > organizadores! > > Grande abraço e nos vemos na próxima BSDCon Brasil (ou antes, sei lá! haha)! > > Danilo. Só posso engrossar o coro aqui para dizer que o evento foi realmente fantástico! Tivemos algumas faltas importantes de pessoas da nossa comunidade (o Patrick e o Gondim), mas queria agradecer a todos que compareceram. A conferencia foi unica em termos da proximidade que proporcionou entre os participantes. Obrigado Vinicius e Lucas pelo tempo que vocês dedicaram a organização do evento e pela recepção que vocês deram a nós visitantes. Até a próxima! Luiz - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] lock order reversal
On 9 October 2015 at 08:44, Otacílio wrote: > Caros > > Gerei uma imagem para a minha beaglebone utilizando o crochet. Só que de vez > em quando eu recebo uma mensagem de lock order reversal como a seguinte: > > lock order reversal: > 1st 0xcd363f50 bufwait (bufwait) @ /src/FreeBSD/sys/kern/vfs_bio.c:3344 > 2nd 0xc3224400 dirhash (dirhash) @ > /src/FreeBSD/sys/ufs/ufs/ufs_dirhash.c:281 > KDB: stack backtrace: > lock order reversal: > 1st 0xcd363f50 bufwait (bufwait) @ /src/FreeBSD/sys/kern/vfs_bio.c:3344 > 2nd 0xc0842e68 kernel linker (kernel linker) @ > /src/FreeBSD/sys/kern/kern_linke r.c:552 > KDB: stack backtrace: > db_trace_self() at db_trace_self > pc = 0xc062ddb0 lr = 0xc0242ff8 (db_trace_self_wrapper+0x30) > sp = 0xdd1b6580 fp = 0xdd1b6698 > db_trace_self_wrapper() at db_trace_self_wrapper+0x30 > > Do que eu pesquisei na Internet encontrei essa descrição > > https://www.freebsd.org/doc/faq/troubleshoot.html#idp59178576 > > de que é uma mensagem de um framework informando que um deadlock pode ter > acontecido. Eu gostaria que alguém me dissesse se preciso ficar preocupado > com isso e, caso não, qual o caminho das pedras para o arquivo de > configuração do Kernel que o crochet usa para a beaglebone para que eu possa > desativar isso lá. > Otacilio, Não necessariamente esse aviso quer dizer que um deadlock pode ter acontecido, mas sim que ele 'poderia' acontecer: It is possible to get false positives, as witness(4) is conservative. A true positive report does not mean that a system is dead-locked; instead it should be understood as a warning that a deadlock could have happened here. Alguns desses warnings não representam um problema (falso positivos). Você não precisa se preocupar com isso, isso é normal no -current (os warnings). Desabilite as opções de debug no kernel e você não vera mais esses warnings (além de obter uma performance muito melhor). Para isso comente as seguintes opções no arquivo de configuração do kernel: options INVARIANTS # Enable calls of extra sanity checking options INVARIANT_SUPPORT # Extra sanity checks of internal structures, required by INVARIANTS options WITNESS # Enable checks to detect deadlocks and cycles options WITNESS_SKIPSPIN# Don't run witness on spinlocks for speed Luiz - 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 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 > > 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
Re: [FUG-BR] Problema sério com link aggregation LACP no FreeBSD 10.2-RELEASE
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. []'s Luiz - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
[FUG-BR] committers brasileiros++
O Araujo foi recentemente punido^wreconhecido pelo excelente trabalho que vem executando no src e teve um upgrade no seu commit bit. Agora temos mais um committer brasileiro no src. Parabéns pelo excelente trabalho Marcelo! Luiz - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Erro - sorry no space in lost+found directory
2015-06-25 11:13 GMT-03:00 Robson Peripolli Rodrigues: Em 25 de junho de 2015 10:09, Marcelo/Porks escreveu: 2015-06-25 9:51 GMT-03:00 Robson Peripolli Rodrigues: Bom dia pessoal quero ver se alguém já enfrentou esse problema com o fsck. Deu um erro no meu FreeBSD 9.1 e eu entrei em modo single e dei um fsck mas quando chega no /var ele não consegue corrigir e fica num loop dando a mensagem sorry no space in lost+found directory. A pasta lost+found não está no / . Não estou muito certo, mas há espaço no seu / ? Tenta passar o fsck somente no / e quando der tudo ok, faz no restante. Meu / tem espaço. O lost+found está no /var justamente na partição com problema. Não consigo montar o /var com escrita para limpar o lost+found. Da sempre a mensagem: mount: /dev/mfid0p6: R/W mount of /var denied. Filesystem is not clean - run fsck. Forced mount will invalidate journal contents: Operation not pemitted Em modo leitura monta. Pela mensagem pede para roda o fsck mas como está sem espaço e não consigo remover o seu conteúdo fico sem saída. Quando você monta o /var (como somente leitura) você vê algum espaço livre lá ? Só um chute mas experimenta desabilitar o soft update journaling (se estiver habilitado) e depois rodar o fsck: # tunefs -p /var (para ver as opções ativas desse filesystem) # tunefs -j disable /var # fsck -y /var # fsck -y /var (sim rode duas vezes o fsck) Em ultimo caso e só em ultimo caso, monte o /var utilizando o 'mount -f' e tente apagar alguma coisa lá para liberar um pouco de espaço (depois desmonte e rode o fsck para garantir a integridade do FS). HTH, Luiz - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Openbgpd x Quagga
2015-06-19 18:26 GMT-03:00 Fabio Julian: Boa noite pessoal, gostaria da opinião de vocês sobre a implantação de BGP, hoje temos rodando o Openbgpd no freebsd10.1. Porem precisamos rodar o ospf e não obtivemos sucesso na instalação do mesmo no freebsd10.1 devido as mudanças do CARP. Como utilizávamos o vyos, e também por o Quagga ser cisco like, estamos pensando em migrar o openbgpd para o Quagga, pois ai jã testamos e o ospf roda normal. A minha dúvida é se o Quagga teria uma performance igual ou similar ao openbgpd, ambos rodando no freebsd Atenciosamente, -- Fabio J. Ortlieb Rline Telecom Ltda. (46)8809-3086 (46)3555-8000 A performance de forwarding vai ser a mesma, pois em ambos os casos o forwarding é feito pelo kernel (que roda sempre sem modificações). Já a performance do BGP em si, seja o tempo de carga da tabela de rotas ou o tempo de convergencia, esses dependem diretamente do daemon BGP e podem ser bem diferentes para o quagga e o openbgpd. Você precisa testar se o ospf realmente vai funcionar com o quagga pois com a alteração que foi feita não sei se há garantias nesse sentido. Como o Edinilson comentou você pode instalar os dois no seu servidor para facilitar seus testes. Alguém(tm) deveria corrigir o ospf para funcionar com o novo CARP. Luiz - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Netstat FreeBSD 9 x FreeBSD 10
2015-05-17 11:10 GMT-03:00 Felipe N. Oliva: [...] Bug 200268, https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200268 -- Felipe N. Oliva Administração de Redes e Sistemas Skype: felipe.no88 Felipe, eu conversei com o glebius@ e ele vai dar uma olhada nesse PR. -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] Criação de Partição SWAP em notebook com 8Gbytes de ram.
2015-05-26 5:58 GMT-03:00 Paulo Henrique - BSDs Brasil: On 05/25/15 22:06, Kaio Rafael wrote: Paulo, Tenho uma máquina semelhante a tua. Essa wifi só funciona no openbsd! Desisti do FreeBSD no meu notebook por causa dela. O Desenvolvimento dela ainda é muito recente e preciso de algo estável. To rodando Debian estável com o último kernel. Estava tento alguns problemas de intermitência com ela, aparentemente está mais tranquilo agora. Em 25 de maio de 2015 18:54, Paulo Henrique - BSDs Brasil paulo.rd...@bsd.com.br escreveu: Kaio, Tento as alterações que há aqui ? https://github.com/KreizIT/FreeBSD-IWN Isso é bem antigo hein, acho dificil funcionar hoje em dia (mais de 2 anos o ultimo commit nesse repo). O driver do open esta sendo portado (https://github.com/rpaulo/iwm) mas ainda é recente e por enquanto esta voltado para quem quer ajudar a testar ou corrigir bugs. Na duvida consulte o pessoal na freebsd-wireless@ Luiz - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] CURRENT - Panic no boot
2015-05-20 2:18 GMT-03:00 Guilherme Rigon: Em 20 de maio de 2015 01:50, Luiz Otavio O Souza escreveu: 2015-05-20 1:39 GMT-03:00 Guilherme Rigon: Eu não consigo nem logar no sistema, existe maneira de reverter assim?! Você pode bootar com o kernel antigo. interrompe o boot no loader (acho que no menu de boot no caso do x64) e depois: unload load /boot/kernel.old/kernel boot Se você não tem o kernel antigo ai só com um livecd/memstick. Luiz - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd Fiz esse procedimento, porém caio no seguinte erro: http://imgur.com/rKlMnGb Quando mando dar load nos 2 arquivos que ele carrega no boot, zfs.ko e opensolaris.ko acontece o mesmo problema http://imgur.com/g9PT0Yx -- -- Guilherme Rigon Sim, eu esqueci dos modulos do ZFS. Você precisa carregar esses módulos a partir do diretório do kernel antigo: unload load /boot/kernel.old/kernel load /boot/kernel.old/opensolaris.ko load /boot/kernel.old/zfs.ko boot Luiz - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] CURRENT - Panic no boot
2015-05-19 18:32 GMT-03:00 Guilherme Rigon: Pessoal, Atualizei ontem o meu -CURRENT e aconteceu tudo normalmente, até o final do processo. Porém hoje, o meu ESXi rebootou e eu não consigo mais usar o -CURRENT, está dando o seguinte erro no boot dele. Alguma idéia do que possa ter acontecido? A instalação foi feita usando ZFS e venho usando ele a alguns meses já. erro: http://imgur.com/FoUJCcH eu havia enviado uma mensagem anteriormente com a imagem anexada, peço a algum moderador que apague ela. -- -- Guilherme Rigon Guilherme, Precisa reverter a r282971, eles ainda estão analisando o problema. Maiores detalhes em: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200288 Luiz - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] CURRENT - Panic no boot
2015-05-20 1:39 GMT-03:00 Guilherme Rigon: Eu não consigo nem logar no sistema, existe maneira de reverter assim?! Você pode bootar com o kernel antigo. interrompe o boot no loader (acho que no menu de boot no caso do x64) e depois: unload load /boot/kernel.old/kernel boot Se você não tem o kernel antigo ai só com um livecd/memstick. Luiz - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Sistema baseado em FreeBSD
2015-05-18 8:45 GMT-03:00 Antonio Modesto: On 2015-05-14 5:54 pm, Felipe N. Oliva wrote: Boa tarde, Vou deixar aqui um vídeo de apresentação do sistema HellOS, baseado em FreeBSD. Uma curiosidade: utilizamos o framework TinyBSD para construi-lo. Só uma dúvida. Vi que colocaram no vídeo que o sistema possui NETMAP ativo. Isso já é para encaminhamento de pacotes? Não sabia que já estava estável... Modesto, O netmap é considerado estável já a algum tempo (até já esta no 10-stable). Mas quando se fala 'netmap' hoje em dia, se fala do framework e não das aplicações (que ainda são poucas). Então a menos que exista uma aplicação para o netmap nesse produto, o netmap 'ativo' significa que o framework esta compilado e habilitado no kernel, bastando que você instale e/ou desenvolva sua aplicação. Luiz - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Netstat FreeBSD 9 x FreeBSD 10
2015-05-16 11:36 GMT-03:00 Felipe N. Oliva: On 5/16/15 11:19, Danilo Egea Gondolfo wrote: On 05/16/15 10:26, Felipe N. Oliva wrote: Bom dia lista! Vejam só: Saida do netstat -rn no FreeBSD 9: Routing tables Internet: DestinationGatewayFlagsRefs Use Netif Expire Saida no FreeBSD 10: Routing tables Internet: DestinationGatewayFlags Netif Expire Percebam que a coluna Refs e Use não são mais listadas no FreeBSD 10, alguma alma generosa sabe o motivo? Meu interesse é na coluna Use. Busquei no updating, man, google e afins e não encontrei nada. Att, Boa pergunta. Olhando no código do netstat dá pra ver que ele vai mostrar essa coluna com o parâmetro -W. Isso deve ter acontecido depois que modificaram o netstat para usar a libxo (commit r279122). Manda um email na freebsd-net@, as vezes pode ter sido um esquecimento do cara, por que também não encontrei isso documentado... sei lá... Danilo. - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd Valeu Danilo, na verdade você já resolveu meu problema. Executando netstat -rnW trouxe a coluna Use. Perfeito, obrigado! -- Felipe N. Oliva Administração de Redes e Sistemas Skype: felipe.no88 Não Felipe, isso me parece uma regressão. O campo Use foi removido na r259562: https://svnweb.freebsd.org/base/head/usr.bin/netstat/route.c?r1=256512r2=259562 E depois adicionado novamente na r262763: https://svnweb.freebsd.org/base/head/usr.bin/netstat/route.c?r1=260124r2=262763 Mas me parece que com essas alterações o campo Use acabou caindo dentro do if da flag -W, que segundo o manual: -W Show the path MTU for each route, and print interface names with a wider field size. Ou seja, essa flag não tem nada a ver com o campo Use. Felipe, você pode abrir um PR para documentar isso ? Luiz - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Sistema baseado em FreeBSD
2015-05-14 17:54 GMT-03:00 Felipe N. Oliva: Boa tarde, Vou deixar aqui um vídeo de apresentação do sistema HellOS, baseado em FreeBSD. Uma curiosidade: utilizamos o framework TinyBSD para construi-lo. Por que o tinybsd e não o nanobsd ? O nanobsd trabalha com duas partições read-only (duas copias do sistema), o que facilita muito as atualizações (atualiza somente uma delas, boota com a nova versão e caso algo de errado você pode bootar a partir da partição antiga). 50 horas pra configurar o FreeBSD parece puxado, imagino que isso é baseado em pessoal sem treinamento adequado. Luiz - 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-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 da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] MIPS64 500MHZ no FreeBSD e Pfsense 2.2
2015-04-29 11:39 GMT-03:00 Thiago Gomes: E agora a solução: use o 11 (pra quem não precisa do 10.x como no caso do Renato). Luiz, Como vou usar 11 para o MIPS quem fez só tem para 10.X. Você pode compilar sua propria versão: http://rtfm.net/FreeBSD/ERL/#build Luiz - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] MIPS64 500MHZ no FreeBSD e Pfsense 2.2
2015-04-29 14:56 GMT-03:00 Thiago Gomes: Você pode compilar sua propria versão: http://rtfm.net/FreeBSD/ERL/#build basta executar o script em uma maquina virtual freebsd ? é isso ? -- Thiago Gomes Sim, o script vai compilar o FreeBSD e gerar a imagem pra você. Mas claro, vale a pena ler o script e entender o processo, não é complicado. Luiz - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] MIPS64 500MHZ no FreeBSD e Pfsense 2.2
2015-04-29 9:30 GMT-03:00 mantunes: Isso muito me interessa, como você tá fazendo pra contornar o problema do strip no 10.x? Renato, poderia dizer como seria esse problema.. eu tenho um edge router aqui e estou para instalar o FreeBSD, posso até simular Quando você roda o strip(1) em um binario, ele vai corromper o arquivo. Um workaround é _não_ rodar o strip na instalação do programa e o outro é instalar um fake strip do tipo 'faz nada'. E agora a solução: use o 11 (pra quem não precisa do 10.x como no caso do Renato). Luiz - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] MIPS64 500MHZ no FreeBSD e Pfsense 2.2
2015-04-28 17:28 GMT-03:00 Elizandro Pacheco: Como estão fazendo com a questão de instalação de pacotes? Elizandro Pacheco Ainda não há pacotes para MIPS. Você instala os pacotes necessários através do ports (+ lento pra compilar localmente mas funciona). Luiz - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] MIPS64 500MHZ no FreeBSD e Pfsense 2.2
2015-04-28 11:42 GMT-03:00 Thiago Gomes: Mas no meu caso, que prefiro o FreeBSD puro, estou testando aqui. É um achado um hardware destes rodar o Free redondinho. E o bug. que o renato falou ? teria como dizer como vc fez para gerar a imagem. ? tentei fazer e não deu boot.. pode ser me pvt.. Como o Renato falou o bug é no 10.x, no 11 funciona (e também há formas simples para contornar esse problema). Luiz - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] fsck: Could not determine filesystem type (Dica)
2015-04-10 21:57 GMT-03:00 Paulo Olivier Cavalcanti: On 10/04/2015 21:33, Paulo Henrique - BSDs Brasil wrote: [...] João, No caso pode se usar a opção -t do proprio fsck passando o parametro relacionado ao sistema de arquivo destino que será tratado. Ex. Para Unix filesystem fsck -f ufs /dev/ada3s1 Para vfat ou msdosfs fsck -f msdosfs /dev/da1s1 Boa dica xará, mas foi estranho o fsck não ter determinado o filesystem automaticamente. Isso era um problema que me parece foi introduzido durante a implementação do gpart. A r275179 implementa novos métodos para restaurar essa funcionalidade (foi depois do release do 10.1 mas já esta no stable/10). Luiz - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] MIPS64 500MHZ no FreeBSD e Pfsense 2.2
2014-12-05 12:37 GMT-02:00 Patrick Tracanelli: On 04/12/2014, at 21:52, Alexandre Correa wrote: x86 Sds. Alexandre J. Correa Onda Internet http://www.onda.net.br hehuauhhaua traído pelo auto-complete Era pra ser “Sim mas E ARM?” não é. Procurei boards ARM com 2 ou 3 minipci, e só encontro esses geode velho ou MIPS mais novos incluindo ubiquiti. Os imx6 tem pcie, mas ainda não vi placa com pcie disponível, eu tenho uma wandboard quad e ela não tem slot pcie (embora tenha SATA, USB 3 e varias outras). O imx6 é fornecido em uma placa a parte (com CPU, memória e outros componentes importantes) e tem pcie. Essa placa é conectada a uma placa 'filha' que tem os conectores para aquilo que se deseja utilizar, então há muita variedade de recursos entre as placas com imx6 (e ainda é uma mão na roda para quem quer desenvolver projetos customizados baseado nesse SoC). É uma questão de tempo até PCIe começar aparecer nas placas. Uma boa placa ARM poderia ser uma opção, ja que FreeBSD esta mais avançado nela do que em MIPS aparentemente. Isso não é necessariamente verdade, o suporte do MIPS é _muito bom_, tanto que o ARM so passou na frente agora, depois da RPi e BBB que trouxeram mais usuários, mais desenvolvedores e mais contribuições. MIPS é tão estavel quanto o ARM, só temos menos informação, menos desenvolvedores e consequente pouco suporte a placas mais comuns. Eu tive muitas horas de uso na RB450 e RB450G ( 5000 boots e muito provavelmente 1000 hrs de uso), não há o que falar pois numa coisa a mikrotik acertou, os hardwares são confiáveis :) Luiz - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] MIPS64 500MHZ no FreeBSD e Pfsense 2.2
On 4 December 2014 at 11:03, Gustavo Freitas wrote: realmente, na hora q fizer isso rodar no beaglebone, basta uma googlada por uma placa com 2 nic.. onde vc viu uma placa com 2 nic. ? Pode ser com 5 ? :-) http://www.bananapi.com/index.php/component/content/article?layout=editid=59 Luiz - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] BSD Magazine - PPPoE Concentrator Dual Stack!
2014-12-03 16:59 GMT-02:00 Evandro Nunes: 2014-12-03 15:12 GMT-02:00 Otavio Augusto: [...] por isso insisto, cade freebsd pra mips? pra arm está bem legal... cade freebsd pra tilera? http://svnweb.freebsd.org/base/head/sys/mips/ :-) Embora o MIPS funcione bem no free com o suporte que veio da Juniper (bem estável por sinal), não há desenvolvedores ativos suficientes para manter o suporte a todo tipo de hardware disponível, pois no MIPS não existe padrão como no x86, cada placa, placa fabricante podem ser sistemas completamente diferentes, não existe BIOS ou outro sistema de enumeração dos dispositivos e recursos da placa, cada placa precisa de suporte especifico (drivers, mapeamento de recursos no kernel, ...). Que hardware que roda com tilera ? Só mikrotik ? O freebsd tem pouquíssimos desenvolvedores que portam e mantém essas arquiteturas, sem um aporte de alguma parte interessada infelizmente não rola. Os desenvolvedores preferem trabalhar com arquiteturas bem suportadas como o novo arm64/ARMv8 (que deve ser produzido em massa pela HP e Cavium entre outros). http://www.prnewswire.com/news-releases/cavium-to-sponsor-freebsd-armv8-based-implementation-277724361.html Até agora poucos sortudos tiveram acesso ao hardware real baseado nessa plataforma (nenhum desenvolvedor do FreeBSD teve acesso ao hardware até o momento), mas todos que tentaram já viram o FreeBSD bootando no hardware real (até onde é possível, ainda se trata de WIP) baseado no trabalho que esta sendo feito com o emulador fornecido pela ARM. E isso foi trabalho de 1 desenvolvedor: http://svnweb.freebsd.org/base/projects/arm64/ O arm64 tem ACPI e UEFI e vai se parecer bastante com o x86, por isso todo mundo esta de olho. Agora o FreeBSD/ARM tem até suporte a guest XEN (que esta sendo integrado com o pessoal da citrix). ARM caminha para se tornar uma arquitetura tier 1 no FreeBSD (mesmo com o baixo número de desenvolvedores ativos). ou seja o freebsd tem que seguir evoluindo nessas archs os commiters da lista devem saber se esses 2 milhões que a foundation ja arrecadou esse ano, o quanto desse esforço está destinado a financiar melhorias em mips e arm por exemplo A fundação trabalha em várias frentes, apoiando desenvolvimentos específicos, se aproximando dos fabricantes, conseguindo documentação para os desenvolvedores e também fomentando a comunidade (com os eventos por exemplo) para atrair mais gente e consequentemente mais desenvolvedores. Luiz - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Intencionalmente derrubando desempenho de CPU.
2014-11-05 23:40 GMT-02:00 Joao Rocha Braga Filho: Dando uma pesquisada no powerd descobri algumas coisas interessantes. Tem como diminuir o clock do processador à mão. Com o seguinte comando vi o clock atual e as possibilidades: root:[748] sysctl -a | grep dev.cpu...freq dev.cpu.0.freq: 1093 dev.cpu.0.freq_levels: 2500/30940 2187/27072 1875/23205 1562/19337 1250/18480 1093/16170 Note que já reduzi ao mínimo. Como fiz isto? Assim: root:[747] sysctl dev.cpu.0.freq=1093 dev.cpu.0.freq: 1093 - 1093 Joao, Existem duas partes trabalhando juntas aqui para fazer isso funcionar. A primeira é baseada no cpufreq(4), uma interface definida no FreeBSD para exportar as funcionalidades relacionadas a controle de clock da CPU (freqüências suportadas, freqüência atual e a possibilidade de setar a freqüência para um novo valor) e isso de uma maneira independente da tecnologia, marca ou modelo da CPU. A segunda parte é o powerd(8), um daemon que captura as informações relevantes do seu sistema para ajustar dinamicamente a freqüência da CPU (utilizando as funções exportadas pelo cpufreq(4)). Então, para um ajuste manual, apenas o suporte do cpufreq(4) é o bastante para que você possa configurar a freqüência da CPU 'na mão ' via sysctl(8). Já o powerd(8) vai tentar fazer as coisas por você de acordo com o perfil que você selecionar. O uso de C-states (citado em outra resposta) aumenta a latencia do sistema (o tempo que leva entre uma interrupção e a respectiva resposta do sistema), mas pode ser interessante quando tudo o que se quer é economia. Como verifiquei se funcionou? Pelo top, vendo o tempo de idle diminuir, pelo barulho do ventilador de CPU diminuir, e pela temperatura do processador cair mais de 10 graus C. root:[749] sysctl -a | grep dev.cpu...temperature: dev.cpu.0.temperature: 47,0C dev.cpu.1.temperature: 47,0C dev.cpu.2.temperature: 47,0C dev.cpu.3.temperature: 47,0C Em geral o meu computador já tem desempenho mais do que o suficiente para o meu dia a dia. Eu gostaria de ter mais memória. O powerd parece fazer besteira, pois parece não entender que se tratam de 4 núcleos. Não foi porque você setou manualmente a freqüência da cpu 0 ? Eu também brinquei um pouco de parar HDs: root:[773] atacontrol spindown ad8 60 root:[774] atacontrol spindown ad8 ad8: spin down after 60 seconds idle Bibliografia: https://forums.freebsd.org/threads/howto-freebsd-cpu-scaling-and-power-saving.172/ man pages. Será que vou baixar a conta de luz? Provavelmente... se você rodar tempo suficiente usando um perfil bem econômico. Se o valor vai ser perceptível na conta é outra conversa. Um micro comum (básico) gasta cerca de R$ 40,00 por mês de energia (ligado 24 x 7), talvez você consiga reduzir um pouco esse valor. Agora se você quer economia de verdade e caso seja possível para o seu perfil de uso, mude seu 'home' server pra ARM ou MIPS e veja o consumo cair para um decimo do que você usa hoje (consumo aproximado de 5W - tenho uma RPi no alarme de casa que no ultimo teste rodou mais de 6 horas numa bateria de 12V 7Ah). Att., Luiz - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Valor aconselhavel para variável HZ
2014-11-06 12:29 GMT-02:00 Eduardo Schoedler: 2014-11-06 11:55 GMT-02:00 Paulo Henrique - BSDs Brasil paulo.rd...@bsd.com.br: Pessoal, pelo que compreendi, quanto mais alto o valor do HZ, mais rápido o sistema vai responder requisições de tarefas do kernel e do hardware. Embora como negativamente menor será o tempo disponível para limpar a sujeira de outro processo. Diminui a latência da rede e o tempo de resposta a uma requisição. Nesse sábado vou fazer uns testes aumentando o hz o máximo possível e ver como será o comportamento do sistema, depois posto os resultados. Contudo estou na dúvida de como fazer para verificar isso, o unixbench seria uma alternativa? Se não estou enganado, o aumento de HZ auxilia também no shaping, pois há maior quantidade de ciclos. O HZ em geral diminui a latencia, pois como seu processo vai rodar mais vezes por segundo as chances de você atender uma interrupção mais rapidamente aumenta. Porém há um tradeoff que você precisa analisar aqui, pois o context switch é um processo lento e caro para o sistema, então a performance não escala na mesmo proporção que você aumenta o HZ (chega um momento onde sua CPU vai estar mais ocupada fazendo context switch do que trabalhando com seus processos). Por isso em aplicações onde o context switch é ainda mais dispendioso para o sistema (como em guest virtualizados), diminuir o HZ ajuda. Att., Luiz - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Valor aconselhavel para variável HZ
On 6 November 2014 12:13, Fabricio Lima wrote: + ab (apache bench) Lembrando q para maquinas virtuais, reduzem este parametro. Correto. Veja isso tb: However, in FreeBSD 9, the dynamic tick mode (aka tickless mode) is the default, controlled by the kern.eventtimer.periodic setting which defaults to 0 (read: tickless mode). This year FreeBSD 10-HEAD got a new reincarnation of the kernel event timers backend callout(9) https://www.freebsd.org/cgi/man.cgi?query=calloutsektion=9, no more limited by or even related to Hz rate. FreeBSD head é o 11 :) E essa alteração não tem relação direta com o valor do HZ. callout(9) é só uma implementação de timers utilizada no kernel, que antes se baseava no valor do HZ para os cálculos (internos) de timeout. Ex.: execute a seguinte rotina/função após 0.5 segundos. Nesse caso o tempo era convertido em ticks levando em conta o valor de HZ do sistema. Isso era simples mas limitava o menor tempo 'util' para 1 tick (se HZ = 100, 1 tick = 1 seg / 100, se HZ=1000, 1 tick = 1 seg / 1000, ...). O novo sistema de callout é mais preciso, permite o uso de frações de tempo muito pequenas e por isso o valor de HZ do sistema não serve mais para descrever esses pequenos valores. O tickless ajuda na ecomonia. Ative o periodic e veja a diferença com o systat -vm 1. No tickless o sistema só acorda quando existe alguma coisa para ser feita (mesmo com alto valor de HZ) e com o periodic o interrupt handler do timer vai rodar na freqüência determinada por HZ (em geral um desperdício - esse knob so existe para contornar bugs em determinados chipsets). Att., Luiz - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] queues pf.conf - estatísticas
2014-11-04 14:53 GMT-02:00 Fabricio Lima: psiuuu vou falar baixo pra ninguem me escutar... mas ate hj nunca consegui aprender a carregar uma MIB.. simplesmente nao entendo estes arquivos malditos. mas neste link tem as MIB pro pf, por isso vc nao achou, nao está nativamente ai. http://svnweb.freebsd.org/base/head/usr.sbin/bsnmpd/modules/snmp_pf/ Para ativar esse modulo você precisa remover os comentários em /etc/snmpd.config: # # pf(4) module # begemotSnmpdModulePath.pf= /usr/lib/snmp_pf.so E ativar o bsnmpd no /etc/rc.conf. Att., Luiz - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Baixa performance de roteamente com Xenserver
2014-10-27 9:52 GMT-02:00 Diogo Dalfovo: Bom dia pessoal, Estou fazendo alguns testes com FreeBSD no Hyper-v, Vmware e Xenserver ate aqui tudo certo. Estou testando FreeBSD 10.0-RELEASE e agora fiz upgrade para 10.1-RC3 e com PFsense 2.2. Bom, testes com Hyper-v e Vmware os testes ocorreram de madeira satisfatória com melhor desempenho e estabilidade com Vmware. Fazendo o mesmo teste com Xenserver apesar de ele não ser suportado oficialmente ate o momento, ele se mostrou ate com mais disposição em determinados testes, porem, tem um que esta me deixando encubado. ??? O xen é suportado sim e, inclusive, esta sendo ativamente desenvolvido para suportar dom0. Teste bem simples de roteamento não passa de alguns kbits, coisas simples. Teste de ping bem baixos, porem com TCP e UDP não vai. E o teste é simples apenas uma rede tentando acessar a outra com iperf, netperf e ping: rede (A.1) - (A.2) Router FreeBSD (B.2) - rede (B.1) Sem nat, regras de firewal, nada simplesmente um route add e a comunicação não passa de kbits. Para tirar a prova, fiz a mesma coisa so que no lugar do FreeBSD coloquei um Linux e o trafego passou para 2G. Alterei forwarding para fastforwarding e nada. Atualizei para RC3 e também nenhuma melhora, fiz varios tunnings no Xenserver também não ajudaram. Alguém ja teve essa experiencia? E isso so acontece no Xenserver e so nesta ocasião. Você esta rodando o xen em que modo ? Que placa de rede detectou na vm ? Eu não tenho ambiente aqui pra testar isso, mas por favor mande uma mensagem descrevendo seu problema para freebsd-net@ e coloque em cópia o royger@. E a menos que alguém te ajude rápido por lá não deixe de abrir um PR com a descrição do seu cenário e do problema que você esta vendo. Obrigado, Luiz - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Problemas com ARP kernel: arp: unknown hardware addressformat (0x1100)
2014-10-15 10:49 GMT-03:00 Edinilson - ATINET: Prezados, bom dia! Tenho recebido diversas mensagens de ARP com esse erro abaixo, mas nao estou conseguindo identificar o problema na minha rede. Alguem sabe como me ajudar? Oct 13 01:50:45 rblive kernel: arp: unknown hardware address format (0x1100) (from 45:00:00:94:d2:7c to 9b:a5:00:00:00:00) Oct 13 02:26:26 rblive kernel: arp: unknown hardware address format (0x1100) (from 45:00:00:84:33:bb to 6a:0f:00:00:00:00) Oct 13 21:43:29 rblive kernel: arp: unknown hardware address format (0x1100) (from 45:00:00:3c:41:71 to 6e:2f:00:17:10:a7) Oct 13 21:43:29 rblive kernel: arp: unknown hardware address format (0x1100) (from 60:00:00:00:00:14 to 90:44:00:8e:01:be) Oct 13 21:59:39 rblive kernel: arp: unknown hardware address format (0x1100) (from 45:00:00:28:68:47 to 51:3a:41:43:41:43) Oct 13 23:02:21 rblive kernel: arp: unknown hardware address format (0x1100) (from 45:00:00:34:55:c5 to 28:2e:00:08:4d:69) Oct 13 23:02:21 rblive kernel: arp: unknown hardware address format (0x1100) (from 45:00:00:74:48:d3 to 95:d3:63:65:3a:31) Oct 14 00:43:30 rblive kernel: arp: unknown hardware address format (0x1100) (from 45:00:00:74:f9:0d to d9:eb:35:2e:31:3a) Oct 14 01:15:02 rblive kernel: arp: unknown hardware address format (0x1100) (from 45:00:00:34:df:85 to 43:e4:2e:32:35:30) Oct 14 04:36:07 rblive kernel: arp: unknown hardware address format (0x1100) (from 45:00:05:3c:02:ad to fe:8c:ac:e2:c5:6b) Ja tentei identificar com tcpdump, mas nao consegui. Encontrei até uma mensagem antiga na lista freebsd-stable orientando como fazer, mas não resolveu. http://lists.freebsd.org/pipermail/freebsd-stable/2007-January/032530.html Ja tive este problema aqui (e ainda ocorre as vezes) e, pelo que percebi aqui pode ser: 1o) Alguma placa de rede de sua rede com defeito e enviando frames com erros. É dificil de encontrar qual é a bendita. SE estiver com tempo, um tcpdump -p -i SUA-PLACA arp as vezes pode indicar qual é a placa (o erro aparece logo apos varias requisicoes de arp who-has .); Precisa usar mais verbose no tcpdump pra ver o conteúdo completo do pacote: # tcpdump -xxvvnei ifname arp Um ciclo normal (arp request e reply) se parece com isso aqui: 11:11:43.428875 e8:40:f2:c2:98:00 ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.0.55 tell 192.168.0.10, length 28 0x: e840 f2c2 9800 0806 0001 0x0010: 0800 0604 0001 e840 f2c2 9800 c0a8 000a 0x0020: c0a8 0037 11:11:43.430530 b8:27:eb:58:ee:51 e8:40:f2:c2:98:00, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Reply 192.168.0.55 is-at b8:27:eb:58:ee:51, length 46 0x: e840 f2c2 9800 b827 eb58 ee51 0806 0001 0x0010: 0800 0604 0002 b827 eb58 ee51 c0a8 0037 0x0020: e840 f2c2 9800 c0a8 000a 0x0030: ^C O número que você precisa procurar esta na ultima coluna na primeira linha, é esse valor que descreve o tipo de hardware e os tipos de endereços utilizados no request/reply. O valor '0001' corresponde a 'ethernet'. O FreeBSD esta dizendo que existem pacotes com o valor '1100', coisa que não devia acontecer (numa rede ethernet). Se você conseguir um pacote desses, por favor encaminhe para nós (pode conter mais informações sobre a origem do pacote). Isso pode ser uma placa ou switch problemático enviando pacotes corrompidos para a rede ou simplesmente um protocolo diferente (proprietário?). A forma de identificar a origem desses pacotes é pelo MAC address de onde eles estão partindo e o problema é que se for uma placa enviando pacotes corrompidos o MAC address também pode estar errado e se for um protocolo proprietário ele também pode usar um MAC address que não o original da placa... ai so mesmo desligando equipamento por equipamento para encontrar de onde os pacotes estão vindo. 2o) Protocolos que não IP trafegando na rede. Um exemplo é o IPX, que algum maluco ainda ativa em alguma maquina (este é facil de pegar com um tcpdump -p -i SUA-PLACA ipx). Não, não se trata desse tipo de protocolo, é um sub-tipo do protocolo ARP. O ARP por si é um protocolo como o IPX e no FreeBSD o pacote já foi decodificado com um pacote ARP (o valor '0806' na sétima coluna identifica o protocolo). Por isso precisamos de um pacote completo para ver do que se trata. Porem, de um modo geral, é um erro que só é informativo e não causa maiores transtornos. Isso mesmo, é só um pacote não reconhecido (um ARP para um endereço não ethernet numa rede ethernet) e vai ser descartado. Luiz - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Comportamento estranho do ntp no FreeBSD-10.1-PRERELEASE
2014-09-16 10:06 GMT-03:00 Eduardo Lemos de Sa: Oi Paulo 2014-09-15 20:13 GMT-03:00 Paulo Cavalcanti: Em 15 de setembro de 2014 16:23, Eduardo Lemos de Sa eduardo.lemosd...@gmail.com escreveu: [...] Eu resolvi fazer um teste: sudo /etc/rc.d/ntpd stop sudo date 1600 (atrasei deliberadmente o relógio em 4 minutos) sudo /etc/rc.d/ntpd onestart (depois eu fiz uma outra tentativa e troquei o onestart por um restart) e o horário na máquina local não mudou (se adiantou em 4 minutos). Não satisfeito, fiz um reboot (é a minha máquina desktop) e nada (de melhor) aconteceu. No dmesg não aparece qualquer menção de que o horário foi modificado. Por favor, alguém tem alguma ideia de como descobrir o porquê do erro? Procure também no /var/log/messages alguma coisa referente a ntp. Faça um dig 0.freebsd.pool.ntp.org e veja se está resolvendo. Se me lembro bem o ntp tem uma tolerância de 1000 segundos de atraso, fora isso ele não sincroniza. Experimente atrasar o relógio em 600 segundos, por exemplo. Obrigado pela atenção. Sim, o tempo máximo de ajuste é de 1000 segundos, mas eu atrasei o relógio em 4 minutos (240 s), o que deveria ser suficiente. Eu fiz um dig no 0.freebsd.pool.ntp.org. Parece que está tudo certo. Por favor, veja: Ola Eduardo, O limite de 1000s inicial do ntp pode ser desabilitado adicionando 'ntpd_sync_on_start=YES' no seu /etc/rc.conf. Com essa alteração o ntpd vai corrigir o horário mesmo quando o relógio esta errado bem além desse limite de 1000s. Geralmente quando o ntpd não acerta o horário é porque ele não esta conseguindo sincronizar com os servidores (isso aconteceu recentemente comigo pois meu provedor bloqueou todos pacotes na porta 123 por conta de ataques DoS). Utilize o ntptime para verificar o status do ntpd: % ntptime ntp_gettime() returns code 0 (OK) time d7c2fef9.42d0e548 Tue, Sep 16 2014 15:24:57.261, (.261000372), maximum error 996836 us, estimated error 25764 us, TAI offset 0 ntp_adjtime() returns code 0 (OK) modes 0x0 (), offset 3615.118 us, frequency 31.199 ppm, interval 1 s, maximum error 996836 us, estimated error 25764 us, status 0x6001 (PLL,NANO,MODE), time constant 10, precision 0.001 us, tolerance 496 ppm, Esse é o status de um servidor com o ntp sincronizado (verifique os dois OKs no ntp_gettime() e ntp_adjtime()). E abaixo segue o status de um servidor onde o ntp esta bloqueado: # ntptime ntp_gettime() returns code 5 (ERROR) time d7c2cbe0.8b0c561c Tue, Sep 16 2014 11:46:56.543, (.543157550), maximum error 943516 us, estimated error 16 us, TAI offset 0 ntp_adjtime() returns code 5 (ERROR) modes 0x0 (), offset 0.000 us, frequency 13.402 ppm, interval 1 s, maximum error 943516 us, estimated error 16 us, status 0x2040 (UNSYNC,NANO), time constant 0, precision 0.001 us, tolerance 496 ppm, Além dos erros o campo status também tem a flag 'UNSYNC'. Rode um tcpdump na sua interface e veja se há respostas dos servidores, aqui no caso do server bloqueado só há tx e nada de rx. # tcpdump -nei XXX port 123 Att., Luiz - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] ARMv6 FreeBSD na beaglebone 5v
2014-07-17 16:47 GMT-03:00 Evandro Nunes: luiz e patrick boa tarde muito legal esses testes e essas mudanças eu estou usando snapshots nao criei nenhuma imagem minha ainda tem snapshot do 11-current armv6? se eu for fazer minha imagem, como faço? luiz entendi que tem algo novo mas não como usar, se você pudesse reproduzir so a parte relevante desse codigo do site beagleboard.org em shell script eu agradeco muito rsss outra coisa que não quer calar é como eu leio um valor de um pino que esteja em modo IN? gpioctl é o flags? não né? tem sample code em C pra isso caso não tenha um utilitário tipo gpioctl pra ler? Desculpe a demora, eu fiquei longe da minha BBB por algum tempo :/ As imagens oficiais (para as versões 10 e 11) podem ser encontradas em: ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/arm/armv6/ISO-IMAGES Para fazer sua própria imagem o caminho é com o crochet: https://github.com/kientzle/crochet-freebsd E ai você pode seguir algum tutorial como esse aqui: http://www.onemansanthology.com/blog/freebsd-on-beaglebone-black/ Para utilizar um servo, você pode conectar o servo de acordo com esse diagrama: https://learn.adafruit.com/controlling-a-servo-with-a-beaglebone-black/wiring E na BBB você vai configurar assim o PWM2 (que tem saída A no pino 21 e saída B no pino 13 do conector P8): sysctl dev.am335x_pwm.2.freq=50 E ai ajustar a posição do servo com: sysctl dev.am335x_pwm.2.duty[A|B]= (dutyA para a saída A e dutyB para a saída B - você pode controlar 2 servos com cada modulo PWM). Para saber onde estão os pinos na BBB utilize a tabela do wiki: https://wiki.freebsd.org/FreeBSD/arm/BeagleBoneBlack O driver do PWM foi atualizado (e testado com servos) no 11 e no 10-stable. Acho que você já conseguiu ler o valor do pino, mas se ainda não conseguiu o valor dele aparece na ultima linha do gpioctl(8): # gpioctl 14 0/14 1 # gpioctl 3 0/3 0 Nesse caso o pino 14 retornou 1 e o pino 3 0 (zero). Ou o valor que lê logo a frente do pino no caso do gpioctl -l: [...] pin 08: 0 gpio_8IN pin 09: 0 gpio_9IN pin 10: 1 gpio_10IN [...] Vou mandar um exemplo para manipulação em C na thread do HC-SR04. Att., Luiz - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Erro sonewconn
On 26 August 2014 10:55, Jorge Petry - BSD wrote: Bom dia pessoal. Alguém ja passou por esse tipo de erro? Estão aparecendo nos logs e dmesg. Possuo 02 Servers com Freebsd 10-RELEASE rodando jails e aparece nos 2. sonewconn: pcb 0xf80265003dc8: Listen queue overflow: 151 already in queue awaiting acceptance sonewconn: pcb 0xf80177664188: Listen queue overflow: 8 already in queue awaiting acceptance sonewconn: pcb 0xf80177664188: Listen queue overflow: 8 already in queue awaiting acceptance sonewconn: pcb 0xf80265003dc8: Listen queue overflow: 151 already in queue awaiting acceptance sonewconn: pcb 0xf80265003dc8: Listen queue overflow: 151 already in queue awaiting acceptance Jorge, Isso pode acontecer quando o daemon/programa recebe muitas conexões e não consegue aceitar todas as conexões que estão na fila. O tamanho dessa fila pode ser configurado durante a configuração do socket pelo listen(8) (backlog) até o tamanho máximo que é o sysctl kern.ipc.somaxconn (128 por padrao). Espero que ajude a identificar o problema ai. Luiz - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] ARMv6 FreeBSD na beaglebone 5v
2014-07-15 10:34 GMT-03:00 Evandro Nunes: sim, estou assistindo a um curso no youtube excelente, ja consigo ler esquematicos agora apesar de não ter decorado todos os simbolos, e em especial não decorar as cores dos aneis nos resistores mas tudo ficou claro dentro desse assunto me digam o seguinte quero fazer isso em shell script: http://beagleboard.org/Support/BoneScript/ServoMotor/ no trecho: var duty_cycle = (position*0.115) + duty_min; b.analogWrite(SERVO, duty_cycle, 60, scheduleNextUpdate); o duty_cycle é o dutyA ou dutyB nas sysctl do freebsd? o period é o 200? equivalente a: // call updateDuty after 200ms setTimeout(updateDuty, 200); posso por então o period do PWM em 200 e o dutyA (ou B?) em (position*0.115) + duty_min num shell script? Cada modulo de PWM tem duas saídas que são nomeadas de PWM1A e PWM1B para o modulo 1 e PWM2A e PWM2B para o modulo 2. Como a freqüência do PWM é configurada por modulo as saídas A e B vão operar na mesma freqüência mas podem ter ciclos de trabalho diferentes (por exemplo: frequência PWM 100Khz, saída A 20% e saída B 60%). Assim são 2 módulos PWM e 4 saídas. O pino 14 do conector P9 corresponde a saída A do PWM1 (conforme https://wiki.freebsd.org/FreeBSD/arm/BeagleBoneBlack). No caso do servo, o duty cycle não são os 200ms, esse valor é o tempo no qual a saída do PWM é atualizada (a cada 200ms ela tem um novo valor). O período é calculado através da freqüência que nesse caso é o '60' passado no analogWrite(). O 60 corresponde a 60Hz (servos RC operam entre 50~60Hz). O PWM da BBB não funcionava com freqüências tão baixas (antes o mínimo era 1.525kHz) até a r266937 quando corrigi isso. Como ainda não fiz o MFC você só vai conseguir utilizar servos com o -current (que tem 2 sysctls a mais - clockdiv e frequency). Com essa sysctl 'frequency', você pode setar ela diretamente pra 60 e depois só precisa alterar o duty cycle (A ou B dependendo da saída que você estiver utilizando) para movimentar o servo. Como teste eu liguei um potenciometro em uma das entradas analógicas e um programa em C lendo esse valor e alterando o duty cycle do PWM, assim o servo acompanhava o movimento conforme o movimento que era feito no potenciometro. Luiz - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] ARMv6 FreeBSD na beaglebone 5v
2014-07-11 16:41 GMT-03:00 Evandro Nunes: luiz entendi, era meu receio e como eu vou ativar a bobina de um relé de 5v? será que a cubie tem gpio de 5v? outra coisa o que é o HIGH e o LOW no freebsd? é o PU PD via gpioctl? na cubie o sata está funcional? luiz tem outros utilitários fora o gpioctl que eu possa brincar com a placa? Eu adicionei dois circuitos que você pode utilizar para acionar reles a partir dos 3.3V aqui: https://wiki.freebsd.org/FreeBSD/GPIO-hardware Todas essas placas recentes funcionam com 3.3V, você vai precisar construir um circuito para acionar o relê ou comprar algo pronto como o Patrick indicou (também tem muita coisa compatível com arduino que funciona com 3.3V). O HIGH e LOW seguem os padrões, são representados pelos valores 1 e 0. O PD é o pull-down e o PU é o pull-up. Eles são utilizados geralmente quando os pinos são configurados como entradas, ai acionando o pull-up ou o pull-down (que é o equivalente a adicionar um resistor de ~100K nessa função) evita que o pino fique flutuando, sendo possível nesse caso, se conectar um push button sem qualquer outro componente adicional (o pull-up configurado e o push button ligado entre o pino GPIO e o terra. Nesse caso o pino recebe o valor 1 com o botão aberto e 0 com o botão pressionado). Você pode também ler o valor das entradas analógicas na BBB (cuidado! máximo de 1.8V para as entradas analógicas) . Veja mais detalhes no manual do adc: ti_adc(4). Com o PWM você pode controlar servos, gerar tensões analógicas, ajustar a luminosidade de LEDs... Me parece que a interface SATA ainda não funciona na cubieboard, os drivers estão comentados no kernel (mas ainda não tive a oportunidade de testar nenhuma cubieboard). Luiz - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] ARMv6 FreeBSD na beaglebone 5v
2014-07-11 19:06 GMT-03:00 Evandro Nunes: otavio como isso vai funcionar? vai puxar mais corrente ou a conversão pra subir 1.2v vem do 3.3v? quero dizer estamos falando de amperagem ou voltagem na origem pra conseguir ter maior voltagem no resultado? desculpe a ignorancia, ela é bem grande mesmo quando se trata de transitors e cia rsss pra eu saber como disseram aqui na lista se fazendo isso corro risco de matar a placa e qual será a corrente desses 5.5v? Veja os circuitos que publiquei no wiki, você precisa de uma segunda fonte de alimentação na mesma tensão do relê que você vai alimentar (5~12V) e o transistor ou o opto-acoplador se encarregam de alimentar o relê na presença dos 3.3V no pino GPIO. O mais seguro é o opto-acoplador, com ele sua placa fica eletricamente isolada da sua segunda fonte e o risco de você danifica-lá é muito baixo. Nos dois circuitos, com o transistor utilizado (BC548 ou compatível) você pode chavear até 100mA (suficiente para a bobina dos relês). Com os circuitos que publiquei (que são testados), sem ligar seus pinos a tensões diferentes de 3.3V e sem coloca-los em curto-circuito você não vai queimar sua placa. Na duvida consulte alguém de sua confiança e você não terá problemas. Luiz - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] ARMv6 FreeBSD na beaglebone 5v
2014-07-11 15:05 GMT-03:00 Evandro Nunes: ola com gpioctl eu consigo ligar/desligar o P9_5 e o P9_6 na BBBlack? se sim ou com outro comando, qual é e qual é o pino na saida do gpioctl -l que é fisicamente o P9_5? posso somar 32 ao 5 e seria o pino 37 no free? http://insigntech.files.wordpress.com/2013/09/bbb_pinouts.jpg Não é possível Evandro, o pino 5 e 6 no P9 são conectados diretamente ao 5V da entrada da placa - VDD_5V (conector P4). Esses pinos não tem energia quando a placa é alimentada pela USB. Os pinos 7 e 8 (SYS_5V) são conectados depois do PMIC (podem ser desligados junto com a placa através do botão power) e sempre tem energia independente do tipo de energia aplicada na placa (conector P4 ou USB). O esquema da BBB esta disponível em PDF e ajuda a esclarecer esses detalhes. Utilize a referencia do wiki (https://wiki.freebsd.org/FreeBSD/arm/BeagleBoneBlack) para saber quais pinos você pode utilizar e quais são reservados no FreeBSD. Todos os pinos gpio_xx você consegue controlar com o gpioctl(8), a única diferença é que eles operam em 3.3V (e não toleram 5V!!!). Você pode converter a tensão utilizando buffers, transistores ou conversores de níveis (a philips tem um AN sobre isso para I2C). Att., Luiz - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] [OFF-TOPIC] Erro em documentação
2014-05-16 10:45 GMT-03:00 Renato Botelho: On Friday, May 16, 2014 03:10:06 AM tridente 1 wrote: O último exemplo da utilização do comando crontab em http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/configtuning-cron .html está incorreto. Lê-se: To remove all of the cron jobs in a user crontab: % crontab -lremove crontab for dru? y Ele deve ser: To remove all of the cron jobs in a user crontab: % crontab -rremove crontab for dru? y É uma prática muito antiga dos sistemas BSD colocar easter eggs como esse em toda a documentação. Como você foi a pessoa que encontrou esse, pode passar lá no escritório central do FreeBSD e retirar seu brinde surpresa. Parabéns!!! :) Olha, essa foi tão boa que eu estou levando o brinde dele, um boné da FreeBSD Foundation (sério). Comprei dois ontem e vou dar um pro trident. trident, entra em contato comigo e me passa seu contato para que eu possa providenciar a entrega pra você. -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] [OFF-TOPIC] Erro em documentação
2014-05-16 12:12 GMT-03:00 Marcelo Gondim: Em 16/05/14 11:38, Luiz Otavio O Souza escreveu: 2014-05-16 10:45 GMT-03:00 Renato Botelho: On Friday, May 16, 2014 03:10:06 AM tridente 1 wrote: O último exemplo da utilização do comando crontab em http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/configtuning-cron .html está incorreto. Lê-se: To remove all of the cron jobs in a user crontab: % crontab -lremove crontab for dru? y Ele deve ser: To remove all of the cron jobs in a user crontab: % crontab -rremove crontab for dru? y É uma prática muito antiga dos sistemas BSD colocar easter eggs como esse em toda a documentação. Como você foi a pessoa que encontrou esse, pode passar lá no escritório central do FreeBSD e retirar seu brinde surpresa. Parabéns!!! :) Olha, essa foi tão boa que eu estou levando o brinde dele, um boné da FreeBSD Foundation (sério). Comprei dois ontem e vou dar um pro trident. trident, entra em contato comigo e me passa seu contato para que eu possa providenciar a entrega pra você. LooS me passa o link da compra do boné que fiquei interessado. :D Hey Gondim :) Então não achei um link para esses produtos, eu comprei aqui na BSDCan direto com um dos caras da Foundation (funciona meio que como uma doação pra fundação). Vou perguntar se eles tem como vender isso direto. []'s Luiz - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Mysql comendo toda swap
2014-05-15 3:54 GMT-03:00 Fernando Gilli: O Fernando nunca comentou qual versão ele esta rodando, por isso não comentei antes, mas existe um bug no 10-RELEASE que faz uso agressivo da swap mesmo quando não necessário (mesmo com memória livre disponível). É preciso atualizar ao menos para a r265886 para ter esse problema corrigido. Att., Luiz Mesmo setando o table_open_cache menor, de uma hora para outra ta tudo travado. É a segunda vez que acontece isso, estoura a swap trava tudo, só rebotando, e com medo rodando um fsck kernel: swap_pager: indefinite wait buffer: bufobj: 0, blkno: 42054, size: 4096 kernel: swap_pager: indefinite wait buffer: bufobj: 0, blkno: 11271, size: 61440 kernel: swap_pager: indefinite wait buffer: bufobj: 0, blkno: 26643, size: 61440 kernel: swap_pager: indefinite wait buffer: bufobj: 0, blkno: 21722, size: 61440 é possivel aplicar o svn só para o r265886? ou esse erro é badblock? Não recomendo aplicar somente a correção dessa revisão (embora você possa tentar), acho mais tranquilo atualizar seu sistema para o 10-stable que também vai te trazer correções para outros problemas. Quanto ao erro, ele acontece quando o sistema esta fazendo a leitura de paginas do swap, então provavelmente indica algum erro no disco (timeout de leitura). Att., Luiz - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Mysql comendo toda swap
2014-05-12 11:37 GMT-03:00 Eduardo Schoedler: Em 12 de maio de 2014 02:18, Fernando Gilli escreveu: O tuning melhorou bastante.. total used free sharedbuffers cached Mem: 491199292 0 0 4 Swap: 1024 7 1016 Certamente você estava alocando mais memória do que podia ;). O Fernando nunca comentou qual versão ele esta rodando, por isso não comentei antes, mas existe um bug no 10-RELEASE que faz uso agressivo da swap mesmo quando não necessário (mesmo com memória livre disponível). É preciso atualizar ao menos para a r265886 para ter esse problema corrigido. Att., Luiz - 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 10
2014-05-12 10:57 GMT-03:00 Marcelo Gondim: Em 12/05/14 09:34, Márcio Luciano Donada escreveu: Senhores, bom dia Como você estão atualizando o FreeBSD nessa versão 10? Através do freebsd-update ou via svn e compilando o sistema todo? Opa Marcio, Aqui em todos os servidores eu compilo o sistema userland + kernel e ainda os programas de terceiros (ports). Uso a árvore stable com cuidado, quer dizer que só atualizo quando preciso de algo que antes não funcionava ou quando tem alguma atualização de segurança. :) A última atualização que fiz foi esses dias para 10.0-STABLE revisão 265408 que inclusive já corrige o problema dos processos sshd zumbi que brotam quando você faz muito acesso remoto. O risco do STABLE, ao meu ver, são os MFCs (Merge From Current) que são coisas que podem dar um problema, mas sinceramente nunca tive problema com eles que me afetasse. :) Por isso o branch é chamado de 'stable' :) Desenvolvimento só no -head a ai só vai para o -stable o que já esta testado, claro que podem haver problemas não previstos (interação com outras partes do sistema que foram alteradas no -head), mas geralmente o stable é bem seguro. Por outro lado como eu só uso o -stable, sou suspeito para comentar :) Att., Luiz - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Desativar cache de disco
2014-05-06 12:28 GMT-03:00 Paulo Henrique - BSDs Brasil: [...] Valeu Marcelo, o chipset da placa é um X58 ( PCIe 2.0 ) o que daria 500MB/s, estou meio pé atrás com a controladora ela parou de perder a localização dos discos no bus mais ainda não atige a velocidade equiparável a outro servidor com a mesma placa, embora que tenha a ver pelo fato dos outro servidor não ser HDs da WD e sim da Seagate. A controladora é uma LSI MPT C1068E ( não tem nenhuma firmware no site do fabricante ) Os HDs no servidor com problemas é WD serie Green de 2TB com 64Mbs de cache configurados em gmirror+gstripe em raid 10 no outro servidor só muda os discos que são Seagate de 3TB ( reconhecendo apenas 2 TB por limitação da controladora ) e nele chego a atingir até 190MB/s . HDs da série 'green' em geral são incompatíveis com o uso para servidores. Eles são voltados ao mercado desktop e geralmente ficam mais do lado da economia de energia do que do lado da performance (o oposto do que se espera em servidores). Se puder faça também o teste de leitura direto do disco (sem usar o gmirror+gstripe) e veja se há alguma diferença. Att., Luiz - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Erro de configuração: Apache?
2014-04-30 13:42 GMT-03:00 Prof. João Henrique: Olá a todos. Não sei se é exatamente off-topic. Se for, peço que me desculpem. Escrevo pois preciso de opiniões que reforcem ou refutem um laudo. Quando um endereço fictício, como www.aleluia.com.br/livro/ apresenta normalmente o conteúdo, mas ao digitar www.aleluia.com.br/livro o retorno é um erro 404, em qual SOFTWARE estaria o erro de configuração? Suponha que a máquina tenha Apache instalado. Quando se configura um Alias no apache, se você especifica o Alias com a '/' no final você precisa necessariamente utilizar a barra no final para acessar essa URL. Alias /livro/ /usr/local/www/livro - causa o problema Alias /livro /usr/local/www/livro - funciona sem o '/' no final Inclusive isso esta documentado na configuração do apache: # # Alias: Maps web paths into filesystem paths and is used to # access content that does not live under the DocumentRoot. # Example: # Alias /webpath /full/filesystem/path # # If you include a trailing / on /webpath then the server will # require it to be present in the URL. You will also likely # need to provide a Directory section to allow access to # the filesystem path. Att., Luiz - 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 11-CURRENT
2014-04-24 19:12 GMT-03:00 Nenhum_de_Nos: houve evolução no DIR-825 e WR1043ND ? coloquei freebsd no dir e não ficou estável, no 1043 nem consegui gerar imagem que desse nele :( Não muita Matheus, infelizmente :( O meu 1043 continua aqui acumulando poeira (comprei na BSDCan no ano passado e nunca sequer liguei). O problema geralmente é o tamanho da flash que é muito pequena nesses roteadores e qualquer alteração no FreeBSD pode comprometer o tamanho final da imagem. Mas, até onde me lembro, nós arrumamos os problemas da imagem no 1043 e algumas pessoas reportaram sucesso com ele. O seu problema com o DIR-825 era referente ao wifi (ath) não ? Nesse sentido houve alguma evolução recentemente, o Adrian commitou algumas correções que podiam travar a interface wireless no modo AP. A infra-estrutura do port do MIPS é bem estável (mais que o ARM até a pouco tempo), porém há menos gente trabalhando (menos drivers, imagens, instalação, usabilidade em geral). O MIPS é utilizado (e o atual port veio) pela Juniper, NetLogic e agora a bola da vez é a ERL da ubiquiti (que ainda não tenho nenhuma aqui, se alguém tiver acesso e quiser me vender uma podemos conversar :) Luiz - 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 11-CURRENT
On 24 April 2014 15:18, mantunes wrote: http://lists.freebsd.org/pipermail/freebsd-snapshots/2014-April/83.html é serio ? 11.0-CURRENT armv6 BEAGLEBONE: 11.0-CURRENT armv6 RPI-B: posso dar um grito de alegria ?? Sim, estão disponíveis imagens oficiais do 10-stable e do 11-current. Recentemente o suporte SMP no ARM foi declarado estável, então estamos caminhando no sentido de que o ARM venha logo a se tornar uma plataforma tier-1. Ainda há algumas arestas para se tratar, mas quem testar, com certeza vai gostar do que vai ver (estabilidade e bom funcionamento). Att., Luiz - 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 travando quando crio uma vlan
2014-04-10 15:58 GMT-03:00 Marcelo Gondim: Opa e ae LooS, tudo tranquilo? Então, o meu ambiente aqui possui lagg e a vlan em cima desse lagg. Você consegue adicionar o lagg aí pra gente testar? Uma outra coisa que não sei se pode estar influenciando e já até reclamei com a operadora do meu clear channel é que estou precisando cadastrar os mac address dos meus peers que tenho com essa operadora, senão meu router não fala com a outra ponta. Vou dar um exemplo: Opa Gondim, Ontem eu consegui perder o acesso a maquina reconfigurando as interfaces, devo passar no datacenter hoje e ai já dou um retorno de como isso fica com o lagg. []'s Luiz - 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 travando quando crio uma vlan
2014-04-10 15:58 GMT-03:00 Marcelo Gondim: rede 192.168.0.0/24 Router Local iBGP Router Público BGP Internet O Router Local anuncia o prefixo 192.168.0.0/24 para o Router Público BGP. Quando eu crio a vlan no Router Público BGP, a rede 192.168.0.0/24 não chega e não passa mais pelo Router Público BGP. Mas do Router Público eu pingo o Router Local e vice-versa. Gondim, Meu teste aqui foi o seguinte: Router teste --- Router iBGP --- Router Borda (eBGP) No seu ambiente e pela sua descrição você podia verificar se os anúncios do seu Router Local estão chegando no Router Publico e se as rotas necessárias para acesso da rede 192.168.0.0/24 ainda estão na fib. Imagino que no seu Router Local tudo funcione. Não há nenhuma configuração perdida no seu rc.local para essa interface ? Quando você cria a vlan ela aparece sem nenhuma configuração ? Enquanto ela não esta associada a nenhuma interface física seria muito dificil ela gerar algum problema: # ifconfig vlan666 create # ifconfig vlan666 vlan666: flags=8002BROADCAST,MULTICAST metric 0 mtu 1500 ether 00:00:00:00:00:00 nd6 options=29PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL vlan: 0 parent interface: none A tarde vou refazer os testes aqui com lagg. Att., Luiz - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Processos zumbi brotando no sshd - FreeBSD 10.0
Gondim, O kib@ rastreou esse problema: http://lists.freebsd.org/pipermail/freebsd-hackers/2014-April/044921.html É um problema na linkagem do sshd, precisa aplicar esse patch e recompilar o sshd. Na thread tem toda a informação de como foi feito o debug e todos os detalhes do problema. Em alguns dias acredito que essa correção já esteja no 10-stable. Quando puder faz o teste ai e veja se você ja pode ficar livre do walking-dead.sh :) Luiz - 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 travando quando crio uma vlan
2014-04-11 10:32 GMT-03:00 Luiz Otavio O Souza: 2014-04-10 15:58 GMT-03:00 Marcelo Gondim: rede 192.168.0.0/24 Router Local iBGP Router Público BGP Internet O Router Local anuncia o prefixo 192.168.0.0/24 para o Router Público BGP. Quando eu crio a vlan no Router Público BGP, a rede 192.168.0.0/24 não chega e não passa mais pelo Router Público BGP. Mas do Router Público eu pingo o Router Local e vice-versa. Gondim, Meu teste aqui foi o seguinte: Router teste --- Router iBGP --- Router Borda (eBGP) No seu ambiente e pela sua descrição você podia verificar se os anúncios do seu Router Local estão chegando no Router Publico e se as rotas necessárias para acesso da rede 192.168.0.0/24 ainda estão na fib. Imagino que no seu Router Local tudo funcione. Não há nenhuma configuração perdida no seu rc.local para essa interface ? Quando você cria a vlan ela aparece sem nenhuma configuração ? Enquanto ela não esta associada a nenhuma interface física seria muito dificil ela gerar algum problema: # ifconfig vlan666 create # ifconfig vlan666 vlan666: flags=8002BROADCAST,MULTICAST metric 0 mtu 1500 ether 00:00:00:00:00:00 nd6 options=29PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL vlan: 0 parent interface: none A tarde vou refazer os testes aqui com lagg. Gondim, Sem novidades, mesmo com o lagg consigo criar as vlans aqui sem afetar o funcionamento do sistema :/ Luiz - 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 travando quando crio uma vlan
2014-04-07 20:30 GMT-03:00 Marcelo Gondim: Em 07/04/14 18:48, Eduardo Schoedler escreveu: Em 4 de abril de 2014 10:59, Marcelo Gondim: Vou fazer mais testes na madruga de amanhã. O uptime já foi pro saco mesmo ahahahahahahah E aí Godim, como ficou a novela? ;) Rapaz, Olha sinistro viu. Fiz tanta coisa tipo primeiro eu fiz o famoso: ifconfig vlan6 create Olhei a FIB e nada havia mudado, no BGP também não mudou nada. Tentei rodar o /etc/rc e /etc/netstart e também não adiantou. Matei o processo do bgpd e reiniciei e nada. Nos logs também não vi nada Olha, não sei o que pode ser mas por essa eu não esperava mesmo. Outra coisa feia que tá dando também no FreeBSD 10 são as sessões zumbi que estão ficando presas no sshd. A conexão fica como CLOSED, não morre e fica como um processo zumbi. Isso acontece com servidores que tem acessos ssh constantes. Hoje mesmo entrei em um servidor aqui e haviam 10 processos zumbi do sshd. Algumas pessoas relataram que não é só com o sshd que está acontecendo isso não. Parece ser um problema de Kernel. Eu também estou esperando esse acerto e enquanto isso criei um script para matar os processos zumbi e dei o nome de The_Walking_Dead.sh rsrsrsrsr Gondim, Tenho aqui um servidor rodando openbgpd e FreeBSD 10 (pre-release): # uname -a FreeBSD ibgp.xx.com.br 10.0-PRERELEASE FreeBSD 10.0-PRERELEASE #0 r260596M: Tue Jan 14 13:49:15 BRST 2014 r...@ibgp.xx.com.br:/usr/obj/usr/stable-10/sys/GENERIC amd64 # pkg info | grep openbgpd openbgpd-5.2.20121209 Free implementation of the Border Gateway Protocol, Version 4 # bgpctl show Neighbor ASMsgRcvdMsgSent OutQ Up/Down State/PrfRcvd ibgp XX 50 34 0 00:06:45 60/100 Nesse ambiente, adicionar uma VLAN não me criou nenhum problema... Depois atualizei o sistema pra o 10-stable: # uname -a FreeBSD ibgp.xx.com.br 10.0-STABLE FreeBSD 10.0-STABLE #0 r264261: Thu Apr 10 14:46:42 BRT 2014 r...@ibgp.xx.com.br:/usr/obj/usr/stable-10/sys/GENERIC amd64 Criei outra VLAN com o opengbgp rodando e mais uma vez nenhum problema aqui. Deve ter algum detalhe na seu ambiente que causa o problema, mas eu não consegui replicar ele com uma simples instalação do openbgpd no FreeBSD 10. Você consegue replicar esse problema em outro computador ? Eu gostaria de replicar esse problema localmente... Att., Luiz PS: No problema do SSHD você tentou setar a variavel UsePrivilegeSeparation como 'no' no seu sshd_config ? É possível que isso resolva o problema dos processos zumbies (embora não se trate de uma solução e sim de um workaround). - 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 travando quando crio uma vlan
2014-04-04 10:33 GMT-03:00 Eduardo Schoedler: Em 4 de abril de 2014 10:11, Antonio Modesto Amaral Sousa escreveu: Quando o problema acontece você consegue pingar o router pelo IP das outras VLANS? O que acontece com as rotas que estavam na FIB? Esse é um ponto interessante para determinar se realmente é um problema no kernel (uma vez que a interface sobe e funciona) ou no openbgpd. Talvez você também precise abrir um ticket no openbgpd tb, Godim :) Exato, embora eu não tenha certeza do quanto o pessoal do OpenBSD faz questão de manter uma versão portável do openbgpd como já acontece com o openssh. Eu acho que as diferenças são gerenciadas (e feitas) pelo maintainer do port. Seria realmente interessante tentar identificar o que acontece, se o FreeBSD ainda responde, se ele pode receber, transmitir e encaminhar pacotes, se o openbgpd continua enviando os anúncios corretos para os peers, se sua tabela de rotas se alterou... Luiz - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] O instalador do FreeBSD 10.0 é péssimo
2014-03-30 10:33 GMT-03:00 Joao Rocha Braga Filho: 2014-03-30 9:46 GMT-03:00 Renato Botelho: On Dom, 2014-03-30 at 03:44 -0300, Joao Rocha Braga Filho wrote: Acabei de instalar um HD de 1 GB no meu notebook, e resolvi instalar o FreeBSD 10.0. Baixei o CD de instalação, coloquei num CD e fui tentar instalar. Só tive decepção. Estou com saudades do instalador do 8.x. O instalador do CD não presta para nada. Não me deixa fazer os labels como eu quero, e ainda é buguento. O do DVD, do CD Boot Only e do PenDrive são ruins também? Usam o mesmo lixo? Me desculpe João, mas, não é porque você não conseguiu fazer que o negócio é um lixo. Se você desse uma lida em todas as possibilidades que o novo instalador abriu, iria mudar de opinião, o sysinstall cumpriu seu papel, mas era uma caixa de abelhas, ninguém mais tinha motivação pra mexer naquilo. O instalador que me apareceu não tem nenhuma flexibilidade. Ele não permite fazer múltiplos file systems por partição. Não me permite mudar a blocagem nem o número de i-nodes, i.e., mudar os parâmetros do newfs. A sugestão de divisão do disco é ruim, colocando o swap no final do disco, o que degrada o desempenho, pois é a parte mais lenta do disco, de menor taxa de transferência, como ainda provoca muito seek longo, de praticamente o disco inteiro, o que é a pior hipótese. Este que me apareceu não usa o bsdlabel, permitindo somente swap e mais 3 file systems. eu sempre separo em 5, pelo menos: /, /tmp, /usr /var, /home. Na verdade voce não precisa do bsdlabel que é limitado a (se não me engano) 16 slices por instancia (* 4 no caso das partições MBR). O instalador usa GPT por padrão que dobra a capacidade total de slices de 64 para 128. E para o uso de file systems com opções diferenciadas você pode fazer manualmente (o instalador permite que você faça seu particionamento manualmente, monte suas partições para que o instalador termine o processo de instalação. Eu pessoalmente usei pouquíssimas vezes o 'default' sugerido pelo instalador (em partes pelos problemas que você citou). Me apareceu um bug, e várias vezes. As setas não funcionavam para trocar de campo quando entrava na opção de modificar uma configuração. Mas vamos ao seu problema técnico, o que exatamente você não conseguiu fazer? Pelo que consegui entender seu problema está no particionamento, correto? Se for isso, as respostas (como sempre) podem ser encontradas no handbook [1]. Se a resposta não estiver ali, posta mais detalhes (deixando a raiva de lado e permanecendo no âmbito técnico) que iremos tentar te ajudar. Eu estava no meio da madrugada, e a instalação não fluiu como era com o Sysinstall. Eu passei horas tentando, e com o antigo em menos de meia hora eu tinha um sistema funcionando. Um exemplo de inconsistência de interface de usuário é escolher o tipo de teclado com enter, e o espaço não funcionando, e escolher os pacotes a serem com o espaço. Uma outra coisa estranha. A figura 2.15 do handbook mostra as opções de esquema de partições. Estas opções só aparecem em modo guiado, coisa que experimentei agora. No modo manual não tem estas opções. Só testei o modo guiado agora, pois assumi que o modo manual me daria todas as opções possíveis. A impressão que eu tive agora é que o instalador não está pronto, que ainda é um rascunho. Olha, você praticamente acertou... :) O sysinstall, embora bem completo, só suportava particionamento baseado em MBR e com a necessidade de se evoluir aqui, não só para o GPT, mas para formatos utilizados em outras arquiteturas (PowerPC, sparc, ia64) isso passou a ser um problema, pois a pessoa que mantinha o sysinstall não tinha tempo nem condições de testar as alterações necessárias. Nesse ponto o Nathan, desenvolvedor da plataforma PowerPC, fez o bsdinstall, um shell script que era muito mais simples e suportava todas as arquiteturas necessárias. As vezes é preciso dar um passo pra trás para poder voltar ao caminho certo. Como ninguém assumiu esse problema antes, ele foi la e fez. Agora (muito tempo depois de pronto) nós podemos reclamar ou contribuir para que esse instalador melhore. A sua critica é valida e se estruturada um pouco diferente (mostrando as diferenças pontualmente, sugerindo melhoras) poderia ser um ponto de partida para um pequeno projeto de melhoria do bsdinstall. Afinal quem faz o FreeBSD são as contribuições de pessoas como nós (que usamos e sentimos na pele as dificuldades do sistema) - i.e. não espere pelas melhorias, trabalhe por elas! Att., Luiz - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Processos zumbi brotando no sshd - FreeBSD 10.0
On 27 March 2014 16:44, Marcelo Gondim wrote: Pessoal, Tem uma thread na lista freebsd-stable@ que está acontecendo um negócio meio feio no FreeBSD 10. Parece que não está só acontecendo com o sshd mas com ele dá pra ver nitidamente o problema ocorrer: em servidores FreeBSD 10 com muitos acessos ssh, tem brotado vários processos zumbi nele. Aí fuçando os processos com procstat e netstat viu-se que o que fica preso são conexões de estado CLOSED. Loos ou alguém aqui da lista tá sabendo de algo sobre isso? [snip] Gondim, Eu não estou acompanhando esse problema de perto, mas há relatos aqui e ali de outros daemons (sendmail ao menos) falhando com sintomas similares (pacotes que não são enviados/processados resultando numa conexão travada). Ainda não há um consenso do que esta acontecendo, mas o problema esta sendo investigado. Como tudo indica que se trata um problema no network stack e não dos daemons, eu sugiro que você abra uma nova thread na freebsd-net@, lá voce vai ter atenção das pessoas certas, o pessoal que pode ter idéias sobre o que foi alterado recentemente e o que poderia causar um problema assim. Para referencia o problema do sendmail foi tratado aqui: http://lists.freebsd.org/pipermail/freebsd-current/2014-March/049039.html Att., Luiz - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Termômetro USB
2014-02-19 12:34 GMT-03:00 Patrick Tracanelli: On 19/02/2014, at 11:55, Renata Dias wrote: mantunes, Eu pedi para o meu setor de compras confirmar se não encontra esse TEMPer no Brasil, no http://www.portaldasantaifigenia.com.br por exemplo... rs No deal extreme levaria meses... De qualquer forma ainda estou bastante insegura se vai rodar bem no FreeBSD. Márcio Elias, Pelo que pesquisei sobre essa linha da Ubiquiti, ela necessita de conexão 2.4GHz, não tem nenhuma entrada RJ45 ou outra. Para quem me sugeriu o Arduino, teria algum material (for dummies) para me indicar ? Essa placa LM75 é apenas o sensor, correto? eu preciso de mais o que pra funcionar o conjunto todo? Como é a conexão do conjunto todo com o servidor (serial, rj45 ..)? Obrigada a todos ! Renata, eu sempre sugiro aos meus clientes o EM01B, que pode ser comprado aqui: http://eesensors.com/products/websensors/websensor-classic.html A maioria dos clientes de Data Center vão com essa opção, pq além de temp você monitora humidade (e outras coisas como luminosidade mas a maioria não da atenção a isso). Não sai tão barato quanto Arduino, especialmente se cair na receita, mas chega rápido, é confiável e tem um aspecto profissional. Um outro cliente que tenho comprou esse: https://store.serverscheck.com/ também gostei mas prefiro o primeiro, que é mais discreto e tem menos funções inúteis. Isso dito vamos ao arduino. Eu aconselharia essa opção não só por ser mais barato mas especialmente por ser mais divertido. Sugiro o uso do sensor DHT11 que te da temperatura e humidade, custa no máximo 16 reais. Além desse sensor você vai precisar da Protoboard, custa 99 reais o kit arduino start pra começar a brincar de lego. Você pode pegar as informações por serial (USB-serial) no FreeBSD sem qualquer problema. Se quiser tem esse kit também, que ainda vem com rede e display, ai voce pode mostrar a temp e humid no display e pegar via rede as informações. http://produto.mercadolivre.com.br/MLB-541582730-kit-arduino-uno-r3-ethernet-shield-fonte12v-lcd-dht11-_JM Enfim tudo depende do seu tempo e disposição pra brincar de lego ;-) Os dois produtos prontos vão chegar rápido. O arduino vai ser divertido. Faça sua escolha hehehe Pessoal, Por conta do meu trabalho com o gpio(4) no FreeBSD e como eu tenho interesse em fomentar o uso do FreeBSD para uso em sensores e outras soluções embarcadas eu vou fornecer kits contendo todos os componentes necessários para se fazer isso com FreeBSD. Os kits serão compostos por: - Beaglebone Black ou Raspberry Pi (dependendo da disponibilidade das placas); - Sensor DHT11 para leitura de humidade e temperatura; - Todos os cabos e conexões para conexão do sensor; - Cartão microSD com imagem testada e pronta para funcionamento, incluindo acesso dos valores medidos (humidade e temperatura) via cli (sysctl(8)) e SNMP, acesso do sistema via ssh; - Fonte com todos cabos e conexões. (Kit pronto para utilização - não sendo necessário nenhum desenvolvimento ou customização para uso) Outros sensores (e também entradas e saídas) também podem ser fornecidas no kit sob encomenda. Lembrando-se que se trata de um sensor com interface ethernet e acesso SNMP (fácil integração com sistemas de monitoramento). Para quem se interessar, por favor, me contate fora da lista. Att., Luiz - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Termômetro USB
2014-02-17 16:43 GMT-03:00 Otacílio: Em 17/02/2014 15:50, Renata Dias escreveu: Boa tarde, Alguém poderia me indicar uma marca e modelo de Termômetro USB para conectar a um servidor FreeBSD e controlar a temperatura do ambiente? A intenção é que eu consiga através deste FreeBSD gerar alertas no Nagios quando a temperatura do datacenter oscilar. Obrigada. Você poderia usar Arduino com o sensor LM75 para fazer isso. Se nunca mexeu com Arduino mas souber programar faz isso em uma tarde. Com o LM75 e uma RPi ou uma BBB você tem um sensor ethernet e rodando FreeBSD =) (incluindo monitoramento via snmp...) Luiz - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Termômetro USB
2014-02-17 17:17 GMT-03:00 Lucas Dias: Em 17 de fevereiro de 2014 17:08, Gustavo Freitas escreveu: luiz onde posso encontrar o LM75, e não entendi esse BBB BBB, não é Big Brother Brasil hehehe Nesse caso, esse BBB é http://www.beagleboard.org/Products/BeagleBone%20Black Show de bola. Vale a pena conhecer e olhar. Focando nessa demanda específica, com dedicação exclusiva, uma semana entra em funcionamento. Isso! e quanto ao LM75: http://produto.mercadolivre.com.br/MLB-534546262-arduino-bricks-sensor-de-temperatura-c-ci-lm75a-i2c-bus-_JM Os meus eu comprei na Mult Comercial em SP: http://loja.multcomercial.com.br/ecommerce_site/produto_20444_4689_Circuito-Integrado-LM75CIM-3- Tenho o driver para ele em: http://loos.no-ip.org/gpio/lm75.diff Esse driver exporta a temperatura (e os outros parametros) do LM75 via systcl: # sysctl dev.lm75.1 dev.lm75.1.%desc: LM75 temperature sensor dev.lm75.1.%driver: lm75 dev.lm75.1.%location: addr=0x96 dev.lm75.1.%pnpinfo: name=lm750 compat=lm75 dev.lm75.1.%parent: iicbus1 dev.lm75.1.temperature: 30.0C dev.lm75.1.thyst: 75.0C dev.lm75.1.tos: 80.0C dev.lm75.1.conf.faults: 1 dev.lm75.1.conf.mode: comparator dev.lm75.1.conf.polarity: active-low dev.lm75.1.conf.shutdown: 0 Você pode ter até 8 sensores em cada bus i2c. Att., Luiz - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Xorg na Beaglebone black
2014-02-05 20:21 GMT-02:00 Otacílio otacilio..@bsd.com.br: Consegui criar uma imagem para a minha beaglebone black com o freebsd 11, mas está sem suporte a interface gráfica. Algum dos colegas já conseguiu adicionar um xserver a ela? Ainda não há driver para a saída HDMI na BBB: http://lists.freebsd.org/pipermail/freebsd-arm/2013-December/007136.html Na RPi a saída HDMI funciona, mas ainda não há audio :( Esse ultimo provavelmente é minha culpa, já que fiquei de providenciar já faz algum tempo... Att., Luiz - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
[FUG-BR] Fwd: Raspberry Pi and BeagleBone images available on FreeBSD FTP mirrors
-- Forwarded message -- From: Glen Barber g...@freebsd.org Date: 29 January 2014 16:18 Subject: Raspberry Pi and BeagleBone images available on FreeBSD FTP mirrors To: freebsd-...@freebsd.org Hi, For those not subscribed to the -snapshots@ mailing list, arm/armv6 images for the RPI-B and BEAGLEBONE systems are now available on the FreeBSD FTP mirrors. The work to integrate building ARM images was sponsored by the FreeBSD Foundation. Checksums are in the announcement mail here: http://lists.freebsd.org/pipermail/freebsd-snapshots/2014-January/66.html Images for RPI-B and BEAGLEBONE are expected to be available weekly (unless something goes wrong with the builds) for 11.0-CURRENT and 10.0-STABLE. PANDABOARD and CUBIEBOARD images should be available next week. Many thanks to Tim Kientzle for Crochet, which is used to produce these images, and to Warner Losh for his input on various things over the last weeks. Enjoy! Glen - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Problemas com roteamento FreeBSD-9.2
[...] Era isso mesmo, mas o mais estranho nisso é que após aprender a rota, nada a fazia sair da tabela FIB, somente o reboot. Como sou um pouco insistente em testes, simulei agora a pouco em bancada a mesma sequência dos testes relatados no início da thread na versão 9.1 e na 9.2, conforme eu já previa, na versão 9.1 esse comportamento não acontece, já na versão 9.2, o problema se repetiu . Os filtros por hora resolveram o caso no FreeBSD-9.2. Bem que eu poderia ter feito esses filtros antes :), mas confesso que esses em específico passaram batido, haja visto que usei a 9.1 por um bom tempo e não acontecia isso. Essa mudança de comportamento foi introduzida com a r248070: http://svnweb.freebsd.org/base?view=revisionrevision=248070 Antes o problema era que qualquer daemon de roteamento podia (pelo mesmo motivo que eles adicionam) remover uma rota de um dos seus IPs configurados em uma das interfaces e ai você teria o IP configurado mas ele não funcionaria. Essa alteração protege essas rotas marcando-as com uma flag especifica. O bug aqui talvez seja no momento depois do BGP fazer ou tentar fazer a alteração dele. Nesse ponto, pelo que entendi, a rota não pode mais ser removida, o que deveria acontecer automaticamente quando o IP da interface fosse removido (se, em teoria, ela esta protegida). Luiz - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Problemas com roteamento FreeBSD-9.2
2014-02-03 Samuel Peres samuelpe...@migtelecom.com.br: On 2/3/2014 7:01 PM, Marcelo Gondim wrote: Em 03/02/14 16:41, Samuel Peres escreveu: On 03/02/2014 15:57, Edinilson - ATINET wrote: [...] Vou fazer esse teste mais tarde e reporto os resultados. Uma coisa é fato, já bem próximo de 800Mb de tráfego passando por esse FreeBSD, em um hardware bem dimensionado, devo admitir que estou perdendo um pouco a confiança no sistema para roteamento. Não importa o que os mais experientes e saudosistas digam. Uso FreeBSD há mais de 10 anos (comecei com a versão 4.7) e uso aqui para praticamente tudo, até mesmo como desktop no meu notebook, mas para roteamento acima de 500Mb estou caindo fora. Alguém roda com mais de 1Gb de tráfego? Parabéns e fico feliz por você! Eu aqui estou tendo problema até mesmo com um simples route delete. Preciso atualizar para a versão 10, regredir para a 9.1 ou aplicar patch para corrigir um troço desse? Fala sério, muitos sabem que não é tão simples assim, principalmente quando é 800Mbit/s passando pelo sistema. Problemas acontecem em qualquer sistema, sejam eles pagos ou abertos. A questão eh o que você precisa fazer para resolve-los. No FreeBSD eu tenho todo o código aberto, seja para identificar o problema, seja para corrigi-lo (se eu puder). No meu caso isso faz toda diferença. Você deveria adquirir um suporte profissional que lhe traga segurança (no sentido de alguém que possa lhe prover as respostas e as soluções necessárias sem que você precise se preocupar se isso é um patch, uma atualização ou até uma correção local). Não é porque se trata de um sistema open source que não há custo de manutenção do mesmo, nem sempre é possível fazer tudo 'em casa'. Outra questão é que você deveria ter um segundo sistema de backup, fazer teste com o único sistema que você tem _não é um opção_. Att., Luiz - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Problemas com roteamento FreeBSD-9.2
2014-02-03 Samuel Peres samuelpe...@migtelecom.com.br: Boa tarde, Estou com um problema estranho no FreeBSD-9.2 (r260799) com OpenBGPD. Não consigo remover 1 rota específica, retorna o seguinte erro: # route delete -inet 187.xx.xxx.0/22 -iface vlan569 -fib 0 route: writing to routing socket: Address already in use delete net 187.16.216.0: gateway vlan569 fib 0: gateway uses the same route Exit 1 No momento não estou com nenhum IP configurado na mesma subnet da rota que estou tentando remover (tinha, mas removi com ifconfig sem nenhum problema). Com netstat ou bgpctl consigo ver a rota em questão, vejam: # netstat -nr | grep 187.xx.xxx 187.xx.xxx.0/22187.xx.xx.xx UG1 0 3806179 vlan569 Entretanto, não era para essa rota na está na VLAN 569, era para está em outra VLAN. Esse mesmo problema foi tratado em [1], onde aparentemente só foi corrigido aplicando um patch, mas não estou muito otimista e recorro a FUG em busca de ajuda. Já tive esse problema umas duas ou três vezes, infelizmente só consegui resolver após um reboot. Percebi que esse problema acontece da seguinte forma (simulei isso para constatar): * Todas sessões BGP estão down no início. Em seguida: 1- Subo a sessão BGP do PTT; 2- Subo a sessão BGP da Algar; Tudo ok até aqui 3- down na sessão com PTT; 4- down na sessão da Algar; 5- Subo novamente a sessão da Algar; 6- Tento subir novamente a sessão com o PTT; Ou seja, o sexto passo eu não executo com sucesso, visto que perco comunicação com o roteador do PTT. Loucura não? Com certeza, mas acontece isso aqui e já tentei atualizar o FreeBSD para tentar resolver e nada. O negócio é tão maluco que nem mesmo a tabela arp dos endereços associados a VLAN do PTT eu consigo remover quando acontece isso. Retorna o erro arp: writing to routing socket: Invalid argument. Se tento adicionar o IP novamente a VLAN retorna o erro ifconfig: ioctl (SIOCAIFADDR): Address already in use. Em outra localidade tenho um Mikrotik (estou aguardando a chegada de um Juniper MX10) com o mesmo cenário (PTT e Algar) e não acontece esse problema. Alguém tem alguma dica? [1] http://forums.freebsd.org/viewtopic.php?t=42547 Obrigado! Samuel Peres Samuel, Pela sua descrição do problema e pela descrição e patch no forum o que 'parece' que esta acontecendo no seu caso é o seguinte: Você configura o IP nas interfaces e sobe o BGP. O BGP esta recebendo os blocos que você utiliza para falar com seus upstreams (IPs locais configurados nas interfaces) e essas rotas são adicionadas pelo daemon BGP no sistema sobre-escrevendo as rotas que foram adicionadas quando o IP foi adicionado na interface. A partir daqui o sistema sai de sincronismo, pois mesmo removendo o IP da interface não vai remover as rotas e você também não pode remove-las manualmente porque elas estão marcadas como PINNED. Até onde olhei o melifaro não fez nenhuma alteração nesse código recentemente, então atualizar não é uma opção. E aquele patch é um hack para resolver aquele problema especifico do usuário do forum (interfaces p2p). Você tem filtros no seu BGP para os seus IPs/blocos locais ? Eu acho que isso resolveria o seu problema, evitando que as rotas aprendidas pelo BGP sobre-escrevam as rotas PINNED. Att., Luiz - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Carregamento do gmirror e gstripe no loader.conf
2014-01-29 Marcelo Gondim gon...@bsdinfo.com.br: Pessoal, Estou tentando faz um tempo colocar todo o disco inclusive o raiz em gmirror+gstripe(raid10) pra bootar e não consigo. Quando inicia o boot já manda na lata o Not ufs. Creio que o motivo seja porque para carregar o geom é necessário primeiramente carregar o kernel. O zfs funciona porque tem um boot específico para ele. Só vi uma solução: colocar o / fora do raid e colocar o restante /usr, swap, /var e /tmp no raid10. Alguém já conseguiu bootar o sistema com tudo no geom raid? Meu loader.conf: geom_mirror_load=YES geom_stripe_load=YES vfs.root.mountfrom=ufs:/dev/stripe/root []'s Gondim Como esta criando raid10? Gstripe = gmirror+ gmirror ou Gmirror = gstripe + gstripe? [...] Pelo que percebi eu não consigo carregar o gstripe e o gmirror antes do kernel ser carregado e por isso o /boot não fica visível, dando o tal erro: Not ufs O que funcionou para mim foi tirar o / do gmirror e gstripe, aí nesse caso carregou o kernel e o módulo gmirror e gstripe. O restante funcionou de boa. A minha dúvida era se existe alguma maneira de carregar o gmirror e gstripe antes de tudo, como o tal initrd do Linux. Gondim, Da forma como eu vejo (posso estar errado, claro) o gstripe não pode ser utilizado na partição de boot (no root '/'). No gmirror você tem os dois (ou mais) discos iguais o tempo todo, assim se você montar e ler o root '/' a partir de qualquer um dos discos que compõem o mirror e você sempre vai ler os mesmos dados, independente de qual disco você faça a leitura. No caso do gstripe as informações (os blocos) estão espalhados pelos discos que compõe o stripe e assim você não pode ler a partição (ou slice) sem primeiro reconstruir o RAID, coisa que como você já notou não é simples. Mesmo no linux, com o uso do initrd, é preciso de uma pequena partição de boot - sem RAID - que no caso contém a imagem que será utilizada para boot e carga dos módulos. Montando o root '/' numa pequena partição separada ou até com o gmirror deve resolver seu problema (lembrando que o root '/' pode ser sobreposto depois). Att., Luiz - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Arm
2013/10/19 Bruno Araújo bjara...@gmail.com: Quero usar como DNS recursivo, pppoe server (mpd), QoS e controle de tráfego(individual por túnel pppoe). Minha intenção é usar a edgerouter ubiquiti. Vou dar uma olhada nesses scritps e pesquisar sobre u-boot. A edgerouter é uma boa plataforma, estou esperando que ela logo se torne mais acessível aqui pra gente. Se não me engano quem usa tem criado a imagem com os scripts do Warner: http://bsdimp.blogspot.com.br/2011/01/freebsdmips-for-cavium-octeon.html http://bsdimp.blogspot.com.br/2010/01/booting-instructions-for-freebsd-on.html No wiki tem algumas referencias também: https://wiki.freebsd.org/FreeBSD/mips/Octeon Porém para a interface de rede nessa placa, eu posso adiantar que o altq ainda não funciona. Luiz - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Arm
2013/10/21 Fernando Ferreira da Silva fernando.si...@gmail.com: Luiz, o meu é cubieboard2 https://wiki.freebsd.org/FreeBSD/arm/Cubieboard Luiz - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] IPFW FWD em Bridge - Luiz Souza
2013/10/4 Patrick Tracanelli eks...@freebsdbrasil.com.br: Em 04/10/2013, às 11:56, Renata Dias renatchi...@gmail.com escreveu: Patrick, Eu consigo rodar este mesmo patch http://loos.no-ip.org:280/lusca_bridge.diff no 9.2-STABLE ? Renata, não consegue não. A partir do MFC do PFIL pro IPFW e bridge, alguma coisa quebrou (acho que a forma que os mbuff tags são marcados, não sei) e esse patch apesar de aplicar normalmente, com pouca mudança (so o path do ip_fw2.c saindo do netinet) não funciona mais. O MFC aconteceu em algum momento entre o 9.1-RELEASE e o 9.1-STABLE então se mantenha no 9.1-RELEASE-pX se precisa desse patch. O Loos comentou comigo que ia arrumar um tempo pra investigar o que quebrou exatamente que esse patch não funciona mais. Melhor que investigar/corrigir/gerarnovopatch é que agora com commit bit do src quem sabe ele não consiga commitar em definitivo ;-) Seria o ideal! :D Loos esse patch foi send-pr(1)? Se foi fala o PR # ai, se tiverem muitos aqui na lista que precisam desse patch sugiro que todos dêem follow-up em um possível PR pra ajudar a dar a importância devida ao patch e mostrar a importância dele entrar na base. Patrick, Renato, Eu não criei nenhum PR para aquele patch porque ele funcionou um tanto quanto sem querer e eu não poderia justificar aquelas alterações, o que definitivamente é um no-go. Outra coisa que dificulta o commit é a falta de testes ou talvez até a completa falta de suporte para ipv6. Fora isso, o fato que vocês já comentaram muito bem, essa topologia é mais complicada para ser utilizada (no final das contas), pois não escala bem. Fora o Brasil e alguns outros poucos países o interesse nesse tipo de solução é muito pequeno. Eu acho que o que eles chamam de modo 'paralelo' deve funcionar sem patches. Se não funciona esse seria o primeiro ponto a ser corrigido. Att., Luiz - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] OpenBGPD com rota em outra rede
2013/10/3 spiderslack spidersl...@yahoo.com.br: Ola pessoal, não sei se o assunto e off-topic, mas se for desconsiderem Estou configurando BGP utilizando FreeBSD e OpenBGPD. A sessão BGP fecha porém não navego. Fazendo uma analise com o pessoal da operadora verifiquei que o nexthop das rotas aprendidas via BGP apontam para o endereço dos 2 peer que fecho o BGP(multihop) dentro da rede da operadora, e não para o endereço IP conectado diretamente. Eu inicialmente crio uma rota estatica apontando para esses 2 peer BGP indo pelo roteador diretamente conectado. Mas quando o BGP fecha, todas as rotas apontam para esses 2 IPs dentro da nuvem da operadora, e não para o ip diretamente conectado ( e como se tivesse um gateway default em outra rede e uma rota estatica para chegar nesse gateway default). Tipo se um pacote vir para o destino 8.8.8.8 o qual na tabela de rotas aponta para o peer BGP ele vai ter q procurar de novo na tabela de rotas para chegar nesse gateway remoto(vai usar minha rota estatica), fazendo 2 consultas na tabela de roteamento, isso não gera overhead? E testei em um roteador Cisco com a operadora e funcionou o FreeBSD não vai. Alguem já passou por isso? Isso e normal do BGP ou tem haver de como o FreeBSD faz o lookup das rotas?. Desde já agradeço. Acho que é só você alterar o nexthop das rotas aprendidas, nao ? # adicione no seu bgpd.conf match from any set nexthop ip.do.seu.gateway.bgp E claro, você deve melhorar esse filtro e fazer ele ser mais especifico para a sua situação (mas pra um unico upstream ele esta ok...). Att., Luiz - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Hardware 802.11ac
On 28 August 2013 09:25, Paulo Fragoso pa...@nlink.com.br wrote: Alguém já testou o 802.11ac no FreeBSD? Acho que nem o Adrian Chadd :-) O 10 (que sai até o fim do ano) vai trazer o suporte a 802.11n. O 802.11ac esta no radar dos desenvolvedores, mas ainda não existe nenhum esforço nesse sentido. E falando do Adrian, ele falou um pouco sobre o que vem por ai, em wireless, na BSDCan: http://www.bsdcan.org/2013/schedule/events/386.en.html Att., Luiz - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Erro arpresolve: can't allocate llinfo for
2013/8/7 Hygor hyg...@gmail.com Em 6 de agosto de 2013 17:55, Listas Discussão dl.la...@gmail.com escreveu: Observei esse problema também e até agora não encontrei solução. Fiz uns testes com FreeBSD e OpenOSFPD e por exemplo, tenho o ip 172.16.0.1/30 configurado numa interface do FreeBSD, essa interface está ligada em outro roteador com o ip 172.16.0.2/30. Fecho uma sessão OSPF entre ambos, ao anunciar a rede 172.16.0.0/30 pelo OSPF o FreeBSD remove a rota que é criada ao configurar o ip na interface e adiciona a recebida pelo OSPF. Bem estranho, ele não dá a devida preferência para a rota diretamente conectada e pior que, ao derrubar o OSPF, ele simplesmente remove a rota da tabela, não sobe a rota diretamente conectada. Esse foi exatamente o comportamento apresentado... acredito que quem está fazendo isso é o OpenOSPFD( no meu caso o OpenBGPD). Não posso falar pelo OSPF nem pelo openospfd que eu não conheço. Porém, no caso do openbgpd, ele é transparente e por isso mesmo não faz nenhum filtro automagicamente, se ele receber uma rota ele vai tentar incluir ela na tabela de rotas do SO. Se ele deve ou não fazer isso quando já existe uma rota estática na tabela é uma coisa que eu não sei responder. De qualquer forma eu sempre adiciono filtros para todas as minhas redes locais (meus blocos e todas as redes que uso que para conectar aos meus upstreams e downstreams) da mesma forma como já é feito com as redes reservadas: # filter bogus networks deny from any prefix 10.0.0.0/8 prefixlen = 8 deny from any prefix 127.0.0.0/8 prefixlen = 8 deny from any prefix 169.254.0.0/16 prefixlen = 16 deny from any prefix 172.16.0.0/12 prefixlen = 12 deny from any prefix 192.0.2.0/24 prefixlen = 24 deny from any prefix 192.168.0.0/16 prefixlen = 16 deny from any prefix 224.0.0.0/4 prefixlen = 4 deny from any prefix 240.0.0.0/4 prefixlen = 4 # refuse to accept our prefixes deny from any prefix xxx.xxx.xxx.0/21 prefixlen = 22 # client 1 deny from any prefix xxx.xxx.xxx.0/22 prefixlen = 22 # client 2 deny from any prefix xxx.xxx.xxx.0/20 prefixlen = 20 # client x deny from any prefix xxx.xxx.xxx.0/22 prefixlen = 22 # client y deny from any prefix xxx.xxx.xxx.0/22 prefixlen = 22 # client w deny from any prefix xxx.xxx.xxx.0/20 prefixlen = 20 # my IP block deny from any prefix xxx.xxx.xxx.0/20 prefixlen = 20 # my IP block deny from any prefix xxx.xxx.xxx.0/30 prefixlen = 30 # upstream deny from any prefix xxx.xxx.xxx.0/30 prefixlen = 30 # upstream Luiz - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Current em produção
2013/8/8 gon...@bsdinfo.com.br Pessoal, Alguém aqui está usando o FreeBSD current em producão? Se sim como está a estabilidade? O current não costuma ter problemas de estabilidade, a questão é que existem bons e maus momentos para se atualizar o current. Você pode atualizar o seu current justo para uma revisão problemática e acabar com seu sistema 'emperrado' de alguma forma. Quebrar o current não é um pecado mortal e acontece com alguma frequencia. É esperado que os usuários do current saibam lidar com esses problemas que por ventura possam ocorrer. Essa é provavelmente a maior dificuldade para se acompanhar o current (que fora isso costuma funcionar muito bem). Att., Luiz - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Problemas com o modulo ehci ( usb 2.0 )
2013/8/6 Paulo Henrique - BSDs Brasil paulo.rd...@bsd.com.br Acho que deve ter algo relacionado ao USB 3.0 pois em um outro que tem a placa-mãe X58 da intel tive que desativar a USB 3.0 pois estava travando a maquina, mais o FreeBSD é um 8.4-Stable. Valeu pelas dicas. USB 3.0 usa o driver xhci e não o ehci (que eh USB 2.0 mesmo). Faça o teste com as sysctls e se não houver resultado, poste seu primeiro e-mail na stable@ (ou faça um followup no PR mesmo) junto com o dmesg (e o pciconf -lv) da maquina. Você viu se no seu caso tem mais algum dispositivo compartilhando a IRQ 16 com o ehci ? Att., Luiz PR: http://www.freebsd.org/cgi/query-pr.cgi?pr=156596 - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Erro arpresolve: can't allocate llinfo for
2013/8/6 Hygor hyg...@gmail.com 2013/8/6 Hygor hyg...@gmail.com Bom dia, Estou tendo problemas em uma vlan onde nao consigo pingar os ips do msm segmento.. nessa interface esta setado um ip /22... nos logs aparecem a seguinte msg: arpresolve: can't allocate llinfo for IP Nessa mesma interface tenho outra vlan sem nenhuma anomalia. Algum dos colegas já se deparou com essa msg nos logs? Já aumentei o kern.ipc.nmbclusters para 32768 segue a saida do netstat -m 1796/2434/4230 mbufs in use (current/cache/total) 1794/1394/3188/32768 mbuf clusters in use (current/cache/total/max) 1794/1278 mbuf+clusters out of packet secondary zone in use (current/cache) 0/104/104/16384 4k (page size) jumbo clusters in use (current/cache/total/max) 0/0/0/8192 9k jumbo clusters in use (current/cache/total/max) 0/0/0/4096 16k jumbo clusters in use (current/cache/total/max) 4037K/3812K/7849K bytes allocated to network (current/cache/total) 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) 0/0/0 requests for jumbo clusters denied (4k/9k/16k) 0/0/0 sfbufs in use (current/peak/max) 0 requests for sfbufs denied 0 requests for sfbufs delayed 0 requests for I/O initiated by sendfile 0 calls to protocol drain routines via arping eu pingo todos os IPS.. Você não tem nenhum problema ai na sua configuração ? As redes não estão se 'sobrepondo' de alguma maneira ? Pode passar mais detalhes da sua configuração ? Isso não é problema com limite de buffers... Luiz - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Storage NAS com ZFS ou UFS
2013/7/28 Gustavo Freitas gst.frei...@gmail.com Pessoal, Estou com NAS o mesmo é freenas, irei usar para armazenamento de backup tenho 4 discos 2 TB cada, o cliente não quer Raid, já que o mesmo é somente para armazenar arquivos de backup, a minha dúvida é posso o ZFS é ideal ? Gustavo, Independente da questão do RAID, sempre que você pretenda utilizar vários discos o ZFS é uma boa escolha. A qualquer momento você pode adicionar e/ou remover discos do seu pool. Se o seu sistema comporta bem o ZFS (64bits, com memória sobrando) você não terá problemas. Luiz - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Panic no sbdrop
2013/7/29 Marcelo Gondim gon...@bsdinfo.com.br Estou testando com o aumento desse parâmetro cujo default era 0, para ver se surte algum efeito diferente. Mas alguém saberia explicar o que é esse sbdrop? sbdrop: socket buffer drop - drop data from a socket buffer em sys/kern/uipc_sockbuf.c e o único panic(sbdrop) no código esta em sbdrop_internal() no mesmo arquivo. se você disparou esse panic (você não enviou o backtrace...) é porque coisas ruins (tm) aconteceram ai. seus mbuf estão corrompidos e nesse ponto (já corrompido) não há nada que o sistema possa fazer. Isso me parece mais um efeito do que a causa do problema. Você ja tentou falar com o mav@ ? AFAIR ele é um dos desenvolvedores do mpd. Att., Luiz - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] ISO do 9.2
2013/7/23 Matheus L. Abreu matheusl.ab...@gmail.com On Tue, Jul 23, 2013 at 3:23 PM, Nilton Jose Rizzo ri...@i805.com.br wrote: quem quizer já testar o 9.2 em uma vm pode fazer o download da iso aqui i386 ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/ISO-IMAGES/i386/9.2/ ou amd64 ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/ISO-IMAGES/amd64/9.2/ Rizzo Alguém achou o changelog? Esse ainda é o BETA1 Matheus e por isso não existe o changelog. O 9.2-Release esta previsto para o fim de Agosto. Luiz - 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] - Morte do Pedro Madsen
2013/7/17 Pablo Sánchez phack...@gmail.com Caros, Faleceu ontem de madrugada o Pedro Madsen, membro muito ativo aqui da lista, de causas naturais. Acredito que muitos aqui o conheciam ou simpatizavam com essa pessoa que vai deixar saudades, por isso tomei a liberdade de informar por aqui. Um abraço e paz. RIP Pedro. - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] HD Aparece no zpool list mas os arquivos não aparecem
2013/7/17 joao jamaicabsd jamaica...@gmail.com Luiz, segue: pool: hddados state: ONLINE scrub: none requested config: NAMESTATE READ WRITE CKSUM hddados ONLINE 0 0 0 ad6 ONLINE 0 0 0 errors: No known data errors Tem algo errado ai joão, quais foram os comando que você usou para chegar até aqui ? Aparentemente não tem nada mesmo nos seus discos :/ Att., Luiz - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Montar HD do FreeNAS no FreeBSD 8.2
2013/7/16 joao jamaicabsd jamaica...@gmail.com Boa noite a todos. Tentei de várias vezes montar um HD que estava num Freenas no meu bsd, mas não tem jeito de conseguir. Quero acessar os arquivos do tal HD. Segue o gpart show =34 3907029101 ad5 GPT (1.8T) 34 41943041 freebsd-swap (2.0G) 4194338 39028347972 freebsd-ufs (1.8T) # gpart show ad5 =34 3907029101 ad5 GPT (1.8T) 34 41943041 freebsd-swap (2.0G) 4194338 39028347972 freebsd-ufs (1.8T) Se uso o comando mount: mount /dev/ad5 /mnt/hd2tbbkp/ resultado do comando acima: mount: /dev/ad5 : Invalid argument ou #mount -t ufs /dev/ad5 /mnt/hd2tbbkp/ resultado do comando acima: mount: /dev/ad5 : Invalid argument Como faço pra montar esta partição no meu FreeBSD? Obrigado Nesse caso o correto é: # mount /dev/ad5p2 /mnt/X No gpart show você vê que é a partição '2' que se refere a partição do tipo freebsd-ufs. Att., Luiz - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Montar HD do FreeNAS no FreeBSD 8.2
2013/7/16 joao jamaicabsd jamaica...@gmail.com Estou vendo agora que no hd que realmente quero recuperar os dados que ele é ZFS, alguém pode me ajudar, estou lendo várias coisas, mas estou com medo de perder os dados. Esse disco não pode ser ZFS porque nesse caso a partição seria do tipo freebsd-zfs e não freebsd-ufs. Att., Luiz - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Finalmente o Brasil tem um committer no src novamente
Obrigado pessoal :-) E só espero poder realmente contribuir com o desenvolvimento do sistema, seja com algum código, seja disseminando o seu uso. E sim, a principio as minhas áreas de interesse são os embarcados e o gpio. []'s Luiz - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Finalmente o Brasil tem um committer no src novamente
2013/7/3 Luiz Gustavo Costa luizgust...@luizgustavo.pro.br * Patrick Tracanelli (eks...@freebsdbrasil.com.br) wrote: Da pra commitar aquele patch de fwd em bridge no source pra parar de ser algo solto? Acho inclusive que quebrou depois da restruturação do pfil (sys/netinet/ipfw - sys/netpfil/ipfw). É isso mesmo, quebrou já no 9.1-STABLE, o src do RELEASE ainda vai de boa. Vamos precisar atualizar o patch e tentar conseguir um review de alguém experiente na área, mas quem sabe dessa vez conseguimos. Assim que sobrar algum tempo aqui vou tentar rever esse patch. []'s Luiz - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Limitação de mac address por interface?
2013/7/2 Renato Frederick ren...@frederick.eti.br Em 02/07/13 00:03, Marcelo Gondim escreveu: Em 01/07/13 23:01, Marcelo Araujo escreveu: Olá Marcelo Godim, Sim, existe um limite na tabela arp no FreeBSD!! Infelizmente esse limite é definido estaticamente, e que vai fazer o FreeBSD manter mais ou menos 600 MAC ADDRESS em sua tabela arp. Para um servidor de grande porte é o bastante. Porém para um ROUTER ou BGP, já não é muito!!! É possível aumentar esse valor, você precisa fazer o seguinte: Edite o arquivo: sys/net/if_llatbl.h Localize a linha que contém: #define LLTBL_HASHTBL_SIZE 32 /* default 32 ? */ Aumente para 512 e verifique o resultado, caso não seja o bastante, aumente para 1024. Apenas lembrando, que isso vai consumir mais memória de máquina. Atenciosamente, Opa valeu Marcelo!!! Passei pra ele a informação. O pessoal poderia colocar esse aumento em alguma sysctl heim! :) ficaria bem mais prático. Grande abraço, Gondim - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd Opa, Eu olhei aqui, hoje com o PTT-SP eu tenho 296MAC cadastrados. Então, a princípio não precisaria de mexer com isto, caso o cliente conecte-se apenas a 1 PTT. Eu conversei com o Marcelo (araujo@) em private e peguei algumas referencias com ele para essa modificação: http://lists.freebsd.org/pipermail/freebsd-net/2012-December/034108.html http://lists.freebsd.org/pipermail/freebsd-net/2012-November/033786.html No segundo link há um formula interessante para o calculo dessa variável que é: Número esperado de MACs / 4 Porém diferente do que ficou parecendo na mensagem do Marcelo essa variável não determina um limite estatico para o número máximo de macs na tabela arp. Isso ainda é determinado pela memória disponível no sistema (e talvez arquitetura...). Nos próprios links vocês vão ver os comentários de 2.000-3.000 (e ainda 3999) endereços na tabela (com o valor default de 32). Aumentando a número de entradas na tabela hash melhora o funcionamento do sistema nesses casos (on há milhares de endereços na tabela). Att., Luiz - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Calcular valor para kern.ipc.nmbclusters
2013/4/1 Listas Discussão dl.la...@gmail.com Estou pensando em dobrar esse valor ou triplicar, na dúvida procurei por alguma forma de calcular, no manual até fala em cálculo para um servidor web de acordo com o número de conexões, mas no meu caso não faço idéia de quantide de conexões simultâneas. O ruim de tudo isso é ter que reiniciar o servidor, só de madrugada agora e mesmo assim vai ter cliente que vai chiar :) Qual o valor que você está usando Gondim? No meu server tenho 1 igb onboard e 3 dessas Intel Dual. Essa máquina aí é um router? Pode aumentar esse valor sem grandes problemas (desde que você tenha memória RAM suficiente). Esses drivers novos pre-alocam várias filas para cada placa dessa (com MSIX). E como é uma fila para cada CPU o auto-tuning nem sempre funciona (além do que você tem pouca memória): igb1: Intel(R) PRO/1000 Network Connection version - 2.3.4 port 0xece0-0xecff mem 0xdd7e-0xdd7f,0xddc0-0xddff,0xdd7bc000-0xdd7b irq 45 at device 0.1 on pci3 igb1: Using MSIX interrupts with 9 vectors igb1: Ethernet address: 90:e2:ba:04:18:d1 igb1: Bound queue 0 to cpu 0 igb1: Bound queue 1 to cpu 1 igb1: Bound queue 2 to cpu 2 igb1: Bound queue 3 to cpu 3 igb1: Bound queue 4 to cpu 4 igb1: Bound queue 5 to cpu 5 igb1: Bound queue 6 to cpu 6 igb1: Bound queue 7 to cpu 7 Como você tem pouca memória (1GB) talvez seja melhor você limitar as filas por placa mesmo. Num router assim eu recomendaria pelo menos 8GB de RAM... memória é barato e hoje em dia todo acesso é via DMA (mapeado na RAM). _NUNCA_ deixe faltar. Att., Luiz - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Digest freebsd, volume 80, assunto 56
2012/11/22 Otacílio otacilio.n...@bsd.com.br: Também gostaria que todos os mantenedores de ports trabalhassem para que os ports atuais funcionassem sem bugs, mas infelizmente nem sempre isso acontece e apenas as versões vão mudando. Também, é sempre trabalho voluntário e é preciso se conformar com isso. O trabalho do pessoal dos ports é fazer com que eles possam ser compilados e instalados corretamente no FreeBSD, cuidando de todas as dependencias e assim por diante. O trabalho deles não é corrigir os ports, o FreeBSD não pode e não vai consertar todos os programas do mundo (mesmo que eles estejam no ports!) :) Os mantenedores podem (e devem) trabalhar com os desenvolvedores do port em questão para que os problemas sejam solucionados. E nada, repito, nada impede que qualquer pessoa entre nesse 'loop' e ajude na solução dos problemas. O FreeBSD precisa 'muito' de mão de obra (a maior parte dos problemas que você citou, simplesmente são efeitos dessa falta de mão de obra...) vamos ajudar ? []'s Luiz - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Monitorar o uso da CPU com o MRTG
2012/11/9 Luiz Gustavo Costa luizgust...@luizgustavo.pro.br: Ai que tá... via sysctl tem que fazer uns calculos doidos lá para gerar a porcentagem de cpu (só se tiver um template pronto pra isso). Nativo não tem. via snmp também não é possivel com net-snmp normal, você só podera encontrar no pacote net-mgmt/bsnmp-ucd em complemento ao bsnmp nativo do freebsd. Eu faço isso com o bsnmpd padrão... no /etc/snmpd.config eu preencho o 'location' e 'contact', adiciono uma community no 'read' e comento o 'write' (no meu caso só faço o monitoramento...). Depois descomento a seguinte linha: begemotSnmpdModulePath.hostres = /usr/lib/snmp_hostres.so Adiciono no /etc/rc.conf: bsnmpd_enable=YES E pronto. No Cacti, você edita o device, vai em Associated Data Queries e adiciona o SNMP - Get Processor Information e SNMP - Get Mounted Partitions e já pode criar os gráficos. Com isso você gera gráficos de CPU, Memória, SWAP, espaço em disco e outros. E isso sem instalar nada no FreeBSD. Thanks to bsnmpd ! []'s Luiz - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Dell Latitude e5400 e Wireless
2012/11/4 Joao Rocha Braga Filho goffr...@gmail.com: Achei algo no dmesg: siba_bwn0: Unknown mem 0xf69fc000-0xf69f irq 17 at device 0.0 on pci12 siba_bwn0: warn: multiple PCI(E) cores siba_bwn0: unsupported coreid (USB 2.0 Device) siba_bwn0: unsupported coreid (unknown) siba_bwn0: unsupported coreid (Internal Memory) siba_bwn0: unknown chipid 0x4322 for PLL PMU init João, Manda o seu dmesg e a saída do pciconf -lv para a lista freebsd-wireless@ lá o pessoal vai poder te ajudar. Att., Luiz - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Concentrador PPPoE
2012/11/4 mail gter mail.g...@gmail.com: Boa tarde, Alguém utiliza freebsd como concentrador PPPoE ? Em nossa rede utilizamos Mikrotik, mas em virtude das limitações de hardware das routerboards estamos estudando alternativas. A ideia de rodar mikrotik sobre sobre x86 não me agrada muito. Há certas incompatibilidades de hardware e há também o fato de não ser possível tunar o sistema ou realizar ajustes mais específicos. O sistema de certa forma é inflexível. Em um rápida pesquisa encontrei um único daemon, chamado pppoed, cuja última atualização foi em 2002. O pppoed(8) roda sobre o ppp(8) que, por sua vez, roda no userland e precisa executar um processo para cada conexão ativa, isso consome muita memória em ambientes com muitas conexões. Já o mpd implementa isso no kernel e com um overhead muito menor para cada conexão. Se você procurar nas listas oficiais você vai achar gente falando de concentradores baseados em MPD e FreeBSD gerando 500Mb/s de trafego. Se você não precisa ou pode conviver sem um Winbox da vida para gerencia, como foi comentado aqui, pode ir tranquilo com essa solução. Att., Luiz - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] kernel ARM9/11
2012/10/31 Marcos - mensagem.particu...@hotmail.com: Prezados O kernel freebsd ,tem compatibilidade com os seguintes?? ARM926EJ 533MHZ soc VR3520F (ARM9) CPU CLG7700 800MHz(ARM11) Olha, compatibilidade tem, mas ai depende exatamente do que você espera por compatibilidade. ARM926EJ é só a família e é muito amplo, porém é suportado com certeza. Agora quando você parte para o SoC, como o VR3520F (que tem documentação aberta aparentemente: http://elinux.org/Pollux) você nota que ele vai precisar de drivers especificos para os seus dispositivos e me parece que não tem nada assim na arvore (e também duvido que no NetBSD seja muito diferente, a não ser que este SoC esteja em alguma placa extramamente comum ou 'da moda'). os dois existem naqueles thin client made in china, estou pensando em adiquirir para testar. Testar para que uso/finalidade ? Só teste mesmo ? As vezes existem outras soluções mais prontas para o que você precisa... Agora, se você espera por algo do tipo instala e usa (com suporte a X e tudo mais), esquece... Não estamos lá ainda. Att., Luiz - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] sockstat estranho
2012/10/11 Jorge Petry jo...@bsd.com.br: Olá pessoal. Ao digitar o comando sockstat -4c tenho um retorno estranho: USER COMMANDPID FD PROTO LOCAL ADDRESS FOREIGN ADDRESS ?? ? ? tcp4 127.0.0.1:29073 127.0.0.1:389 ?? ? ? tcp4 127.0.0.1:64257 127.0.0.1:389 ?? ? ? tcp4 127.0.0.1: 127.0.0.1:63900 ?? ? ? tcp4 127.0.0.1:61844 127.0.0.1:389 ?? ? ? tcp4 127.0.0.1: 127.0.0.1:57562 ?? ? ? tcp4 127.0.0.1:33217 127.0.0.1:389 ?? ? ? tcp4 127.0.0.1:10025 127.0.0.1:25011 ?? ? ? tcp4 72.55.131.112:80 78.96.143.167:8700 ?? ? ? tcp4 127.0.0.1:18859 127.0.0.1:3306 ?? ? ? tcp4 72.55.131.112:80 78.96.143.167:8701 Alguma ideia do que pode estar acontecendo? Rodo freebsd 8.3 amd64 Você compilou o kernel dessa maquina ? Ou chegou a atualizar o sistema todo ? Onde você baixou os fontes do kernel ? Isso tem cara de falta de sincronismo do kernel e do resto do sistema, tenta bootar com o kernel GENERIC (original) e veja se resolve o problema. Você tem que usar os fontes na mesma versao no sistema todo. Em ultimo caso você faz uma atualização completa do sistema para atualizar o kernel e o base system, deixando tudo na mesma versão. Att., Luiz - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] [OFF-TOPIC] BSD em RouterBoards PowerPC
2012/9/28 Antonio Modesto mode...@isimples.com.br: Boa Tarde, Estou pensando em testar o FreeBSD (ou outro BSD que funcione) em routerboards, principalmente as powerpc. Alguém aqui da lista já conseguiu instalar ou tem alguma informação sobre como fazer isso? Antonio, Aqui tem alguma informação sobre o que você precisa para compilar o FreeBSD para uma RB800/RB1000: http://www.fug.com.br/historico/html/freebsd/2012-07/msg00563.html Mas elas não completamente suportadas... Estou trabalhando para que as RB4xx sejam completamente suportadas no FreeBSD (falta pouco) e ai sim possamos gerar alguns manuais de instalação passo a passo. Se você tiver alguma RB para testar, junte-se ao time (de um eheheh). Att., Luiz - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] erro ao compilar o kernel
2012/9/23 Nilton Jose Rizzo ri...@i805.com.br:
Pessoas, estou tentanto customizar um kernel super enxuto
em um VM do Virtual Box, porém estou com dificuldades. Quando
compilo gera esse erro e já procurei e não achei o que esta faltando.
A principio peguei o GENERIC e fui tirando o que eu não tenho/quero
e dá o erro abaixo
segue o arquivo de configuração do kernel e o respectivo erro:
www.rizzo.eng.br/kernel/erro.png
www.rizzo.eng.br/kernel/jails
Nilton,
Tem certeza que você não alterou acidentalmente os fontes do seu kernel ?
Aquela macro não existe daquela forma (a não ser que seja um erro de
copy-paste): TCPS_HAVERCVdSYN
Já a macro TCPS_HAVERCVDSYN() existe e esta definida em tcp_fsm.h que
não parece ser afetado por nenhuma opção do kernel neste ponto.
root@server01:/data/head/sys/netinet # grep -R TCPS_HAVERCVDSYN *
tcp_fsm.h:#define TCPS_HAVERCVDSYN(s) ((s) = TCPS_SYN_RECEIVED)
tcp_output.c: if (TCPS_HAVERCVDSYN(tp-t_state)) {
tcp_subr.c: if (TCPS_HAVERCVDSYN(tp-t_state)) {
Att.,
Luiz
-
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] erro ao compilar o kernel
2012/9/24 Leonardo Augusto lalin...@gmail.com: /usr/cvsup/src ??? nao é mais /usr/src agora ? Os fontes podem ficar em qualquer lugar (e também ser construidos a partir de qualquer path). O /usr/src é apenas o local padrão. Att., Luiz - 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 on Raspberry Pi.
2012/9/11 Alessandro Martins alessandro.mart...@gmail.com: Pessoal, Alguém já fez a instalação? Ainda não... Ja estou com o meu Pi aqui (e comprando outro), mas ainda não tive tempo de compilar e rodar o FreeBSD nele. Você tem um ? vai instalar ? Tem alguma coisa aqui: http://kernelnomicon.org/?p=164 Todo código para o Pi já esta no -head (bom.. só existe o suporte básico - suporte a CPU, timers, etc. A única 'feature' que vi por enquanto é o framebuffer para o console e o hps@ que fez o commit recentemente do suporte ao USB OTG: http://www.mail-archive.com/freebsd-current@freebsd.org/msg141323.html). Se você for instalar, nos conte como foi. Se precisar de ajuda nos avise (efnet/freenode #freebsd-br). Luiz - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] FreeNAS ou NAS4Free
2012/8/9 Eduardo Schoedler lis...@esds.com.br: Pessoal, Vocês conhecem alguma lista de discussão sobre essas distribuições, baseadas em FreeBSD? Alguém conhece essas plataformas? Utilizam em conjunto com o XenServer para exportar volumes por iSCSI? Como fazem para fazer backup, exportar, mover um volume de uma caixa para outra? Enfim, gostaria de saber casos de sucesso e também de problemas. Eduardo, Nós aqui instalamos o FreeNAS pra ver como funcionava, exportando o volume com iSCSI para dois VMWares. Depois dos testes instalamos outro, dessa vez com FreeBSD puro também exportando os volumes ZFS via iSCSI e sendo acessado por outros 2 VMWares. Esses 2 VMWares tem cerca de 15 servidores virtuais, entre windows, FreeBSD e linux. Essa segunda maquina tem um acesso médio (e constante) de 23Mb/s e os picos chegam fácil nos 250Mb/s. Até hoje (150~200 dias de uso) 0 (zero) problemas =) Att., Luiz - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
