Alterando a resolução de uma Sun Ultra 5

Utilizo ocasionalmente uma estação Sun Ultra 5 no trabalho. Tinha um monitor LCD sobrando e resolvi aposentar o monitor CRT que ainda estava em uso.

Se fosse um computador moderno, plug and play, bastava trocar um monitor pelo outro mas não era o caso.

Antes de fazer a troca verifiquei qual a resolução do LCD, do contrário não teria imagem posteriormente caso o CRT estivesse com uma resolução incompatível. A resolução do LCD era 1280 x 1024 x 60Hz.

Em uma janela de terminal basta digitar o comando:

m64config -depth 8 -res 1280x1024x60 now

-depth é o parâmetro de profundidade de cores.

now ativa a nova resolução.

Basta desligar, trocar os monitores e ligar novamente.

Instalando o android 6.0 Marshmallow no LG Volt H442f

ATENÇÃO: esse método de upgrade para o LG Volt H442f é não-oficial e requer maiores conhecimentos. Se feito inadequadamente pode inutilizar o aparelho!

Ainda não há root para o android 6.0 no LG Volt H442f. Se você precisa de root no aparelho não faça esse upgrade!

Créditos: todo o método foi feito e descrito pelo K Stênio que o enviou como um comentário em outro post. Gentilmente autorizou a publicação que achei bastante completa e importante, apenas formatei o texto para o blog.


 

Descobri ontem dando uma passeada pelo XDA-Developers. Foi lançada uma imagem KDZ Polonesa para o LG-H440N, que em resumo é o mesmo que o nosso LH-H442F. Segui as instruções nos tópicos e consegui instalar no meu aparelho. Está funcionando perfeitamente bem!

Se alguém tiver interesse, fiz um pacote com a maioria dos arquivos necessários aqui: https://www.dropbox.com/s/181rlx7tzbquk5y (só não inclui as imagens KDZ porque são muito grandes).

Para instalar o Android 6.0 Marshmallow em seu LG-H442F (“LG Volt 4G”), basta seguir esses passos:

1º – Extraia os arquivos. Entre na primeira pasta e installe os drivers da LG (recomendo remover os antigos, caso tenha instalado). Talvez seja necessário reiniciar o computador;

2º – Na segunda pasta, abra o arquivo “DOWNLOAD LINK” e baixe a imagem H440n10. Salve ela nessa mesma pasta. Após, coloque o celular em modo de download e rode o programa “LGFlashTool2014” com permissão de administrador para fazer o flash dessa imagem;

3º – Passe a introdução do celular e deixe ele ligado conectado ao computador. Entre na terceira pasta e instale os arquivos do LGUP em ordem (primeiro o LGUP_8994_DLL_Ver_0_0_3_23 e depois o 2nd – LGUP_Install_Ver_1_14_3);

4º – Abra a quarta pasta e execute o comando “h440n.bat” com permissão de administrador;

5º – Finalmente na quinta pasta, faça o download da imagem H440n20a . Após, abra o LGUP e insira o caminho completo de onde está essa nova imagem KDZ, incuindo a extensão (o LGUP não vai conseguir enxergar o arquivo pois está configurado apenas para a extensão .tot e não para .kdz, mas funciona mesmo assim);

6º – Clique no botão start e espere. O celular irá reiniciar algumas vezes e então você terá o Android 6.0 Marshmallow!

Pokémon GO: Failed to detect location.

Pokémon GO foi oficialmente lançado no Brasil fazendo o mesmo sucesso que o jogo obteve no mundo.

Pude observar um problema, a mensagem de Failed to detect location. Curiosamente o problema é restrito o jogo, qualquer outra aplicação (Google Maps, iGO, GPS Tester) que faça uso do GPS funciona normalmente e em poucos segundos obtém a posição do sensor GPS do aparelho.

É possível observar nos ícones indicadores que o GPS está ativo e a localização também.

O problema ocorre quando o aparelho está com a opção “Permitir localizações fictícias” (“Allow mock locations”) habilitada no menu de configuração “Opções de desenvolvedor” (“Developer options”).

Desmarque essa opção e o jogo poderá utilizar o GPS sem maiores problemas.

Sem a mensagem de erro de localização após a alteração:

2016-08-06 13.29.37

Movendo VMs entre hosts VMware ESXi sem VMotion ou armazenamento compartilhado

Trabalho com diversos servidores VMware ESXi para otimizar a utilização de recursos de hardware. Ocasionalmente é necessário mover ou copiar alguma máquina virtual entre servidores.

Sem o ambiente vSphere e a ferramenta vMotion as opções são escassas: copiar as VMs para um drive externo, o que implica acesso físico aos servidores (nem sempre possível ou conveniente) ou copiar a VM através do cliente gratuito VMware vSphere para o armazenamento da máquina onde ele está instalado e, em seguida, fazer a cópia para o servidor de destino. Nesse caso é necessário que a máquina tenha espaço livre em disco suficiente para receber a cópia.

A opção que permite essa operação sem as cópias intermediárias é a ferramenta ovftool, disponível para download gratuito no próprio site da VMware (necessário criar uma conta gratuita para fazer o download). Há versões para Linux e Windows, 32 e 64 bits.

É uma ferramenta de linha de comando, assim o exemplo utilizado tem os mesmos comandos qualquer que seja a versão utilizada.

Para instalar no linux execute o seguinte comando após baixar:

$ sudo ./VMware-ovftool-4.1.0-2459827-lin.i386.bundle

No exemplo o servidor de origem tem hostname camaleao, o de destino zebra. A VM a ser copiada é Papagaio. Os servidores tem root como usuário administrativo e os datastores estão como o nome default datastore1.

Para verificar se a VM está disponível usamos o comando ovftool vi e informamos a senha do usuário root:

$ ovftool vi://root@camaleao
Enter login information for source vi://camaleao/
Username: root
Password: ***********
Error: Found wrong kind of object (ResourcePool). Possible completions are:
Papagaio
Hydra_2k3
Gaviao
Hydra_VM
Morgan_2k3

Faça o mesmo no servidor de destino para  se certificar que não existe uma VM com mesmo nome:

$ ovftool vi://root@zebra.acessonet.com.br
Enter login information for source vi://zebra/
Username: root
Password: ***********
Error: Found wrong kind of object (ResourcePool). Possible completions are:
javali
Hamster
Dragao

Após a verficação inicial o comando ovftool -ds é utilizado para fazer a transferência (observe que é necessário se autenticar em cada um dos servidores):

$ ovftool -ds=datastore1 vi://camaleao/Papagaio_DNS vi://zebra
Enter login information for source vi://camaleao/
Username: root
Password: ***********
Opening VI source: vi://root@camaleao:443/Papagaio_DNS
Enter login information for target vi://zebra/
Username: root
Password: ***********
Opening VI target: vi://root@zebra:443/
Deploying to VI: vi://root@zebra:443/
Transfer Completed
Completed successfully

O tempo de transferência pode ir de minutos a horas, dependendo da velocidade da rede, servidores e do espaço em disco ocupado pela máquina virtual.

Após a cópia basta fazer ajustes necessários de endereço IP, VMWare tools, etc.

Atenção! Se a VM tiver em sua configuração uma imagem ISO como drive de CD ou DVD o processo é interrompido com a mensagem “The task was canceled by a user” como pode ser visto abaixo:

$ ovftool -ds=datastore1 vi://camaleao/Papagaio_DNS vi://zebra
Enter login information for source vi://camaleao/
Username: root
Password: ***********
Opening VI source: vi://root@camaleao:443/Papagaio_DNS
Enter login information for target vi://zebra/
Username: root
Password: ***********
Opening VI target: vi://root@zebra:443/
Error:
– The task was canceled by a user.
Completed with errors

Basta alterar a configuração da VM e remover a imagem e deixar a opção CD/DVD como a do servidor.

iGO no android kitkat 4.x e lollipop 5.x com root

Algumas pessoas gostam de utilizar o programa de GPS iGO nos celulares android, para terem uma opção de navegação completamente offline, em termos de mapas e rotas.

A partir do android kitkat o Google mudou a api que permite o acesso ao cartão SDHC do dispositivo por programas de terceiros, causando alguns problemas relativos a perda de acesso a gravação no cartão de memória.

No caso do iGO algumas pessoas estavam instalando o programa inteiro na memória interna do aparelho, mas isso é só para quem tem dispositivos com muita memória, já que dependendo da configuração de mapas a instalação ocupa facilmente 500M, podendo chegar a 1G.

Fiquei curioso e resolvi fazer uns testes. A instalação ocorria normalmente, mas observei que toda vez que o programa fosse acessado era necessário fazer a configuração inicial (linguagem, escolha de vozes, sistema de medidas, configurações regionais).

Com o adb dei uma olhada no diretório da aplicação (no caso um LG H442f firmware 10f, a localização pode mudar entre diferentes fabricantes e versões de firmware):

C:\adt-bundle-windows-x86-20131030\sdk\platform-tools> .\adb shell
shell@c70ds:/ $ su
su
root@c70ds:/ # cd /data/data/com.navngo.igo.javaclient
cd /data/data/com.navngo.igo.javaclient
root@c70ds:/data/data/com.navngo.igo.javaclient # ls -l
ls -l
lrwxrwxrwx u0_a118  u0_a118           2016-04-21 21:47 android_linked_root -> /storage/external_SD/iGO/
lrwxrwxrwx u0_a118  u0_a118           2016-04-21 21:47 branding.gro -> /storage/external_SD/iGO/branding.gro
lrwxrwxrwx u0_a118  u0_a118           2016-04-21 21:47 branding.zip -> /storage/external_SD/iGO/branding.zip
drwxrwx--x u0_a118  u0_a118           2016-04-21 21:47 cache
lrwxrwxrwx u0_a118  u0_a118           2016-04-21 21:47 content -> /storage/external_SD/iGO/content
lrwxrwxrwx u0_a118  u0_a118           2016-04-21 21:47 data.gro -> /storage/external_SD/iGO/data.gro
lrwxrwxrwx u0_a118  u0_a118           2016-04-21 21:47 data.zip -> /storage/external_SD/iGO/data.zip
lrwxrwxrwx u0_a118  u0_a118           2016-04-21 21:47 debug -> /storage/external_SD/iGO/debug
lrwxrwxrwx u0_a118  u0_a118           2016-04-21 21:47 gfx -> /storage/external_SD/iGO/gfx
-rw------- u0_a118  u0_a118         2 2016-04-21 21:47 kuka_logger.txt
lrwxrwxrwx install  install           2016-04-22 00:31 lib -> /data/app/com.navngo.igo.javaclient-2/lib/arm
lrwxrwxrwx u0_a118  u0_a118           2016-04-21 21:47 license -> /storage/external_SD/iGO/license
-rw------- u0_a118  u0_a118        94 2016-04-21 21:47 monkey.txt
lrwxrwxrwx u0_a118  u0_a118           2016-04-21 21:47 save -> /storage/external_SD/iGO/save
-rw------- u0_a118  u0_a118       656 2016-04-21 21:47 sentinel.txt
lrwxrwxrwx u0_a118  u0_a118           2016-04-21 21:47 sys.txt -> /storage/external_SD/iGO/sys.txt
lrwxrwxrwx u0_a118  u0_a118           2016-04-21 21:47 ui_android -> /storage/external_SD/iGO/ui_android
lrwxrwxrwx u0_a118  u0_a118           2016-04-21 21:47 ui_igo9 -> /storage/external_SD/iGO/ui_igo9
lrwxrwxrwx u0_a118  u0_a118           2016-04-21 21:47 ux -> /storage/external_SD/iGO/ux

Pode-se observar que a maioria dos arquivos estão com link simbólico, isto é, o arquivo está fisicamente no cartão SDHC (/storage/external_SD) e são referenciados na memória interna, para economizar o armazenamento interno do aparelho.

A informação de link está presente tanto no “l“(ink) das permissões vistas no lado esquerdo (ex.: lrwxrwxrwx) como no símbolo -> do lado direito que aponta onde fisicamente está armazenado o arquivo.

No caso de um aparelho com root fica fácil corrigir o problema, basta trazer o mínimo necessário de arquivos para a memória interna, que são os arquivos que sofrem algum tipo de escrita (preferências, locais favoritos, etc): sys.txt e as pastas android_linked_root e save. Para isso remove-se o link com o comando rm e copia-se o arquivo com o comando cp:

root@c70ds:/data/data/com.navngo.igo.javaclient # rm sys.txt
root@c70ds:/data/data/com.navngo.igo.javaclient # cp /storage/external_SD/iGO/sys.txt .

As pastas android_linked_root e save são removidas com o rm e criadas internamente com o comando mkdir. Basta recriar a pasta save, a pasta android_linked_root é criada de maneira automática pelo programa com todas as permissões e conteúdos necessários quando o iGO é executado pela primeira vez:

root@c70ds:/data/data/com.navngo.igo.javaclient # rm android_linked_root
root@c70ds:/data/data/com.navngo.igo.javaclient # rm save
root@c70ds:/data/data/com.navngo.igo.javaclient # mkdir save

Os arquivos criados e copiados são pertencentes ao usuário que os criou (root), então é necessário corrigir a propriedade para que fique igual ao usuário interno do programa (u0_a118, no exemplo):

...
drwx------ root root 2016-04-22 01:00 save
-rw------- u0_a118 u0_a118 656 2016-04-21 21:47 sentinel.txt
-rwx------ root root 13455 2016-04-22 00:58 sys.txt
...
root@c70ds:/data/data/com.navngo.igo.javaclient # chown -R u0_a118.u0_a118 sys.txt save

Após a correção das permissões temos o seguinte:

drwx------ u0_a118 u0_a118 2016-04-22 01:00 save
-rw------- u0_a118 u0_a118 656 2016-04-21 21:47 sentinel.txt
-rwx------ u0_a118 u0_a118 13455 2016-04-22 00:58 sys.txt

A partir desse momento o iGO passa a funcionar corretamente, não sendo necessário a configuração inicial a cada utilização e a gravação de favoritos e demais personalizações são permanentes.

Windows 2003 travando periodicamente

Um dos servidores em que trabalho travava periodicamente a cada 21 dias. Sem pistas, eu ficava observando e analisando os logs do Eventviewer.

Um dia uma mensagem me chamou a atenção, estava registrada pouco antes primeiros erros no AD, NTFRS e DNS:

Event Type: Error
Event Source: NTDS General
Event Category: Service Control
Event ID: 2103
Date: 11/29/2009
Time: 12:16:22 AM
User: NT AUTHORITY\ANONYMOUS LOGON
Computer: Server
Description:
The Active Directory database has been restored using an unsupported restoration procedure.
Active Directory will be unable to log on users while this condition persists.

Comecei a fazer buscas para esse problema e achei uma solução interessante nesse post e com uma discussão detalhada do que pode causar esse problema:

https://awinish.wordpress.com/2010/12/24/netlogon-paused-issue-resolved/

A solução correta é fazer o demote e promote do servidor em questão no Active Directory

A solução do problema abaixo não é a mais correta do ponto de vista técnico mas é funcional (e rápida):

-Abra o  Regedit no servidor problemático do AD
-Abra HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters
-Encontre a chave Dsa Not Writable=dword:00000004
-Delete a chave completa
-Abra um prompt de comando e desabilite a replicação com o comando:

C:\temp> repadmin /options nome_do_servidor -DISABLE_OUTBOUND_REPL 

-Habilite a replicação com o comando:

C:\temp> repadmin /options nome_do_servidor -DISABLE_INBOUND_REPL 

-Reboot o servidor

A maneira correta é com o demote e promote do servidor em questão, essa informação é um método rápido e não recomendado, apesar de funcional.

VMware – Erro no Event Viewer: Failed registration of app type 2

Estava observando erros frequentes no Event Viewer em alguns servidores Windows 2003 em hosts VMware ESXi 5.x.

A mensagem completa no Event Viewer:

Event Type: Warning
Event Source: VMware Tools
Event Category: None
Event ID: 1000
Date: 16/1/2016
Time: 15:18:23
User: SRV-DESKTOP-REM\user
Computer: SRV-DESKTOP-REM
Description:
[ warning] [vmusr:vmtoolsd] Failed registration of app type 2 (Signals) from plugin unity.

Após muitas informações desencontradas, o problema básico é que o arquivo tools.conf não é criado, é criado vazio ou seu conteúdo (em caso de upgrade do tipo de VM) está com valores incorretos.

Para as versões VMware 5.x o conteúdo correto é o seguinte:

[logging]
log = true

# Enable tools service logging to vmware.log
vmsvc.level = debug
vmsvc.handler = vmx

# Enable new "vmusr" service logging to vmware.log
vmusr.level = error
vmusr.handler = vmx

# Enable "Volume Shadow Copy" service logging to vmware.log
vmvss.level = debug
vmvss.handler = vmx

Ele deve ser salvo com o nome tools.conf na pasta apropriada do OS guest.

Windows XP and Windows Server 2000/2003:

C:\Documents and Settings\All Users\Application Data\VMware\VMware Tools\tools.conf

Windows Vista, Windows 7, and Windows Server 2008  :

C:\ProgramData\VMware\VMware Tools\tools.conf

Linux, Solaris e FreeBSD :

/etc/vmware-tools/tools.conf

Maiores detalhes:

https://communities.vmware.com/thread/419192

http://kb.vmware.com/kb/2036350

Passando uma variável shell Unix para uma query SQL

Resolvi alterar alguns scripts que coletavam dados de arquivos texto de log por meio de querys SQL em um banco de dados.

Os scripts rodam após a meia noite e os dados coletados são do dia anterior.

Não gostei muito da sintaxe dos comandos SQL para selecionar a data do dia anterior, ia ter que deixar os comandos num arquivo .sql externo, queria queries de uma linha dentro do shell.

Criar uma variável com a data do dia anterior é fácil com o uso do comando date em formato AAAA-MM-DD, mas estava com problemas para que o SQL abrisse a variável. A solução é o uso de aspas duplas para a query a ser executada e simples na parte do comando onde a variável deve ser convertida.

#!/bin/sh
 ontem=$(date +%F --date="1 days ago") 
# Extraindo dados do banco de dados MySQL 
/usr/bin/mysql -u db_user -pdb_password -e "select FromHost from SystemEvents WHERE ReceivedAt LIKE '%${ontem}%' " DataBaseName

Análise e visualização de arquivos de log

Por conta de alguns equipamentos remotos que gerencio comecei a fazer a coleta de logs em um único servidor Linux, o problema passou a ser como tratar e visualizar esses logs.

Algumas necessidades são cobertas por scripts que varrem os arquivos e enviam emails automáticos informando situações de maior severidade.

O que eu queria de verdade era poder analisar esses arquivos por meio de uma página onde eu pudesse fazer buscas por horário, equipamento, tipo de erro ou alguma combinação.

Para isso os arquivos deveriam ser consolidados em um banco de dados e uma interface web seria acrescentada.

A necessidade seria coberta com um conjunto de utilitários:

rsyslog – versão mais moderna do syslog original do Linux, com o recurso de acesso a um banco de dados SQL para consolidação dos dados.

MySQL – o banco de dados SQL escolhido. Poderia ser o PostgreSQL

LogAnalyzer – frontend em PHP para visualização e análise dos logs.

rsyslog – Instalação e configuração

A substituição do syslog pelo rsyslog é bem simples, basta instalar o pacote:

Comandos para CentOS e RedHat:

yum install rsyslog rsyslog-mysql

Comandos para Debian e Ubuntu:

apt-get install rsyslog rsyslog-mysql

Como e já tinha o MySQL configurado basta criar o banco de dados para o rsyslog. O rsyslog fornece um script pronto que cria um banco chamado Syslog:

# mysql < /usr/share/doc/rsyslog-mysql-3.22.1/createDB.sql

mysql> grant all on Syslog.* to syslogwriter@localhost identified by 'syslogwriter_password';
mysql> flush privileges ;

 

Como eu já usava o syslog para fazer a coleta copiei o arquivo /etc/syslog.conf para /etc/rsyslog.conf e adicionei adicionei as linhas necessárias para o rsyslog no início do arquivo:

# Use traditional timestamp format
#$ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat

# Provides kernel logging support (previously done by rklogd)
$ModLoad imklog

# Provides support for local system logging (e.g. via logger command)
$ModLoad imuxsock

# provides UDP syslog reception
$ModLoad imudp
$UDPServerRun 514

# provides MySQL database support
$ModLoad ommysql

e no final do arquivo as linhas para acesso ao banco de dados:

# Logging mysql database
*.* >localhost,Syslog,syslogwriter,syslogwriter_password

Baixei e instalei o LogAnalyser

tar zxvf loganalyzer-3.6.5.tar.gz

cd loganalyzer-3.6.5
mkdir /var/www/html/syslog
cp -a src/* /var/www/html/syslog

cd /var/www/html/syslog
touch config.php
chmod 666 config.php

Abra um browser e abra a configuração inicial do LogAnalyzer:

http://localhost/loganalyzer/

Informe o nome do banco de dados, usuário e senha.

O resultado é muito bom:

Podemos selecionar por evento (ssh):

loganalyzer_1

Ter uma visão geral (observe que clicar sobre uma linha permite usar esse evento como filtro):

loganalyzer_2

E a página de estatísticas:

loganalyzer_3

Making a backup of your DD-WRT config

Tremenda dica para fazer um backup das configurações do dd-wrt!🙂

Matt's Entropy

Assuming you have ssh enabled on your DD-WRT, and that your DD-WRT is at ddwrt.lab.test, the following will generate a shell script that can be used to restore your config:

ssh root@ddwrt.lab.test 'nvram show | grep = | cut -d"=" -f 1 | while read key; do echo nvram set $key="$(nvram get $key)"; done' > ddwrt.config

Restore is then simply:

cat ddwrt.config | ssh -q root@ddwrt.lab.test

Ver o post original

Matt's Entropy

... seeding /dev/random, one blog post at a time.

Maravilhoso Mundo Novo

De volta ao Paraíso

androideia

Idéias e Android, necessariamente não nessa ordem.

Another Airgun Blog

Idéias e Android, necessariamente não nessa ordem.

Armas de Pressão - Modificações e afins

Metade da graça em atirar está em fazer ajustes na arma.

Seguir

Obtenha todo post novo entregue na sua caixa de entrada.

Junte-se a 163 outros seguidores