Re: [FUG-BR] [OFF] pfsense
Já tive problemas tanto com o Free quanto com o pfSense com bce... eu tb n recomendaria não... as bge, por outro lado, são um pouco mais estáveis, mas nada se compara as boas em.. :D Quanto à sobre qual versão usar... se vc pretende fazer algo pra manter por um bom tempo, e não precisa dos recursos da 2.0.. mantenha-se na 1.2.3... primeiro pq ela já é provada e comprovada, e como o colega falou, bem mais bem documentada... e segundo que, na hora de fazer os caminhos pra upgrade definitivo, o maior foco vai ser dado, sem duvida, a subida release release... subir de rc release pode até ser suportado (afinal, estamos falando aqui de freebsd, né? :D), mas 90% do mundo vai estar fazendo uma mesma coisa.. Agora, se vc quiser viver no fio da navalha, só cuidado pra não se cortar.. Um abraço! 2011/4/29 Danilo Chilene bicof...@gmail.com Boa noite, Testei o Pfsense 2.0 com placas bce em um HP Proliant não foi legal, tive vários problemas. Ainda não recomendo para quem tem placas broadcom. 2011/4/29 Sergio Augusto Vladisauskis sergi...@gmail.com O 2.0RC é baseado no 8.0-RELEASE, então deve estar com poucos drivers compatíveis com placas de rede mais recentes. Também tenho vontade de coloca-lo em produção, pois fazer tudo por vc mesmo é complicado e cansativo as vezes. On Thu, 28 Apr 2011 17:25:32 -0300, Márcio Luciano Donada wrote: Em 28/4/2011 16:37, Sergio Augusto Vladisauskis escreveu: Peguei esses dias a ISO do 2.0 para instalar numa máquina que quero fazer um AP, mas após a instalação, o HD não dá boot nem com reza brava... Andei dando uma olhada, parece que os caras estão utilizando o GRUB para gerenciar o boot! Tentei várias vezes e acabei desistindo do pfSense, fiz meu AP com o FreeBSD 8.2 na unha mesmo. Eu tive um problema com a interface bce0 no pfsense 2, pra testar usei o FreeBSD 8.2-STABLE e não tive nenhum problema. Como o pfsense 2 ainda é RC, vou esperar mais um pouco, pois tenho muita vontade de rodar em um server em produção com pfsense. - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd -- Sergio Augusto Vladisauskis - Oportunix IT Services Brasil - ME - Site: http://www.oportunix.com.br - Fone: +55 13 3822 2300 - Móvel: +55 13 9117 9694 - Skype: oportunix - Registered Linux User: 305281 - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] RES: Duvida Com Servidor que Some do da Rede
Não sei se é uma possibilidade pra voce, mas voce acha que pode ser alguem fazendo algum tipo de ataque na sua rede sem fio? Outra coisa.. vc já mediu pra ver se isso ocorre periodicamente? tipo, a cada 2hs, a cada exatos 30m? []s 2008/8/11 Cobausque [EMAIL PROTECTED] Sim .. pensei nisto tb.. mas pelo menos no arp não encontro erro nenhum tanto no servidor quando em maquina cliente.. cheguei a chcar a rede com snifers e um Linux com uns logs pra ver se achava algo de estranho mas nada .. mesmo .. nada ... -Mensagem original- De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Em nome de Paulo Pires Enviada em: segunda-feira, 11 de agosto de 2008 11:10 Para: Lista Brasileira de Discussão sobre FreeBSD (FUG-BR) Assunto: Re: [FUG-BR] Duvida Com Servidor que Some do da Rede Parece muito com os sintomas de outra máquina usando o IP do servidor. 2008/8/11 Cobausque [EMAIL PROTECTED] Pessoal gostaria de saber da lista .. o que pode estar provocando o seguinte comportamento na rede... O meu servidor some do mapa para quem esta como estação ou seja .. eu sou um cliente do meu servidor .. estou trabalhando normalmente em algum momento do dia não consigo ais chegar neste servidor ... e ao checar o servidor com algum tipo trafshow .. realmente ao há nada passando .. tipo em seguida dou um ping em uma estação tudo volta a funcionar .. ou seja ao tentar qualquer tipo de comunicação no sentido SERVIDOR - CLIENTE funciona .. mas CLIENTE-SERVIDOR não ... Bom é uma rede por radio.. tenho um AP onde todos se conectam pra que a rede funcione. Já foi trocado .. AP que tranmite.. foi trocado equipamento nas estações clientes troquei o freebsd que era um 5.2 passei pra 6.2 instalação do 0.. ou seja sistema operacional 100% novo .. troquei as placas que estão Tb no servidor .. em resumo parte de equipamento físico foi 100% trocado ... sistema do servidor freebsd Tb 100% novo .. mas mesmo assim o comportamento persiste.. Alguém já viu algum comportamento semelhante.. já conversei com algumas pessoas me falaram que poderia ser problema com equipamento.. mas descarto esta idéia pois troquei tudo .. mas mesmo assim o comportamento persiste. Este comportamento é aleatório acontece do nada .. .. do nada para .. e pra voltar basta acessar o servidor e dar pôr exemplo um simples ping na estação cliente e tudo volta a funcionar. - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd -- Um abraço. Paulo A. P. Pires ... Qui habet aurem audiat quid Spiritus dicat ecclesiis. - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Dica autenticação squid
hmm... na verdade, não seria bem ao passwd, ele num tem as senhas.. vc teria que liberar o seu master.passwd, e ensinar ao seu daemon como ler e interpretar isso... eu acho uma péssima ideia ter o seu master.passwd compartilhado, mas ai vai de cada um. a maneira elegante de fazer isso, eu acho que seria via radius, mas também num sei se tem como o squid autenticar via radius. []s Guto 2008/8/13 Filipe Alvarez [EMAIL PROTECTED] 2008/8/13 Aguiar Magalhaes [EMAIL PROTECTED] Pessoal, alguém saberia me dizer como posso fazer o squid autenticar usando o /etc/passwd de outra máquina ? Especificamente para a instrução: authenticate_program /usr/local/libexec/squid/ncsa_auth /etc/passwd Aguiar Tenho certeza que não é a melhor solução, mais você pode compartilhar o acesso ao passwd remoto via NFS ou Samba. []s - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] RES: RES: Maldito Samba?
Correndo o risco de falar uma grande besteira, um ultimo questionamento, sobre os bad cksum: vendo os logs dele, eu percebi que todos os bad checksum são em pacotes SAINDO do gateway para a rede (ou seja, o tcpdump os viu antes deles efetivamente passarem por uma placa de rede). Isso não é um comportamento esperado, já que segundo o ifconfig dele, a placa tem suporte a checksum offloading (RXCSUM, TXCSUM e VLAN_HWCSUM) ? bge0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=9bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM ether 00:13:21:c6:15:e0 inet 192.168.0.254 netmask 0xff00 broadcast 192.168.0.255 media: Ethernet autoselect (1000baseTX full-duplex) status: active []s Guto - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Replicar Instalação
O truque que eu fiz em uma máquina a umas semanas atrás foi com o cpdup (do ports), que consegue fazer uma cópia mais precisa dos arquivos: - Ligue o HD novo e crie as labels e slices que desejar... uma slice para o /, uma para /usr, uma para /home e etc como voce quiser - Monte o / do HD em algum lugar do seu hd, por exemplo, /novo - Monte todas as labels do NOVO hd debaixo de /novo.. /novo/usr, /novo/var, /novo/home e etc.. é importante montar todas as labels que voce vai usar, para que os arquivos já sejam copiados para as labels novas! - crie um arquivo chamado /.cpignore com o nome do diretorio novo (no caso, apenas novo): # echo novo /.cpignore - mude para o diretório raíz, e faça a copia per-se # cd / # cpdup -x . novo - isso VAI demorar. se quiser, pode adicionar o parâmetro -v no cpdup, para ter uma ideia, mas isso aumenta o tempo de cópia. - terminada a cópia, substitua o hd antigo pelo novo (ou instale o novo em outra máquina), tomando o cuidado de marcar corretamente primary/secondary, master/slave identico ao original. - boote com o cd do freebsd, e reinstale o bootloader (já que os arquivos foram copiados, mas não o bootloader) e pronto.. seu micro deve bootar corretamente o novo sistema! lembre-se apenas de, caso os esquemas de labels e slices do HD novo não batam com o anterior, é necessário editar o /etc/fstab para corrigir. Já fiz este procedimento algumas vezes, no serviço, em casa e em VMs, e nunca tive problemas. Aos mais aventurados a fazer isso remotamente, eu sugiro a manpage do cpdup, mas ISSO eu nunca tentei. espero que tenha ajudado. []s - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] RES: Mensagem - dmesg
Rodrigo, Voce pode por favor passar o modelo do servidor e da controladora que voce tem ai? estamos em vias de comprar uns servidores dell com esse processador e controladora SAS, e quero ter isso em mente quando escolher os modelos! []s 2008/8/5 Rodrigo Calado [EMAIL PROTECTED] Esta nova mensagem surgiu: Aug 5 06:48:53 box kernel: Approaching the limit on PV entries, consider increasing either the vm.pmap.shpgperproc or the vm.pmap.pv_entry_max sysctl. O sistema é um freebsd 7.0 amd64 rodando num processador: CPU: Intel(R) Xeon(R) CPU L5335 @ 2.00GHz (2000.08-MHz K8-class CPU) Origin = GenuineIntel Id = 0x6fb Stepping = 11 Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA ,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Features2=0x4e33dSSE3,RSVD2,MON,DS_CPL,VMX,TM2,SSSE3,CX16,xTPR,PDCM,DCA AMD Features=0x20100800SYSCALL,NX,LM AMD Features2=0x1LAHF Cores per package: 4 usable memory = 4281946112 (4083 MB) avail memory = 4120588288 (3929 MB) ACPI APIC Table: PTLTD APIC FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs []s Rodrigo T. Calado | OBCURSOS | Tecnologia da Informação | Supervisor de TI Setor de Indústrias Gráficas, Qd. 01, Número 945 | CEP: 70610-410 | Brasília - DF | Brasil Fone: +55 (61) 3031 | Fax: +55 (61) 3321 9041 | Direto: +55 (61) 3031 7735 D Celular: +55 (61) 9982 7222 / 9304 0706 | E-mail: [EMAIL PROTECTED] -Mensagem original- De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Em nome de Patrick Tracanelli Enviada em: segunda-feira, 4 de agosto de 2008 13:33 Para: Lista Brasileira de Discussão sobre FreeBSD (FUG-BR) Assunto: Re: [FUG-BR] Mensagem - dmesg Rodrigo Calado escreveu: Caros colegas, O meu servidor dedicado estava travando nos últimos dias e obtive a seguinte mensagem através do dmesg: mpt0: QUEUE FULL EVENT: Bus 0x00 Target 0x12 Depth 128 Esta mensagem significa que o servidor cessou a transmissão de dados porque se entupiu? Se puderem me ajudar. Att., Caro Calado (varios poetas tem esse sobrenome), é exatamente isso, na verdade o canal de dados entupiu. Isso pode ter sido causada por um evento de interrupt da placa, em grande demanda de transferencia ou falha do Storage. Esse driver é bem estavel, eu nao consideraria falha nele. Algum problema na fibra tambem pode ser a causa. Como está a topologia da FABRIC onde esse FreeBSD está? Você pode avaliar estatísticas de perdas/retransmissão de dados na porta que está o FreeBSD? Os logs param por ai? Não teve um unable to create a path to send adicional não? Eu uso esse driver com sucesso, quando tive comportamento similar a causa era o switch de fibra. Alias é SCSI ou fibra seu ambiente? -- Patrick Tracanelli FreeBSD Brasil LTDA. Tel.: (31) 3516-0800 [EMAIL PROTECTED] http://www.freebsdbrasil.com.br Long live Hanin Elias, Kim Deal! - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Praticas de Segurança para FreeBSD com DN S
Um detalhe que me ocorreu: Se o servidor que a Cristina está montando for um servidor de resolução recursivo, vai ser necessário liberar a saída de portas altas/UDP to any porta 53, para que o servidor consiga fazer consultas a servidores externos. Uma coisa que eu uma ideia que eu já tive, mas nunca avaliei muito em termos de performance e eficiência, é fazer essa regra da seguinte maneira: ipfw add allow udp from me 1024-65535 to any 53 out keep-state uid bind. Alguem tem alguma opinião formada quanto a isso? (o range de portas eu ainda tenho ver com certeza) []s 2008/7/28 Cristina Fernandes Silva [EMAIL PROTECTED] Parabens irado pelos tutoriais.. 2008/7/28 irado furioso com tudo [EMAIL PROTECTED]: Em Fri, 25 Jul 2008 09:12:24 -0300 Cristina Fernandes Silva [EMAIL PROTECTED] escreveu: Valeu pelas dicas, sobre implementação das regras de bloqueio com ipfw ou pf , o que eu poderia implementar para o DNS, saliento que ele será somente dns e não terá outra função principalmente de nat, controle de banda, proxy, web. Tem alguma dica ? bem.. voce tera de fazer uma analise criteriosa do serviço. Eu começaria assim: a) bloquear TUDO que venha da 'net pra mim - estabelecendo a politica b) aceitar ssh pela porta (???) ou por knock-door somente a partir da maquina ip-addr aqui, que é a maquina de controle c) liberar consultas tcp/udp na porta 53 - DNS c-1) não estou bem certo, mas acho que uma outra porta deve TAMBÉM permanecer aberta pelo mesmo motivo - veja no handbook, por exemplo, quais as portas que escutam solicitações. btw, sugiro ler êstes dois artigos, que cometi tempos atrás, é possivel que vc possa aproveitar alguma coisa como, por exemplo, as alterações em sysctl.conf http://under-linux.org/wiki/index.php/Tutoriais/FreeBSD/FreeBSD-Firewall-1 http://under-linux.org/wiki/index.php/Tutoriais/Seguranca/gw-firewall vc deverá desconsiderar tudo a que se refira a gateway ou bridge, aproveitando apenas as regras in - não esqueça, nada out, esta máquina não tem razão de deixar SAIR algo. adicionalmente insisto: uma boa pesquisa em http://www.onlamp.com/bsd vai esclarecer muita coisa :) divirta-se. -- saudações, irado furioso com tudo Linux User 179402/FreeBSD BSD50853/FUG-BR 154 Não uso drogas - 100% Miko$hit-free Deus, para a felicidade do homem, inventou a fé e o amor. O Diabo, invejoso, fez o homem confundir fé com religião e amor com casamento. (Machado de Assis) - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] dúvida sobre o freebsd-update
hmm.. mais ou menos. Existem os patches que são pra arquivos do sistema, e os patches que são para o kernel. Para os patches de daemons e outros arquivos do sistema (como por exemplo o named), basta que voce reinicie o daemon específico: o freebsd-update faz o patch do source E TAMBÉM do binário respectivo. Agora, para os patches de sources do kernel (como por exemplo o de TCP, que saiu no 7.0-Release-P1), é sim necessário recompilar o kernel, reinstala-lo e reiniciar a máquina para que ele entre em funcionamento. []s 2008/7/29 João Paulo Just [EMAIL PROTECTED] -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Giancarlo Rubio wrote: | Após o update, sem dar boot, o uname -a ainda mostra o FreeBSD 7.0-RELEASE | #0, creio que irá para o 7.0-RELEASE-p3 somente após o boot, certo? | | SIm Não é preciso recompilar o kernel com o novo .h com o #define da versão pra atualizar o printf() do uname não? - -- João Paulo Just Diretor Executivo - Justsoft Informática Ltda. http://www.justsoft.com.br/ - -- Feira de Santana, BA, Brasil. +55 75 8104 8473 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIjwLkXL+vuN2d7ZwRAgMmAJ4qjLyTCsrliDPWnZJ2V+97EoPYXACeL8Ia 2k7qSodaDCaCtW7eGG/GoCk= =BkZJ -END PGP SIGNATURE- - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] RES: Duvidas do IPFW
um truque que me ensinaram para reiniciar a firewall remotamente é dar o seguinte (comando do tcsh:) # sleep 10 ; sh /etc/rc.firewall simple /tmp/firewall.log é importante que voce NÃO TOQUE no teclado até a shell retornar. essa linha vai dar 10 segundos para sessão ficar em silêncio, e ai então re-executará o script de firewall redirecionando toda a saída para um arquivo temporário, sem exibir nada na tela. Assumindo-se que o seu arquivo esteja OK (ou que voce pelo menos tenha uma regra logo depois do flush que libera o ssh para o seu micro), o script vai ser executado e te retornar uma shell e depois voce pode buscar no arquivo gerado se houve algum erro de inicialização da firewall. Só cuidado com: - as regras básicas (as que liberam o ssh para o micro que voce estiver) sempre devem sempre, independente das outras terem erros ou não (inclusive erros de abrir e fechar aspas, que acabam por zonear o resto do arquivo a partir daquele ponto!). - regras stateful (inclusive ssh) vão ser todas fechadas, já que elas vão ser apagadas e reescritas. assim, os states se perdem. - programas que mandam dados periodicamente podem quebrar isso (e te trancar pra fora do sistema). exemplos disso são coisas rodando em background (tail -f /var/log/messages ) e o gerenciador de consolesscreen, se voce configurou ele para aparecer com algum dado periódico (horario ou load) na barra. O importante é que, entre dar o [enter] do comando e a shell retornar (10 a 20 segundos depois, dependendo do numero de regras, carga e velocidade do sistema), NADA deve ser enviado por nenhum dos dois lados através da sessão ssh. []s 2008/7/29 Renato Frederick [EMAIL PROTECTED] compilar o meu kernel sem a opção options IPFIREWALL_DEFAULT_TO_ACCEPT SEM a opção DEFAULT_TO_ACCEPT, ou seja por padrão tudo fechado. Caso esta opção esteja presente ai o padrão é tudo aberto. Vejo como desvantagem o bloqueio da sessão SSH se você der um flush... vai cair no deny all :-( ou seja, o meu firewall é fechado, um de nós dois está enganado.. ali em cima diz que o default dêle é ACEITAR. Eu (se for o caso) não vejo desvantagem em defini-lo como fechado por default, mais fácil de controlar. - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Dynamic DNS with DHCP
Voce chegou a liberar na firewall do master a porta 53/TCP? - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Dynamic DNS with DHCP
Não. A resolução de nomes funciona via UDP, porém os zone-transfers rodam sobre TCP. :) []s Guto On Sat, Jul 26, 2008 at 4:51 PM, Alessandro de Souza Rocha [EMAIL PROTECTED] wrote: nao seria udp. 2008/7/26 Guto Andreollo [EMAIL PROTECTED]: Voce chegou a liberar na firewall do master a porta 53/TCP? - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd -- Alessandro de Souza Rocha Administrador de Redes e Sistemas FreeBSD-BR User #117 Long live FreeBSD Powered by (__) \\\'',) \/ \ ^ .\._/_) www.FreeBSD.org http://www.freebsd.org/ - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Date / Cron !
Quando voce atualiza o /etc/crontab, não é necessário dar nenhum comando, o crond já pega a atualização na hora. Agora, quanto ao problema do horario, dar um kill -HUP no crond não adianta.. eu tive esse problema a alguns dias, e só consegui colocar o crond na hora certa dando um stop / start mesmo. []s On Fri, Jul 11, 2008 at 4:40 PM, Jean Duarte - Cabral Sistemas [EMAIL PROTECTED] wrote: Pessoal, Atualizei a Data de meu servidor pelo sysintall Ficando a Zona: BRT Fri Jul 11 16:38:58 BRT 2008 É assim o correto? Porem meus disparos do Crontab estão sendo efetuados com 3 horas de atraso? Como resolver isso? Quando eu atualizo o /etc/crontab o comando de atualização é um Kill -HUP no Pid dele? Atenciosamente Jean Duarte - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
