Automatizando com Puppet

Baixar e instalar o pacote dos repositórios em todos os servidores
# wget https://apt.puppetlabs.com/puppetlabs-release-wheezy.deb
# dpkg -i puppetlabs-release-wheezy.deb

Instalação no Server Slave:
puppet-server# apt-get update && apt-get install puppet -y

Instalação no Master Server:
puppet-master# apt-get update && apt-get install puppetmaster -y

Configuração no Slave:
puppet-server# vim /etc/puppet/puppet.conf

[main]
  server=puppet-master
  runinterval=300 # Intervalo de atualização do agente puppet (em segundos)
  ...

puppet-server# puppet agent -t
puppet-server# vim /etc/default/puppet


START=yes

puppet-server# /etc/init.d/puppet restart

Configuração no Master:
puppet-master:~# puppet cert list
“puppet-server” (C0:DF:77:C2:1E:49:69:BD:AA:60:B6:B6:7E:74:A9:B5)

puppet-master:~# puppet cert sign puppet-server
notice: Signed certificate request for puppet-server
notice: Removing file Puppet::SSL::CertificateRequest puppet-server at ‘/var/lib/puppet/ssl/ca/requests/puppet-server.pem’

puppet-master:~# vi /etc/puppet/fileserver.conf


 [files]
 path /etc/puppet/files
 allow *

puppet-master:~# mkdir /etc/puppet/files

Exemplos de deploy:
Atualizar o sistema e instalar o ntp
puppet-master:~# vim /etc/puppet/manifests/site.pp

package { 'ntp': ensure => 'present'
  }

exec { 'apt-get update':
  path => '/usr/bin/:/bin/:/sbin:/usr/sbin/'
  }

exec { 'apt-get upgrade -y':
  path => '/usr/bin/:/bin/:/sbin:/usr/sbin/'
  }

node 'puppet-server' { }

Atualizar o sistema e copiar motd para servidor através de classes:
puppet-master:~# vim /etc/puppet/files/motd

PUPPET SERVER

puppet-master:~# vim /etc/puppet/manifests/services_base.pp

class update_system {
  exec { 'apt-get update':
  path => '/usr/bin/:/bin/:/sbin:/usr/sbin/'
  }
  }

class upgrade_system {
  exec { 'apt-get upgrade -y':
  path => '/usr/bin/:/bin/:/sbin:/usr/sbin/'
  }
  }

class update_files {
  file { "/etc/motd":
  ensure => present,
  source => "puppet:///files/motd"
  }
  }

puppet-master:~# vim /etc/puppet/manifests/hosts.pp

node 'puppet-server' {
  include update_system
  include upgrade_system
  include update_files
  }

puppet-master:~# vim /etc/puppet/manifests/site.pp

import 'services_base.pp'
import 'hosts.pp'

Deploy automático de aplicação web:
puppet-master:~# vim /etc/puppet/manifests/webserver.pp

Exec { path => [ "/bin/", "/sbin/", "/usr/bin/", "/usr/sbin/" ] }

class apache_install {
  $pacotes = [ "apache2", "php5", "php5-ldap", "php5-imap", "php5-gd", "php5-mysql", "wget", "vim", "nfs-common" ]
  package { $pacotes: ensure => "installed" }
  }

class copy_files {
  file { "/etc/apache2/sites-available/sistema.conf":
  ensure => present,
  source => "puppet:///files/sistema.conf"
  }
  }

class enable_sites {
  exec { 'ln -s /etc/apache2/sites-available/glpi.conf /etc/apache2/sites-enabled/sistema: }
  exec { 'a2dissite 000-default': }
  }

class mount_systems {
  exec { 'mount -t nfs puppet-master:/opt/sistemas /var/www': }
  exec { 'echo "puppet-master:/opt/sistemas /var/www nfs defaults,hard,bg 0 0" >> /etc/fstab': }
  }

class restart_apache {
  exec { 'service apache2 restart': }
  }

puppet-master:~# vim /etc/puppet/manifests/hosts.pp

node 'puppet-server' {
  include apache_install
  include copy_files
  include enable_sites
  include mount_systems
  include restart_apache
  }

puppet-master:~# vim /etc/puppet/manifests/site.pp

import 'webserver.pp'
import 'hosts.pp'

NGINX

Desenvolvido originalmente por Igor Sysoev, o NGiNX (pronuncia-se engine X), é um servidor HTTP e proxy reverso de alta performance, bem como um proxy reverso para IMAP e POP3.

Neste artigo abordaremos seu funcionamento como servidor HTTP simples, proxy reverso para servidores apache, e balanceamento de carga. Todos os testes foram feitos em um servidor rodando Debian 7.8. Então, mãos á obra.

Criando um servidor http simples
Instalar o nginx;
[root@webserver ~]# apt-get install nginx

Criar o arquivo de configuração do site;
[root@webserver ~]# vim /etc/nginx/conf.d/sysadmin.conf

server  {
	listen 80;
	root /var/www/html;
	index index.html index.htm;
	server_name sysadmin.com;
	access_log /var/log/nginx/sysadmin.log;
}

Em seguida, criar o link simbólico para o arquivo de configuração do novo site, remover o default e reiniciar o daemon;
[root@webserver ~]# ln -s /etc/nginx/conf.d/sysadmin.conf /etc/nginx/sites-enabled/
[root@webserver ~]# rm -rf /etc/nginx/sites-enabled/default
[root@webserver ~]# /etc/init.d/nginx restart

Pronto. Basta acessar do navegador web o site sysadmin.com (caso exista um apontamento no DNS é claro).

Configurando um Proxy Reverso
O proxy reverso é responsável por receber e encaminhar requisições à sites e aplicações hospedados pela organização. Ele é o único alvo das requisições dos clientes, por esse motivo o proxy adiciona uma camada de segurança ao sistema, encaminhando as requisições dos clientes para os servidores principais.
Observe o cenário:
proxyreverso

Supondo que o servidor web esteja rodando apache na porta 8080 com ip 192.168.1.10 e o mesmo hospeda o site no endereço linuxsemgarotear.com, os passos para configurar o proxy reverso são;

Criar o arquivo de configuração do site;
[root@webserver ~]# vim /etc/nginx/conf.d/linuxsemgarotear.conf

server { 
listen 80; 
server_name linuxsemgarotear.com; 
access_log /var/log/nginx/linuxsemgarotear.log; 

location / { 
proxy_pass http://192.168.1.10:8080; 
include proxy_params;
    }
}

Observe a sessão location. Ela indica que toda requisição será encaminhada para o endereço http://192.168.1.10 na porta 8080, ou seja, para o servidor apache que está hospedando o site.

Em seguida, criar o link simbólico para o arquivo de configuração do site, remover o default e reiniciar o daemon;
[root@webserver ~]# ln -s /etc/nginx/conf.d/linuxsemgarotear.conf /etc/nginx/sites-enabled/
[root@webserver ~]# rm -rf /etc/nginx/sites-enabled/default
[root@webserver ~]# /etc/init.d/nginx restart

Acesse o site e veja o proxy em funcionamento.
Para o teste, interrompa o daemon do apache no servidor principal.

Load Balancer
Por fim, vamos configurar o load balancer.
Tomando por base o exemplo anterior, suponhamos que o servidor web (apache) seja redundante. Nesse caso o nginx fará o balanceamento de carga entre os dois servidores web.
Abaixo, as informações do ambiente:
Servidores Apache:
Webserver1 – ip 192.168.1.10 – porta 8080
Webserver2 – ip 192.168.1.11 – porta 8080
Vale lembrar que o diretório de armazenamento dos arquivos do site (/var/www, por exemplo) deve ser consistente em ambos os servidores. Isso pode ser feito exportando o diretório via nfs de um storage, utilizando sistema de arquivos distribuídos(GFS), ou outra técnica de sua preferência.

Criar o arquivo de configuração no nginx;
[root@webserver ~]# vim /etc/nginx/conf.d/linuxsemgarotear.conf

upstream pool_server {
        server 192.168.1.10:8080 weight=3;
        server 192.168.1.11:8080;
}

server {
        listen 80;
        server_name linuxsemgarotear.com;
        access_log /var/log/nginx/linuxsemgarotear.log;

        location / {
                proxy_pass      http://pool_server;
                include proxy_params;
            }
}

Observe que na sessão upstream, onde o balanceamento é configurado, é possível atribuir um peso para cada servidor. Dessa forma o nginx encaminhará uma carga maior de requisições para o primeiro servidor.

Caso você esteja hospedando uma aplicação que faça controle de sessão (como php por exemplo), será necessário instalar o módulo rpaf (em nosso caso o libapache2-mod-rpaf) no apache. Esse módulo permite que o apache trate as requisições utilizando o endereço do cliente. De outro modo o site/aplicação não funcionará corretamente.

Ainda podemos incrementar tanto o proxy reverso quanto o balanceamento de carga. O NGINX é conhecido por sua alta performance ao tratar inclusive conteúdos estáticos (imagens, css, javascript, etc.). Com isso em mente, podemos dizer para o NGINX tratar diferentes tipos de conteúdos estáticos e encaminhar o restante, reduzindo dessa forma a carga do apache.

Vamos tomar como base o exemplo anterior de balanceamento de carga, e editar o arquivo, incluindo alguns parâmetros;
[root@webserver ~]# vim /etc/nginx/conf.d/linuxsemgarotear.conf

upstream pool_server {
        server 192.168.1.10:8080 weight=3;
        server 192.168.1.11:8080;
}

server {
        listen 80;
        server_name linuxsemgarotear.com;
        access_log /var/log/nginx/linuxsemgarotear.log;

        location ~ ^/(images|javascript|js|css|flash|media|static)/ {
                root /var/www/linuxsemgarotear;
                expires 30d;
        }

        location ~* ^.+\.(jpg|jpeg|gif|png|ico|css|zip|tgz|gz|rar|bz2|doc|xls|exe|pdf|ppt|txt|tar|mid|midi|wav|bmp|rtf|js)$ {
                root /var/www/linuxsemgarotear;
                expires 30d;
        }

        location / {
                proxy_pass      http://pool_server;
                include proxy_params;
         }
}

As sessões em destaque configuram o NGINX para tratar localmente conteúdos estáticos.
Lembrando que o diretório /var/www/linuxsemgarotear deve ser exatamente idêntico ao dos servidores apache. Como dito anteriormente, isso pode ser feito exportando o diretório de um storage (criando assim um ponto único de armazenamento para todos os servidores envolvidos no processo) ou via GFS.

Por hoje é só galera. Deixe seu comentário, sugestão ou crítica.
Abç

RHEL/CENTOS 7 – OpenLDAP e Automount

OPENLDAP RHEL7
SERVIDOR:
Instalação dos pacotes necessários:
[root@ldap ~]#yum install openldap openldap-clients openlda-servers migrationtools

Gerando a senha e o certificado:
[root@ldap ~]# slappasswd -n > /etc/openldap/passwd
New password:
Re-enter new password:
[root@ldap ~]# cat /etc/openldap/passwd
{SSHA}RzdNb3SLWI3kaTwWawePv15IWierde7k

[root@ldap ~]#openssl req -new -x509 -nodes -out /etc/openldap/certs/cert.pem -keyout /etc/openldap/certs/priv.pem -days 365
O common name deve ser o nome FQDN do servidor.

Alterando permissões de segurança:
[root@ldap ~]#chown ldap:ldap /etc/openldap/certs/*
[root@ldap ~]#chmod 600 /etc/openldap/certs/priv.pem

Preparar a base de dados LDAP:
[root@ldap ~]#cp /usr/share/openldap-servers/DB_CONFIG.example /var/lib/ldap/DB_CONFIG

Gerar a base de dados:
[root@ldap ~]#slaptest
Desconsiderar erros apresentados nesse comando.

Alterar o dono da base LDAP:
[root@ldap ~]#chown ldap:ldap /var/lib/ldap/*

Ativar e iniciar o serviço:
[root@ldap ~]#systemctl enable slapd.service
[root@ldap ~]#systemctl start slapd.service
[root@ldap ~]# netstat -lt | grep ldap
tcp 0 0 0.0.0.0:ldap 0.0.0.0:* OUÇA
tcp6 0 0 [::]:ldap [::]:* OUÇA

Adicionar schemas:
[root@ldap ~]# cd /etc/openldap/schema/
[root@ldap schema]# ldapadd -Y EXTERNAL -H ldapi:/// -D “cn=config” -f cosine.ldif
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
adding new entry “cn=cosine,cn=schema,cn=config”

[root@ldap schema]# ldapadd -Y EXTERNAL -H ldapi:/// -D “cn=config” -f nis.ldif
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
adding new entry “cn=nis,cn=schema,cn=config”

Criar LDIF:
[root@ldap ~]#vi /etc/openldap/changes.ldif

dn: olcDatabase={2}hdb,cn=config
changetype: modify
replace: olcSuffix
olcSuffix: dc=example,dc=com

dn: olcDatabase={2}hdb,cn=config
changetype: modify
replace: olcRootDN
olcRootDN: cn=Manager,dc=example,dc=com

dn: olcDatabase={2}hdb,cn=config
changetype: modify
replace: olcRootPW
olcRootPW: nesse ponto, copiar a senha do arquivo /etc/openldap/passwd (gerada com o comando slappasswd) e colar aqui.

dn: cn=config
changetype: modify
replace: olcTLSCertificateFile
olcTLSCertificateFile: /etc/openldap/certs/cert.pem

dn: cn=config
changetype: modify
replace: olcTLSCertificateKeyFile
olcTLSCertificateKeyFile: /etc/openldap/certs/priv.pem

dn: cn=config
changetype: modify
replace: olcLogLevel
olcLogLevel: -1

dn: olcDatabase={1}monitor,cn=config
changetype: modify
replace: olcAccess
olcAccess: {0}to * by dn.base="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" read by dn.base="cn=Manager,dc=example,dc=com" read by * none

Enviar a configuração para o slapd:
[root@ldap ~]# ldapmodify -Y EXTERNAL -H ldapi:/// -f /etc/openldap/changes.ldif
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
modifying entry “olcDatabase={2}hdb,cn=config”
modifying entry “olcDatabase={2}hdb,cn=config”
modifying entry “olcDatabase={2}hdb,cn=config”
modifying entry “cn=config”
modifying entry “cn=config”
modifying entry “cn=config”
modifying entry “olcDatabase={1}monitor,cn=config”

Criar o base.ldif:
[root@ldap ~]#vi /etc/openldap/base.ldif

dn: dc=example,dc=com
dc: example
objectClass: top
objectClass: domain

dn: ou=People,dc=example,dc=com
ou: People
objectClass: top
objectClass: organizationalUnit

dn: ou=Group,dc=example,dc=com
ou: Group
objectClass: top
objectClass: organizationalUnit

Construir a estrutura de serviço de diretórios:
[root@ldap ~]# ldapadd -x -W -D cn=Manager,dc=example,dc=com -f /etc/openldap/base.ldif
Enter LDAP Password:
adding new entry “dc=example,dc=com”
adding new entry “ou=People,dc=example,dc=com”
adding new entry “ou=Group,dc=example,dc=com”

Criar usuários para teste:
[root@ldap ~]#mkdir /home/guests
[root@ldap ~]#useradd -d /home/guests/ldapuser01 ldapuser01 | passwd ldapuser01
[root@ldap ~]#useradd -d /home/guests/ldapuser02 ldapuser02 | passwd ldapuser02
[root@ldap ~]#useradd -d /home/guests/ldapuser03 ldapuser03 | passwd ldapuser03

Alterar o nome do domínio:
[root@ldap ~]#cd /usr/share/migrationtools/
[root@ldap ~]#sed -i ‘s/padl/example/g’ migrate_common.ph

Adicionar os usuários ao serviço de diretório:
[root@ldap ~]#tail -n 3 /etc/passwd > users
[root@ldap ~]#./migrate_passwd.pl users users.ldif
[root@ldap migrationtools]# ldapadd -x -W -D cn=Manager,dc=example,dc=com -f users.ldif
Enter LDAP Password:
adding new entry “uid=ldapuser01,ou=People,dc=example,dc=com”
adding new entry “uid=ldapuser02,ou=People,dc=example,dc=com”
adding new entry “uid=ldapuser03,ou=People,dc=example,dc=com”

[root@ldap ~]#tail -n 3 /etc/group > groups
[root@ldap ~]#./migrate_group.pl groups groups.ldif
[root@ldap migrationtools]# ldapadd -x -W -D cn=Manager,dc=example,dc=com -f groups.ldif
Enter LDAP Password:
adding new entry “cn=ldapuser01,ou=Group,dc=example,dc=com”
adding new entry “cn=ldapuser02,ou=Group,dc=example,dc=com”
adding new entry “cn=ldapuser03,ou=Group,dc=example,dc=com”

Testar a configuração:
[root@ldap ~]#ldapsearch -x cn=ldapuser01 -b dc=example,dc=com

Configurar o firewall e o serviço de log:
[root@ldap ~]#firewall-cmd –permanent –add-service=ldap
[root@ldap ~]#firewall-cmd –reload

[root@ldap ~]#vi /etc/rsyslog.conf

local4.* /var/log/ldap.log

Disponibilizar o certificado via web (Opcional):
[root@ldap ~]#yum install httpd
[root@ldap ~]#systemctl enable httpd
[root@ldap ~]#systemctl start httpd

[root@ldap ~]#firewall-cmd –permanent –add-service=http
[root@ldap ~]#firewall-cmd –reload

[root@ldap ~]#cp /etc/openldap/certs/cert.pem /var/www/html

CLIENTES:
Instalar os pacotes:
[root@client1 ~]#yum install openldap-clients nss-pam-ldapd

Configurar resolução do nome do servidor:
[root@client1 ~]#echo ‘192.168.122.60 ldap.example.com ldap’ >> /etc/hosts
[root@client1 ~]#ping ldap.example.com

Configurar autenticação LDAP:
[root@client1 ~]#authconfig-tui
– Cache Information
– Use LDAP
– Use MD5 Passwords
– Use Shadow Passwords
– Use LDAP Authentication
– Local authorization is sufficient

Use TLS
ldap://ldap.example.com
dc=example,dc=com

[root@client1 ~]#scp ldap.example.com:/etc/openldap/certs/cert.pem /etc/openldap/cacerts/
ou
[root@client1 ~]#wget -O /etc/openldap/cacerts/cert.pem http://ldap.example.com/cert.pem (caso o httpd tenha sido configurado)

[root@client1 ~]#getent passwd ldapuser01
Caso não retorne nenhum resultado, repetir o processo de autenticação (authconfig-tui).

MONTAGEM AUTOMÁTICA DO DIRETÓRIO HOME (SERVIDOR)
Instalar pacotes:
[root@ldap ~]#yum groupinstall file-server

Configurar o firewall:
[root@ldap ~]#firewall-cmd –permanent –add-service=nfs
[root@ldap ~]#firewall-cmd –reload

Ativar e iniciar os serviços:
[root@ldap ~]#systemctl enable nfs-server.service
[root@ldap ~]#systemctl enable nfs-idmap.service
[root@ldap ~]#systemctl start nfs-server.service
[root@ldap ~]#systemctl start nfs-idmap.service

Configurar permissões;
[root@ldap ~]#chmod 777 /home/guests/

Configurar o contexto SELinux:
[root@ldap ~]#yum install -y setroubleshoot-server
[root@ldap ~]#semanage fcontext -a -t public_content_rw_t “/home/guests(/.*)?”
[root@ldap ~]#restorecon -R /home/guests/
[root@ldap ~]# setsebool -P nfs_export_all_rw on
[root@ldap ~]# setsebool -P nfs_export_all_ro on
[root@ldap ~]# setsebool -P use_nfs_home_dirs on
ou
Desabilitar o SELinux:
[root@ldap ~]#getenforce
Enforcing
[root@ldap ~]#sed -i ‘s/SELINUX=enforcing/SELINUX=disabled/g’ /etc/selinux/config
[root@ldap ~]#reboot

Exportar o diretório:
[root@ldap ~]# vi /etc/exports

 /home/guests *(rw,no_root_squash)

[root@ldap ~]#exportfs -avr
[root@ldap ~]#systemctl restart nfs-server
[root@ldap ~]#showmount -e localhost

MONTAGEM AUTOMÁTICA DO DIRETÓRIO HOME (CLIENTE)
Instalar pacotes:
[root@client1 ~]#yum install -y autofs nfs-utils

Configurar o automount:
[root@client1 ~]#vi /etc/auto.master.d/guests.autofs

/home/guests /etc/auto.guests

[root@client1 ~]#vi /etc/auto.guests

* -rw,sync ldap.example.com:/home/guests/&

Ativar e iniciar o serviço:
[root@client1 ~]#systemctl enable autofs
[root@client1 ~]#systemctl start autofs

Testar o login:
[root@client1 ~]# su – ldapuser01
[ldapuser01@client1 ~]$ pwd
/home/guests/ldapuser01

Verificar a montagem do diretório:
[ldapuser02@client1 ~]$ df -h
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/rhel-root 7.9G 847M 7.0G 11% /
devtmpfs 491M 0 491M 0% /dev
tmpfs 498M 0 498M 0% /dev/shm
tmpfs 498M 6.6M 491M 2% /run
tmpfs 498M 0 498M 0% /sys/fs/cgroup
/dev/mapper/rhel-home 997M 33M 965M 4% /home
/dev/vda1 497M 97M 401M 20% /boot
ldap.example.com:/home/guests/ldapuser01 997M 33M 965M 4% /home/guests/ldapuser01

RHEL/CENTOS 7 Network Teaming

Criar a interface com failover:
[root@server1 ~]#nmcli con add type team con-name team1 ifname team1 config ‘{“runner”: {“name”: “activebackup”}}’

Atribuir um ip estaticamente (somente se não houver DHCP na rede):
[root@server1 ~]#nmcli con mod team1 ipv4.addresses 192.168.1.122/24
[root@server1 ~]#nmcli con mod team1 ipv4.method manual

Atribuir as portas da interface:
Primeiro devemos verificar o nome das interfaces disponíveis:
[root@server1 ~]# nmcli d s
DISPOSITIVO     TIPO          ESTADO                                                                 CONEXÃO
ens18                   ethernet     conectado                                                               System ens18
team1                   team          conectando (obtendo configuração de IP)          team1
ens19                   ethernet     desconectado                                                         —
lo                           loopback   não gerenciável                                                      —

Então, adicionar as portas:
[root@server1 ~]# nmcli con add con-name team1-port1 type team-slave ifname ens18 master team1
A conexão “team1-port1” (26e1c02e-0f8d-43f8-af19-182baf15acaf) foi adicionada com sucesso.
[root@server1 ~]# nmcli con add con-name team1-port2 type team-slave ifname ens19 master team1
A conexão “team1-port2” (09675173-b9fe-4340-96da-3103a100d50c) foi adicionada com sucesso.

Verificando as conexões:
[root@server1 ~]# nmcli c s
NOME                       UUID                                                                      TIPO                       DISPOSITIVO
team1-port2              09675173-b9fe-4340-96da-3103a100d50c    802-3-ethernet      ens19
team1                        12b17e19-1f65-4bb6-97ac-13b4054ed987     team                      team1
System ens18           f9fb6712-dfda-4264-9bb6-39cc5d567cf3        802-3-ethernet      ens18
team1-port1               26e1c02e-0f8d-43f8-af19-182baf15acaf         802-3-ethernet      —

Perceba que a interface ens18 ainda não foi atribuída a porta 1. Logo, devemos reconectar esse dispositivo:
[root@server1 ~]#nmcli dev dis ens18
[root@server1 ~]#nmcli con up team1-port1

Verificar novamente as conexões ativas:
[root@server1 ~]# nmcli c s –active
NOME                       UUID                                                                      TIPO                       DISPOSITIVO
team1-port2              09675173-b9fe-4340-96da-3103a100d50c    802-3-ethernet      ens19
team1                        12b17e19-1f65-4bb6-97ac-13b4054ed987     team                      team1
team1-port1              26e1c02e-0f8d-43f8-af19-182baf15acaf          802-3-ethernet     ens18

Verificando o status da interface master:
[root@server1 ~]# teamdctl team1 state
setup:
    runner: activebackup
ports:
    ens18
        link watches:
            link summary: up
            instance[link_watch_0]:
                name: ethtool
                link: up
    ens19
        link watches:
            link summary: up
            instance[link_watch_0]:
                name: ethtool
                link: up
runner:
    active port: ens19

Testando o failover:

  1. Descobrir o ip da conexão:
    [root@server1 ~]# nmcli c s team1 | grep IP4.ENDEREÇO
    IP4.ENDEREÇO[1]: ip = 172.16.146.33/24, gw = 172.16.146.1
  2. Usando outra máquina, efetuar o ping no ip do servidor;
  3. Desconectar o cabo da interface ativa;
  4. Verificar o status das portas no servidor:
    [root@server1 ~]# teamnl team1 ports
    2: ens18: up 1000Mbit FD
    3: ens19: down 0Mbit HD
  5. Verificar se a interface de backup assumiu como interface ativa;
    [root@server1 ~]# teamdctl team1 state
    setup:
        runner: activebackup
    ports:
        ens18
            link watches:
                link summary: up
                instance[link_watch_0]:
                    name: ethtool
                    ink: up
        ens19
            link watches:
                link summary: down
                instance[link_watch_0]:
                    name: ethtool
                    link: down
    runner:
        active port: ens18
  6. Verificar se o ping ainda responde;
  7. Reconectar a interface primária e repetir o teste na interface secundária;

Alterando a conexão para loadbalance:
[root@server1 ~]# nmcli dev dis team1
[root@server1 ~]# nmcli c s team1 | grep team.config
team.config: {“runner”: {“name”: “activebackup”}}
[root@server1 ~]# nmcli con mod team1 team.config ‘{“runner”; {“name”: “loadbalance”}}’
[root@server1 ~]# nmcli c s team1 | grep team.configteam.config: {“runner”; {“name”: “loadbalance”}}
[root@server1 ~]# nmcli con up team1-port1
[root@server1 ~]# nmcli con up team1-port2
[root@server1 ~]# teamdctl team1 state
setup:
    runner: loadbalance
ports:
    ens18
        link watches:
            link summary: up
            instance[link_watch_0]:
                name: ethtool
                link: up
    ens19
        link watches:
            link summary: up
            instance[link_watch_0]:
                name: ethtool
                link: up

RHEL/CentOS 7 autenticando no AD

Instalar o daemon:
[root@server1 ~]#yum install realmd

Buscar informações do domínio:
[root@server1 ~]#realm discover domain.com
domain.com
type: kerberos
realm-name: DOMAIN.COM
domain-name: domain.com
configured: no
server-software: active-directory
client-software: sssd
required-package: oddjob
required-package: oddjob-mkhomedir
required-package: sssd
required-package: adcli
required-package: samba-common

Certifique-se que os pacotes requeridos estejam instalados:
[root@server1 ~]#yum install samba-common adcli sssd oddjob oddjob-mkhomedir

Ingressar no domínio:
[root@server1 ~]#realm join domain.com

Esse comando utiliza por padrão a conta de Administrador do domínio. Para conectar usando um usuário diferente, especificar o usuário com o comando –user
[root@server1 ~]#realm join domain.com –user user01

Após ingressar no domínio, verifique novamente as informações do domínio:
[root@server1 ~]# realm discover domain.com
domain.com
type: kerberos
realm-name: DOMAIN.COM
domain-name: domain.com
configured: kerberos-member
server-software: active-directory
client-software: sssd
required-package: oddjob
required-package: oddjob-mkhomedir
required-package: sssd
required-package: adcli
required-package: samba-common
login-formats: %U@domain.com
login-policy: allow-realm-logins

Configurar permissionamento:
[root@server1 ~]#realm permit –realm domain.com –all

Habilita o uso de logins (no sistema local) usando todas as contas do domínio. Para restringir o acesso a usuários específicos, basta alterar o parâmetro –all pela lista de contas de usuários:
[root@server1 ~]#realm permit –realm domain.com user01@domain.com user02@domain.com

Ao verificar as informações do dominio (realm discover domain.com), os usuários permitidos serão exibidos no parâmetro permitted-logins:
[root@server1 ~]# realm discover domain.com
domain.com
type: kerberos
realm-name: DOMAIN.COM
domain-name: domain.com
configured: kerberos-member
server-software: active-directory
client-software: sssd
required-package: oddjob
required-package: oddjob-mkhomedir
required-package: sssd
required-package: adcli
required-package: samba-common
login-formats: %U@domain.com
login-policy: allow-permitted-logins
permitted-logins: user01@domain.com, user02@domain.com
permitted-groups:

Para logar usando a conta do domínio:
[root@server1 ~]#su – user01@domain.com

Para usar o nome simples (sem o @domain ou DOMAIN\\) alterar o parâmetro abaixo para False.
[root@server1 ~]#vi /etc/sssd/sssd.conf
use_fully_qualified_nameFalse

Reiniciar o serviço sssd:
[root@server1 ~]#systemctl restart sssd.service

O campo login-formats e o formato dos nomes dos usuários no campo permitted-logins serão alterado:
[root@server1 ~]# realm discover domain.com
domain.com
type: kerberos
realm-name: DOMAIN.COM
domain-name: domain.com
configured: kerberos-member
server-software: active-directory
client-software: sssd
required-package: oddjob
required-package: oddjob-mkhomedir
required-package: sssd
required-package: adcli
required-package: samba-common
login-formats: %U
login-policy: allow-permitted-logins
permitted-logins: user01, user02
permitted-groups:

Deixar do domínio:
[root@server1 ~]# realm leave starfish.local –user user01

Sistema de Arquivos Distribuídos no Debian (GlusterFS)

Cenário: Disponibilizar sistema de arquivos distribuído agregando espaço em servidores distintos na mesma rede para formar um único local de armazenamento redundante e escalável.
Equipamentos:

Captura de tela de 2015-09-03 14:35:57

  • Dois servidores atuando como DFS glusterfs servers;
  • Um servidor de distribuição atuando como cliente (glusterfs client) do DFS e fileserver (Samba – CIFS) para compartilhamento do ponto de montagem do DFS;
  • Cliente;

Nomes:
Servidor principal: glusterfs01.localdomain.com
Servidor secundário: glusterfs02.localdomain.com
Servidor de distribuição: fileserver.localdomain.com

Configurações:
Relacionamento de nomes (caso não exista registro no DNS);
Em todos os servidores atualizar o arquivo hosts:
127.0.0.1 localhost.localdomain localhost
192.168.0.102 glusterfs01.localdomain.com glusterfs01
192.168.0.103 glusterfs02.localdomain.com glusterfs02

Install GlusterFS:
Debian Wheezy
#wget -O – http://download.gluster.org/pub/gluster/glusterfs/3.5/3.5.2/Debian/wheezy/pubkey.gpg | apt-key add –
#echo deb http://download.gluster.org/pub/gluster/glusterfs/3.5/3.5.2/Debian/wheezy/apt wheezy main > /etc/apt/sources.list.d/gluster.list
#apt-get update
#apt-get install [ glusterfs-server | glusterfs-client ]
Ubuntu 16.04
#add-apt-repository ppa:gluster/glusterfs-4.1
#apt-get update
#apt-get install [ glusterfs-server | glusterfs-client ]

Criar o pool:
root@glusterfs01:~# gluster peer probe glusterfs02.localdomain.com
Probe successful

Verificar o status do pool:
root@glusterfs01:~# gluster peer status
Number of Peers: 1
Hostname: glusterfs02.localdomain.com
Uuid: d19cb707-7b23-4d11-8e9c-183cd0a18d96
State: Peer in Cluster (Connected)

Criar o volume testvol com replica (mirroring):
root@glusterfs01:~# gluster volume create testvol replica 2 transport tcp glusterfs01.localdomain.com:/data glusterfs02.localdomain.com:/data
Creation of volume testvol has been successful. Please start the volume to access data.

Repare que o parâmetro replica 2 deve corresponder a quantidade de servidores no pool.

Iniciar o volume:
root@glusterfs01:~# gluster volume start testvol
Starting volume testvol has been successful

Caso apresente o erro “Starting volume testvol has been unsuccessful”, será necessário reiniciar o daemon GlusterFS no servidor secundário:
root@glusterfs02:~#/etc/init.d/glusterfs-server restart
root@glusterfs02:~# netstat -tap | grep glusterfsd
tcp 0 0 *:24010 *:* LISTEN 1458/glusterfsd
tcp 0 0 localhost.localdom:1021 localhost.localdo:24007 ESTABLISHED 1458/glusterfsd

Checar o status do volume:
root@glusterfs01:~# gluster volume info
Volume Name: testvol
Type: Replicate
Status: Started
Number of Bricks: 2
Transport-type: tcp
Bricks:
Brick1: glusterfs01.localdomain.com:/data
Brick2: glusterfs02.localdomain.com:/data

Por padrão, todos os clientes terão acesso ao volume. Para restringir o acesso basta executar:
root@glusterfs01:~#gluster volume set testvol auth.allow 192.168.0.110
Vale ressaltar que wildcards podem ser utilizados (ex. 192.168.0.* ou 192.168.0.110,192.168.0.111)

Montar o volume no FileServer:
root@fileserver:~#mkdir /mnt/glusterfs
root@fileserver:~#mount.glusterfs glusterfs01.localdomain.com:/testvol /mnt/glusterfs

Lembrando que qualquer servidor do pool pode ser usado como alvo (glusterfs01.localdomain.com ou glusterfs02.localdomain.com).

Montagem permanente (Fstab):
glusterfs01.localdomain.com:/testvol /mnt/glusterfs glusterfs defaults,_netdev 0 0

Todo o conteúdo criado ou inserido no diretório /mnt/glusterfs do FileServer, será replicado no diretório /data dos servidores membros do gluster (glusterfs01 e glusterfs02) fazendo assim o RAID 1.
Esse diretório deverá ser compartilhado com clientes Windows. Para clientes Linux, o volume testvol poderá ser mapeado diretamente no fstab das máquinas.

Expandindo o sistema:
root@glusterfs01:~#gluster volume add-brick testvol glusterfs03:/data glusterfs04:/data
root@glusterfs01:/data# gluster volume info
Volume Name: repvol
Type: Distributed-Replicate
Status: Started
Number of Bricks: 2 x 2 = 4
Transport-type: tcp
Bricks:
Brick1: glusterfs01:/data
Brick2: glusterfs02:/data
Brick3: glusterfs03:/data
Brick4: glusterfs04:/data

Nesse caso o sistema passa a ser RAID 01 (distribuído e replicado).
Para configurar o sistema como totalmente replicado (nesse caso RAID 5), será necessário recriar o volume adicionando os novos servidores.

Reduzir volume:
root@glusterfs01:~# gluster volume remove-brick testvolglusterfs02.localdomain.com:/data
Removing brick(s) can result in data loss. Do you want to Continue? (y/n)

Rebalanceamento do volume:
Esse comando é necessário executar sempre que houver uma alteração no volume (aumentar, reduzir, etc.).
root@glusterfs01:~#gluster volume rebalance testvol start

Fonte: http://www.gluster.org/community/documentation/index.php/Gluster_3.1_Filesystem_Administration_Guide

Diferenças entre antigo exame LPI 202 com a nova versão 11/2013

Oi! Como prometido, posto o relato comparativo dos tópicos do novo exame LPI 202. Pra quem estava acompanhando o modelo anterior deve ter percebido que no atualizado os tópicos vão até ao “212”, contando com o novo tópico 200 no exame 201. Segue abaixo as diferenças do exame 202!

Mudanças do exame LPI 202

O primeiro tópico do exame, agora inicia no 207 Domain Name Server.

Adicionado novo conteúdo no subtópico 207.1   Basic DNS server configuration:

Conhecimento de  dig, dnsmasq, djbdns e PowerDNS como alternativos name servers

Adicionado novo conteúdo no subtópico 207.3 Securing a DNS server:

Conhecimento de dnssec-signzone

Mudanças no tópico 208 Web Services

Adicionado novo conteúdo no subtópico 208.1 Implementing a web server:

Conhecimento de AuthUserFile, AuthGroupFile

Renomeado o subtópico 208.2 de “Maintaining a web server” para “Apache configuration for HTTPS”

Novo conteúdo e termos:

SSL configuration files, tools and utilities
Ability to generate a server private key and CSR for a commercial CA
Ability to generate a self-signed Certificate from private CA
Ability to install the key and Certificate
Awareness of the issues with Virtual Hosting and use of SSL
Security issues in SSL usepache2 configuration files /etc/ssl/*, /etc/pki/* openssl, CA.pl SSLEngine, SSLCertificateKeyFile, SSLCertificateFile, SSLCertificateChainFile SSLCACertificateFile, SSLCACertificatePath SSLProtocol, SSLCipherSuite, ServerTokens, ServerSignature, TraceEnable

Adicionado novo conteúdo no subtópico 208. 3 Implementing a proxy server:

Antes conteúdo sobre Squid 2.x, agora o conteúdo é para o Squid versão 3.x

Inserido novo subtópico 208.4 Implementing Nginx as a web server and a reverse proxy

Conteúdo e Termos:

Candidatos deverão estar aptos a instalar e configurar um reverse proxy server, Nginx. Configuração básica de Nginx como um HTTP server está incluido.

Reverse Proxy, Basic Web Server, etc/nginx/, nginx

Mudanças no tópico 209 File Sharing

Foi adicionado novo conteúdo no subtópico 209.2 NFS Server Configuration:

Conhecimento de NFS v4.

Mudanças no tópico 210 Network Client Management

Inserido novo subtópico 210.4 Configuring an OpenLDAP server:

Conteúdo e Termos

Candidato deverá estar apto para configurar um básico OpenLDAP server incluindo o formato LDIF  e controles de acesso essenciais. Entender de regras de SSSD com autenticação e na identidade. OpenLDAP, Access Control, Distinguished Names, Changetype Operations, Schemas and Whitepages , Directories, Object IDs, Attributes and Classes, Conhecimentos de System Security Services Daemon (SSSD). Termos slapd, slapd.conf, LDIF, slapadd, slapcat, slapindex, /var/lib/ldap/* e loglevel.

 Mudanças no tópico 212 System Security

Novo conteúdo adicionado ao subtópico 212.1 Configuring a router:

Conhecimento de IPv6 e filtering

Removido conteúdo do subtópico 212.3 Securing Shell:

Conteúdo relacionado a XWindow.

Renomeado subtópico 212.4 de “TCP Wrapper” para “Security Tasks”

Novo conteúdo e termos:

Tools and utilities to scan and test ports on a server
Locations and organisations that report security alerts as Bugtraq, CERT, CIAC or other sources
Tools and utilities to implement an intrusion detection system (IDS)
Conhecimento de OpenVAS e Snort. Termos telnet, nmap, fail2ban, nc e iptables

Renomeado subtópico 212.5 de “Security Tasks” para “OpenVPN”

Novo conteúdo e termos:

Candidatos deverão estar aptos a configurar uma VPN (Virtual Private Network) e criar secure point-to-point ou site-to-site connections. Termos: etc/openvpn/* openvpn

——- Fim de alterações do exame 202 ———-

O tópico 213 foi removido no novo exame, porém parte do conteúdo foi movido para o  novo tópico 200 do exame 201, relatado no meu post anterior.

Claro que, pode estar faltando ou obter algum conteúdo divergente do real, mesmo fazendo a leitura da fonte original. Então caso seja necessário, comentem que retificarei o conteúdo.

É isso e vamos estudar agora.

Fonte:

http://www.lpi.org/linux-certifications/programs/lpic-2/exam-202/

http://wiki.lpi.org/wiki/LPIC-2_Objectives_V3

 

Diferenças entre antigo exame LPI 201 com a nova versão 11/2013

Muita gente deve estar passando pela mesma situação que a minha atualmente. Está se preparando para os exames da certificação LPI 2. No mês de Novembro Outubro de 2013 foi anunciado a nova versão dos exames, o que prejudicou muito quem estava estudando nessa época e não teve tempo de fazer as provas. Agora muita coisa mudou, temos que replanejar todo o estudo e para facilitar fiz um pequeno relato comparativo do que mudou no novo exame. A começar pelo exame 201.

Mudanças do exame LPI 201 

Novo tópico inserido – 200 Capacity Planning:

Subtópico 200.1 Measure and Troubleshoot Resource Usage

Subtópico 200.2 Predict Future Resource Needs

Mudanças no tópico 201: 

Foi removido o subtópico 201.3 “patching a kernel”

Foi removido o subtópico 201.4 “Customise, build and install a custom kernel and kernel modules”

Mudanças no tópico 202: 

Adicionado novo conteúdo no subtópico 202.1:

SysV init environment

Adicionado novos centeúdos no subtópico 202.2:

Grub 2, Awareness of UEFI, Hardware Inicialization Setup e MBR

Adicionado novo subtópico 202.3 Alternate Bootloaders

Mudanças no tópico 204:

Adicionado novos conteúdos no subtópico 204.2:

Tools and utilities for iSCSI, WWID, WWN e LUN numbers

Mudanças no tópico 205 e 206:

Foi movido o subtópico “205.4 Notify users on system-related issues” para subtópico “206.3 Notify users on system-related issues” com mesmo conteúdo.

Estas foram as mudanças do exame LPI 201 lançada em sua nova versão de 11/2013. Vou tentar fazer logo o comparativo com o exame LPI 202, até lá vamos focando a 201. Abraço e boa sorte!

Fonte:

http://www.lpi.org/linux-certifications/programs/lpic-2/exam-201/

http://wiki.lpi.org/wiki/LPIC-2_Objectives_V3

Atualizado 29/04/2014: Exame 202

Diferenças entre antigo exame LPI 202 com a nova versão 11/2013

 

 

Instalação e Configuração do SAMBA

O Samba tem como função principal o compartilhamento de arquivos e impressoras para Windows.

  1. Instalar o samba.
    #apt-get install samba
    A instalação vai questionar a respeito do nome do domínio, ou grupo de trabalho da rede.
  2. Como de costume, vamos renomear o arquivo de configuração padrão e criar um novo:
    #cd /etc/samba
    #mv smb.conf smbbkp.conf
  3. Em seguida criar o arquivo de configuração:
    #vi smb.conf
    Primeiramente vamos configurar o samba como um servidor de arquivos públicos. Nesse caso o sistema não solicitará autenticação. Para isso basta inserir o conteúdo abaixo no arquivo de configuração:


    [global]
    netbios name = SrvFile 
    server string = Servidor Samba
    security = share 
    [public]				
    comment = Itens Públicos 	
    available = yes 			
    browseable = yes 		
    path = /var/samba/share 	
    writeable = yes 			
    veto files = /*.avi/*.mp3	
    detele veto files = yes		
    public = yes 			
    

    Abaixo a descrição de cada entrada no arquivo:
    A seção [global] especifica configurações globais.
    Netbios name:Nome netbios do computador. Aparece entre parênteses nos clientes Windows.
    Server String: Descrição do computador. Primeiro nome nos clientes Windows.
    Security:Utilizado para autenticação separada de cada compartilhamento.
    A seção [public] define o compartilhamento público.
    Comment:Comentário sobre o recurso compartilhado.
    Available: Disponibiliza o recurso compartilhado.
    Browseable: Permite a visualização do compartilhamento.
    Path:Caminho do diretório compartilhado.
    Writeable: Permite a escrita. Pode ser substituido por Read only = yes.
    Veto Files:Tipos de arquivos que serão bloqueados.
    Delete Veto Files: Deleta todos os tipos de arquivos listados anteriormente.
    Public:Não solicita usuário e senha.

  4. Após configurar o arquivo, deve-se criar o diretório especificado na opção path, e atribuir as permissões:
    #mkdir -p /var/samba/share
    #chmod 777 /var/samba/share
  5. Em seguida, basta reiniciar o serviço para o compartilhamento se tornar disponível:
    #/etc/init.d/samba restart
  6. O Samba ainda permite o compartilhamento restrito. Nesse nível, apenas usuário que possuam contas armazenadas no servidor samba poderão acessar o compartilhamento. O conteúdo do arquivo de configuração deverá ficar assim:

    [global]
    netbios name = SrvFile 
    server string = Servidor Samba
    security = user 
    
    [homes]			
    comment = Diretório pessoal
    writeable = yes
    browseable = yes

    Security = user: Apenas essa opção está diferente do compartilhamento público. A opção user define o nível de autenticação de usuário.
    A seção [homes] define o compartilhamento dos diretórios pessoais dos usuários. Ainda é possível definir outros diretórios com a opção path.

  7. Após configurar o arquivo, é necessário criar o usuário. O comando abaixo cria o usuário no samba:#smbpasswd -a user1Vale ressaltar que o usuário deverá estar previamente cadastrado no sistema (/etc/passwd).
  8. Em seguida, basta reiniciar o serviço para o compartilhamento se tornar disponível:#/etc/init.d/samba restart

Todas as alterações feitas no arquivo de configuração, podem ser testadas com o comando testparm.

Instalação e Configuração do Apache

Utilizando o apache podemos:

  • Criar sites no Web Server
  • Restringir acesso a determinados sites
  • Monitorar sites
  • Criptografar sites (SSL)

Criação de sites no Web Server

  1. #apt-get install apache2;
  2. #mkdir /var/www/intranet. Cria um diretório para armazenamento do site intranet dentro de /var/www/. Esse é o diretório padrão de localização dos arquivos de sites utilizado pelo Apache. Após a criação do diretório, será necessário criar o arquivo index.html dentro do diretório;
  3. Em seguida, vamos criar o arquivo de configuração do site com o comando #vi /etc/apache2/sites-available/intranet. O apache possui dois diretórios /etc/apache2/sites-available e /etc/apache2/sites-enabled. O primeiro diretório, armazena os arquivos de configuração dos sites, enquanto o segundo, armazena os links dos arquivos de configuração. O apache utiliza os links para carregar os sites, evitando que alterações sejam feitas no arquivo de configuração original.
    • A entrada VirtualHost permite que mais de um site possa ser hospedado no mesmo servidor;
    • A entrada ServerName especifica o nome do site;
    • A entrada DocumentRoot especifica o local do diretório de armazenamento dos arquivos do site;
    • As entradas Error log e CustomLog especificam se o apache vai registrar os logs de erro e os logs de acesso respectivamente. Os log são salvos no diretório de log do apache /var/apache2/log. Caso o mesmo servidor possua mais de um site, os logs dos sites serão combinados no log padrão do apache. Para desmembrar os logs, basta inserir caminhos diferentes no parâmetro CustomLog para CADA SITE. Por exemplo para o site http://www.intranet.com o parametro pode ser: CustomLog /var/www/intranet/access.log combined

    Essas são apenas as opções básicas para criação de um site. Posteriormente veremos mais opções.

  4. Após salvar o arquivo de configuração, será necessário carregar o arquivo para o diretório dos links. Esse processo é feito com o comando a2ensite intranet;
  5. Em seguida, deve-se criar o arquivo index.html do site e salvá-lo no diretório especificado em DocumentRoot no arquivo de configuração;
  6. Por fim, reiniciaremos o serviço com o comando apache2ctl restart ou /etc/init.d/apache2 restart;

Para criar mais de um site nesse mesmo servidor, basta repetir todo o processo para o novo site.

  1. mkdir /var/www/comercial. Cria o diretório comercial;
  2. Para o arquivo de configuração, vamos concatenar o arquivo de configuração do site intranet para um novo arquivo chamado comercial, pois apenas poucas informações serão alteradas nesse novo arquivo.cat /etc/apache2/sites-available/intranet > /etc/apache2/sites-availabe/comercial;
  3. Após a criação do arquivo, apenas os parametros ServerNameDocumentRoot e CustomLog serão alterados para o nome do site e o diretório respectivamente;

     ServerName www.comercial.com
    	DocumentRoot /var/www/comercial
    	CustomLog /var/www/comercial/access.log combined

  4. Após a criação do arquivo de configuração, basta rodar o comando a2ensite comercial para que o mesmo se torne disponivel pelo apache;
  5. /etc/init.d/apache2 restart, reinicia o servidor;

Note que no processo de criação do segundo site, não criamos o arquivo index.html dentro do diretório do site. Ao invés disso, foi criado um arquivo chamado Teste.txt em branco. Após reiniciar o serviço, foi efetuado o teste de conexão com um dos clientes. O resultado para o site http://www.intranet.com foi satisfatório, retornando a página especifica (o arquivo index.html). Já para o site http://www.comercial.com, o teste foi efetuado mas o navegador listou o conteúdo do diretório utilizado para armazenar o site ao invés da página web, exibindo apenas o arquivo .txt criado anteriormente:



Isso acontece porque o diretório especificado em DocumentoRoot no arquivo de configuração do site, não possui um arquivo index.html. Nesse caso o apache por padrão irá listar o conteúdo do site, como se fosse um servidor ftp. Para impedir essa ação, basta inserir a linha abaixo no arquivo de configuração do site:


Options -Indexes

A opção Indexes faz com que o apache liste os arquivos do diretório caso não encontre, nesse mesmo diretório, um arquivo index. Inserindo o sinal  antes da opção Indexes, o apache entende que ele não deverá conceder a permissão para nenhum cliente web a este diretório. Vale ressaltar, que a criação de um novo site no mesmo Web Server, geralmente necessita que as configurações do DNS sejam alteradas. Isso porque o novo site, conterá um domínio diferente. No exemplo, criamos dois sites http://www.intranet.com e http://www.comercial.com. Nas configurações de DNS, foram especificadas somente as zonas para o dominiointranet.com. Nesse caso, para que o segundo site funcione corretamente, será necessário criar outra zona com o domínio comercial.com. Basta repetir o processo de configuração de zonas, alterando apenas as opções referentes a nome da zona no BIND.

Restrição de acesso

É possível, e em alguns casos extremamente recomendável, restringir o acesso a determinados sites, ou partes dele, fazendo com que o navegador do cliente solicite um usuário e uma senha para permitir a exibição do site. Isso é feito basicamente, inserindo, no diretório que deseja bloquear no servidor, o arquivo .htaccess. Abaixo os passos para restringir o acesso á todo o site http://www.intranet.com, liberando o acesso apenas ao usuário user1:

  1. vi /var/www/intranet/.htaccess, inserir o conteúdo abaixo:

     AuthName "Área Restrita"
    	AuthType Basic
    	AuthUserFile /etc/apache2/.apasswd
    	Required valid-user

    • AuthName: Nome que será exibido na janela de solicitação de autenticação para o cliente;
    • AuthType: Tipo de autenticação utilizada;
    • AuthUserFile: Caminho do arquivo utilizado para autenticação, criado com o comando htpasswd;
    • Require: Site só será exibido quando um usuário válido for identificado;
  2. htpasswd -c /etc/apache2/.apasswd user1: cria o arquivo .apasswd informado no .htaccess e o usuário user1. Após executar o comando, o mesmo pede para inserir uma senha. O argumento -c é responsável por criar o arquivo, caso queira alterar a senha para o usuário em questão, basta retirar o argumento. O nome do arquivo é de livre escolha, porém tende ser o mesmo nome indicado no arquivo htaccess.
  3. Editar o arquivo de configuração do site, inserindo as opções conforme a imagem:


    A opção mais importante é a AllowOverride all que especifica que o acesso será liberado para todos os usuários cadastrados.

  4. #/etc/init.d/apache2 restart;

Caso seja necessário bloquear apenas uma pasta, basta mover o arquivo .htaccess para essa pasta e inserir o caminho completo no arquivo de configuração do site:

  1. #mkdir /var/www/intranet/financeiro: Cria a pasta financeiro dentro do site http://www.intranet.com. Será acessada pelo cliente como http://www.intranet.com/financeiro, já que/var/www/intranet é a Raiz;
  2. #mv /var/www/intranet/.htaccess /var/www/intranet/financeiro/: Move o arquivo para a pasta financeiro;
  3. Alterar, no arquivo de configuração do site intranet, o parametro Directory, incluindo a pasta financeiro;

No lado cliente, ao acessar o site http://www.intranet.com todos os usuário terão acesso, porém ao acessar o site http://www.intranet.com/financeiro, apenas o usuário criado anteriormente (com o htpasswd) terá acesso.

Monitorando sites

O Apache registra todos os acessos em logs. A entrada CustomLog no arquivo de configuração do site, especifica o arquivo access.log que irá registrar os acessos. A ferramenta webalizer, permite visualizar de forma mais “agradável” essas informações, criando gráficos e estatísticas de uso do site em questão. Monitorando o site http://www.comercial.com

  1. #apt-get install webalizer;
  2. Editar a linha 28 do arquivo de configuração /etc/webalizer/webalizer.conf, inserindo o caminho completo do arquivo de log do site que se deseja monitorar, nesse caso/var/www/comercial/access.log, informada no parametro CustomLog do arquivo de configuração do site;
  3. Editar a linha 42, inserindo o diretório onde será salvo o arquivo de log gerado pelo webalizer./var/www/comercial/webalizer;
  4. #mkdir /var/www/comercial/webalizer, cria o diretório usado pelo programa;
  5. Usando o navegador do cliente, acessar a página http://www.comercial.com/webalizer.

Nesse caso, pode-se restringir o acesso a esse diretório (webalizer) criando o arquivo htaccess, como vimos anteriormente, para que apenas o administrador do site possa monitorá-lo. É comum que alguns caractéres utilizado na criação do site (arquivos com pontuação, por exemplo), não sejam exibidos corretamente no navegador. Isso acontece porque o arquivo usa um arquivo diferente da codificação suportada pelo webserver. Em alguns casos, esse problema é facilmente corrigido configurando a codificação do apache. O arquivo /etc/apache2/conf.d/charset especifica o tipo de codificação usado pelo apache. Basta descomentar a linha AddDefaultCharset. Na maioria dos casos a codificação padrão UTF-8 é utilizada, porém existem outras, como por exemplo ISO-8859-1. Em outros casos, é necessário inserir uma opção no cabeçalho da própria página para especificar o tipo de codificação. Para páginas em html pode-se inserir a linha abaixo:

 meta http-equiv="content-type" content="text/html; charset=UTF-8" entre < />

Usando OpenSSL

  1. #mkdir /etc/apache2/ssl: Cria o diretório para armazenar os arquivos de senha e certificado;
  2. #openssl req -new -out server.csr: Gera o arquivo de requisicao de certificado (.csr) e a chave privada (privkey.pem), usada na criptografia do arquivo de requisicao;
  3. #openssl rsa -in privkey.pem -out server.key: O que acontece, é que a chave privkey.pem criada com o comando anterior, usa o método de criptografia DES3. Esse método é utilizado para criptografar, mas não serve para assinar o certificado. O método utilizado para assinatura é o RSA. Esse comando cria uma chave para assinatura (.key) a partir da chave utilizada para criptografia (privkey.pem);
  4. #openssl x509 -req -signkey server.key -in server.csr -out server.crt -days 3650: Esse comando cria um certificado (.crt), a partir do arquivo de requisição (.csr) assinando o certificado com a chave privada (.key). O certificado terá validade de 3650 dias. Esse procedimento é utilizado para autoassinar o certificado;
  5. #vi /etc/apache2/site-available/site: Editar o arquivo de configuração do site inserindo as linhas abaixo:

     SSLEngine	on
    	SSLCertificateFile	/etc/apache2/ssl/server.crt
    	SSLCertificateKeyFile	/etc/apache2/ssl/server.key

  6. #a2enmod ssl: Habilita o módulo SSL;
  7. /etc/init.d/apache2 restart: Reinicia o servidor apache