Dicas, Linux

vpnc graphical client on KDE 4.x

Recently I needed to configure a VPN connection in my workstation to connect with our corporate Server. That server uses a Cisco VPN solution so the support for this kind of VPN in Linux systems is offered by the vpnc client package.

vpnc client supports only CLI control and configuration. To be able to configure your vpnc connections in a graphical environment (KDE, Gnome, etc) you need to install another package. In my case I had to install the following package:

sudo yum install -y kde-plasma-networkmanagement-vpnc.x86_64

I’m sharing this with you because that package is not present in the official distro repos neither in EPEL. I’m using RHEL 7. After some seaching on the Internet I could find that pkg in the alternative nux repository.

After install this pkg I was able to configure my VPN connection using the graphical NetworkManager KDE applet. See one screenshot:

kde-vpnc-networkmanager

Geral, Linux, RHEL, Tools, Virtualização

Integrando o Vagrant com libvirt/KVM no RHEL/CentOS 7

Primeiro o que é Vagrant?

Vagrant é uma ferramenta utilizada para criação e configuração de ambientes de trabalho (desenvolvimento, testes, homologação, produção etc) de forma configurável, reproduzível, portável, isolada  e automatizada. Humm… lembra um pouco algumas características do Docker, não?

Bom, em partes sim! Porém para um ambiente que utiliza virtualização tradicional. Docker e seu ecosistema tem avançado em uma velocidade absurda. Mas creio que ainda levará um tempo para o mercado corporativo começar a adotar Docker em larga escala em seus Data Centers privados. Virtualização tradicional tem vida longa ainda e, na minha opinião, irá coeexistir junto com iniciativas de Cloud baseadas em Containers.

Descrevendo de uma forma um pouco mais clara… Vagrant permite que você:

  • crie imagens (Boxes) baseadas em um Sistema Operacional qualquer
  • instale e configure pacotes/recursos utilizando uma ferramenta de automação (Provisioner) – também chamada de Configuration Management Tool. Vagrant suporta diversas dessas ferramentas: shell, chef, puppet, ansible.
  • provisione essa imagem em um hypervisor (Provider) específico: VirtualBox, VMWare, HyperV, KVM. Vagrant poder ser integrado inclusive com Cloud Providers como AWS, Digital Ocean etc.

Bom, Não vou me estender na descrição da ferramenta neste post. Para mais detalhes veja a Vagrant doc oficial.

Quando você lê o a documentação oficial do site, percebe que os providers oficialmente suportados e disponíveis Out of Box pelo Vagrant são: VirtualBox o Vmware.

Pô! Uso Linux e meu Hypervisor é o KVM! Como fazer com que o Vagrant utilize o KVM como provider?

Graças à API libvirt e o mecanismo de Vagrant plugins, existe um plugin que permite essa integração: vagrant-libvirt

Neste post descrevo os passos para instalar e configurar o Vagrant integrado com libvirt/KVM em um Host RHEL 7/Centos 7.redhat-logo

Infelizmente até o momento o Vagrant não está disponível no reposiório oficial da Red Hat. Entretanto ele está disponível no próprio site do projeto Vagrant, ná página Vagrant downloads.

Após baixar o RPM para seu host instale utilizando o yum.

sudo yum localinstall ~/Downloads/vagrant_1.7.4_x86_64.rpm

Confira a instalação

vagrant --version
Vagrant 1.7.4

Instale os seguintes pacotes necessários para plugin do provider (libvirt):

sudo yum install libxslt-devel libxml2-devel libvirt-devel libguestfs-tools-c

Em seguida instale o plugin do libvirt e o plugin nfs_guest.

vagrant plugin install vagrant-libvirt vagrant-nfs_guest

Installing the ‘vagrant-libvirt’ plugin. This can take a few minutes…
Installed the plugin ‘vagrant-libvirt (0.0.30)’!

Verifique a lista de plugins instalados:

vagrant plugin list

vagrant-kvm (0.1.9)
vagrant-libvirt (0.0.30)
vagrant-nfs_guest (0.1.5)
vagrant-share (1.1.4, system)

Ok! O próximo passo é começar a provisionar VMs. Na terminologia do Vagrant VMs são Boxes. Assim como o Docker hub, existe um repositório público de Boxes chamado Atlas Hashcorp. Basta buscar por um Box usando o nome do sistema operaciona ou o nome do provider. Ex: procure por imagens criadas para libvirt.

Vamos adicionar uma Box em meu host local. Eu escolhi uma imagem baseada no Centos 7 criada pelo usuário uvsmtid.

vagrant vagrant box add --insecure uvsmtid/centos-7.0-minimal
==> box: Loading metadata for box 'uvsmtid/centos-7.0-minimal'
box: URL: https://atlas.hashicorp.com/uvsmtid/centos-7.0-minimal
==> box: Adding box 'uvsmtid/centos-7.0-minimal' (v1.0.0) for provider: libvirt
box: Downloading: https://atlas.hashicorp.com/uvsmtid/boxes/centos-7.0-minimal/versions/1.0.0/providers/libvirt.box
==> box: Successfully added box 'uvsmtid/centos-7.0-minimal' (v1.0.0) for 'libvirt'!

Diferentemente de uma Docker Image os Vagrant Boxes são imagens de VMs tradicionais! Portanto são bem maiores. O download pode demorar um pouco. Aguarde!

Verifique as imagens adicionadas em seu host com o comando abaixo

vagrant box list
uvsmtid/centos-7.0-minimal (libvirt, 1.0.0)

Agora é necessário criar um descritor chamado VagrantFile. Esse cara é uma espécie de Dockerfile e através dele o Vagrant faz toda a sua mágica de provisionamento da VM.
Crie um diretório (como um projeto) para hospedar o descritor e os metadados para as suas Vagrant Boxes.

mkdir -p ~/vagrant/centos7-minimal
cd ~/vagrant/centos7-minimal

vagrant init uvsmtid/centos-7.0-minimal
A `Vagrantfile` has been placed in this directory. You are now
ready to `vagrant up` your first virtual environment! Please read
the comments in the Vagrantfile as well as documentation on
`vagrantup.com` for more information on using Vagrant.

Veja que o Vagrant criou um descritor Vagrantfile no diretório atual e um diretório oculto (.vagrant) para armazenar metadados (arquivos criados durante a inicialização da).

➜  tree -a .
.
├── .vagrant
│   └── machines
│       └── default
│           └── libvirt
│               ├── created_networks
│               ├── creator_uid
│               ├── id
│               ├── index_uuid
│               └── private_key
└── Vagrantfile

Agora basta executar o comando:

vagrant up

Bringing machine 'default' up with 'libvirt' provider...
==> default: Creating image (snapshot of base box volume).
==> default: Creating domain with the following settings...
==> default:  -- Name:              centos7-minimal_default
==> default:  -- Domain type:       kvm
==> default:  -- Cpus:              1
==> default:  -- Memory:            512M
==> default:  -- Base box:          uvsmtid/centos-7.0-minimal
==> default:  -- Storage pool:      default
==> default:  -- Image:             /var/lib/libvirt/images/centos7-minimal_default.img
==> default:  -- Volume Cache:      default
==> default:  -- Kernel:
==> default:  -- Initrd:
==> default:  -- Graphics Type:     vnc
==> default:  -- Graphics Port:     5900
==> default:  -- Graphics IP:       127.0.0.1
==> default:  -- Graphics Password: Not defined
==> default:  -- Video Type:        cirrus
==> default:  -- Video VRAM:        9216
==> default:  -- Keymap:            en-us
==> default:  -- Command line :
==> default: Pruning invalid NFS exports. Administrator privileges will be required...
==> default: Creating shared folders metadata...
==> default: Starting domain.
==> default: Waiting for domain to get an IP address...
==> default: Waiting for SSH to become available...
    default:
    default: Vagrant insecure key detected. Vagrant will automatically replace
    default: this with a newly generated keypair for better security.
    default:
    default: Inserting generated public key within guest...
    default: Removing insecure key from the guest if it's present...
    default: Key inserted! Disconnecting and reconnecting using new SSH key...
==> default: Configuring and enabling network interfaces...
==> default: Rsyncing folder: /home/rsoares/vagrant/centos7-minimal/ => /vagrant

Voila!
Sua VM Centos7 UP and Running!

NOTA: na época da escrita desse post a última release do plugin vagrant-libvirt era a 0.0.30. Tem um bug nessa versão documentado em: https://github.com/pradels/vagrant-libvirt/issues/412. Nos comentários da issue tem um trecho de código (Ruby) que resolve o problema. Copie o trecho de código e altere o arquivo ‘ ~/.vagrant.d/gems/gems/vagrant-libvirt-0.0.30/lib/vagrant-libvirt/action/prepare_nfs_settings.rb. Salve o arquivo e execute o vagrant up novamente.

Para acessar a VM:

vagrant ssh

Para ver um status das VMs gerenciadas pelo Vagrant no host atual:

vagrant global-status
id       name    provider state   directory
------------------------------------------------------------------------
5b3e766  default libvirt running /home/rsoares/vagrant/centos7-minimal

The above shows information about all known Vagrant environments
on this machine. This data is cached and may not be completely
up-to-date. To interact with any of the machines, you can go to
that directory and run Vagrant, or you can use the ID directly
with Vagrant commands from any directory. For example:
"vagrant destroy 1a2b3c4d"

Para efetuar um shutdown na VM:

vagrant halt
==> default: Halting domain...

Para eliminar a VM:

vagrant destroy
==> default: Removing domain...

Pode destruir sem dó! A ideia do Vagrant é essa! Criar e recriar ambientes de forma rápida, automatizada sem stress! 🙂

Bom, por hoje é só! Há muito mais para falar do Vagrant e suas funcionalidades. Em um próximo post quero abordar a questão da portabilidade entre os diferentes providers (Hypervisors). Tipo, como portar essa mesma imagem que foi provionada em cima do KVM (com o plugin libvirt) para o provider VMWare ou VirtualBox? É possível!


Referências utilizadas neste post:

Dicas, Docker, Linux

Comandos Docker: torne sua CLI mais fácil e ágil

Tips & Tricks SeriesApós trabalhar um tempo com Docker na linha de comando você percebe que alguns comandos são muito repetitivos e um tanto chatos. Apesar de o cliente de linha de comando do Docker ser extremamente poderoso, existe uma infinidade de parâmetros e combinações para se lembrar.

Em um ambiente Unix-like (*-Linux, Mac, etc) é possível tornar algumas tarefas repetitivas um pouco mais ágil e divertida. Veja como é possível definir algumas variantes dos comandos Docker mais comuns: docker run, docker psdocker images, docker inspect, docker exec, e assim por diante…

É possível definir novos comandos e expor em seu profile shell utilizando aliases e functions via Linux Shell. Veja alguns que defini em meu ~/.bash_profile (pode ser o ~/.bashrc também!):

NOTA: após editar e salvar o arquivo execute ‘source ~/.bash_profile’ para carregar as novas definições em sua shell.

Nas duas primeiras linhas defini dois alias:

  • di: listar as imagens em meu repositório local; e
  • dps: listar todos os containers criados

Em seguida defino algumas funções que utilizam sub-comandos e combinações de parâmetros um pouco mais elaborados:

  • dock-run <nome ou id da imagem>: cria um container utilizando a imagem informada
  • dock-exec <nome ou id do container>: executa o shel (/bin/sh) do container informado. Equivalente ao docker attach
  • dock-ip <nome ou id do container>: obtém o endereço ip do container
  • dock-rmc: remove todos os containers inativos (com status exited)
  • dock-rmi: remove todas as imagens com id ‘none

Espero que essa dica seja útil pra vocês também!

Compartilhe seus comandos também comentando abaixo 😉

Dicas, Linux, RHEL

Dica para usuários do YUM: gerenciador de pacotes em sistemas Red Hat like

Volta e meia preciso usar algum comando mais específico do YUM ou RPM no Red Hat Enterprise Linux. Entenda por “mais específico” qualquer comando diferente de:YUM Cheat Sheet for RHEL

yum search‘, ‘yum install‘, ‘yum erase, remove

rpm -qa‘ ou ‘rpm -ivH

Em uma ocasião mais recente precisei investigar onde o yum havia instalado o conteúdo de um determinado pacote no sistema.

Pesquisando no Google descobri o utilitário ‘repoquery‘ disponível no pacote ‘yum-utils‘. Este comando permite listar o conteúdo do pacote rpm mostrando os paths dos arquivos instalados no sistema de arquivos.

Exemplo: para listar o conteúdo do pacote ‘rhscl-dockerfiles’ instalado no RHEL 7, utilize o comando abaixo.

$ sudo repoquery -l rhscl-dockerfiles
/usr/share/rhscl-dockerfiles
/usr/share/rhscl-dockerfiles/rhel6
/usr/share/rhscl-dockerfiles/rhel6/httpd24
/usr/share/rhscl-dockerfiles/rhel6/httpd24/Dockerfile
/usr/share/rhscl-dockerfiles/rhel6/httpd24/README.md
/usr/share/rhscl-dockerfiles/rhel6/httpd24/enablehttpd24.s
...

Bem, a dica é que existe um documento chamado  ‘YUM COMMAND CHEAT SHEET‘ disponível no site da documentação oficical do Red Hat Enterprise Linux. Trata-se de uma listagem bem objetiva dos principais comandos e opções avançadas do mecanismo de gerência de pacotes do RHEL (yum). O PDF é público e pode ser obtido através do link [1]

___

[1] https://access.redhat.com/sites/default/files/attachments/rh_yum_cheatsheet_1214_jcs_print-1.pdf

Docker, Linux

Excluindo uma tag de um repositório Docker em um registro remoto

Quando voce publica uma imagem Docker em algum repositório remoto (privado ou público) não é possível excluir uma tag da imagem utilizando o cliente docker na linha de comando.

docker rmi <id da imagem>

isso removerá apenas do seu registro local.

Para remover do registro público é necessário utilizar a API REST [1] do serviço de registro do docker.

De acordo com a documentação da API Docker Registry [2] o endpoint é o seguinte:

DELETE /v1/repositories/(namespace)/(repository)/tags/(tag*)

Exemplo:

DELETE /v1/repositories/reynholm/help-system-server/tags/latest HTTP/1.1
Host: registry-1.docker.io
Accept: application/json
Content-Type: application/json
Cookie: (Cookie provided by the Registry)

Exemplo que usei no meu caso:

[root@rhel7-server-1 httpd]# curl -X DELETE my-private-docker-registry.com:5000/v1/repositories/rsoares/rhel7/tags/latest
true

Pronto!

Se o retorno for ‘true‘ sua tag foi removida!

Execute novamente a requisição REST para se certificar

curl -X DELETE my-private-docker-registry.com:5000/v1/repositories/rsoares/rhel7/tags/latest
{"error": "Tag not found"}

Observe o retorno:

{"error": "Tag not found"}

[1] https://docs.docker.com/reference/api/registry_api
[2] https://docs.docker.com/reference/api/registry_api/#delete-a-repository-tag

Containers, Dicas, Linux

Installing the OpenJDK 7 in a RHEL 7 Docker Image: systemd dep issue

Hello guys!

redhat-docker

Maybe you are thinking… WTF! Why have this guy written this post in English?!

Well,
I think this is my first blog post in this blog written in en_US. The motivation is simple. The subject (Docker and all the related things around it) is attracting almost all the attention of IT at this moment. So the basic idea is to help more people that might face the same issue described in this post.

So, please ignore any language/typo mistake.

😉

Ok!

For those trying to build a RHEL 7 Docker Base Image with Java 7 support (OpenJDK 7 packages), the openjdk pkgs depends on systemd. When you try to install the openjdk via yum you may see the following error:

bash-4.2# yum install java-1.7.0-openjdk.x86_64 java-1.7.0-openjdk-devel.x86_64
Resolving Dependencies
--> Running transaction check
---> Package java-1.7.0-openjdk.x86_64 1:1.7.0.71-2.5.3.1.el7_0 will be installed
...
Dependencies Resolved
==================================================================================================================================================
 Package Arch Version Repository Size
==================================================================================================================================================
Installing:
 java-1.7.0-openjdk x86_64 1:1.7.0.71-2.5.3.1.el7_0 rhel-7-server-rpms 196 k
 java-1.7.0-openjdk-devel x86_64 1:1.7.0.71-2.5.3.1.el7_0 rhel-7-server-rpms 9.1 M
Installing for dependencies:
...
systemd x86_64 208-11.el7_0.5 rhel-7-server-rpms 2.6 M
 systemd-sysv x86_64 208-11.el7_0.5 rhel-7-server-rpms 36 k
 sysvinit-tools x86_64 2.88-14.dsf.el7 rhel-7-server-rpms 63 k
...
Transaction Summary
==================================================================================================================================================
Install 2 Packages (+86 Dependent packages)
'Transaction check error:
file /usr/lib/rpm/macros.d/macros.systemd from install of systemd-208-11.el7_0.5.x86_64 conflicts with file from package fakesystemd-1-14.el7.x86_64'

The rhel7 official base image includes a fakesystemd (from @koji-override-0/7.0 repo) instead of full systemd. I’m not sure if this fafesystemd pkg is shipped with rhel 7 docker base image (I have to check to confirm). I saw some blogs posts saying it is used to avoid a number of bad implications with running full systemd on Docker Containers. I thik it come as a dependence with the openssh-server pkg I’ve installed before. This fakesystemd provides only some fake files to satisfy some other pkgs requirements that depends on systemd service:

bash-4.2# rpm -ql fakesystemd-1-14.el7.x86_64
/etc/binfmt.d
/etc/modules-load.d
/etc/sysctl.d
/etc/systemd
/etc/systemd/system
/etc/systemd/user
/etc/tmpfiles.d
/etc/udev
/etc/udev/rules.d
/usr/lib/binfmt.d
/usr/lib/modules-load.d
/usr/lib/rpm/macros.d/macros.systemd
/usr/lib/sysctl.d
/usr/lib/systemd
/usr/lib/systemd/catalog
/usr/lib/systemd/ntp-units.d
/usr/lib/systemd/system-generators
/usr/lib/systemd/system-preset
/usr/lib/systemd/system-shutdown
/usr/lib/systemd/system-sleep
/usr/lib/systemd/user-generators
/usr/lib/systemd/user-preset
/usr/lib/tmpfiles.d
/usr/share/pkgconfig
/usr/share/systemd
/var/lib/systemd
/var/lib/systemd/catalog

The workaround I’ve found for now is to remove the fakesystemd in order to be able to install the openjdk packages.

bash-4.2# yum remove fakesystemd-1-14.el7.x86_64

As I mentioned before to avoid the issues with the full systemd inside Docker containers I followed this approach: http://developerblog.redhat.com/2014/05/05/running-systemd-within-docker-container/

Well, I hope this could help you.