Utilizar wireshark como usuário comum :: ubuntu

[Sandro Gambini]

Palavras chave: ubuntu wireshark permissão wireshark-common dumpcap sudo

Para quem utiliza o Ubuntu, o software de captura de pacotes, por filosofia/segurança não permite que usuários comuns façam capturas on-line dos pacotes, estes podem apenas abrir arquivos já capturados.

Pois bem, para utilizar o wireshark no ubuntu em sua plenitude, temos que executá-lo como root ou através do sudo.

Ex.: em um terminal digite: sudo wireshark

ou se preferir executar diretamente da parte gráfica: <ALT+F2> para abrir a janela de comandos e gksudo wireshark

Para permitir que o usuário pobre mortal possa executar o wireshark inclusive para capturas de pacotes, devemos fazer o seguinte:

Através do comando: sudo dpkg-reconfigure wireshark-common, reconfigurar o wireshark para habilitar essa permissão.

Com isso será criado o grupo wireshark como pode se observar em /etc/groups.

Agora basta inserir o usuário pobre mortal, que deve ter a permissão, nesse grupo que a primeira parte estará ok!

 

O último passo é fazer com que o programa /usr/bin/dumpcap faça parte do grupo do wireshark também:

Pronto! Nesse exemplo o usuário sandro tem permissão de executar o wireshark em sua plenitude.

Lembre-se de fazer logoff e logon para o usuário pertencer ao grupo novo. Para checar a quais grupos um usuário pertence, basta executar o comando groups como ele mesmo:

É isso!

Att,
-- 
Sandro Gambini
Engenharia / SAGE
sandro....@automalogica.com.br

(11) 7464-3384

skype: sandrogambini

 AUTOMALÓGICA 
Sistemas para Automação Ltda.

www.automalogica.com.br

R. Casimiro Martho, 101 - Vila Maria Luíza
Jundiaí-SP - CEP. 13209-270

(11) 4521-3261

[Otavio Busnardo]

Prezados usuários,

 

Vou aproveitar o momento para levantar um tema : SOM no SAGE.

 

Tenho participado de um projeto que possui 2 servidores e 2 IHMs. As IHMs se conectam aos servidores por ssh e não pela rede de difusão como alguns projetos que conheço. Os servidores não possuíam placas de som e as IHMs possuíam.  O problema é que não saía som de jeito nenhum nas IHMs que são as máquinas que os operadores irão mexer.

 

Fiz um pequeno teste: fiz minha máquina, que possuía som, como servidor e, fiz a IHM se conectar a minha máquina e ... voilá, funcionou o bendito som !!!

 

Só para constar, lendo o manual de Administração do SAGE, tive que instalar um tal de SSOM na máquina IHM para funcionar o esquema.

 

Agora, se o servidor não tem placa de som, pelo menos comigo, não funcionou. Pensei que funcionaria tendo pelo menos placa de som nas IHMs.

 

Agora, pergunto a quem é mestre de Linux, existe alguma forma de fazer sair som no SAGE sem precisar contar com a placa de som do computador remoto (servidor) ???

 

Alguém já passou por algo semelhante ???

 

Este deve ser um bom tema de discussão !!!

 

Forte abraço a todos !!!

 

Atenciosamente,

OTAVIO BUSNARDO

[Conde Jose Ideburque Leal]

Otavio:

Para começar o SAGE não trabalha com o conceito de mestre/escravo entre seus servidores.

Os dois servidores SAGE estão sempre recebendo ao mesmo tempo as MCD´s ( pacotes chamados de memória compartilhada e distribuida que contém os dados das varreduras realizadas na rede de processo) via  os serviços GCD e GMCD. No entando somente um dos dois servidores é que fica fazendo a difusão dos dados na rede de difusão, AQUELE QUE ESTIVER RODANDO O PROCESSO ALARME. Se você desativar manualmente o processo alarme no VISOR DE PROCESSO, vai verificar que esse processo migra e  passa a rodar no outro servidor, o qual,  então,  passa a fazer a difusão da rede de difusão em substituição ao servidor anterior. 

Antigamente, o SAGE tinha um drive de som no diretório cd :/drivers pode ser que o cepel tenha mantido esse driver lá, embora não se use mais. Esse conversor era que permitia ao SAGE dispor de som, se não me engano.

Da uma olhada lá, que sabe se isso estivr correto ao habilitarmos esse conversor não seja possível fazer o que vc quer ?!

at

Conde

[Rodrigo Claro]

Olá pessoal,

Nós utilizamos uma arquitetura parecida com a proposta, sendo 3 servidores e varias IHM's e nossos alarmes são configurados na base fonte para rodar nas IHM's e não nos servidores. Assim, o SOM funciona perfeitamente nas IHM'S atendendo a necessidade apresentada. 

É importante salientar que o Visor de Alarme depende do processo ALR, assim sendo, precisa estar rodando em pelo menos uma das maquinas que estão na rede de difusão. 

No seu caso, as IHMs não rodam nesta rede e isso sim é um impecilho. Acredito q vc não conseguira desta forma. Experimente colocar as IHMs na rede de difusão e tenho certeza que funcionara. 

-----

Rodrigo Claro 

CTEEP

Sent to IPhone

Twiiter @rlinux

[Otavio Busnardo]

Olá Conde,

 

A questão não entra nem no mérito dos Servidores, mas sim de conexões ssh de uma máquina IHM ao servidor e esta máquina IHM nem está na rede de difusão. Ela pega as informações gráficas via ssh, pois o Linux permite esta funcionalidade.

 

Mas o som era a questão: como capturar o som de uma máquina remota (servidor) ?

 

No manual de Administração tem um esquema de como fazer isto.

 

A questão é : será que consigo som mesmo não tendo uma placa de som instalada no servidor ?

 

Não sei se foi isso que quis dizer, mas tentei o comando para instalar sinal sonoro (quando não existem placas de som), mas o mesmo não funcionou no servidor.

 

 

@Rodrigo,

 

Pois é, a questão é que este funcionamento ocorre no padrão de Furnas, por isso não utilizamos a rede de difusão, eles possuem um script que acessa em ssh os servidores e é assim que eles exigem.

 

Att,

 

Otavio

[Evandro Fantin Abitante]

O SSH pode em tese transportar todos os recursos da máquina remota  para a máquina local.

 

Acho que a questão principal aqui é que neunum som é gerado nos servidores (não há placas de audio nos mesmos), logo não há o que ser transportado para a IHM.

 

Posso estar sendo preciptado, mas não vejo uma solução para esta situação.

 

Abs

 

Alguns links que podem ser úteis:

http://superuser.com/questions/231920/forwarding-audio-like-x-in-ssh

http://linux.die.net/man/1/arecord

 

 

 

Evandro Fantin Abitante
 

Tel: +55 (19) 9140-5168

Chat evandro....@gmail.com

"Bom mesmo é ir à luta com determinação, abraçar a vida e viver com paixão, perder com classe e viver com ousadia, pois o triunfo pertence a quem se atreve, e a vida é muito bela para ser insignificante."

Charles Chaplin

** Aviso_Legal **
Esta mensagem pode conter informações confidenciais e/ou privilegiadas. Se você não for o destinatário ou a pessoa autorizada a receber esta mensagem, não deve usar, copiar ou divulgar as informações nela contida ou tomar qualquer ação baseada nessas informações.

[rlinux]

Ok, duas coisas.

A primeira é o servidor não possuir placa de som. Até onde eu sei isso não é necessário uma vez que o SAGE pode transferir o SOM até mesmo para a campainha do sistema, ou seja, aquele pequeno autofalante que quase todas as máquinas tem. O SOM inclusive fica ensurdecedor ...rsrsrsrs

Use o "aumix" via linha de comando para controlar isso. 

Mas, a solução correta no seu caso (Devido a sua Arquitetura) seria instalar uma versão Exceed On Demand 7.0 ou superior no servidor e conectar as IHM's através dele, assim o Exceed proverá o SOM que vc deseja para as IHM's.

Abraço,

Em 13 de abril de 2012 10:51, Otavio Busnardo <otavio....@smgtech.com.br> escreveu:

--
Rodrigo Tadeu Claro (rlinux)

rlinuxapps.blogspot.com

gplus.to/rlinux

[Evandro Fantin Abitante]

Só pra arrematar o que eu disse anteriormente,

 

creio que o que o SAGE faz (ALR) não é transportar o som propriamente dito, na verdade o host (servidor) envia dados para o cliente (IHM), que os interpleta e produz sons.

 

Inté...

Evandro Fantin Abitante
 

Tel: +55 (19) 9140-5168

Chat evandro....@gmail.com

"Bom mesmo é ir à luta com determinação, abraçar a vida e viver com paixão, perder com classe e viver com ousadia, pois o triunfo pertence a quem se atreve, e a vida é muito bela para ser insignificante."

Charles Chaplin

** Aviso_Legal **
Esta mensagem pode conter informações confidenciais e/ou privilegiadas. Se você não for o destinatário ou a pessoa autorizada a receber esta mensagem, não deve usar, copiar ou divulgar as informações nela contida ou tomar qualquer ação baseada nessas informações.

[Antonio Guglielmi]

Fala Otávio!

Acredito que quando o processo alr é ativado ele faça uma verificação da disponibilidade do som, e caso não esteja disponível mantém os sons do sistema bloqueados. Isso pode ser visto pelas mensagens mostradas na ativação do alr, como "Som disponível no início do processamento" ou "Som indisponível no início do processamento".

Dependendo de como for feito este teste pelo processo, caso o servidor não tenha nenhuma placa de som configurada, o retorno será sempre o de som indisponível, inviabilizando o uso.

Para contornar isso, como já foi dito, antes era possível forçar o SAGE a usar o PC speaker como saída de som (comando drivers/instala_sin). Este script inseria um módulo para ser executado com o kernel, e portanto é dependente do mesmo. Acontece que depois que o SAGE migrou para o CentOS estes módulos não foram atualizados, e o script "instala_sin" não funciona mais. A versão existente no diretório drivers mais recente é sin_2.4.21-27.EL_code.o, que é de um kernel anterior aos 2.6.x usados atualmente.

Bom, com a criação dos sons de alarmes locais, ativados por um serviço de rede que utiliza o servidor de som instalado nas ihms baseadas em conexões X, acredito que esta verificação de disponibilidade do som deveria ter sido modificada, para evitar que o mesmo não funcione quando os servidores não possuem placa de som, que é justamente quando mais precisamos da função.

Bom não sei como é o comportamento interno, portanto tudo pode ser um chute, mas sugiro fazer um teste para ver se é esta disponibilidade ou indisponibilidade indicada pelo processo alr que está atrapalhando o funcionamento.

O SAGE envia os sons para um destes dois dispositivos: /dev/audio ou /dev/dsp. Se o micro não tiver placa de som, provavelmente estes dispositivos não existem.

Tenta "enganar" o SAGE criando links falsos para estes dispositivos:

# ln -s /dev/audio /dev/null

# ln -s /dev/dsp /dev/null

e ativa o SAGE novamente. Provavelmente o alr deve indicar som disponível no início do processamento.

Depois faz a configuração para selecionar o som Local a partir da ihm que está rodando o servidor de som, e vê se melhora o resultado.

Att.

___________________________________________
Antonio José Guglielmi Filho
mail: anton...@gmail.com

2012/4/13 Evandro Fantin Abitante <evandro....@gmail.com>

[Antonio Guglielmi]

Desculpa,

Falei os comandos invertidos. O correto é:

# ln -s /dev/null /dev/audio

# ln -s /dev/null /dev/dsp

Até mais

___________________________________________
Antonio José Guglielmi Filho
mail: anton...@gmail.com

2012/4/13 Antonio Guglielmi <anton...@gmail.com>

[Allan Magri]

Olá Turma, Fizemos esse esquema em uma subestação controladora e está aparentemente funcionando há alguns meses. Um procedimento simples foi executado no computador onde havia necessidade de sair o som do alarme, considerando que foi instalado o CentOS do cepel. (Não é nenhum nóh da rede de difusão). Em $SAGE/drivers: # instala_transportes SSOM Com esse comando, o executável ServSom é colocado no diretório /usr/local/sage_transp e os sons em /usr/local/sage_transp/config/$BASE/bd Abrimos telas por X (sem difusão). No visor de Acesso a opção de som selecionada precisa ser local ao invés de global. (No arquivo main.led é possível escolher o padrão local ou global). Alguns efeitos colaterais são, por exemplo, quando há perda de conexão IP e o som está tocando, não conseguimos silenciar pois perdemos a interface, e o terminal de operação precisa ser reiniciado. Um contorno foi alterar o som contínuo de queda de nó do SAGE para um som breve (ocr.dat), que para depois de algum tempo sozinho (Mas só funciona quando é queda de um nó do SAGE que está servindo telas). Já para o caso de quando abre um DJ, dispara o som contínuo, e logo após falha a conexão com o TO, aí só reiniciando mesmo. Isso aconteceu duas ou três vezes nesses 6 meses, uma delas foi por causa de conflito de IP de um laptop que não faz parte da rede de operação. Dia desses, em conversa no CEPEL, eles me disseram que estava melhorando o sistema de som por IP do SAGE e que poderíamos esperar melhoramentos.... OBS:. Nosso servidor SAGE não possui nenhuma placa de som. Állan. --- On Fri, 4/13/12, Antonio Guglielmi <anton...@gmail.com> wrote:

[Eduardo Fracassi]

Ola Otavio,
Apesar de eu não estar mais atuando diretamente; a ultima ação da CEPEL foi comentada por Allan Magri.
Só completando:
* os updates que relatam sobre o som para o seu caso são 19, 20-1 e 20-11 caso tenha os .lst em mãos
* a instrução para desativar caso necessário é #desinstala_transportes
* ao instalar esse SSOM é apresentado no Visor do SAGE novos botões de SOM que serão utilizados

Comentário extra de um serviço em FURNAS em 2008.
Na data já existia o scripts deles, porém o SOM foi resolvido levando uma "extensão do servidor (caixa de som)" até a mesa do operador.
Importante frisar que ambos servidores tinham placas de som.

Também concordo com o Evandro, onde no seu caso sem a placa de som, acredito não ser possível mesmo que a CPU tenha aquele velho e chato alto-falante padrão.

Em outra ocorrência igual a sua, tentamos fazer sem sucesso:
* instalamos o drive de som no servidor que não tinha placa de som (instruções do sage CEPEL)
* redirecionamos o "audio" para esse drive (instruções do  linux)

É isso
Um abração.

[Rodrigo Claro]

Como disse anteriormente e ao contrario de alguns comentários postados aqui, o SOM funciona mesmo sem placa de som, desde q o hw possua o speaker e que por sua vez, o refinamento pode ser feito via shell com o cmd "aumix". Importante, este pacote não existe no CentOS. Pegue um .deb, converta-o em .rpm "use o alien" e instale com --nodeps. 

Uma opção q utilizamos a 4 anos atras foi a implantação de um servidor de som "à parte" que pegava o som do dispositivo /dev/som e direcionava para o "icecast". Funcionou durante um bom tempo entre nossos Centros de Operaçao que ficam distantes mais de 40km. 

O único problema foi o delay de 3 seg. Mas para uma rede local, isso deve reduzir ainda mais. 

Já testamos o esquema de SOM com rede local e global mas até onde eu sei, esta maquina deve estar na rede de DC. 

-----

Rodrigo Claro 

Sent to IPhone

Twiiter @rlinux