Esse tópico pode parecer um pouco confuso como foi para mim também ao iniciar minha leitura. Ele envolve diversas habilidades que um administrador de sistema deveria possuir para uma boa manutenção e uso do sistema computacional. Isso inclui capacidade para trabalhar com o servidor de logs do sistema, construção de pacotes de software e implementação de planos de backup. Os objetivos desse post são:

• Configurar um servidor de log central
• Empacotamento de software
• Operações de backup

Objetivo 1: Sistema de Log

Quando se fala de sistema de log em ambientes Unix-like, já imagine que seja algo referente ao syslog. O syslog hoje é a implementação de gerência de log mais utilizada.

A popularidade do syslog se deve ao fato de ser muito flexível, permitindo que o serviço opere sobre uma rede de dados, permitindo assim uma gerência de logs centralizada na rede local. Porém, o syslog possui algumas fragilidades em sua implementação, pois não existe uma relação autenticada entre o cliente e servidor de logs. Também não existe criptografia nos dados trafegados na rede. E, para piorar ainda mais, os dados são enviados através de pacotes UDP, o que torna mais simples o Spoofing de endereços IP.

O que fazer quando o serviço não é seguro? Fortalecer ao máximo o ambiente ao redor! Ou seja, em um ambiente ideal, os logs devem ser trafegados em uma rede de segurança reforçada, de maneira que uma estação de trabalho não possa capturar o tráfego facilmente.

Configurando um Servidor Syslog

A configuração padrão do syslog não permite que ele seja utilizado como servidor. Para alterar essa configuração, é necessário iniciar o serviço do syslog com a opção “r”. Se estivermos utilizando como servidor a distro RedHat, basta incluirmos a opção como valor da variável SYSLOGD_OPTIONS do arquivo /etc/sysconfig/syslog. No Debian, a inclusão da opção “r” deve ser realizada no script de inicialização do serviço em /etc/init.d. Após a modificação do syslog para que ele atue como um servidor de logs, é necessário reiniciar o daemon syslog, caso seja RedHat, ou sysklogd, caso seja Debian.

Para reforçar um pouco a segurança do syslog, ele suporta uma lista de clientes confiáveis, que podem ser especificados através da opção “l” da mesma maneira como fizemos com a opção anterior.

Configurando um Cliente Syslog

Creio que não seja necessário explicar detalhes específicos da configuração de um cliente syslog, pois esse conteúdo já é abordado na LPIC-1. Vamos apenas relembrar de conceitos básicos.

O syslog organiza os logs de acordo com facilidades. Cada facilidade indica uma origem ou tipo de log possível. As facilidades possíveis são: authpriv, auth (ou security), cron, daemon, kern, lpr, mail, news, syslog, user, uucp e local0 a local7.

Cada facilidade pode ser refinada em níveis de urgência dos logs. Os níveis possíveis são: debug, info, notice, warning, err, crit, alert e emerg. Quanto mais severo o log, mais baixo é seu nível. A tabela abaixo nos ajuda a entender isso.

debug (7)

info (6)

notice (5)

warning (4)

err (3)

crit (2)

alert (1)

emerg (0)

Isso quer dizer que caso configurarmos o syslog para registrar efeitos de alguma facilidade no nível err, todos os níveis abaixo automaticamente serão logados.

O syslog pode realizar diversas ações sobre um determinado log. Segue abaixo descrição de cada uma delas:

• Arquivo – enviar as mensagens para serem gravadas em um arquivo em um sistema de arquivo local.
• Pipe – enviar as mensagens como entrada para outra aplicação.
• Terminal – enviar as mensagens para um terminal.
• Servidor – enviar as mensagens para um servidor de logs.
• Usuário – enviar as mensagens para um usuário local.

O arquivo de configuração do syslog no cliente é por padrão /etc/syslog.conf. Vamos a um exemplo desse arquivo.

kern.warning;*.err;authpriv.none /dev/tty10
mail.* |/dev/console
*.crit @servidor

A primeira linha irá enviar os logs da facilidade kern com níveis igual ou inferior a warning para o terminal tty10, assim como também todos os logs de níveis igual ou inferior a err e qualquer log da facilidade authpriv que não esteja enquadrado em nenhum dos oito níveis.

A segunda linha do exemplo enviará todos os logs de quaisquer níveis da facilidade mail para /dev/console, que representa o terminal utilizado pelo usuário no momento.

A última linha enviará os dados de qualquer facilidade com níveis igual ou inferior a crit para o computador de nome “servidor”.

logger

Sintaxe:

logger [opções] [mensagem]

Podemos utilizar a ferramenta logger para envio de mensagens da linha de comando para o syslog.

Exemplos de uso:

tail -f /var/log/message | logger -t logdomessage -p local6.info

logger -p info -t terminal ‘Teste de Log’

O primeiro exemplo acima irá enviar todos os logs que surgirem no arquivo /var/log/message para o syslog local na facilidade local6 e nível info. Além disso, será incluso um prefixo aos logs (“logdomessage”) de maneira a facilitar a identificação dos mesmos. O segundo exemplo envia para o syslog local, no nível info, a mensagem “Teste de Log” utilizando o prefixo “terminal”.

Objetivo 2: Empacotamento de Software

Na LPIC-1 aprendemos a manipular pacotes de software no padrão RPM (RedHat Package Management) e DEB (Debian Package). Na LPIC-2 o candidato deverá ter habilidade para construir os próprios pacotes de software. Para uma pesquisa mais profunda sobre o assunto, recomendo o livro “Gerenciamento de Pacotes de Software no Linux”de Rubem E. Ferreira, que pode ser encontrado aqui.

Construindo Pacotes RPM

Os pacotes distribuídos no formato RPM também são distribuídos em outro formato, chamado SRPM, ou Source RPM. Esse pacote não tem os binários pré-compilados como qualquer outro pacote RPM comum. Em vez disso, esses pacotes possuem o código-fonte necessário para a compilação do software.

Oras, mas para que um SRPM com o código-fonte do aplicativo se posso baixar o código-fonte direto com o desenvolvedor original? Simples! O SRPM além do código-fonte possui também todas as informações necessárias para a construção do pacote já criadas. Isso inclui a lista de dependências, comentários, scripts de pré e pós instalação, aplicação de possíveis patches e muito mais!

Os arquivos SRPMs são identificados pelo sufixo no nome dos arquivos. Algo como “src.rpm”. Vamos utilizar o pacote do interpretador de comandos bash em nossos testes!

Para tanto, inicialmente precisamos possuir as ferramentas de desenvolvimento para a compilação da aplicação. Em nosso exemplo precisamos das dependências autoconf, ncurses-devel, bison e gcc.

Após isso, podemos realizar a reconstrução do pacote a partir do código-fonte com o comando abaixo.

# rpmbuild –rebuild bash-3.2-9.fc7.src.rpm

Após o processo de configuração e compilação, se tudo ocorrer bem, o pacote RPM será colocado em /usr/src/redhat/RPMS/i386/bash-3.2-9.i386.rpm. Ele já está pronto para ser instalado.

Outra possibilidade para a modificação de um pacote RPM através de seu SRPM é prosseguindo com a instalação do pacote SRPM normalmente. Ou seja, devemos realizar o comando abaixo.

# rpm -ivh bash-3.2-9.fc7.src.rpm

Com o pacote instalado, seu conteúdo foi armazenado nos diretórios contidos em /usr/src/redhat. Abaixo, uma descrição do objetivo de cada diretório encontrado no endereço mencionado.

• BUILD – utilizado durante o processo de reconstrução do pacote.
• RPMS – onde serão colocados os pacotes finalizados.
• SOURCES – local onde os arquivos fontes serão armazenados.
• SPECS – contêm arquivos especiais chamados SPECS (extensão .spec) que contêm informações sobre cada pacote, como a versão, nome do desenvolvedor/empacotador, descrição, pacotes dos quais depende, changelog.
• SRPMS – onde os arquivos SRPMS são colocados ao final do processo.

Faça então as modificações que forem preciso no conteúdo do pacote acessando os diretórios de /usr/src/redhat. Após isso, é necessário acessar o diretório SPECS onde encontraremos o arquivo bash.spec. Com esse arquivo podemos também reconstruir o pacote utilizando a ferramenta rpmbuild. Vejam o exemplo abaixo.

# rpmbuild -bb bash.spec

De toda a saída que será gerada, o que nos importa será o trecho abaixo.

Gravei: /usr/src/redhat/RPMS/i386/bash-3.2-9.i386.rpm

Indica exatamente onde foi gravado o pacote resultado da compilação. O diretório poderá ser diferente no trecho referente à arquitetura. O exemplo acima de uso do rpmbuild com a opção “bb” irá apenas gerar o pacote com os binários. Caso quiséssemos gerar o pacote binário e também o pacote SRPM, bastaria substituir a opção utilizada por “ba”, como abaixo:

# rpmbuild -ba bash.spec

Se nossa intenção for apenas gerar o pacote SRPM, basta utilizar a opção “bs”.

# rpmbuild -bs bash.spec

Pronto! Reconstruímos um pacote RPM. 🙂

Modificando Pacotes RPM

Como vimos, o arquivo SPEC de um pacote é um dos mais importantes. Nele são definidas todas as características do pacote. O arquivo é composto de diversas entradas possíveis, incluindo macros que são como aliases para comandos ou endereços, seções que definem scripts a serem executados, e registros apenas informativos.

A tabela abaixo nos informa sobre o significado de uma das principais entradas contidas no arquivo.

Entrada	Descrição
Name:	Nome do pacote
Summary:	Breve descrição do pacote.
Version:	Versão do pacote.
Release:	Release do pacote.
License:	Licença do pacote.
Group:	Grupo do pacote, sendo um dos grupos contidos em /usr/share/doc/rpm-versão/GROUPS
URL:	Sítio web do pacote.
Source:	Localização dos fontes para construção do pacote.
Patch:	Patches a serem aplicados no código-fonte ao construir o pacote. Os patches devem estar no diretório /usr/src/redhat/SOURCES.
Buildroot:	Diretório temporário onde serão construídos os pacotes. Normalmente se utiliza a macro %{_tmppath}.
Requires:	Pacotes requeridos apenas no momento da instalação.
Prereq:	Pacotes requeridos para estarem presentes no sistema para que o mesmo funcione adequadamente.
BuildPrereq:	Pacotes requeridos para a construção do pacote.
%description	Descrição do pacote.
%prep	Script que irá descompactar o software e aplicar os patches.
%setup	Macro para descompactação do código-fonte.
%patch	Macro para aplicação dos patches.
%build	Script que irá construir o software.
%configure	Macro utilizada para a configuração de softwares que utilizam autoconf ou automake. Equivale a executar o configure.
%install	Script que irá instalar o software.
%makeinstall	Macro utilizada para a instalação de softwares que utilizam autoconf ou automake. Equivale ao comando make install.
%clean	Script de remoção dos arquivos e diretórios temporários utilizados na construção do pacote.
%post	Script que irá ser executado após a instalação do pacote.
%preun	Script que irá ser executado antes da desinstalação do pacote.
%postun	Script que irá ser executado após a desinstalação do pacote.
%files	Seção que define os arquivos do pacote e seus atributos.
%defattr	Macro que define as permissões padrão dos arquivos especificados em %files.
%{_bindir}	Macro que define o diretório /usr/bin do sistema.
%{_sysconfdir}	Macro que define o diretório /etc do sistema.
%{_mandir}	Macro que define o diretório dos manuais de referência on-line do sistema.
%{_datadir}	Macro que define o diretório /usr/share do sistema.
%{_doc}	Macro que define o diretório /usr/share/doc do sistema.
%{_libdir}	Macro que define o diretório /lib do sistema.
%{_includedir}	Macro que define o diretório /usr/include do sistema.
%changelog	Histórico do pacote.

Vamos observar um exemplo prático de uso das entradas da tabela acima. Para tanto, utilizarei o mesmo pacote dos exemplos anteriores: bash. O exemplo abaixo poderia ser modificado de acordo com a necessidade do empacotador, porém, para efeitos didáticos, apenas estou exibindo o conteúdo original (com alguns cortes) para entendermos o arquivo.

Version: 3.2
Name: bash
Summary: The GNU Bourne Again shell (bash) version %{version}
Release: 9%{?dist}
Group: System Environment/Shells
License: GPL
Url: http://www.gnu.org/software/bash

As linhas acima nos informam a versão do software, nome, descrição breve, release, grupo ao qual o software pertence, licença do pacote e URL do projeto.

Source0: ftp://ftp.gnu.org/gnu/bash/bash-%{version}.tar.gz
Source2: ftp://ftp.gnu.org/gnu/bash/bash-doc-%{version}.tar.gz
Source3: dot-bashrc
Source4: dot-bash_profile
Source5: dot-bash_logout

Essas linhas indicam os arquivos fontes utilizados para a construção do pacote. Os fontes devem estar no diretório /usr/src/redhat/SOURCES.

Patch1: ftp://ftp.gnu.org/gnu/bash/bash-3.2-patches/bash32-001
Patch2: ftp://ftp.gnu.org/gnu/bash/bash-3.2-patches/bash32-002

(…)

Patch126: bash-setlocale.patch
Patch130: bash-infotags.patch
Patch131: bash-cond-rmatch.patch

Patches a serem aplicados durante a construção do pacote.

Requires: mktemp
Requires(post): ncurses
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)

Essas linhas indicam que o pacote bash necessita do pacote mktemp para ser instalado. Através do uso de algumas macros, é definido onde será a localização do diretório temporário para a construção do pacote.

BuildRequires: texinfo bison
BuildRequires: ncurses-devel
BuildRequires: autoconf, gettext

Os pacotes texinfo, bison, ncurses-devel, autoconf e gettext são necessários para a construção do pacote.

%description
The GNU Bourne Again shell (Bash) is a shell or command language
interpreter that is compatible with the Bourne shell (sh). Bash
incorporates useful features from the Korn shell (ksh) and the C shell
(csh). Most sh scripts can be run by bash without modification. This
package (bash) contains bash version %{version}, which improves POSIX
compliance over previous versions.

Uma descrição completa do software contido no pacote.

%prep
%setup -q -a 2
%patch1 -p0 -b .001
%patch2 -p0 -b .002

(…)

%patch126 -p1 -b .setlocale
%patch130 -p1 -b .infotags
%patch131 -p1 -b .cond-rmatch

(…)

Script responsável por descompactar o software e aplicar os patches necessários para a construção do pacote.

%build
autoconf
%configure –with-bash-malloc=no –with-afs
make “CPPFLAGS=-D_GNU_SOURCE `getconf LFS_CFLAGS`”

(…)

Script responsável por construir o pacote, fazendo uso de diversas macros, como a %configure, que equivale a executar o arquivo configure contido no código-fonte do software.

%install
rm -rf $RPM_BUILD_ROOT

(…)

Script que executará a instalação do pacote.

%clean
rm -rf $RPM_BUILD_ROOT

(…)

Script responsável pela remoção dos arquivos do diretório temporário de construção de pacotes.

%post

HASBASH=””
HASSH=””

if [ ! -f /etc/shells ]; then
> /etc/shells
fi

(…)if [ -z “$HASSH” ]; then
echo “/bin/sh” >> /etc/shells
fi) < /etc/shells

Script executado após a instalação do pacote.

%postun
if [ “$1” = 0 ]; then
/bin/grep -v ‘^/bin/bash$’ < /etc/shells | \
/bin/grep -v ‘^/bin/sh$’ > /etc/shells.new
/bin/mv /etc/shells.new /etc/shells
fi

Script executado após a desinstalação do pacote.

%files -f %{name}.lang
%defattr(-,root,root)
%doc CHANGES COMPAT NEWS NOTES POSIX
%doc doc/FAQ doc/INTRO doc/article.ms

(…)

%{_mandir}/*/..1*
%doc doc/*.ps doc/*.0 doc/*.html doc/article.txt

Especificação dos arquivos que fazem parte do pacote, indicando seus atributos e documentação associada.

%changelog
* Mon Feb 12 2007 Tim Waugh <twaugh@redhat.com> 3.2-9
– Rebuild to link with libtinfo instead of libncurses.

* Wed Feb 7 2007 Tim Waugh <twaugh@redhat.com> 3.2-8
– Avoid %%makeinstall (bug #225609).

(…)

Changelog do pacote. Ou seja, as modificações que foram realizadas e os respectivos autores.

Construindo Pacotes DEB ou DPKG

Os pacotes DEB (Debian Package) ou também conhecidos como pacotes DPKG (Debian PacKaGe) têm o mesmo propósito dos pacotes RPM. É um software licenciado como GPL que conta com desenvolvedores não apenas no mundo Linux, como também em outras variantes Unix.

Os pacotes podem ser de dois tipos:

• pacotes binários – contêm os binários do software de maneira encapsulada, que torna mais simples e prática a distribuição do código.
• pacotes fonte – contêm o código-fonte e procedimentos para geração de pacotes binários.

Em nossos exemplos iremos utilizar os pacotes fonte para a criação e modificação de pacotes binários. Para tanto, vamos utilizar ferramentas como dpkg-buildpackage e debuild.

Os pacotes DEB já vêm integrados à ferramenta apt que iremos utilizar em nossos exemplos. O apt possui a opção junto com à sua variante apt-get para permitir ao usuário baixar diretamente dos repositórios o pacote fonte. Vamos utilizar como exemplo o velho e simpático bash novamente! 🙂

Para tanto, o primeiro comando que devemos realizar será:

$ apt-get source bash

Considerando que estamos em um diretório vazio, com esse comando serão baixados os arquivos bash_3.2-0ubuntu7.diff.gz, bash_3.2-0ubuntu7.dsc e bash_3.2.orig.tar.gz. O significado de cada um deles logo abaixo.

• diff.gz – patch a ser aplicado no código-fonte do software.
• dsc – arquivo de controle do empacotamento do software.
• orig.tar.gz – contém o código-fonte original do software.
• changes – não presente em nosso exemplo, descreve as mudanças feitas na release do pacote.

Com os arquivos em mãos, vamos fazer um exemplo com a ferramenta dpkg-buildpackage.

dpkg-buildpakage

Sintaxe:

dpkg-buildpackage [opções]

O dpkg-buildpackage já realiza a criação do pacote binário e o assina digitalmente com uma chave gpg.

Exemplos de uso:

# dpkg-buildpackage -kthigu@thigu.org

$ dpkg-buildpackage -k thigu@thigu.org -r/opt/fakedebian

O primeiro comando irá realizar a construção do pacote e o assinando com a chave do e-mail thigu@thigu.org. O segundo e último exemplo realiza o mesmo, porém, como usuário comum apontando para um diretório que seja possível acesso de leitura-escrita.

debuild

Sintaxe:

debuild [opções]

debuild é um script de automação do processo de geração de pacotes de binários ou fonte, de maneira a disponibilizarmos em um repositório. Tem funcionamento parecido com o dpkg-buildpackage.

Exemplos de uso:

# debuild -kthigu@thigu.org

$ debuild -kthigu@thigu.org -rootcmd=/opt/fakedebian

Os dois exemplos têm propósito parecido com o do comando dpkg-buildpackage, porém, o debuild deixará prontos os pacotes para que sejam enviados a um repositório Debian.

Modificando Pacotes DEB

Vimos como realizar a reconstrução dos pacotes de maneira simples utilizando duas ferramentas diferentes. Vamos ver agora como realizar a modificação nas características do pacote através dos arquivos de controle. Os arquivos de controle de pacotes DEB são basicamente control e rules. Ambos os arquivos se encontram no interior do diretório debian do diretório fonte do pacote.

control

Esse arquivo contém informações sobre o pacote fonte e o pacote binário. Informações como dependências, nome, versão, desenvolvedor, arquitetura. A tabela abaixo contém as entradas mais utilizadas.

Entrada	Descrição
Source:	Nome do pacote fonte.
Section:	Seção do pacote.
Priority:	Prioridade de distribuição do pacote.
Maintener:	Mantenedor do pacote.
Build-Depends:	Dependências para a construção do pacote.
Standard-Version:	Versão dos padrões Debian do pacote.
Uploaders:	Uploader do pacote.
Package:	Nome do pacote binário.
Architeture:	Arquitetura do pacote.
Depends:	Pacotes requeridos para a instalação do pacote.
Description:	Descrição do pacote.
URL:	URL do pacote.

Vejamos o exemplo do arquivo debian/control do pacote fonte do bash.

Source: bash
Section: base
Priority: required
Maintainer: Ubuntu Core developers <ubuntu-devel-discuss@lists.ubuntu.com>
XSBC-Original-Maintainer: Matthias Klose <doko@debian.org>
Standards-Version: 3.6.2
Build-Depends: autoconf, patch, bison, libncurses5-dev, texinfo, autotools-dev, debhelper (>= 4.1), texi2html, locales
Build-Depends-Indep: tetex-bin

Esse primeiro trecho do arquivo nos informa sobre o pacote fonte do bash.

Package: bash
Architecture: any
Pre-Depends: ${shlibs:Pre-Depends}
Depends: base-files (>= 2.1.12), debianutils (>= 2.15)
Conflicts: bash-completion
Replaces: bash-doc (<= 2.05-1), bash-completion
Suggests: bash-doc
Essential: yes
Section: shells
Priority: required
Description: The GNU Bourne Again SHell
Bash is an sh-compatible command language interpreter that executes
commands read from the standard input or from a file. Bash also
incorporates useful features from the Korn and C shells (ksh and csh).
.
Bash is ultimately intended to be a conformant implementation of the
IEEE POSIX Shell and Tools specification (IEEE Working Group 1003.2).
.
Included in the bash package is the Programmable Completion Code, by
Ian Macdonald.

(…)

A segunda seção indica especificamente sobre o pacote binário, como o nome, dependências para instalação, conflito com possíveis pacotes, sugestões e uma descrição. A descrição é composta por uma breve e uma longa. A primeira linha é uma descrição breve. A partir da segunda linha se inicia a descrição longa, onde não é recomendável que se use linhas em branco, para que não haja uma separação da seção e essa se confunda com as próximas.

rules

Arquivo do tipo Makefile. Ou seja, é um script que será interpretado por /usr/bin/make -f . Esse arquivo contém as instruções necessárias para a compilação do código-fonte do pacote. A tabela abaixo contém os principais alvos de compilação para esse arquivo.

Alvo	Descrição
build:	Alvo obrigatório. Contém as instruções para configurar e compilar o código-fonte.
build-arch:	Alvo opcional. Contém as instruções para configurar e compilar o código-fonte de acordo com uma arquitetura.
build-indep:	Alvo opcional. Contém as instruções para configurar e compilar o código-fonte independente da arquitetura.
binary:	Alvo obrigatório. Invoca os subalvos binary-arch e binary-indep. Eles irão copiar/mover os arquivos executáveis para o diretório debian/nome-do-programa.
clean:	Alvo obrigatório. Contém as instruções para remover os arquivos temporários da compilação.
get-orig-source:	Alvo opcional. Contém as instruções para obtenção do código-fonte original do programa.

Além dos alvos mais comuns, também existem algumas variáveis de ambiente em comum com a maior parte dos pacotes. A tabela abaixo tem o significado das mais populares.

Variável de Ambiente	Descrição
DEB_BUILD_ARCH	Arquitetura Debian onde o pacote será construído.
DEB_HOST_ARCH	Arquitetura Debian onde o pacote será instalado.
DEB_BUILD_GNU_TYPE	Tipo de sistema GNU onde o pacote será construído.
DEB_HOST_GNU_TYPE	Tipo de sistema GNU onde o pacote será instalado.
DEB_BUILD_GNU_CPU	Tipo de CPU onde o pacote será construído.
DEB_HOST_GNU_CPU	Tipo de CPU onde o pacote será instalado.
DEB_BUILD_GNU_SYSTEM	Tipo de sistema operacional onde o pacote será construído.
DEB_HOST_GNU_SYSTEM	Tipo de sistema operacional onde o pacote será instalado.

Vamos ao exemplo nosso de cada dia! 🙂

#! /usr/bin/make -f
# -*- makefile -*-

#export DH_VERBOSE=1

unexport LANG LC_ALL LC_CTYPE LC_COLLATE LC_TIME LC_NUMERIC LC_MESSAGES

# architecture dependent variables
DEB_BUILD_GNU_TYPE := $(shell dpkg-architecture -qDEB_BUILD_GNU_TYPE)
DEB_HOST_ARCH := $(shell dpkg-architecture -qDEB_HOST_ARCH)
DEB_HOST_ARCH_OS := $(shell dpkg-architecture -qDEB_HOST_ARCH_OS)
DEB_HOST_GNU_CPU := $(shell dpkg-architecture -qDEB_HOST_GNU_CPU)
DEB_HOST_GNU_SYSTEM := $(shell dpkg-architecture -qDEB_HOST_GNU_SYSTEM)
DEB_HOST_GNU_TYPE := $(shell dpkg-architecture -qDEB_HOST_GNU_TYPE)

(…)

As linhas acima fazem a declaração de algumas variáveis de ambiente descritas anteriormente.

build: before-build bash-build minimal-build static-build preinst-build check

before-build:
: # see #327477, needed to have HAVE_DEV_STDIN defined
(…)

bash-build:
$(MAKE) -f debian/rules do-build-bash \
(…)

minimal-build:
$(MAKE) -f debian/rules do-build-min \
(…)

minimal-configure:
$(MAKE) -f debian/rules do-configure-min \
(…)

static-build:
$(MAKE) -f debian/rules do-build-static \
(…)

static-configure:
$(MAKE) -f debian/rules do-configure-static \
(…)

all-bashdb-build: bashdb-build

bashdb-build:
DEBUGGER_START_FILE=/usr/share/bashdb/dbg-main.inc \
(…)

bashdb-configure:
DEBUGGER_START_FILE=/usr/share/bashdb/dbg-main.inc \
(…)

bashdb-doc-build: stamps/stamp-build-bashdb-doc
stamps/stamp-build-bashdb-doc:
(…)

bash-doc-build: stamps/stamp-build-bash-doc
stamps/stamp-build-bash-doc:
(…)

check: stamps/stamp-check
stamps/stamp-check: bash-build
(…)

clean:
dh_testdir
dh_testroot
(…)
dh_clean

preinst-build: debian/bash.preinst
debian/bash.preinst: debian/bash.preinst.c
(…)

install: bash-install

bash-install: bash-build stamps/stamp-install-bash
stamps/stamp-install-bash: stamps/stamp-build-bash
dh_testdir
dh_testroot
dh_clean -k -p$(p) -p$(p_doc) -p$(p_bins)
dh_installdirs -p$(p) \
(…)

As linhas resumidas acima nos mostram os mais diversos tipos de alvos possíveis para o make. No exemplo temos, além das já tratadas anteriormente, before-build, bash-build, bash-configure, minimal-build, minimal-configure, static-build, static-configure, etc.

Objetivo 3: Operações de Backup

Último objetivo dessa aula de hoje! Para a LPIC-2 é interessante que o candidato possa criar uma política de backup simples para ambientes standalone, ou seja, uma estratégia de backup em um único servidor em vários sem uso de recursos de rede, como a criação de SANs (Storage Area Network).

O candidato deve apenas estar ciente de alguns detalhes importantes quando pensamos em backup. Primeiramente, o objetivo de se realizar esse tipo de planejamento é poder fazer com que haja sempre disponibilidade dos dados importantes para a empresa. Sendo assim, a política de backup deve prever recuperação de desastres, como terremotos, enchentes, furações, ou quaisquer outros fatores, naturais ou não, que façam com que recursos fiquem inoperantes ou indisponíveis.

Existem três tipos de desastres, se fôssemos classificá-los.

• Natural – tornados, furações, inundações, fogo.
• Humano – erro de operação, sabotagem, ataque terrorista.
• Ambiente – falha de equipamento, erro de software, falha de rede.

Para a maior parte desses desastres é necessário que haja uma cópia dos dados em um local remoto, de maneira a poder evitar que um único sinistro torne todos os dados indisponíveis. Sendo assim, é necessário definirmos os pontos de falhas e analisarmos o ciclo de riscos e a probabilidade de cada um deles. O plano de backup externo deve levar em conta os seguintes fatores.

• Área geográfica – distância da organização e a probabilidade do local externo ser afetado pelo mesmo desastre.
• Acessibilidade – tempo para recuperar os dados do local externo, caso necessário.
• Segurança – capacidade de manter de maneira segura os dados, até mesmo os mais sensíveis.
• Ambiente – estrutura para armazenamento dos dados (temperatura, umidade, prevenção contra fogo, etc).
• Custo – custo de manutenção.

Todas as variáveis mencionadas irão diretamente afetar o modo como será realizado o plano de backup. Afinal, o plano tem quer compatível com a realidade da empresa. Existirão situações em que os dados devam ser transportados por equipes de seguranças armados até localizações distantes, porém, outras situações podem requerer apenas que seja enviada uma cópia do dado de uma partição para outra no sistema, ou talvez uma sincronização dos dados através da Internet com um computador remoto.

Durante a criação da estratégia de backup devemos também conhecer exatamente quais dados precisamos proteger, ou seja, do que fazer backup! Afinal, em um servidor de arquivos com metade de seu armazenamento apenas com música de usuários desocupados, talvez realizar um backup de tudo não seja interessante, ou talvez seja, tudo irá depender das necessidades da sua organização.

Concluindo

Bem, fiz esse post com um pouco de pressa, já que escrevi ele todo hoje! 😛 Então, caso encontrem erros, ou algo no mínimo suspeito, é só levantar a mão e mandar um comentário para cá que eu verifico, ok?

Não sei se terei tempo ainda para postar mais algo sobre a prova 201 da LPIC-2, afinal, prova marcada para dia 31 de Julho, ou seja, terça-feira! Creio que até lá irei apenas fazer uma leitura dinâmica sobre os textos e fazer muito simulado (mais ainda!). Mas não se preocupem, tem a prova 202 LPIC-2 marcada também! 😛 Então voltarei aqui para fazer uns artigos sobre esse, que acredito eu, seja o conteúdo mais difícil!

Abraços a todos e até mais! 😀