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!):

# Docker aliases
alias di='sudo docker images'
alias dps='sudo docker ps -a'
# useful Docker functions
dock-run() { sudo docker run -i -t –privileged $@ ;}
dock-exec() { sudo docker exec -i -t $@ /bin/bash ;}
dock-log() { sudo docker logs –tail=all -f $@ ;}
dock-port() { sudo docker port $@ ;}
dock-vol() { sudo docker inspect –format '{{ .Volumes }}' $@ ;}
dock-ip() { sudo docker inspect –format '{{ .NetworkSettings.IPAddress }}' $@ ;}
dock-rmc() { sudo docker rm `sudo docker ps -qa –filter 'status=exited'` ;}
dock-rmi() { sudo docker rmi -f `sudo docker images | grep '^<none>' | awk '{print $3}'` ;}
dock-do() {
if [ "$#" -ne 1 ]; then
echo "Usage: $0 start|stop|pause|unpause|<any valid docker cmd>"
fi
for c in $(sudo docker ps -a | awk '{print $1}' | sed "1 d")
do
sudo docker $1 $c
done
}

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.

Containers, Linux

Executando um comando Docker em todos os Containers

Este simples shell script permite executar um comando do Docker em todos os Containers de um única vez. É um script bobinho mas bastante últil.

#!/bin/bash
if [ "$#" -ne 1 ]; then
echo "Usage: $0 start|stop|pause|unpause|<any valid docker cmd>"
exit 1
fi
for c in $(sudo docker ps -a | awk '{print $1}' | sed "1 d")
do
sudo docker $1 $c
done

view raw
doDocker.sh
hosted with ❤ by GitHub

Para fazer um stop:

./doDocker stop

Para fazer um start:

./doDocker start

Para pausar:

./doDocker pause
Linux

JBoss EAP 6.x como serviço no RHEL7: Systemd

Para aqueles que já estão utilizando o RHEL 7 (ou suas derivações: Centos, OEL, Scientific Linux) perceberam que os serviços não são mais controlados pelo mecanismo SysV (adicionados através do comando chkconfig). O RHEL 7 utiliza um novo mecanismo de gerência de serviços e inicialização do sistema chamado Systemd. Para mais detalhes ou um overview do Systemd veja as referências [1] e [2].

Abaixo descrevo um passo a passo de como adicionar o JBoss EAP 6 como serviço através do Systemd.

Crie um usuário chamado jboss.

[root@rhel7-server-1 bin]# adduser jboss
[root@rhel7-server-1 bin]# passwd jboss

Instale o JBoss EAP em um diretório de sua preferência. O script original sugere o diretório: /usr/share/jboss-as.

Eu particularmente costumo instalar em /opt.

mkdir /opt/redhat
unzip /tmp/jboss-eap-6.x.zip -d /opt/redhat
chown -R jboss.jboss /opt/redhat

Crie os seguintes diretórios que serão utilizados pelo script de inicialização.

[root@rhel7-server-1 bin]# mkdir /etc/jboss-as
[root@rhel7-server-1 bin]# mkdir /var/log/jboss-as
[root@rhel7-server-1 bin]# mkdir /var/run/jboss-as
[root@rhel7-server-1 bin]# chown jboss.jboss /etc/jboss-as
[root@rhel7-server-1 bin]# chown jboss.jboss /var/log/jboss-as
[root@rhel7-server-1 bin]# chown jboss.jboss /var/run/jboss-as

Copie e altere o arquivo de configuração auxiliar do script de init

[root@rhel7-server-1 bin]# cp init.d/jboss-as.conf /etc/jboss-as/
[root@rhel7-server-1 bin]# vim /etc/jboss-as/jboss-as.conf

Remova o comentário das variáveis e adiciene novas conforme destacado no trecho abaixo.

# General configuration for the init.d scripts,
# not necessarily for JBoss AS itself.

# Path to JBoss EAP Installation
JBOSS_HOME=/opt/redhat/jboss-eap-6.3

# The username who should own the process.
#
JBOSS_USER=jboss

# The amount of time to wait for startup
#
STARTUP_WAIT=30

# The amount of time to wait for shutdown
#
SHUTDOWN_WAIT=30

# Location to keep the console log
#
JBOSS_CONSOLE_LOG=/var/log/jboss-as/console.log

# JBoss configuration file
JBOSS_CONFIG=standalone.xml

# Public IP Address where JBoss will listen
JBOSS_PUB_BIND=192.168.122.65

# Management IP Address where JBoss will listen
JBOSS_MGMT_BIND=192.168.122.65

Faça a seguinte alteração no script de init original do JBoss EAP

vim $JBOSS_HOME/bin/init.d/jboss-as-standalone.sh
if [ -z "$JBOSS_PUB_BIND" ]; then
JBOSS_PUB_BIND=127.0.0.1
fi

if [ -z "$JBOSS_MGMT_BIND" ]; then
JBOSS_MGMT_BIND=172.0.0.1
fi

JBOSS_SCRIPT="$JBOSS_HOME/bin/standalone.sh -b $JBOSS_PUB_BIND -bmanagement=$JBOSS_MGMT_BIND"

Nota: por padrão o JBoss sobe na interface de loopback (localhost – 127.0.0.1). Essa alteração é necessária para informar/parametrizar os endereços onde as interfaces pública e de gerência devem ouvir conexões externas.

Caso tenha instalado a JVM OpenJDK (Default no REHL 7), edite o arquivo abaixo.
Nota: Caso o arquivo não exista, crie!

vim /etc/java/java.conf
# System-wide Java configuration file -*- sh -*-

# Location of jar files on the system
JAVA_LIBDIR=/usr/share/java

# Location of arch-specific jar files on the system
JNI_LIBDIR=/usr/lib/java

# Root of all JVM installations
JVM_ROOT=/usr/lib/jvm

# You can define a system-wide JVM root here if you're not using the
# default one.
#
# If you have a base JRE package installed
# (e.g. java-1.6.0-openjdk):
JAVA_HOME=$JVM_ROOT/jre
#
# If you have a devel JDK package installed
# (e.g. java-1.6.0-openjdk-devel):
#JAVA_HOME=$JVM_ROOT/java

# Options to pass to the java interpreter
#JAVACMD_OPTS=

Crie o script que será adicionado ao systemd com o seguinte conteúdo:

[jboss@rhel7-server-1 init.d]$ sudo vim /etc/systemd/system/jboss-as.service
[Unit]
Description=JBoss EAP Service
After=syslog.target network.target

[Service]
ExecStart=/opt/redhat/jboss-eap-6.3/bin/init.d/jboss-as-standalone.sh start
ExecStop=/opt/redhat/jboss-eap-6.3/bin/init.d/jboss-as-standalone.sh stop
Type=forking
PIDFile=/var/run/jboss-as/jboss-as-standalone.pid

[Install]
WantedBy=multi-user.target

Execute os comandos abaixo para habilitar o serviço no systemd:

[jboss@rhel7-server-1 init.d]$ sudo chmod 644 /etc/systemd/system/jboss-as.service

[jboss@rhel7-server-1 init.d]$ sudo systemctl enable jboss-as.service
ln -s '/etc/systemd/system/jboss-as.service' '/etc/systemd/system/multi-user.target.wants/jboss-as.service'

Inicie o serviço.

[jboss@rhel7-server-1 init.d]$ sudo systemctl start jboss-as.service

[jboss@rhel7-server-1 bin]$ sudo systemctl status jboss-as.service
jboss-as.service - JBoss EAP Service
Loaded: loaded (/etc/systemd/system/jboss-as.service; enabled)
Active: active (running) since Wed 2014-11-12 22:40:58 BRST; 8s ago
Main PID: 6969 (java)
CGroup: /system.slice/jboss-as.service
├─6877 /bin/sh /opt/redhat/jboss-eap-6.3/bin/init.d/jboss-as-standalone.sh start
├─6879 runuser -s /bin/bash jboss -c ulimit -S -c 0 >/dev/null 2>&1 ; LAUNCH_JBOSS_IN_BACKGROUND=1 JBOSS_PIDFILE=/var/run/jboss-as/jboss-as-standalone.pid /opt/redha...
├─6881 bash -c ulimit -S -c 0 >/dev/null 2>&1 ; LAUNCH_JBOSS_IN_BACKGROUND=1 JBOSS_PIDFILE=/var/run/jboss-as/jboss-as-standalone.pid /opt/redhat/jboss-eap-6.3/bin/st...
├─6882 /bin/sh /opt/redhat/jboss-eap-6.3/bin/standalone.sh -b 192.168.122.65 -bmanagement=192.168.122.65 -c standalone.xml
└─6969 java -D[Standalone] -server -XX:+UseCompressedOops -verbose:gc -Xloggc:/opt/redhat/jboss-eap-6.3/standalone/log/gc.log -XX:+PrintGCDetails -XX:+PrintGCDateSta...

Nov 12 22:40:58 rhel7-server-1 systemd[1]: Starting JBoss EAP Service...
Nov 12 22:40:58 rhel7-server-1 systemd[1]: Started JBoss EAP Service.
Nov 12 22:40:58 rhel7-server-1 runuser[6879]: pam_unix(runuser:session): session opened for user jboss by (uid=0)
Nov 12 22:41:02 rhel7-server-1 jboss-as-standalone.sh[6869]: Starting jboss-as: [ OK ]

Verifique o log do serviço:

[jboss@rhel7-server-1 init.d]$ tail -f /var/log/jboss-as/console.log

22:13:13,010 INFO [org.jboss.ws.common.management] (MSC service thread 1-2) JBWS022052: Starting JBoss Web Services - Stack CXF Server 4.3.0.Final-redhat-3
22:13:13,033 INFO [org.apache.coyote.http11.Http11Protocol] (MSC service thread 1-1) JBWEB003000: Coyote HTTP/1.1 starting on: http-/127.0.0.1:8080
22:13:13,081 INFO [org.jboss.as.server.deployment.scanner] (MSC service thread 1-4) JBAS015012: Started FileSystemDeploymentService for directory /opt/redhat/jboss-eap-6.3/standalone/deployments
22:13:13,084 INFO [org.jboss.as.remoting] (MSC service thread 1-4) JBAS017100: Listening on 127.0.0.1:4447
22:13:13,084 INFO [org.jboss.as.remoting] (MSC service thread 1-2) JBAS017100: Listening on 127.0.0.1:9999
22:13:13,338 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-4) JBAS010400: Bound data source [java:jboss/datasources/ExampleDS]
22:13:13,465 INFO [org.jboss.as] (Controller Boot Thread) JBAS015961: Http management interface listening on http://127.0.0.1:9990/management
22:13:13,465 INFO [org.jboss.as] (Controller Boot Thread) JBAS015951: Admin console listening on http://127.0.0.1:9990
22:13:13,466 INFO [org.jboss.as] (Controller Boot Thread) JBAS015874: JBoss EAP 6.3.0.GA (AS 7.4.0.Final-redhat-19) started in 3564ms - Started 151 of 189 services (56 services are lazy, passive or on-demand)

Veja o arquivo de PID do processo do serviço

[jboss@rhel7-server-1 init.d]$ cat /var/run/jboss-as/jboss-as-standalone.pid
5615

[jboss@rhel7-server-1 init.d]$ pstree -U -h -l -s 5615
systemd───jboss-as-standa───runuser───bash───standalone.sh───java───34*[{java}]
[jboss@rhel7-server-1 init.d]$

[1] https://access.redhat.com/articles/754933
[2] https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/System_Administrators_Guide/chap-Managing_Services_with_systemd.html

Linux

Instalando o Postgres 9 no RHEL 7

Recentemente precisei instalar um Postgres DB em uma VM RHEL 7 para testes. Aproveitei para compartilhar os passos seguidos aqui no Blog. Esse passo a passo deve funcionar em qualquer Distro RHEL-like: Fedora, Centos, Scientific Linux, OEL, etc.

A instalação é a mais básica possível, pois o propósito desse DB é apenas para testes e laboratórios. Nada de tuning ou personalização.
Instale os seguintes pacotes do repositório Postgresql.org oficial.

[rsoares@rhel7-server-1 ~]$ sudo yum install http://yum.postgresql.org/9.4/redhat/rhel-7-x86_64/pgdg-redhat94-9.4-1.noarch.rpm
[rsoares@rhel7-server-1 ~]$ sudo yum groupinstall "PostgreSQL Database Server 9.4 PGDG"

Inicialize o Postgres DB.

sudo /usr/pgsql-9.4/bin/postgresql94-setup initdb

Habilite e teste o serviço do Postgres.

[rsoares@rhel7-server-1 ~]$ sudo systemctl enable postgresql-9.4.service
[rsoares@rhel7-server-1 ~]$ sudo systemctl start postgresql-9.4.service
[rsoares@rhel7-server-1 ~]$ sudo systemctl stop postgresql-9.4.service

Troque para o usuário de sistema do postgres.

[rsoares@rhel7-server-1 ~]$ sudo su - postgres

Altere o pg_hba.conf (espécie de “firewall” do Postgres) para permitir o acesso externo através da rede da VM.

-bash-4.2$ vim /var/lib/pgsql/9.4/data/pg_hba.conf
# TYPE DATABASE USER ADDRESS METHOD

# "local" is for Unix domain socket connections only
local all all peer
# IPv4 local connections:
host all all 127.0.0.1/32 ident
host all all 192.168.122.0/24 md5

Altere o binding do serviço para aceitar conexões em qualquer endereço IP da VM.

-bash-4.2$ vim /var/lib/pgsql/9.4/data/postgresql.conf
#------------------------------------------------------------------------------
# CONNECTIONS AND AUTHENTICATION
#------------------------------------------------------------------------------

# - Connection Settings -

listen_addresses = '*' # what IP address(es) to listen on;

Logout do postgres user.

Ctrl + D no terminal

Reinicie o serviço postgres

[rsoares@rhel7-server-1 ~]$ sudo systemctl start postgresql-9.4.service
[rsoares@rhel7-server-1 ~]$ sudo systemctl status postgresql-9.4.service
postgresql-9.4.service - PostgreSQL 9.4 database server
Loaded: loaded (/usr/lib/systemd/system/postgresql-9.4.service; enabled)
Active: active (running) since Thu 2014-11-06 17:21:38 BRST; 1s ago
Process: 24832 ExecStop=/usr/pgsql-9.4/bin/pg_ctl stop -D ${PGDATA} -s -m fast (code=exited, status=0/SUCCESS)
Process: 25292 ExecStart=/usr/pgsql-9.4/bin/pg_ctl start -D ${PGDATA} -s -w -t 300 (code=exited, status=0/SUCCESS)
Process: 25286 ExecStartPre=/usr/pgsql-9.4/bin/postgresql94-check-db-dir ${PGDATA} (code=exited, status=0/SUCCESS)
Main PID: 25296 (postgres)
CGroup: /system.slice/postgresql-9.4.service
├─25296 /usr/pgsql-9.4/bin/postgres -D /var/lib/pgsql/9.4/data
├─25297 postgres: logger process
├─25299 postgres: checkpointer process
├─25300 postgres: writer process
├─25301 postgres: wal writer process
├─25302 postgres: autovacuum launcher process
└─25303 postgres: stats collector process

Confira o binding do serviço na porta TCP padrão so Postgres (5432)

[rsoares@rhel7-server-1 ~]$ netstat -tanp
(Not all processes could be identified, non-owned process info
will not be shown, you would have to be root to see it all.)
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 127.0.0.1:25 0.0.0.0:* LISTEN -
tcp 0 0 0.0.0.0:55970 0.0.0.0:* LISTEN -
tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN -
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN -
tcp 0 0 127.0.0.1:631 0.0.0.0:* LISTEN -
tcp 0 0 0.0.0.0:5432 0.0.0.0:* LISTEN -
tcp 0 0 192.168.122.65:22 192.168.122.1:39634 ESTABLISHED -
tcp6 0 0 ::1:25 :::* LISTEN -
tcp6 0 0 :::47021 :::* LISTEN -
tcp6 0 0 :::111 :::* LISTEN -
tcp6 0 0 :::22 :::* LISTEN -
tcp6 0 0 ::1:631 :::* LISTEN -
tcp6 0 0 :::5432 :::* LISTEN -

Crie um novo DB User

-bash-4.2$ createuser -d -l -P --interactive NEW_DB_USER
Enter password for new role:
Enter it again:
Shall the new role be a superuser? (y/n) n
Shall the new role be allowed to create more new roles? (y/n) n

Crie um novo Data Base

-bash-4.2$ createdb -e -O NEW_DB_USER NEW_DB "New DataBase"
CREATE DATABASE "NEW_DB" OWNER "NEW_DB_USER";
COMMENT ON DATABASE "NEW_DB" IS 'New DataBase';

ref:

[1] https://wiki.postgresql.org/wiki/YUM_Installation

Dicas, Linux

Instalando o Oracle VirtualBox no RHEL 6.x

Recentemente precisei instalar o Oracle VirtualBox (um projeto anteriormente mantido pela Sun Microsystems) em um laptop rodando o RHEL 6.5 (x86_64).

Apesar da instalação do pacote ocorrer sem erro.

# sudo yum localinstall ~/Downloads/VirtualBox-4.3-4.3.12_93733_el6-1.x86_64.rpm

Tive algumas dificuldades devido a falta de alguns pacotes e configurações. Ao executar o VirtualBox pelo terminal pela primeira vez uma mensagem de erro é mostrada instruindo executar o seguinte comando:

# sudo /etc/init.d/vboxdrv setup

Mais erros ocorrem devido a falta de algumas dependências, entre elas, os headers e o código fonte do Kernel do Linux. Para sanar este problema instale os seguintes pacotes via YUM:

sudo yum install kernel-devel kernel-headers binutils glibc-headers glibc-devel gcc make patch dkms

em seguida defina a seguinte variável de ambiente

# export KERN_DIR=/usr/src/kernels/2.6.32-431.11.2.el6.x86_64 #a versão do kernel no seu ambiente pode ser diferente

por fim execute novamente o comando abaixo:

# sudo /etc/init.d/vboxdrv setup

Se tudo der certo após esses passos o VirtualBox deverá ser iniciado normalmente sem erros. Pronto, agora pode começar a criar suas VMs com o VirtualBox.