O DIA semelhante ao VISION

O DIA é um programa FREE similar ao VISION
http://www.gnome.org/projects/dia/downld.html

rc?.d

O que determina se cada serviço vai ser ou não ativado durante o boot, não é o fato de estar ou não instalado, mas sim, a presença de um link simbólico criado dentro de uma das pastas de inicialização do sistema. Por padrão, são executados primeiro os links que estão dentro da pasta "/etc/rcS.d/" (que inclui os serviços essenciais, executados logo no início do boot) e, em seguida, os links dentro da pasta "/etc/rc5.d/", que inclui os demais serviços.

O número (5 no exemplo) indica o runlevel que será usado, que pode ser um valor de 1 a 5. Cada runlevel corresponde a uma pasta, com um conjunto diferente de scripts de inicialização. Esta foi uma forma encontrada pelas distribuições para ter vários "profiles", que podem ser usados de acordo com a situação.

A configuração mais comum é usar o runlevel 1 como um modo de recuperação, no qual apenas os serviços essenciais para concluir o boot são carregados, sem ambiente gráfico e sem suporte a rede. Hoje em dia, o runlevel 1 é pouco usado, pois é mais fácil corrigir problemas dando boot com um live-CD e resolvendo os problemas através dele, mas a possibilidade continua disponível.

Em seguida temos o runlevel 3, onde quase todos os serviços são carregados, com exceção do ambiente gráfico (este modo é muito usado em servidores). Finalmente, temos o runlevel 5, que corresponde ao modo "normal", onde o ambiente gráfico é carregado, junto com todos os outros serviços. Como em outros casos, existem variações; o Slackware, por exemplo, utiliza o runlevel 4 para carregamento do ambiente gráfico, enquanto o Ubuntu usa um sistema completamente diferente.

Usando o runlevel 5, são carregados os scripts colocados dentro da pasta "/etc/rc5.d/", enquanto que, usando o runlevel 3, são carregados os scripts dentro da pasta "/etc/rc3.d/". Nada impede que você modifique a organização dos arquivos manualmente, de forma a fazer o X carregar também no runlevel 3, ou qualquer outra coisa que quiser. São apenas pastas com scripts e links simbólicos e não uma caixa preta.
Se você quiser ver a lista completa, pode dar uma olhada no conteúdo da pasta /etc/rc3.d/

ls -l /etc/rc3.d/

Cada nível de execução é controlado através de links simbólicos existentes nos seis diretórios (/etc/rc.d/rc1.d até /etc/rc.d/rc6.d). Examinemos o conteúdo do diretório /etc/rc1.d:

# ls -l
lrwxrwxrwx 1 root  root 19 Mar 22 21:02 K00linuxconf -> ../init.d/linuxconf
lrwxrwxrwx 1 root  root 18 Mar 22 20:54 K05keytable -> ../init.d/keytable
lrwxrwxrwx 1 root  root 13 Mar 22 20:59 K10xfs -> ../init.d/xfs
lrwxrwxrwx 1 root  root 13 Mar 22 20:58 K15gpm -> ../init.d/gpm
lrwxrwxrwx 1 root  root 15 Mar 22 20:53 K15httpd -> ../init.d/httpd
lrwxrwxrwx 1 root  root 18 Mar 22 21:05 K30sendmail -> ../init.d/sendmail
lrwxrwxrwx 1 root  root 14 Mar 22 21:03 K50inet -> ../init.d/inet
lrwxrwxrwx 1 root  root 13 Mar 22 20:53 K60atd -> ../init.d/atd
lrwxrwxrwx 1 root  root 15 Mar 22 21:06 K60crond -> ../init.d/crond
lrwxrwxrwx 1 root  root 13 Mar 22 21:02 K60lpd -> ../init.d/lpd
lrwxrwxrwx 1 root  root 15 Mar 22 20:59 K75netfs -> ../init.d/netfs
lrwxrwxrwx 1 root  root 17 Mar 22 21:05 K89portmap -> ../init.d/portmap
lrwxrwxrwx 1 root  root 17 Mar 22 20:59 K90network -> ../init.d/network
lrwxrwxrwx 1 root  root 16 Mar 22 21:06 K99syslog -> ../init.d/syslog
lrwxrwxrwx 1 root  root 16 Mar 22 20:59 S00single -> ../init.d/single

Como se pode ver, todo o conteúdo do diretório /etc/rc1.d consiste de links simbólicos apontando para scripts dentro do diretório /etc/rc.d/init.d. A primeira letra dos nomes dos links simbólicos pode ser ou "S" ou "K", indicando se o processo para o qual aponta deve ser ativado (Started) ou desativado (Killed). O número que se segue a esta letra indica a ordem em que os processos devem ser encerrados ou ativados. Em nosso exemplo o primeiro processo a ser desativado é o linuxconf. O primeiro a ser ativado, após terem sido encerrados todos os demais processos, é o script single.
Cada um dos scripts residentes no diretório /etc/rc.d/init.d aceita geralmente três parâmetros: start, stop, restart. Estes parâmetros indicam, respectivamente, a ativação, desativação e desativação seguida de ativação do processo.
Para determinar o nível de execução em que seu sistema está funcionando, utilize o comando /sbin/runlevel. Este comando irá consultar o arquivo /var/run/utmp para determinar o estado atual e o anterior. Caso o estado anterior não possa ser determinado é exibida a letra "N" em seu lugar:

# /sbin/runlevel
N 3

Alteração dos Níveis de Execução
Os níveis de execução podem ser mudados pelo superusuário com o sistema em funcionamento. Sempre que é alterado um nível de execução são comparados, nos dois níveis, os processos que devem ser ativados e quais devem ser desativados. O processo init, que é processo pai de todos os demais (PID 1), compara a lista dos processos que devem ser encerrados no diretório indicativo do nível de execução atual com a lista dos processos que devem ser ativados no nível de execução de destino. De posse desta informação o processo init determinará quais processos devem ser ativados ou desativados.
Para reiniciar o sistema basta executar o comando
init 6 Veja a lista dos links em /etc/rc.d/rc6.d:
K00linuxconf K05keytable K10xfs K15gpm K15httpd K30sendmail K50inet K60atd K60crond K60lpd K75netfs K80random K89portmap K90killall K90network K99syslog S00reboot Como se pode ver, a maioria dos links inicia-se com a letra "K", indicando que os processos serão desativados. Apenas um link inicia-se por "S", S00reboot, que aponta para o script /etc/init.d/halt.
Similarmente, para colocar o sistema em modo monousuário
init 1 Nível de Execução Padrão
O nível em que o sistema irá funcionar é indicado pela entrada
id:3:initdefault: do arquivo /etc/inittab. Neste sistema o nível padrão de execução é 3. Para alterar este nível de execução basta alterar o número "3" para o valor desejado. Nunca altere este valor para "0" ou "6", que indicam, respectivamente, o sistema parado ou em modo de encerramento.
Definição ou Remoção de Processos Residentes
Para desativar um serviço de um determinado nível de execução basta remover o link simbólico do diretório apropriado. Por exemplo, para desativar o serviço httpd, do nível de execução 3, basta remover o link /etc/rc.d/rc3.d/S85httpd do diretório /etc/rc.d/rc3.d.
Similarmente, para inserir um novo serviço, basta criar um link no diretório padrão de execução, apontando para o script correspondente em /etc/rc.d/init.d:
# cd /etc/rc.d/rc3.d # ln -s /etc/rc.d/init.d S99local Este script realmente existe e é normalmente utilizado para inserir os serviços locais. Pela numeração (99), este script sempre será o último a ser ativado.
Importante, certifique-se de escolher uma numeração que posicione a ativação do script na ordem correta. Se o serviço é dependente do funcionamento da rede ele deve necessariamente ser ativado após estes serviços estarem ativos.
Utilitários para Configuração dos Níveis de Execução
Até agora abordamos a configuração manual dos scripts de inicialização. Existem entretanto diversos utilitários para realizar este este trabalho.

• chkconfig
  Utilitário para configuração dos níveis de execução invocado a partir da linha de comandos
• ksysv
  Utilitário gráfico que permite a configuração dos níveis de execução e ativação e desativação de processos individuais
• linuxconf
  Ferramenta genérica de configuração que permite o gerenciamento dos níveis de execução

A forma mais segura de se lidar com esta configuração certamente começa com o entendimento perfeito de seu funcionamento. As interfaces gráficas podem obscurecer o significado real do que se está fazendo e conduzir a uma configuração indesejável. Em qualquer situação, realizando-se o trabalho manualmente ou através de utilitários, recomendamos o backup de todos os arquivos envolvidos para poder retornar à uma situação estável em caso de problemas.
Para lidar com a ativação e desativação de processos residentes, algo que frequentemente precisamos fazer sempre que alteramos a configuração de um serviço, precisamos realizar os seguintes passos:
# cd /etc/rc.d/init.d
# httpd restart
Em nosso exemplo nos dirigimos ao diretório onde ficam todos os scripts de ativação de processos e invocamos o script httpd com o parâmetro "restart".
Um artifício engenhoso para realizar esta tarefa nos é fornecido, através de um alias, em sistemas Conectiva Linux. Este alias, disponível no ambiente do usuário root, chama-se cds:
alias cds='cd /etc/rc.d/init.d && ls'
Como podemos ver, o alias realiza dois passos: a mudança para o diretório /etc/rc.d/init.d e a listagem de seu conteúdo. Desta forma podemos visualizar o nome de todos os scripts disponíveis, facilitando a invocação do script apropriado. Simples, mas extremamente útil.

INIT

 Com o comando innit vc pode iniciar o SO de modo diferente:

• 0 - Interrompe a execução do sistema. todos os programas e daemons finalizados. É acionado pelo comando shutdown -h
• 1 - Modo monousuário, útil para manutenção dos sistema.
• 2 - Modo multiusuário (padrão da Debian)
• 3 - Modo multiusuário
• 4 - Modo multiusuário
• 5 - Modo multiusuário com login gráfico
• 6 - Reinicialização do sistema. Todos os programas e daemons são encerrados e o sistema é reiniciado. É acionado pelo comando shutdown -r e o pressionamento de CTRL ALT DEL.

Mais informações consulte: http://pt.wikibooks.org/wiki/Guia_do_Linux/Avan%C3%A7ado/A_distribui%C3%A7%C3%A3o_Debian_GNU/Linux/N%C3%ADveis_de_Execu%C3%A7%C3%A3o 

e
http://www.flaviotorres.com.br/fnt/artigos/init.php

Serviços de sistema: dando nomes aos bois

Fonte: http://www.hardware.com.br/dicas/servicos-sistema.html

Por Carlos E. Morimoto em 23 de março de 2011 às 11h12
5

Em um post anterior, falei sobre os serviços do sistema, que são scripts, localizados na pasta "/etc/init.d", que executam os comandos apropriados para inicializar os serviços e executar as demais operações necessárias. Alguns deles são executados apenas durante o boot (verificando alguma configuração, por exemplo), enquanto outros inicializam serviços que ficam ativos continuamente.
Além de serem controlados através do painel, os serviços podem ser também controlados via terminal, através dos comando "/etc/init.d/serviço start", "/etc/init.d/serviço stop" e "/etc/init.d/serviço restart", como em:
# /etc/init.d/smb restart
Vamos então a uma descrição de alguns dos principais serviços encontrados em distribuições atuais:
acpid: Este é o serviço responsável por monitorar as funções relacionadas ao ACPI (em conjunto com os módulos do kernel) e enviar informações sobre os eventos para os aplicativos correspondentes. O acpid é um serviço importante, já que sem ele as funções de monitoramento da carga da bateria, ajuste do clock do processador e (em muitas máquinas) até mesmo as teclas de função deixam de funcionar.
alsa: O ALSA é o conjunto de módulos responsável pelo suporte a placas de som. Este serviço se encarrega de ativar os módulos apropriados, criar os dispositivos e desempenhar algumas funções secundária, como salvar e restaurar os volumes. Mesmo que esteja sendo usado o PulseAudio ou outro servidor de som, os drivers do ALSA continuam sendo os responsáveis pelo acesso de baixo nível à placa de som.
anacron: Em qualquer distribuição Linux, diversas tarefas de manutenção do sistema são agendadas através do cron e executadas uma vez por dia, ou uma vez por semana, geralmente durante as madrugadas, quando presume-se que o PC não estará sendo utilizado. O anacron é um serviço responsável por executar as tarefas fora de hora, em casos em que o PC não fica ligado o tempo todo.
avahi-daemon: O Avahi é uma implementação do protocolo Zeroconf, que nasceu como uma idéia da Apple para facilitar a configuração da rede, permitindo que as máquinas divulguem e descubram os serviços disponíveis. É uma daquelas idéias que parecem boas na teoria, mas viram uma bagunça quando implementadas na prática. A menos que você seja um administrador de redes e esteja implantando uma rede com o Zeroconf, é recomendável desativar o avahi-daemon. Em situações normais, ele não deve atrapalhar, mas em determinadas situações ele pode consumir excessivamente recursos do sistema e retardar a resolução de nomes, tornando o acesso mais lento.
bluetooth: Este é o serviço responsável pelo suporte genérico a dispositivos Bluetooth. Ele tem a função de ativar o transmissor Bluetooth (caso presente) e ativar as funções que são usadas pelo Kbluetoothd e outros aplicativos. Naturalmente, você não precisa dele se não usar um adaptador Bluetooth.
cpufreq: O cpufreq é o responsável por ajustar a frequência de operação do processor, de acordo com a carga de trabalho, o que é uma função essencial em qualquer máquinas atual. Desativando o serviço, o processador passará a trabalhar o tempo todo na frequência máxima, o que pode ser desastroso, sobretudo em notebooks. O cpufreq suporta o uso de perfis de desempenho (performance, powersave, etc.), que podem ser ajustados através da opção "Gerenciamento de energia" do Systemsettings (no KDE 4) ou através do applet "Monitor de frequência" (no Gnome).
crond: O crond é o agendador de tarefas padrão no Linux. Além de poder ser usado para executar scripts de backup ou de atualização do sistema (entre inúmeras outras possibilidades), ele é usado pelo sistema para diversas tarefas de manutenção, por isso nunca deve ser desativado.
Você pode agendar tarefas no cron através do arquivo "/etc/crontab", ou através das pastas "/etc/cron.hourly" (scripts executados uma vez por hora), "/etc/cron.daily" (uma vez por dia), "/etc/cron.weekly" (toda semana), "/etc/cron.montly" e "/etc/cron.yearly". Ele é também utilizado por diversos aplicativos gráficos que permitem agendar tarefas.
dm: No Mandriva, este é o serviço responsável pela ativação do KDM ou do GDM, que se encarregam de carregar o ambiente gráfico. Desativar este serviço é uma maneira rápida de derrubar o X em situações que você precisa desativá-lo, como ao instalar o driver da nVidia.
dund: Este serviço controla um recurso muito específico: a criação da porta serial que é usada ao conectar à web usando um smartphone via Bluetooth.
haldaemon: Este é o serviço responsável pelo HAL, que é o responsável por monitorar a conexão de dispositivos disponíveis, ativar a placa de rede cabeada quando um cabo de rede é conectado e diversas outras operações. Ele é um dos serviços básicos em qualquer distribuição atual, por isso é desativado apenas em casos muito específicos.
hidd: Este é mais um serviço relacionado ao Bluetooth, responsável por permitir a conexão de mouses e teclados. Se você estiver tendo dificuldades em ativar seu mouse Bluetooth usando o KBluetooth (o responsável pelo ícone ao lado do relógio), é em provável que esse serviço esteja desativado.
Em distribuições derivadas do Debian (incluindo o Ubuntu) o dund e o hidd são integrados ao serviço principal do Bluetooth e são ativados ou desativados através da configuração colocada no arquivo "/etc/default/bluetooth".
Usando as linhas "HIDD_ENABLED=0" e "DUND_ENABLED=0" eles ficam desativados e mudando para "HIDD_ENABLED=1" e "DUND_ENABLED=1" eles ficam ativos. Como de praxe, a configuração é ajustada automaticamente pelos aplicativos de configuração. Ao conectar um mouse Bluetooth usando o ícone ao lado do relógio, por exemplo, o hidd será automaticamente ativado.
iptables: O Iptables é o firewall padrão do sistema, incorporado diretamente ao kernel. Além de ser configurado através de aplicativos gráficos (como o Firestarter) ou através de interfaces de configuração (como o Segurança > Configurar Firewall" disponível no Centro de Controle do Mandriva), o Iptables pode ser configurado diretamente, através de comandos de terminal.
Em ambos os casos, as regras de Firewall são salvas no arquivo "/etc/sysconfig/iptables", e são ativadas durante o boot pelo serviço "iptables". Ao desativar o serviço, você desativa o Firewall, e faz com que o sistema utilize as políticas padrão (que, dependendo da distribuição, podem ser permitir tudo, ou bloquear tudo).
Este serviço também existe em distribuições derivadas do Debian e funciona basicamente da mesma maneira. A principal diferença é que no caso delas a configuração é armazenada no arquivo "/etc/default/iptables".
ip6tables: Esta é a versão do Iptables que trabalha em conjunto com o protocolo IPV6. Ela foi desenvolvida com o objetivo de conviver pacificamente com a versão antiga. Como quase todas as distribuições atuais mantêm o suporte a IPV6 ativo por padrão, é interessante manter também o ip6tables ativo, para evitar eventuais brechas de segurança.
laptop-mode: É responsável por ativar diversas opções relacionadas ao consumo de energia, aumentando sutilmente a autonomia das baterias em notebooks. Um dos principais tweaks é permitir que o HD seja desligado com maior frequência, já que depois da tela e do processador, ele é o componente que mais consome energia.
Além de não ser muito efetivo, este serviço foi o causador do célebre bug que abreviava a vida útil do HD que afetou versões do Ubuntu e do Mandriva. Embora o problema já tenha sido corrigido, é recomendável mantê-lo desativado por precaução, principalmente se você está utilizando o KDE 4.x, onde o PowerDevil faz um trabalho mais competente.
mandi: O Mandi é um detector de intrusões otimizado para uso em desktops. Ele tem a função de monitorar os pacotes de entrada, detectando indícios de ataques, como por exemplo portscans. Sempre que um ataque é identificado, ele bloqueia o acesso temporariamente usando regras de firewall e envia uma mensagem ao gerenciador de conexões de rede usando o dbus, o que faz com que uma mensagem seja exibida na tela.
Ele é usado por padrão no Mandriva e em algumas outras distribuições e, como qualquer outro sistema de detecção de intrusões, acaba por exibir alguns falsos positivos, o que faz com que muitos prefiram desativá-lo, usando no lugar um firewall simples. Ele também deve ser desativado se você pretender utilizar o Firestarter ou outro firewall gráfico.
messagebus: Este é o serviço responsável pelo DBUS, o servidor de mensagens que é o responsável por transportar as mensagens geradas pelo HAL e outros componentes do sistema. Ele é um dos serviços básicos do sistema e nunca deve ser desativado.
network: Este é o serviço responsável pela ativação das interfaces de rede. Desativá-lo é uma forma rápida de derrubar a rede e reiniciá-lo faz com que o sistema releia os arquivos de configuração de rede, fazendo com que uma nova configuração entre em vigor. Este serviço é encontrado em praticamente todas as distribuições, mas existem diferenças na forma como a configuração da rede é armazenada.
No Mandriva e em outras distribuições da família do Red Hat, a configuração da rede é armazenada na forma de diversos arquivos dentro do diretório "/etc/sysconfig/network-scripts/", enquanto nas distribuições derivadas do Debian é usado um único arquivo, o "/etc/network/interfaces". Em ambos os casos, o serviço se encarrega também de carregar as regras de firewall (caso definidas no "/etc/sysconfig/iptables" ou no "/etc/default/iptables").
Hoje em dia, a configuração da rede é quase sempre feita usando utilitários gráficos, como no caso do drakconnect e do NetworkManager, mas saber como configurar a rede manualmente ainda pode ser útil em muitas situações.
nfs-common: Este serviço ativa os componentes básicos necessários para montar compartilhamentos via NFS. Ele é uma maneira prática de compartilhar arquivos entre máquinas Linux, mas é pouco usado em redes locais, onde o Samba e os compartilhamentos de rede do Windows são de longe os mais usados.
portmap: O portmap é outro serviço relacionado ao NFS, responsável por escutar as portas utilizadas para transmissão dos dados. Se o portmap estiver desativado, o sistema fica um longo tempo tentando montar os compartilhamentos e no final retorna uma mensagem de erro. Alguns outros serviços de rede, como o NIS, também utilizam o portmap, mas eles são pouco comuns hoje em dia.
sshd: Caso o servidor SSH (pacote "openssh-server") esteja instalado, este serviço permite ativá-lo ou desativá-lo conforme desejado. O SSH oferece muitos recursos (acesso remoto, transferência de arquivos, criação de túneis, etc.) e representa um risco de segurança muito pequeno, por isso é muito comum que ele seja usado mesmo em desktops.
syslog: O syslog é o serviço responsável por escrever os logs do sistema, a partir das mensagens enviadas pelos diferentes serviços. Ele não é obrigatório, mas é sempre interessante mantê-lo ativado, com exceção de casos em que você queira desativar os logs para reduzir os acessos ao HD (e assim poder mantê-lo em modo de baixo consumo por mais tempo, economizando energia) em notebooks.
xinetd: Sucessor do antigo inetd, o xinetd tem a função de monitorar determinadas portas TCP e carregam serviços sob demanda. Isto evita que serviços e utilitários que são acessados esporadicamente precisem ficar ativos o tempo todo, consumindo recursos do sistema. Em vez em um único arquivo de configuração, com uma linha para cada serviço, o xinetd utiliza um conjunto de arquivos de configuração (um para cada serviço) que são armazenados na pasta "/etc/xinetd.d/".

KDUMP

KEXEC é um mecamisno de fast boot que permite iniciar um kernel Linux a partir de um kernel já em execução sem passar pela BIOS.

KDUMP é um novo mecanismo de kernel crash dump, capturando o dump utilizando o kexec inicializando em um segundo kernel sempre que o sistema falha, inicializa com pouca memória e captura o dump image.

Réplica da base LDAP com SSL/TLS e SASL

FONTE: http://www.nisled.org/index.php?/Demo-category/securities-and-financial-reporting.html

A réplica na base LDAP é um elemento de fundamental importância para segurança dos dados e para balanceamento de carga.

 Como mostra a figura 1, podemos ter um servidor “master” que recebe os dados e distribui para outros “slave” que pode estar em qualquer parte da empresa, desde um servidor ao lado até em um servidor na matriz em outro país.


A réplica é uma solução bastante utilizada, porém também é um dos momentos mais críticos, pois os dados “inteiros” são transferidos pela rede e até pela Internet. Por isso é de fundamental importância a implementação de métodos que protejam essas informações de curiosos. Neste artigo vamos utilizar duas formas de proteção dos dados, que são:

• TLS/SSL – Criação de um canal criptografado para transferência dos dados; e
• SASL – Vamos utilizar Cyrus-SASL, que implementa uma camada de segurança na autenticação.

Para demonstrar os recursos do LDAP, vamos começar desde a instalação até a réplica da base LDAP. Vamos utilizara distribuição Ubuntu-Server.
1- Instalação do servidor LDAP
Para instalação do OpenLDAP vamos utilizar os pacotes pré-compilados da distribuição.
[root@master]# apt-get install slapd ldap-utils
Com a instalação feita, o próximo passo é a configuração do LDAP. Para isso apague o diretório slapd.d que está dentro do diretório /etc/ldap e crie o arquivo slapd.conf, conforme o exemplo a seguir:

include         /etc/ldap/schema/core.schema
include         /etc/ldap/schema/cosine.schema
include         /etc/ldap/schema/inetorgperson.schema
include         /etc/ldap/schema/openldap.schema
include         /etc/ldap/schema/nis.schema
include         /etc/ldap/schema/misc.schema
password-hash           {CRYPT}
defaultsearchbase       dc=curso,dc=ldap
pidfile         /var/run/slapd/slapd.pid
argsfile        /var/run/slapd/slapd.args
loglevel        1024
modulepath      /usr/lib/ldap
moduleload      back_bdb
moduleload      back_monitor
access to dn.base=""
by * read
access to dn.base="cn=Subschema"
by * read
access to dn.subtree=cn=Monitor
by * read
database        monitor
database        bdb
cachesize       5000
mode            0600
suffix          "dc=curso,dc=ldap"
checkpoint      512 720
rootdn  "cn=manager,dc=curso,dc=ldap"
rootpw  pedra
# Indexing
index   default                                                 sub
index   uid,mail                                                eq
directory       "/var/lib/ldap "
lastmod on

Mude o dominio (dc=curso,dc=ldap) LDAP para aquele que desejar. Em seguida altere o arquivo /etc/default/slapd, e acresce altere a seguinte linha:
SLAPD_CONF="/etc/ldap/slapd.conf"
Feito essas configurações, já podemos iniciar o slapd.
[root@master]# /etc/init.d/slapd restart
Verifique se a porta 389 está aberta.
1.2 -  Criação da base
A figura 2 mostra a estrutura que vamos utilizar na base LDAP.

Segue o arquivo estrutura.ldif

dn: dc=curso,dc=ldap
objectClass: top
objectClass: dcObject
objectClass: organization
dc: curso
o: Sistema de Backup
dn:ou=people,dc=curso,dc=ldap
objectClass: top
objectClass: organizationalunit
objectClass: dcObject
dc: curso
ou:people
dn:ou=group,dc=curso,dc=ldap
objectClass: top
objectClass: organizationalunit
objectClass: dcObject
dc: curso
ou:group
dn:uid=jose,ou=people,dc=curso,dc=ldap
objectClass: top
objectClass: person
objectClass: posixAccount
objectClass: inetOrgPerson
cn:jose
sn: sila
mail:  jose@jose.com
telephonenumber:11-11-1-11
uid: jose
userPassword: x
homeDirectory: /home/jose
displayName: Jose Silva
loginShell: /dev/null
uidNumber: 512
gidNumber: 100
dn: cn=administrador,ou=group,dc=curso,dc=ldap
objectClass: posixGroup
cn: administrador
gidNumber: 999
memberUid: jose

Com o arquivo criado, vamos utilizar o comando ldapadd para importar o arquivo LDIF para a base LDAP
[root@master]# ldapadd –f estrutura.ldif –x –D cn=manager,dc=curso,dc=ldap –W
2 - SSL
Com a estrutura da base LDAP feita, vamos implementar o TLS/SSL no servidor LDAP. Para isso certifique que o pacote opessl esteja instalado. No primeiro passo vamos criar o diretório que será criado o CA (certificador).
[root@master]# mkdir /opt/CAtls
Dentro do diretório criado, execute o script CA.sh –newca para criar um novo CA.
[root@master]opt/CAtls# /usr/lib/ssl/misc/CA.sh –newca
No campo “Enter PEM pass phrase” defina a senha para validação do certificado. Esta Senha vai ser usada para validação das chaves. Preencha os campos como mostra a figura 03;

}  No campo “A challenge password []:”, não defina nada, pressione “enter”. Essa é uma senha além da chave. Toda vez que for utilizar a chave terá que digitar a senha.
}  No campo “Enter pass phrase for” digite a senha definida no “Enter PEM pass phrase”
Após a criação do CA, vamos criar a chave:
[root@master]opt/CAtls# openssl req -newkey  rsa:1024  -nodes -keyout newreq.pem -out newreq.pem
E para finalizar é necessário assinar a chave utilizando o CA criado.
[root@master]opt/CAtls# /usr/lib/ssl/misc/CA.sh –sign
}  Digite a senha do CA e responda todos os questionamentos como “yes”
Agora temos as seguintes chaves:

Copie as chaves para o diretório LDAP:
Crie o diretório para chave no slapd:
[root@master]# mkdir /etc/ldap/tls
Copie as chaves:
[root@master]# cp /opt/CAtls/demoCA/cacert.pem /etc/ldap/tls/
E para terminar a configurar, temos que incluir as seguintes linhas no arquivo slapd.conf:

TLSCACertificateFile /etc/ldap/tls/cacert.pem
TLSCertificateFile /etc/ldap/tls/servercrt.pem
TLSCertificateKeyFile /etc/ldap/tls/serverkey.pem
# Verificação no cliente não é requirida
TLSVerifyClient never

Para o LDAP iniciar automaticamente o SSL, é necessário novamente alterar o arquivo /etc/default/slapd e mudar a seguinte linha:
SLAPD_SERVICES="ldap:/// ldapi:/// ldaps:///“
Reinicie o servidor LDAP e verifique se a porta 636 está aberta.
2.1 - Cliente LDAP com SSL
Antes de iniciar a réplica da base LDAP, vamos testar se o servidor LDAP está respondendo corretamente com o SSL. Para fazermos os testes, crie as chaves no cliente igualmente como criamos no servidor.
Copei as chaves para o diretório /home/tls
[root@master]# cp /opt/CAtls/demoCA/cacert.pem /home/tls/
No primeiro teste vamos utilizar o próprio openssl para fazer a conexão com o servidor.
[root@master]# openssl s_client –connect  master.curso.ldap:636 –showcerts –state –CAfile /home/tls/cacert.pem


Perceba o “Verify Return Code”, deve estar ok. Para finalizar o programa utilize o CTRL+ C.
Para ldapsearch ou alguém outro programa do LDAP poder funcionar utilizando a conexão SSL, vamos editar o arquivo /etc/ldap/ldap.conf acrescentando as configurações das chaves criadas no cliente.

URI     ldaps://localhost
TLS_CACERT /home/tls/cacert.pem
TLS_CERT     /home/tls/ldap.clientecrt.pem
TLS_KEY      /home/tls/ldap.clientekey.pem
TLS_REQCERT never

Feito isso já podemos testar a conexão utilizando o comando LDAPSEARCH. Como mostra o comando seguinte:
[root@master]# ldapsearch -b dc=curso,dc=ldap -D cn=manager,dc=curso,dc=ldap -w pedra –Z
A opção “-Z” faz o ldapsearch utilizar a conexão tls. Esse comando deve retornar toda a estrutura da base LDAP.
3 - SASL
SASL é um acrônimo para Simple Authentication and Security Layer, como o nome diz é uma camada de segurança para autenticação simples, provendo uma camada de criptografia para os protocolos orientados à conexão.
A implementação SASL do slapd utiliza o software Cyrus SASL com suporte a vários mecanismos, incluindo DIGEST-MD5 e CRAM-MD5. Vamos instalar o SASL com suporte ao LDAP usando os pacotes do ubuntu-server, como mostra os comandos a seguir.
[root@master]# apt-get install sasl2-bin libsasl2-2 libsasl2-modules libsasl2-modules-ldap
O LDAP e o SASL irão se comunicar em ambas os lados. Isso significa que vamos fazer o LDAP reconhecer os usuário da base SASL e fazer o SASL reconhecer os usuários do LDAP.
3.1 -  LDAP para SASL
Nessa primeira parte vamos fazer a configuração para que o SASL reconheça os usuários da base LDAP. Para fazer isso, primeiramente vamos configurar o arquivo /etc/default/ saslauthd.

START=yes
DESC="SASL Authentication Daemon"
NAME="saslauthd"
MECHANISMS="ldap"
MECH_OPTIONS=""
THREADS=5
OPTIONS="-c -m /var/run/saslauthd"

Neste arquivo o mais importante é mudar o comando “START” para “yes”, assim o SASL vai ser inicializado automaticamente, a outra alteração é o “MECHANISMS” para buscar os usuários no LDAP. Também é preciso configurar o arquivo /etc/ saslauthd.conf para fazer o SASL buscar as informações na base LDAP.

ldap_servers: ldap://localhost/

Neste arquivo mude os atributos, ldap_bind_dn e o ldap_bind_pw para as informações da sua base LDAP. Faça a mesma coisa com o atributo ldap_search_base.
Antes teste o SASL lembre-se de reinicar o SASL
[root@master]# /etc/init.d/saslauthd restart
Vamos testar para saber se o SASL tá buscando os usuário na base LDAP.
[root@master]# root@ldapserver:/etc# testsaslauthd -u jose -p x
0: OK "Success."
A parâmetro “–u” especifica o usuário e o “–p” a senha. Como você pode ver a configuração do SASL com LDAP tá funcionando perfeitamente.
Em alguns casos é necessário ajustar a permissão do diretório /etc/sasldb2 para que a autenticação funcione.
3.2 -  SASL para LDAP
Neste ponto vamos fazer o LDAP reconhecer os usuários criados na base do SASL.
Primeiramente crie um usuário na base do SASL. É aconselhável ser o mesmo usuário do rootdn do LDAP. O comando que cria usuário no SASL
[root@master]# saslpasswd2 -c admin
Ao executar esse comando, será pedida uma senha para a criação do usuário.
Também é preciso executar o comando ldapsearch para verificar se o LDAP tem suporte ao SASL.

[root@master]# ldapsearch -x  -LLL -s "base" -b "" supportedSASLMechanisms

A saída à cima mostra que o LDAP está com suporte ao SASL. O próximo comando que vamos utilizar é o ldapwhoami e ldapsearch para autenticar o usuário do SASL.
[root@master]# ldapwhoami -h localhost -U admin
Como mostra o comando acima, o LDAP autenticou o usuário do SASL corretamente. E agora podemos usar o usuário do SASL para outras aplicações do LDAP, tais como ldapsearch.

[root@master]# ldapsearch -U admin@ldapserver -b 'dc=curso,dc=ldap' '(objectclass=*)'
SASL username: admin@ldapserver
SASL data security layer installed.
# curso.ldap
dn: dc=curso,dc=ldap
objectClass: top
objectClass: dcObject
objectClass: organization
dc: curso
o: Clodonil Trigo
# people, curso.ldap
dn: ou=people,dc=curso,dc=ldap
objectClass: organizationalUnit
ou: people

O ldapsearch autenticou o SASL corretamente, como mostra a saída acima.
4 - Réplica
Agora com o SSL/TLS e SASL configurados e funcionando, podemos passar para configuração da réplica de conforma segura. Vamos utilizar a réplica com Syncrepl, que é a forma mais moderna.
As principais características do syncrepl são:

• Trabalha no modo stateful. A réplica é baseado em status, não precisa de arquivo de logs;
• Sincronização completa;
• Cliente inicia a réplica;
• Sincronização baseado em eventos ou por períodos (rajadas);
• Multi-Master;

Vamos dividir a configuração em duas partes, sendo o master o servidor que recebe as alterações na base LDAP. Já o slave é o servidor que recebe as mudanças do servidor master.
MASTER:
A configuração do master que é o provider são as seguintes:

moduleload  syncprov
overlay syncprov
syncprov-checkpoint 100 10
syncprov-sessionlog 100
index entryCSN   eq
index entryUUID eq

Acrescente essas configurações no slapd.conf do master. Segue o slapd.conf do master completo.
SLAVE:
Já do lado slapd.conf do slave vamos mostar duas configurações que podem trocar a transferência dos arquivos durante a réplica bem segura.
O primeiro é usando SSL, mas com autenticação simple. As linhas a seguir deve ser incluídas no slapd.conf do slave (link do slapd.conf completo):

provider=ldaps://10.0.0.102:636

A configuração do slave que estamos utilizando trabalha com SSL (ldaps://10.0.0.102:636) e trabalha em modo de rajada em cada 10 segundos. Perceba a tabulação após a primeira linha. Essa tabulação é de fundamental importância para o funcionando da réplica.
A outra configuração alternativa para slapd.conf dá réplica é utilizar o SSL com autenticação SASL.
A seguir estão as linhas para implementar a réplica com SASL e SSL juntos (slapd.conf completo com sasl).

provider=ldaps://10.0.0.102:636

A configuração do syncrepl com SASL e SSL é muito parecida com o anterior. As principais mudanças são os “bindmethod” que foi mudado para sasl e o “authcid” que define o usuário do SASL.
Após ter escolhido uma das formas de réplica, inicie o servidor master e em seguida inicie o servidor slave que automaticamente os atributos do master serão replicados no slave.
Em caso de erro, inicie o slapd em modo de debug para identificar os erros.
[root@master]# slapd –d 123 –u openldap
E com isso temos a configuração de um dos principais recursos do LDAP que é a réplica em modo seguro com SSL/TLS e com autenticação segura com SASL. Lembrando que esses recursos estão disponíveis para outros recursos.

Wireshark

Fonte: http://pragasdigitais.blogspot.com/2011/05/desabilitar-selinux-centos.html

Desabilitando o SELinux

O SELinux (Security-Enhanced Linux) é uma implementação de uma camada de segurança para o Linux, desenvolvido basicamente pela NSA (National Security Agency), a Agência Nacional de Segurança dos Estados Unidos. Ele vem habilitado por padrão na distribuição CentOS. O problema é que, sem configuração específica, ele impede a atualização/transferência de zonas DNS pelo bind/named.

Para verificar se o selinux está habilitado em seu sistema, execute o seguinte comando

selinuxenabled; echo $?

Caso o resultado seja 0, o SELinux está habilitado. Se o resultado for 1, então está desabilitado.

Para desabilitar o SELinux, faça o seguinte:

Edite o arquivo /etc/selinux/config. Localize a linha

SELINUX=enforcing

e troque por

SELINUX=disabled

Isso vai desabilitar o SELinux no próximo reboot. Para desabilitar imediatamente, execute o seguinte comando:

setenforce 0

Isso vai desabilitar o SELinux até o proximo reboot.

Comando yum

Fonte: http://www.opcaolinux.com.br/gnulinux/dicas/14-comandos-linux/68-gerenciadores-de-pacotes.html

Tarefa a ser executada	yum / rpm CentOS / Fedora	apt / dpkg Debian / Ubuntu
Gerenciando o software
Instalar software usando repositórios	yum install pacote	apt-get install pacote
Instalar software usando arquivo de pacote	yum localinstall pacote.rpm rpm -ivh pacote.rpm	dpkg -i pacote.deb
Atualizar um software	yum update pacote rpm -Uvh pacote.rpm	apt-get install pacote
Remover um software	yum erase pacote	apt-get remove pacote
Atualizando o sistema
Atualizar lista de pacotes	yum check-update	apt-get update
Atualizar o sistema	yum update	apt-get upgrade
Procurando por pacotes
Procurar pelo nome do pacote	yum list pacote	apt-cache search pacote
Procurar por padrão	yum search padrão	apt-cache search padrão
Procurar pelo nome do arquivo	yum provides arquivo	apt-file search caminho
Listar todos os pacotes instalados	rpm -qa	dpkg -l
Configurando o acesso a repositórios de software
Listar repositórios	yum repolist	cat /etc/apt/sources.list
Adicionar repositório	(adicionar à /etc/yum.repos.d/)	(editar /etc/apt/sources.list)
Remover repositório	(remover de /etc/yum.repos.d/)	(editar /etc/apt/sources.list)
Comandos diversos
Verificar se um pacote está instalado	rpm -q pacote	dpkg -s pacote
Listar arquivos de um pacote instalado	rpm -ql pacote	dpkg -L pacote
Listar arquivos de um arquivo de pacote	rpm -qpl pacote.rpm	dpkg -c pacote.deb
Obter informações de um arquivo de pacote	rpm -qpi pacote.rpm	dpkg -I pacote.deb
Descobrir a que pacote pertence um arquivo	rpm -qf arquivo	dpkg -S arqiivo

Matahari

Fonte: https://github.com/matahari/matahari#readme
 
Matahari fornece agentes QMF que podem ser usados ​​para controlar e gerir várias peças de funcionalidade, utilizando o protocolo AMQP.
O Advanced Message Queuing Protocol (AMQP) é um aplicativo de padrão aberto camada de protocolo que assegura o transporte confiável de mensagens.
QMF fornece uma camada de estrutura de modelagem em cima de qpid (que implementa AMQP). Essa interface permite que você gerencie um host e seus vários componentes como um conjunto de objectos com propriedades e métodos.

Matahari Agents Build and Install Instructions

Building from source

Step 1 - Install Build Dependencies
Matahari has build dependencies on the following packages:

1. pcre-devel
2. glib2-devel
3. qpid-qmf
4. qpid-qmf-devel
5. qpid-cpp-client
6. qpid-cpp-server
7. qpid-cpp-client-devel
8. qpid-cpp-server-devel
9. sigar
10. sigar-devel
11. libcurl
12. libcurl-devel
13. dbus-glib
14. dbus-glib-devel
15. polkit
16. polkit-devel
17. augeas
18. augeas-devel
19. cmake
20. nss-devel

Matahari requires that the following packages are installed at runtime for certain pieces of functionality to work:

1. puppet, version 2.6.6 or above, required for the sysconfig agent
2. dmidecode, required for the host agent

These packages may be available in your distribution. In Fedora 14 (or later), they can be installed via the yum command. For Fedora users, the script contrib/scripts/install_deps.sh will install the required packages.
Step 2 - Build Matahari

user% make
user% cd linux.build
user% make
root# make install

Installing on Fedora 14 or later

Matahari is pre-packaged for Fedora 14 and later.

root# yum install matahari

Windows instructions

On your Fedora box first:

yum install mingw32-matahari

copy the /usr/share/matahari*/*iso to Windows machine.( or burn iso )
load iso/cd; run setup

Morrer é preciso!

1 Coríntios 1:18
Porque a palavra da cruz é loucura para os que perecem; mas para nós, que somos salvos, é o poder de Deus.


É difícil falar de fé quando esta exige de nós dar o que mais valorisamos. É muito fácil nos alienarmos ao mundo espiritual que não vemos e nos limitarmos somente a aquilo que vemos e achamos. Mas infelizmente somos limitados e impotentes demais para nos darmos o luxo de ignorar nosso futuro, ou então seremos cruéis demais para conosco ao fecharmos os olhos para tantos mistérios incompreensíveis, porém REAIS, tão reais que estão a ponto de nos alcançar no momento que desejarem como a morte, a doença fatal, a perda de um filho, a guerra cruel, a violência, a falência, a loucura, etc.
Será que nossa teimosia em rejeitar o óbvio é maior do que as evidências a nossa volta?  Creio que não!Negar a realidade não é uma solução inteligente para obtermos bons resultados. Por isso minha inteligência e meu instinto de sobrevivência me exige uma posição de busca e de meditação por/em Deus para, pelo menos, fazer minha parte, mesmo que esta verdade me exija tomar decisões que me custem a vida.

Para vivermos é preciso morrer.
Assita o vídeo e medite nesta mensagem com o coração aberto!

A salvação é somente em Cristo!

Tipos de VMware

Fonte: http://hercules-now.com/2010/10/01/virtualizacao-de-sistemas-operacionais-iv/
4.2.2 VMware Server
O VMware Server (que anteriormente chamado de VMware GSX Server) é a versão para uso em servidores de pequenos e médios portes. Tornou-se gratuito em 12 de junho de 2006 e disponibilizado para download no site oficial do fabricante.
O VMware Server é uma máquina virtual do tipo II, ou seja, é necessário que o software execute sobre um sistema operacional anfitrião que pode ser em sistemas operacionais baseados em Linux ou Windows (existe uma versão para cada um destas plataformas).
O programa permite que sejam criadas diversas máquinas virtuais suportando alguns sistemas convidados de um modo otimizado, como por exemplo, algumas versões do Windows, Linux, Solaris e BSD.  Existe também um modo genérico para
que se utilize outros sistemas operacionais sem suporte específico.
O VMware Server, assim como o VMware ESX, também suporta máquinas virtuais com uma ou duas CPU virtuais. Ele pode compartilhar com os sistemas convidados, periféricos do hardware como: CD-ROM, placas de rede e portas USB.
Com ele existe a possibilidade de criar registros instantâneos (chamado de “snapshot”) de uma máquina virtual num dado momento, no qual é possível fazer backup em um determinado estado, ou testar configurações em que se pode reverter.

No VMware Server o suporte a rede é feito através de VMnets (como no ESX Server), possuindo três modos:
- Bridged: a máquina virtual é vista como um outro computador na rede, com endereço IP podendo ser obtido via DHCP.
- NAT: a máquina virtual se conecta ao computador anfitrião, que por sua vez se conecta a rede.
- Host-Only: a máquina virtual apenas se conecta ao anfitrião.
Além disso, possui uma interface web para gerenciamento remoto. Para administração dos sistemas operacionais, o software usa uma versão modificada do VNC (abaixo).

4.2.3 VMware Workstation
Esta é a versão comercial do VMware que é utilizada em estações de trabalho. Possui basicamente os mesmos recursos do VMware Server inclusive com a possibilidade de criar máquinas virtuais.
O VMware Workstation destaca-se pela facilidade de uso proporcionada por seus assistentes que guiam o usuário no processo de criação de máquinas virtuais. Ele também possui um assistente que ajuda a montar clones de máquinas virtuais. Também
é possível criar grupos de máquinas virtuais, de uma só vez, e colocá-las em redes.
Com o VMware Workstation é possível criar máquinas virtuais em dispositivos externo como um disco rígido ou um pen-drive, através de um produto adicional chamado ACE Option Pack.
4.2.4 VMware Player
Esta é a versão mais simples do produto e que também é disponibilizada gratuitamente para download. O VMware Player é indicado para aplicações leves e não pode criar máquinas virtuais, porém executa as máquinas virtuais criadas por outras versões mais completas.
4.2.5 VMWare Infrastructure
O VMware Infrastructure não é uma versão, na verdade ele é uma suíte de aplicativos de virtualização que otimiza o processo de implantação e gerenciamento de máquinas virtuais nas empresas. Ele visa oferecer, em uma solução integrada, ganhos em:
virtualização compreensiva, gerenciamento, otimização de recursos e disponibilidade de aplicações. A suíte é composta de um conjunto de aplicativos cujo principal é o VMware ESX Server. São eles:
- VMware ESX Server: O ESX é um software que provê uma camada de virtualização, no qual abstrai processador, memória, disco e recursos de rede. O ESX possui ainda, um sistema operacional próprio, o que visa aumentar o desempenho das máquinas virtuais.
- Virtual Symmetric Multi Processing (SMP): possibilita que uma simples máquina virtual use múltiplos processadores simultaneamente.
- Virtual Center Management Server: um ponto central para configurar e gerenciar infra-estrutura de TI virtualizada.
- Virtual Infrastructure Client: uma interface que permite administradores e usuários se conectarem remotamente ao Virtual Center Management Server ou instalações individuais do ESX.
- Virtual Infrastructure Web Access: Uma interface web para gerenciamento e acesso remoto.
- VMotion: habilita uma migração em tempo de execução de uma máquina virtual de um servidor para outro com a menor queda possível no nível de serviço.
- High Availability (HA): mantém a alta disponibilidade das máquinas virtuais. Com ele, em caso de falha de um servidor as máquinas virtuais afetadas são automaticamente reiniciadas em outros servidores de produção que possuam condições para abrigá-las.
- Distributed Resource Scheduler (DRS): Distribui de forma inteligente recursos de hardware para as máquinas virtuais.
- Consolidated Backup: um agente centralizado para backup de máquinas virtuais. Ele simplifica a administração e reduz a carga nas instalações do ESX Server.
No próximos tópicos irei publicar a virtualização XEN , Virtual Box e Microsoft Virtual PC e Microsoft Virtual Server cada um
material do Rodrigo Ferreira da Silva LABORATÓRIO NACIONAL DE COMPUTAÇÃO CIENTÍFICA

Máquinas Virtuais

Fonte: http://www.softelabs.com/Suporte/Tech_Support_Linux_and_Virtualization/Entendendo_a_Virtualiza%C3%A7%C3%A3o_-_Linux_Scrpting_com_VmWare

O que é então uma máquina virtual? É geralmente definida como uma aplicação de software " que roda num computador que executa programas como se de uma máquina real se tratasse". Essencialmente, é um Sistema Operativo "hóspede" ou "guest" que é executado e encapsulado num "mundo virtual" isolado de memória, de disco e um espaço de "host operativo" de um sistema. O Sistema O/S convidado não tem "consciência" de que não está em execução física, e que não dispõe de um hardware real. A memória, CPU , disco e interfaces de rede que são utilizados, são recursos fornecidos pelo computador host e pelo software ou núcleo de virtualização (designado de hypervisor "), que está em execução no host VM, e que está encarregado de criar um ambiente totalmente encapsulado que faz crer aos sistemas "condidados" de que estes dispõem de hardware e recursos exclusivos.

Um dos principais benefícios da computação através da virtualização e que desde o ano de 2000 é explorado, é o da consolidação: em vez de correr vários computadores físicos, que normalmente operam em 5% a 10% das suas capacidades, e usando um hardware separado, podemos executar os mesmos sistemas operativos, com todas as suas configurações separadas e aplicações, num único "host" que implementa o suporte de máquina virtual. Os diferentes sistemas operativos convidados e aplicaticações comportam-se exactamente como se estivessem a ser executados no hardware físico exclusivo, apesar de no entanto partilharem o mesmo hardware físico do sistema Host de Virtualização.

Outra vantagem bem importante é a resiliência e a normalização. O hardware virtual "de uma máquina virtual (VM) é a mesma entre todas as VMs (assumindo que eles estão todos usando o mesmo software de virtualização) e por isso é uma coisa simples e trivial a operação de movimentação ou copia de uma máquina virtual, ou instância virtual, de um host para outro - se para fins de failover , ou para a provisão - não importa o hardware físico, de qualquer fornecedor, está a ser usado para as máquinas de acolhimento, ou instância virtuais, que supõem ter recursos de hardware exclusivo.

A líder desde o seu ínicio é a VMware, Inc., fundada em 1998, que é reconhecida como líder de virtualização para a plataforma x86/AMD de 32 e 64 Bits. Os seus produtos incluem o VMware Workstation, usado principalmente em computadores desktop, e VMware Infrastructure (anteriormente chamado ESX), bem como uma versão mais limitada, mas aberta e gratuita chamada VMware Server e actualmente na sua versão 2.x, que no entanto se bem explorada encerra enorme potencial de utilização em produção no Data-Center.

A Meta a atingir

Eu, Pessoalmente e Profissionalmente, tenho máquinas virtuais há muitos anos, e uso esta tecnologia nos meus projectos e nas empresas com as quais tenho colaborado desde 1999. Antes das tecnologias em que também a VMware foi pioneira, e agora líder absoluto de mercado, eu necessitava  testar as configurações de diferentes sistema operativos ou mesmo efectuar o desenvolvimento em ambientes de sistemas Windows e Linux, e desde o começo considerei a adopção destas tecnologias para substituir um laboratório em que seria necessário dispor de dúzias de computadores físicos.

Assim com apenas uma instância do VMware Workstation ou Servidor (VmwServer ou ESX) descobri que também poderia demonstrar vários produtos de software para os meus clientes usando o VMware, e, portanto, mais uma vez a vantagem de um laboratório móvel, sem a necessidade de me arrastar em torno de vários computadores físicos e dos problemas de manutenção que são inerentes a muitos componentes físicos, por mais robustos que eventualmente sejam.

Isso foi há mais de 10 anos. mas hoje em dia regularmente executo quatro ou cinco máquinas virtuais num simples Laptop, bem como mais de uma dezena de outras máquinas virtuais, suportadas através do VMware Server ou Vmware ESXi assente num único servidor físico, para testar e desenvolver várias configurações de software. O software VMware funciona excepcionalmente bem e a sua robustez é comparável à dos ambientes de mainframes, normalmente plataformas corporativas de elevados custos de aquisição e manutenção.

Aqui poderá ter uma visão da consola central simplificada do VMware Server 2.0, através de Web-Browser:

Embora a administração baseada em consola Web seja já  excelente, no entanto tudo depende de ter uma conexão HTTPS com o servidor numa porta específica, optimizado adequadamente e suportado e mantido de uma forma robusta. 

Os Requisitos de Automatização

Muito embora se tenham construído inúmeras soluções de software para simplificar e automatizar as operações de administração e manutenção, eu no entanto tenho vindo a criar o meu próprio caminho, a este respeito, e procurei criar e dispor de soluções que me permitam realizar as tarefas de exploração dos ambientes de virtualização, de uma maneira mais automatizada para as minhas máquinas virtuais e dos meus clientes, aliando "tunning" especifico para estes ambientes. 

O Staff da VMware desenvolveu bastantes utilitários e scripts em Linux e UNIX, bem como API´s, comandos e vasta documentação que nos permite utilizar a linha de comandos Linux e assim tomar o controle sobre as máquinas virtuais que rodam em plataformas da VMware.

Por "linha de comando", pergunta você ? Bem, enquanto a Web baseada em GUI VMware (conforme acima) ela é excelente para tornar a gestão das máquinas virtuais mais fácil e intuitiva, e disponível ao alcance de um clique sobre um ponto de um interface gráfico. No entanto estas funcionalidades a que todos já se habituaram, não estão orientadas nem se se prestam à automatização nem permitem os níveis de segurança que são necessários implementar hoje em dia. É sempre requerida a interacção humana - olhos no Ecran e os dedos no mouse - para realizar qualquer tarefa por mais simples ou rotineira que seja. !!! 

Os comandos passados através de linha de comando, ao contrário, podes ser programados, e assim podem criar-se mecanismos e programas configurados para fazer exactamente o que queremos de uma forma muito definida e precisa.

Este é o caminho para a necessária automatização que confere aos sistemas e plataformas de cloud-computing a fiabilidade e eficácia necessárias, nos dias de hoje aos sistemas computacionais e ainda a forma mais fácil de reduzir custos de implementação , administração e manutenção dos referidos sistemas.

O utilitário de linha de comando, fornecidas pela VMware é chamado VMrun. Este utilitário vem com o VMware Workstation 6.5 e VMware Server 2.0 (mas não com versões anteriores), e achei a documentação no site da VMware. Esta solução particular vou descrever é para a versão Linux somente.

Desta forma a criação de programas ou scripts em Linux são a forma que conheço desde sempre em TI traduzindo e permitindo implementar maior eficácia, com melhores performances e também a mais barata para automatizar e gerir todos os componentes de hardware e software do seu Data-Center. 

Para isso é no mínimo necessário dispor de comandos (ou API´s), que possam ser usandos em scripts Linux, para tarefas que isoladamente podem parecer primárias, mas são importantíssimas para os objectivos de optimização e gestão em ambientes virtualizados, como o:

• exibir as máquinas virtuais disponíveis, que podem ser executados num determinado host
• exibir o status das máquinas virtuais que estão actualmente em execução
• iniciar máquinas virtuais a partir de comandos e scripts no servidor host
• parar as máquinas virtuais no servidor host
• reinicialização (reset) das máquinas virtuais no servidor host
• gerir grupos de máquinas virtuais em conjunto
• executar comandos no sistema operativo convidado (guest OS) das máquinas virtuais

O último requisito é significativo, em relação à minha necessidade para desligar todas as aplicações rodando em minha máquina de convidado, para não perder ou danificar os dados. Para simplesmente "parar" a máquina virtual poderia ser análogo ao pressionar o botão de energia em um computador físico. É assim que se escreve "a perda de dados". Então, eu quero usar os comandos que irá encerrar as aplicações eo sistema operacional de forma segura.

Abordagens e Soluções propostas

Para alcançar esses objectivos, tenho desenvolvido e modificado scripts Linux explorados pela comunidade, para uso em sistemas Linux  em que esteja instalado o  VMware Server 2.0, ou no caso do Vmware ESX (Enterprise version) que possam correr nestes sistemas. 

Através de variáveis de ambiente específicas, que são relativos às máquinas específica de uma determinada instalação e que poderão estar contidas num roteiro de configuração. Este script secundário é chamado pelo script primário (vmutil.sh) para definir todos os parâmetros necessários que são específicos para o host VMware. Isso torna a solução altamente portátil: eu posso usar o mesmo script vmutil.sh no host VMware máquinas diferentes, apenas alterando o script de configuração para cada ambiente diferente.

Os scripts e linhas de comando (em geral), seja em Linux ou em qualquer outro sistema operativo como o Windows, fazem maravilhas para automatizar tarefas repetitivas e que podem ser cronogramadas. E estas vão desde a completa automatização de backups, sem qualquer paragem das máquinas virtuais, que podem ser exploradas 7 X 24 horas e com alta disponibilidade portanto, até à monitorização pro-activa de processos e aplicações, bem como a geração de alertas por e-mail, SMS ou relatórios via WEB, ou mesmo a tomada de acções correctivas face a anomalias detectadas em procedimentos de monitorização de sistemas e aplicações.

Um exemplo simples através do comando VMrun

Como mencionado, a VMware criou o utilitário VMrun para permitir que os utilizadores controlem as máquinas virtuais a partir da linha de comandos , que é toda a base das soluções de scripting em que me tenho empenhado na sua construçõão e adaptação a partir de uma base existente na comunidade, de molde a fornecer soluções de TI e de virtualização robustas, eficazes e assistindo na automatização da maioria das tarefas repetitivas, que hoje em dia caracteriza a realidade dos data-centers, tornando-os por isso altamente ineficazes e obrigando a custos cada vez maiores na sua administração e suporte.

A partir da documentação VMrun, aprendemos que a sintaxe do comando é a seguinte :

VMrun-T-h servidor https://SOftelabs.com:8333/sdk  -u root -p 'Paswd' [start]  "[Virtual Live Library @ Softelabs] eLabs-Hobbit/eLabs-Hobbit.vmx" [hard|soft]

Através da utilização de todas as variantes de um simples comando como o VRUN podem criar-se scripts sofisticados para gerir todas as máquinas virtuais existentes, automatizando processos e minimizando intervenções a que qualquer programa dotado de um "mínimo de inteligência" poderá assistir e resolver, sem qualquer intervenção humana. E não foi para isso que o ser humano criou e aposta em continuar a desenvolver os computadores ???!!!

Outro exemplo do uso do comando VMrun, para iniciar uma máquina virtual, é:

VMrun-T-h servidor https://eLabs:8333/sdk u root -p 'secretpw' start VMwareService "[storage library1] SLES10/SLES10.vmx"

O parâmetro "-T servidor" (tipo) especifica VMware Server 2.0 (em vez de VMware Workstation). O parâmetro para o servidor (host) URL "-h https://eLabs:8333/sdk"especifica os meios pelos quais podemos comunicar com o servidor VMware, usando Secure HTTP na porta 8333 (padrão). O VMware administrador username ("u") e senha ("p") são especificadas, e que o comando é "start". O local para a configuração da máquina virtual (. Vmx) arquivo é na sintaxe do "[<storagegroup>] <diretorio> / <nome_do_arquivo>. Vmx". Grupos de armazenamento são configurados na GUI administrativa VMware eo padrão inicial do grupo de armazenamento para o VMware Server 2.0 (definido durante a instalação) é chamado "standard] [".

Por último e para demonstrar a capacidade que os Scripts em Linux / UNIX e a linha de comandos UNIX podem resolver questões e problemas de automatização de backups, administração e manutenção, etc, de forma tão ou mais eficaz que soluções de software e hardware de mercado que custam autênticas fortunas, e que na maioria das vezes não conseguem sequer ser implementados ou se tira partido insignificantes destas fortunas gastas, apresento um projecto de script para o backup automático ou a consolidação de backups de todas as máquinas virtuais existentes num Data-Center.

O Script Linux que aqui apresento tem base na comunidade como muitos outros e pode ser modificado, e mesmo compilado, para uma implementação especifica, apenas através de algum "know-how" e algumas horas de trabalho, que serão altamenente rentáveis, face aos processos de intervenção humana que ele pode pura e simplemente eliminar.

O serverVCB.sh - script de backup para VMware Server no Linux host

Este "pequeno" script, de que poder efectuar o download a seguir, permite efectuar full live backups a todas as suas instâncias virtuais de forma automática, e constitui um script baseado no ghettoVCB.sh da autoria de William Lam, e que foi adaptado da plataforma ESX, para suporte também na plataforma de virtualização gratuita Vmware Server 2.0.

O ghettoVCB.sh script executa backups de máquinas virtuais que estejam suportadas em Linux hosts. Este efectua snapshots das máquinas virtuais, e em seguida faz o backup do master VMDK (s) e, após a conclusão, apaga o instantâneo (snaphot) até ao próximo backup programado de forma totalmente segura e rápida. 

Este script poder ser por sua vez implementado nos sistemas Linux via crontab, definindo acções programadas em função dos objectivos pretendidos. 

Os backups são efectuados com as máquinas em funcionamento real e sem grande penalização em termos de CPU ou memória e poderão produzir-se e analisar-se de forma totalmente automática acções em função dos resultados das operações efectuadas por este script (ver mais detalhes deste no link aqui).

Este script, para além de muitas outras funcionalidades, permite também efectuar controle e implementar a rotação de até três backups a executar sobre cada uma das instâncias virtuais em pleno funcionamento, e sem prejudicar gravemente os tempos de resposta dos respectivos servidores aplicacionais, como atrás já foi salientado

Nota: Para que o backup funcione, e até face à estratégia que atrás está descrita sobre o molde de funcionamento destes script, as maquinas virtuais não poderão nenhum snapshot associado através da consola de administração web.

Notas Finais

Em suma, o Linux e a Virtualização estão a trazer para o Data-Center o poder da automatização e do controle sobre os processos e operações repetitivas e também sugadoras de recursos humanos ao basearem a exploração dos sistemas exclusivamente em interfaces gráficos e navegação através de cliques.

Têm ainda vantagem de resolver problemas e permitirem construir soluções fiáveis e robustas que constituem alternativas muito mais económicas, face às soluções e software de mercado muito caras, sobretudo nas áreas da monitorização, manutenção e automatização de sistemas.

Como tal os scripts são uma peça fundamental em todo este processo e o "know-how" nestes domínios mandatórios no repensar de estratégias futuras para a introdução e manutenção de sistemas e plataformas de virtualização na sua empresa.

Francisco Gonçalves @ Softelabs.com

Para qualquer dúvida, questão ou "feedback" agradeço o seu contacto para fgoncalves@softelabs.com

Artigos relacionados: O Backup & restore de máquinas físicas e virtuais como o comando DD Linux via remote SSH

Consulte e efectue o download do documento abaixo : Building an enterprise monitoring system using Linux

Se quer reduzir custos e optimizar a sua infra-estrutura tecnológica, deixe o desenho de arquitecturas e o suporte de sistemas Linux por nossa conta !!! 

Quer racionalizar a administração e manutenção dos seus sistemas Linux, Unix e Windows e optimizar as performances destes, reduzindo custos consideráveis em hardware e software caro e ineficiente ? Ou pretende automatizar, de forma eficaz e a baixos custos, os procedimentos de backups e a sincronização em tempo real dos dados dos seus servidores Linux e sistemas de virtualização Vmware, VirtualBox,Xen , KVM ou de Cloud-Computing ? Então fale connosco em info@softelabs.com  e verá os seus problemas resolvidos rápidamente com inovação, eficácia e eficiência, aliando elevada redução de custos em software e hardware. Consulte-nos sem qualquer compromisso e experimente as soluções e os serviços que lhe poderemos garantir.

Comandos básicos no VMware ESXi

Fonte: http://robertbchase.blogspot.com/2008/12/vmware-esxi-ssh-cli-commands.html

vmware-cmd -l | xargs -i'{}' vmware-cmd '{}' stop trysoft hard
Este comando vai enumerar as máquinas virtuais do host, depois passar o id de cada uma para o comando vmware-cmd ... stop, que tenta fazer o desligamento via sistema operacional guest (trysoft) e, se não funcionar, força o desligamento (hard)

vmkerrcode -l
Lista os erros do vmkernel

esxcfg-info
Lista várias informacões sobre o esx host

vim-cmd vmsvc/getallvms

#Lista de todos os vms rodando no hypervisor¹ e fornece o <vmid>²

#Lists all vm's running on hypervisor and provides <vmid>

vim-cmd vmsvc/power.off <vmid>

#Desliga <vmid> referenciada no comando getallvms

#Powers off <vmid> referenced from getallvms command

vim-cmd vmsvc/power.on <vmid>

#Liga <vmid> referenciada no comando getallvms

#Powers off <vmid> referenced from getallvms command

vim-cmd vmsvc/power.reboot <vmid>

#Reinicia/Restart <vmid> referenciada no comando getallvms

#Reboots <vmid> referenced from getallvms command

vim-cmd vmsvc/power.reset <vmid>

#Reinicia/Restart <vmid> referenciada no comando getallvms usando o guest³

#Reboots <vmid> referenced from getallvms command using guest

vim-cmd vmsvc/power.shutdown <vmid>

#Desliga <vmid> referenciada no comando getallvms usando o guest

#Power off <vmid> referenced from getallvms command using guest

vim-cmd vmsvc/destroy <vmid> #Exclui os arquivos vmdk e vmx do disco (destroe sem qualquer posibilidade recuperar o vm) #Deletes the vmdk and vmx files from disk vim-cmd hostsvc/maintenance_mode_enter #Coloca hypervisor em modo de manutenção #Puts hypervisor into maintenance mode vim-cmd hostsvc/maintenance_mode_exit #Tira hypervisor do modo de manutenção #Takes hypervisor out of maintenance mode vim-cmd solo/registervm /vmfs/vol/datastore1/dir/vm.vmx #Registra vm no inventário do hypervisor #Registers vm in hypervisor inventory vim-cmd vmsvc/unregister <vmid> #Cancela o registro do vm com o hypervisor #Unregisters vm with hypervisor vim-cmd vmsvc/tools.install <vmid> #VMware inicia a instalação de ferramentas para VM (vmware tools) #Starts vmware tools installation for VM vim-cmd hostsvc/net/info #Fornece informações sobre a rede do hypervisor #Provides information about hypervisor networking chkconfig -l #Mostra daemons sendo executados no hypervisor. Também pode ser usado para a configuração. #Shows daemons running on hypervisor. Can also be used for configuration. esxtop #Igual ao comando top do Linux para VMware #Same as linux top for vmware vmkerrcode -l #Lista de erros VMkernel #List of vmkernel errors esxcfg-info #Lista uma série de informações sobre o host ESX #Lists a LOT of information about the esx host esxcfg-nics -l #Lista informações sobre NIC (Placa de Rede). Também pode ser usado para a configuração. #Lists information about NIC's. Can also be used for configuration. esxcfg-vswitch -l #Lista informações sobre a swit virtual conectado. Também pode ser usado para a configuração. #Lists information about virtual switching. Can also be used for configuration. dcui #Fornece tela do console para a sessão do ssh #Provides console screen to ssh session vsish #Vmware shell interativo #Vmware interactive shell decodeSel /var/log/ipmi_sel.raw #faz a leitura dos Log de Eventos do servidor (nem sempre está instalado) #Read System Event Log of server

SO VMware ESXi

Fonte: http://www.linhadecodigo.com.br/artigo/2559/virtualizacao-de-servidores.aspx

Um pouco sobre o VMware ESX[i]

Primeiramente, é interessante esclarecer que o VMware ESX não é Linux. Esse software é um hypervisor do tipo “bare metal”, mas que pelo fato de seu SC (Service Console) e sistema de boot ser uma modificação do Linux Red Hat 3, uma grande parte das pessoas tende a pensar no ESX como sendo um tipo (distribuição) de Linux.

O Serviço de Console do ESX é como uma Máquina Virtual especial, que usa uma pequena parte da memória e apenas um “Core” dos processadores. O SC não é o sistema operacional. O ESX foi desenvolvido pela equipe da VMware/EMC2 e por isso é um software comercial e que deve ser devidamente licenciado para uso.

VMware ESX é um sistema operacional, criado exclusivamente para suportar Virtual Machines, e dar a elas o melhor desempenho possível, além de dar total controle aos Administradores sobre as configurações do hardware compartilhado e em uso.

O kernel do ESX é chamado de “VMkernel”, que juntamente com o Service Console (SC), compõe os dois principais componentes desse sistema de virtualização de servidores.

Abaixo segue um diagrama que mostra graficamente o layout da arquitetura, de forma simplificada, do ESX.

Figura 3: Arquitetura de virtualização do VMWare ESX 3.5 (cortesia VMware website).

A suíte de produtos de virtualização da VMware (VI3), cujo VMware ESX é o carro chefe, é composta pela seguinte lista:

3. VMware ESX Server

4. VMware Virtual SMP

5. VMware VMotion

6. VMware DRS (Distributed Resource Scheduler)

7. VMware HA (High Availability)

8. VMware VCB (Consolidated Backup)

9. VMware VirtualCenter (atualmente na versão 4.0)

10. VMware Infrastructure Client

A versão mais recente do ESX é conhecida como “VMware vSphere 4.0”, e implementa uma série de novas funcionalidades, mas sua nova filosofia é “Cloud operating Systems”.

Sistemas operacionais em “nuvens” é uma nova categoria de software, projetado para gerenciar grandes infra-estruturas, num agrupamento de CPUs, memórias, armazenamento e redes, dentro de um ambiente operacional de alta disponibilidade, com facilidades para upgrades e migrações dinâmicas.

Figura 4: Aplicações em nuvens, utilizando virtualização do VMWare vShere 4 (cortesia VMware website).

Diferentemente dos tradicionais sistemas operacionais, onde o sistema operacional gerencia apenas uma máquina individual, o Cloud OS agrega toda a infra-estrutura de um datacenter para criar uma única e poderosa “unidade computacional”, com recursos que podem ser rapidamente e de forma automática, alocados para uma determinada aplicação.

Figura 5: Arquitetura de virtualização do VMWare vSphere 4 (cortesia VMware website)

Maiores detalhes podem ser acessados pelo site:

- http://www.vmware.com/products/vsphere e

- http://www.vmware.com/support/vsphere4/doc/vsp_40_new_feat.html