Criando um switch KVM por software

Nessa postagem mostrarei como fazer um KVM-switch para Linux usando apenas software e um pouco de hardware compatível.

Para começar você precisa dos seguintes dispositivos:

E dos seguintes softwares instalados: ddcutil e Solaar. A instalação deles no Fedora é bastante simples, já que eles estão nos repositórios oficiais do projeto:

sudo dnf install -y solaar ddcutil

Mouse e Teclado

É bem provável que você já tenha o Solaar instalado se você tem o teclado e o mouse da Logitech. De qualquer maneira, a documentação do projeto fornece os passos iniciais para configurar o Solaar, caso seja necessário.

Você pode inspecionar a configuração dos dispositivos usando o comando solaar show. Pessoalmente acho mais simples verificar na GUI do Solaar, já que ela também mostra quais os valores aceitáveis para o comando que usaremos adiante. A informação relevante para nós é a mostrada em “Change Host“. Ela mostra os nomes dos hosts com os quais seu dispositivo está pareado.

Usando as informações mostradas na UI, podemos usar a linha de comando para trocar o host ativo:

solaar config "MX Keys" change-host 1:mercury

Note que o nome do host tem que ser igual ao mostrado na UI e em alguns casos pode ser que somente o número do ID seja mostrado.

Repita o mesmo para o mouse, tomando cuidado de garantir que o ID utilizado é o ID do dispositivo, pois é possível que os eles sejam diferentes entre o mouse e o teclado (ex.: o host 1 do teclado é o host 2 do mouse, etc):

solaar config "MX Master 3" change-host 1:mercury

Monitor

Para controlar o monitor, usamos o programa ddcutil, que serve para interagir com o software do monitor através do conjunto de protocolos DDC-CI. Nesse link aqui, que serviu de referência pra implementar o controle do monitor, você encontra algumas dicas legais sobre o ddcutil.

O primeiro passo é detectar o monitor e ver quais as funcionalidades estão disponíveis:

sudo ddcutil detect

Em algumas distribuições pode ser necessário carregar o módulo i2c-dev. O Fedora já costuma fazer isso por padrão, então nenhum passo a mais é necessário. Se estiver usando outra distro, consulte a documentação.

Se executado com sucesso, o comando vai mostrar uma saída semelhante a esta aqui:

Display 1
I2C bus: /dev/i2c-2
EDID synopsis:
Mfg id: GSM
Model: LG Ultra HD
Serial number:
Manufacture year: 2017
EDID version: 1.3
VCP version: 2.1

Se você estiver usando um laptop, o comando também vai mostrar a informação do monitor embutido. Esse monitor embutido não é relevante para o KVM-switch virtual, portanto podemos ignorar as mensagens de erro referentes a ele.

A informação relevante mostrada pelo comando acima é o I2C bus. Mais especificamente, o número do bus (2, no caso de /dev/i2c-2). Tendo a informação do bus, podemos usa-la para descobrir as funcionalidades do monitor. Para o KVM-switch estamos interessados na funcionalidade “Input Source“. Podemos usar o seguinte comando para descobrir o ID da feature e os valores aceitáveis para configura-la.

sudo ddcutil capabilities --bus=2 | grep -A 5 "Input Source"

Feature: 60 (Input Source)
Values:
11: HDMI-1
12: HDMI-2
0f: DisplayPort-1
10: DisplayPort-2

Isso nos mostra que para mudar o dispositivo de entrada do monitor, podemos usar a feature ID 60 usando os valores (em hexadecimal) 0x11, 0x12, 0x0f e 0x10. Para testar, nesse caso:

sudo ddcutil --bus=2 setvcp 60 0x0f &

Executando esse comando já é possível trocar a entrada do monitor usando apenas a linha de comando.

Finalizando e Integrando no Gnome

Tendo em mãos os comandos para mudar o mouse, teclado e monitor. Podemos colocar tudo isso num script:

sudo ddcutil --bus=2 setvcp 60 0x0f &
solaar config "MX Keys" change-host 2
solaar config "MX Master 3" change-host 2

Repita o processo para outros hosts do seu KVM-switch virtual (ex.: micro 1, micro 2, etc). Não esqueça de dar permissão de execução nos scripts.

Por fim, podemos criar atalhos de teclado no Gnome para que execute esses scripts.

Como funciona?

No meu caso eu configurei os atalhos Ctrl+F2 para alternar para o laptop do trabalho e Ctrl+F3 para alternar para o laptop pessoal.

Obs.:

  • Imagino que funciona com qualquer teclado Logitech com suporte a múltiplos dispositivos (tipo o K810), mas eu não testei.
  • Assim como o teclado, acredito que deve funcionar com outros mouses com suporte a múltiplos dispositivos, tipo o Logitech M720 Triathlon.
  • É possível usar o ddcutil sem sudo e o artigo de referência mostra como fazer isso, porém fiz isso aqui.

Distribuições Linux compatíveis com o padrão Unix

Estava acompanhando uma discussão sobre sistemas Unix no grupo de usuários Fedora Brasil e resolvi pesquisar, a título de curiosidade, se existiam e quais as distribuições Linux certificadas dentro da Especificação Única do Unix (Single Unix Specification – SUS).

Segundo o artigo da Wikipedia que fala a respeito da SUS, existem duas distribuições Linux certificadas como Unix 03:

Ambas são distribuição Linux da família “Red Hat”. O artigo não diz, exatamente, se é uma variante do Red Hat Enterprise Linux – RHEL, portanto cito-o exatamente como descrito no artigo.

Obs.: a versão em português do artigo da Especificação Única do Unix também cita uma distribuição chamada Linux-FT, mas não encontrei nada recente sobre essa distribuição. Esse artigo do Linux Journal de Agosto de 1996 fala um pouco sobre ela. Parece que a distribuição/produto (???) foi adquirida pela Caldera.

Pacotes do OpenPHT para o Fedora

Eu empacotei o OpenPHT, um fork do Plex Home Theater mantido pela comunidade. O Plex Home Theater faz parte de um conjunto de aplicações para “media centers” e roda em diversos sistemas operacionais.

Os pacotes podem ser baixados desse link (no futuro espero contribuir o spec do pacote para o projeto upstream mas, antes disso, pretendo garantir que eles estão plenamente funcionais).

Para os interessados, as instruções de compilação podem ser encontradas nesse gist ou então, na especificação do arquivo RPM que está disponível neste link.

Atualizando o hostname de um Foreman Proxy

Recentemente tive que reconfigurar um dos meus proxies Foreman (cuja instalação e configuração em conjunto com a libvirt eu detalhei nesse post aqui) para que ele passasse a usar um hostname diferente do que eu tinha originalmente configurado. A princípio, essa era uma alteração, acredito eu, deveria ser possível fazer somente através do foreman-installer. Infelizmente não parece ser o caso, já que o instalador parece não atualizar todas as referências ao hostname antigo. Como não encontrei nada na documentação que explicasse isso, compartilho aqui os passos que usei para fazer a alteração na marra. Considerando que o hostname anterior do servidor não está mais disponível e o servidor já encontra-se devidamente configurado com o novo hostname, os passos para reconfigura-lo são os seguintes:

1. Gerar o novo certificado puppet para o servidor:

puppet cert generate <novo fqdn>

2. Editar o arquivo answers, localizado em /etc/foreman-installer/scenarios.d/foreman-answers.yaml, alterando todas as ocorrências do hostname anterior para o novo hostname. E, sim, isso inclui alterar as configurações de certificados para que elas apontem para novo certificado (ex.: websockets_ssl_key, websockets_ssl_cert, puppet_ssl_key, etc).

3. Rodar novamente o instalador do proxy:

foreman-installer \
     --no-enable-foreman \
     --no-enable-foreman-cli \
     --no-enable-puppet \
     --enable-foreman-compute-libvirt \
     --enable-foreman-proxy \
     --foreman-proxy-dns=true \
     --foreman-proxy-dns-provider=virsh \
     --foreman-proxy-dns-interface=virbr0 \
     --foreman-proxy-dhcp=true \
     --foreman-proxy-dhcp-managed=false \
     --foreman-proxy-dhcp-interface=virbr0 \
     --foreman-proxy-dhcp-vendor=virsh \
     --foreman-proxy-dhcp-gateway=192.168.122.1 \
     --foreman-proxy-dhcp-range="192.168.122.2 192.168.122.254" \
     --foreman-proxy-dhcp-nameservers="192.168.122.1" \
     --foreman-proxy-tftp=true \
     --foreman-proxy-tftp-servername=<endereço IP do servidor TFTP> \
     --foreman-proxy-foreman-base-url=<url do servidor Foreman usando o novo FQDN> \
     --foreman-proxy-trusted-hosts=<hostname do servidor Foreman> \
     --foreman-proxy-oauth-consumer-key=<oauth consumer key> \
     --foreman-proxy-oauth-consumer-secret=<oauth consumer key>

Obs.: não esqueça de ajustar o comando do instalador de acordo com o seu ambiente, as funcionalidades gerenciadas pelo foreman e qualquer outra configuração do seu ambiente. O comando acima deve ser utilizado como um exemplo.

4. Revogar os certificados antigos:

puppet cert revoke <fqdn antigo>

E pronto. Depois feito isso, o proxy deve passar a usar o novo hostname.

Configuração do touchpad do Macbook no Fedora

Caso você esteja rodando Fedora em um Macbook e esteja descontente com o comportamento do touchpad, recomendo dar uma olhada nesse meu repositório Copr. Conforme eu expliquei nesse post em inglês, eu empacotei uma configuração do Synclient/Synaptics que deixa o comportamento do touchpad parecido com o do OS X.

A instalação é abusrdamente simples:

dnf copr enable orpiske/synconf
dnf install -y synconf

Basta reiniciar o sistema e o comportamento do touchpad deve ficar semelhante ao do OS X.

 

Configurando o Foreman para Provisionamento com a Libvirt

Introdução

O objetivo desse artigo é fornecer um guia rápido de como configurar o Foreman para que ele possa provisionar máquinas virtuais usando as funcionalidades fornecidas pela libvirt. Ele fornece um material adicional de apoio à excelente documentação fornecida pelo projeto. Esse guia foi feito levando em conta um ambiente com Red Hat Enterprise Linux 6.7 ou 7.2, devendo funcionar sem maiores problemas em ambientes baseados em CentOS 6 ou 7.

Sobre o Foreman

O Foreman é uma ferramenta que permite gerenciar o ciclo de vida de servidores físicos ou virtuais, facilitando o provisionamento de sistemas e aplicações, automação de tarefas e, de modo geral, facilitando o gerenciamento de servidores. Entre outras coisas, ele permite a instalação desassistida de máquinas virtuais e o seu provisionamento em “Compute Resources” como OpenStack, Amazon EC2 e libvirt. Para ter uma ideia de como ele funciona, recomendo esse vídeo:

Continue reading “Configurando o Foreman para Provisionamento com a Libvirt”

Configuração de teclado BR ABNT2 no Evev

Dica de última hora para quem ficou muito tempo afastado 🙂 e nunca mexeu com o evdev: para configurar o suporte a BR ABTN2 no Evev você pode fazer o seguinte:

cp /usr/share/hal/fdi/policy/10osvendor/10-keymap.fdi /etc/hal/fdi/policy/

Editar as linhas de configuração do teclado. Ficará mais ou menos assim:

<merge key="input.xkb.layout" type="string">br</merge>
 <merge key="input.xkb.variant" type="string" />

Reinicie o daemon do hal e pronto.

Benchmarks do Firefox

Com toda essa discussão sobre benchmarks do Firefox, GCC, ICC, etc. Hoje resolvi fazer uns testes de desempenho do Firefox no Arch Linux versus Firefox no Windows.  No Arch, por não saber ao certo qual seria mais adequado, escolhi dois pacotes da AUR: firefox-optimized e firefox-pgo. Ambos foram compilados com -march=x86_64 -mtune=generic -O2 -fomit-frame-pointer -pipe (todas essas flags estavam por PADRÃO no arquivo makepkg.conf do Arch).

Continue reading “Benchmarks do Firefox”

Olá Arch Linux

No post anterior eu contei como eu cheguei ao Gentoo, o que eu fiz e porque eu
deixei ele pra trás. Hoje vou contar qual foi o caminho que eu segui …

Após me frustar com o estado atual do Gentoo, eu decidi que era hora de partir para uma distribuição nova, que tivesse o mesmo espirito que o Gentoo no começo. Além disso eu queria uma distribuição que fosse rolling-releases/rolling-updates, ou seja, uma vez que a distribuição estivesse instalada, não seria mais preciso baixar CDs de atualização a cada novo release. Isso, automaticamente excluí a maioria das distribuições tradicionais: Fedora, OpenSuse, Ubuntu, Slackware, etc. Além disso eu queria uma distribuição que, assim como o Gentoo, fosse fácil de adaptar aos meus gostos (aqui, preciso deixar claro que, sim, eu tenho noção de que é perfeitamente possível fazer isso com, basicamente, qualquer distribuição). Por fim, eu também queria que a distribuição fornecesse pacotes tão atualizados quanto possível. Foi aí que eu acabei chegando no Arch Linux: uma distribuição rolling release, como o Gentoo, mas com um pequeno diferencial: ela usa pacotes binários ao invés de compilar os pacotes a partir dos fontes. Outro diferencial da distribuição é a sua documentação que é quase tão concisa e organizada quanto a do Gentoo.

Continue reading “Olá Arch Linux”

Adeus Gentoo

Eu ainda me lembro muito bem, era pouco mais da metade de dezembro de 2002 e a banda larga via ADSL tinha recém acabado de chegar na minha cidade. Isso permitia que, entre outras coisas, eu pudesse passar horas e mais horas no IRC. Além disso, com a banda larga eu poderia fazer algo que eu sempre gostei: baixar e testar novas versões de softwares, configurar e brincar com o sistema, etc.

Continue reading “Adeus Gentoo”

Um Desktop para rivalizar com o Mac?

Hoje eu instalei o tão esperado KDE 4, que já está por ai a algum tempo, e devo dizer que fiquei incrivelmente surpreso com ele. Os desenvolvedores conseguiram fazer um desktop polido, bonito e prático que não tem precedentes na história das GUIs open source.

De maneira geral o que me impressionou foi a forma como o deskop ficou confortável em resoluções grandes (aquelas utilizadas por monitores com 19 ou mais polegadas). Ao contrário do Gnome que parecia desajeitado na minha resolução (1680×1050), o KDE se ajustou de maneira mais homogênea dando a impressão de utilizar melhor o espaço do desktop.

Continue reading “Um Desktop para rivalizar com o Mac?”

Escrevendo um sistema de arquivos

Neste link, existe um tutorial sobre como escrever um sistema de arquivos simples. Bastante interessante se você se interessa por desenvolvimento em baixo nível. Adicionalmente a este texto recomendo a leitura do Linux Kernel Development, escrito pelo Robert Love, engenheiro da Novel e figurinha conhecida no desenvolvimento do Linux.