Re: [FUG-BR] Monitoramento dispositivos e servidores

2015-05-31 Por tôpico allanpk
 

Valeu. Estive fazendo alguns teste e vi que estações/servidores com
Windows permitem a conexão Snmp, não enviam dados para fora. 

Existe algum agent para Cacti que faça esse envio? O cenário seria +ou-:


20 clientes com grupos distintos. Alguns desses com servidores e
estações a serem monitorados. 

Para fechar 20 conexões VPN ficaria oneroso, ainda que algum desses tem
a mesma faixa de ip e até mesmo nomes de hosts iguais. 

Valeu por demais sugestões. 

Em 18/05/2015 12:20, Patrick Tracanelli escreveu: 

 On 17/05/2015, at 17:17, alla...@ig.com.br wrote: A sugestão seria criar 
 grupos snmp por cliente e gerir via cacti?
 
 Nem precisa de grupo. Define a community, IP e senha de quem pode consultar 
 seu SNMP e configura isso no cacti. Ja que seu cacti ficará na nuvem ele ao 
 menos terá um IP previsível então sabendo a origem da consulta controle por 
 IP e community até sem senha podem ser suficientes especialmente pra 
 monitorar ativos que só suportem snmpv1 ou v2 sem v2c ou v3 onde senhas 
 existem. Ou se for uma rede ampla e complexa, com muitos ativos pra monitorar 
 e todos com IPs RFC1918, ou qualquer dificuldade pra rotear acesso externo, 
 feche uma VPN.
 
 A senha de conexão seria do cacti e segurança via snmp?
 
 A senha pra acesso ao Cacti voce faz como quiser, usa autenticação do Cacti, 
 ou usa do Cacti com authn_digest ou do cacti com authn_otp ou os 3 juntos, o 
 que sua paranoia pedir ;-) E do cacti pro ativo monitorado como mencionado 
 acima...
 
 Valeu
 
 []s
 
 --
 Patrick Tracanelli
 
 FreeBSD Brasil LTDA.
 Tel.: (31) 3516-0800
 316...@sip.freebsdbrasil.com.br
 http://www.freebsdbrasil.com.br [1]
 Long live Hanin Elias, Kim Deal!
 
 -
 Histórico: http://www.fug.com.br/historico/html/freebsd/ [2]
 Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd [3]
 

Links:
--
[1] http://www.freebsdbrasil.com.br
[2] http://www.fug.com.br/historico/html/freebsd/
[3] 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] Uso de opções do tar no FreeBSD

2015-05-31 Por tôpico Marcelo Gondim

Buenas Eduardo,

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

Caríssimos(as)

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

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

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

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


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



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

Obrigado pela atenção

Um abraço

Eduardo





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


Re: [FUG-BR] Problemas com a atualização no FreeBSD-10.1 STABLE amd64

2015-05-31 Por tôpico Nilton Jose Rizzo
Em Sat, 30 May 2015 16:45:55 -0300, Eduardo Lemos de Sa escreveu
 Caros Paulo e Renato
 
 Em 30/05/2015 09:49, Renato Botelho rbga...@gmail.com escreveu:
 
   On May 29, 2015, at 11:28, Eduardo Lemos de Sa 
 eduardo.lemosd...@gmail.com wrote:
  
   Caríssimos
  
   Esbarrei num problema pra lá de estranho: após fazer a atualização do
   FreeBSD-10.1-STABLE AMD64, na última quarta-feira à noite, comecei a ter
   problemas sérios. Após fazer a compilação (o make buildkernel e o make
   buildworld funcionaram, como sempre, sem qualquer problema ou warning) e
   fazer a instalação (make installkernel KERNCONF=GENERIC e make
   installworld), sem qualquer problema, ao rebootar a máquina, o processo
 é
   interrompido (as mensagens vão até o momento em que aparece as menções
 para
   o fuse-bsd). Para resolver o problema, eu carreguei o kernel.old, que
 foi
   até o fim com o processo de boot. Para ver se eu corrigia o problema,
   baixei tudo novamente via svn, recompilei, instalei e o problema voltou
 a
   se repetir.
   Eu não creio que seja problema de hardware porque, se fosse, o
 kernel.old
   [também apresentaria falhas. Olhando o /var/log/messages encontrei isto
  
   acpi_throttle1: failed to attach P_CNT (e que se repete para os outros 7
   cores da máquina)
  
   Também apareceu um
  
   xhci0 XHCI halt/start/probe failed err=18
  
   Tentei resolver o problema da mais forma mais rápida possível:
  
   cp -r /boot/kernel.old /boot/kernel
  
   acreditando que no reboot o kernel.old seria carregado como sendo o
 kernel
   corrente; não funcionou. Então eu copiei o /boot/loader.old para
   /boot/loader e também não funcionou.
  
   Então eu editei o /boot/loader.conf, que estava assim:
  
   nvidia_load=YES
   vboxdrv_load=YES
   atapicam_load=YES
   fuse_load=YES
   sem_load=YES
   amdtemp_load=YES
   kern.maxfiles=25000
   kern.ipc.semmni=1250
   kern.ipc.semmns=9000
   #kern.ipc.shmmax=2863311530
   #kern.ipc.shmall=4194304
 
  Você recompilou o fuse na nova versão? Pq como ele cria um módulo pro
 kernel tem que estar compatível com o stable mais novo.
 
 
 Obrigado pela atenção.
 
 Eu reinstalei o fuse, mas o problema não se resolveu. Como o reboot
 acontece depois deste driver ser carregado, acho que o problema não estah
 nele. Por outro lado, hab mensagens de erro no carregamento dos 
 drive da CPU AMD 64 em cada um dos cores. O que eh estranho eh que 
 se o erro estivesse no drivers do proc, muita gente no mundo estaria 
 gritando, e alto :-) . Mais estranho ainda eh que eu havia copiado 
 os binários do sistema e do kernel para outras máquinas - uma 
 inclusive, com um proc AMD 1075 com 6 cores - instalei-os e não 
 houve problemas. Ou seja, os binários criados em uma máquina não 
 funcionaram nela mas funcionaram em outras máquinas, exceto em uma 
 que apresentou o mesmo tipo de comportamento. Agora, eu resolvi o 
 problema: fiz um boot kernel.old, fiz um svn e carreguei os fontes 
 da versão Release (e não o STABLE, revisão 283269, recompilei tudo - 
 sistema e kernel - instalei e fiz o reboot. Tudo funcionou bem. O 
 estranho, se é que exista algo de não estranho nisto, é que eu 
 pensava que o RELEASE rev 283269 e o STABLE revision 283269 fossem a 
 mesma coisa. Pelo jeito, não o são.
 
 Obrigado pela atenção de vocês
 
 Um abraço
 
 Eduardo

   Não são não ... Versões stable e RELEASE são diferentes em sua
essência.  Axho que o pessoal na lista internacional está chiando
por alguma instabilidade no stable dê uma olhada

  Renato e outros,

 Não só o fuse, mas qualquer ports que use um módulo de
kernel DEVE ser atualizado apois a atualização do sistema,
tais como: Virtual Box, NVidea, fuse só para citar alguns


 
  --
  Renato Botelho
 
  -
  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


---
/*
**Nilton José RizzoUFRRJ
**http://www.rizzo.eng.br  http://www.ufrrj.br
**http://lattes.cnpq.br/0079460703536198
**/

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