Faculdade de Engenharia da Universidade do Porto
Virtualização da instalação e
configuração da IPBrick
Pedro Miguel Pereira Serra
Tese submetida no âmbito do
Mestrado Integrado em Engenharia Electrotécnica e de Computadores
Major de Telecomunicações
Orientador: Pedro Souto (Professor Auxı́liar)
Junho de 2008
c Pedro Serra, 2008
Resumo
Este projecto enquadrou-se no desenvolvimento de uma nova versão da IPBrick, que é
uma distribuição de Linux especı́fica vocacionada para as necessidades das empresas. Tem
como especial foco a preparação deste servidor integrado para usar diversas distribuições
de Linux como sistema operativo de base, ao invés uma única, a Debian, como acontecia
nas versões anteriores. Esta nova IPBrick é um produto que permitirá à iPortalMais atingir novos mercados que trabalham com diferentes plataformas de software.
Partindo da última versão disponı́vel, alterou-se a aplicação de configuração IPBrick para
uma nova arquitectura que permite a abstracção do sistema operativo que a sustenta.
Esta restruturação significa que embora a IPBrick possa usar diferente sistemas operativos, a configuração do sistema é independente do sistema operativo instalado. Por
outras palavras, para o utilizador da IPBrick, o sistema operativo usado é transparente.
i
ii
Abstract
This project was carried out in the context of the development of a new version of
the IPBrick, which is a Linux distribution especially targeted to the needs of enterprises.
The major feature of this new version is that the IPBrick will be available with different
operating systems, instead of only the Debian Linux, as happened up to this new version.
This new IPBrick feature will allow iPortalMais to access to new markets.
Starting with the last version of IPBrick, the IPBrick administration application was
rewritten according to a new architecture that allows the abstraction of the operating system that supports it. This change on the IPBrick structure will allow the use of different
operating systems as a base for IPBrick, while keeping the configuration the same for the
final users, independently of the base operating system used.
iii
iv
Agradecimentos
A todos os que contribuı́ram para este trabalho.
À minha famı́lia.
Aos que contribuem para que o mundo evolua para uma cada vez maior harmonia
entre seres. Certamente estará incluı́do neste grupo o inventor da bicicleta.
Obrigado
Pedro Serra
v
vi
“Eu sei que tenho limite, só não sei qual é.”
Carlos Braga
vii
viii
Conteúdo
1 Introdução
1.1 O que se Pretende? . . . .
1.2 Enquadramento . . . . . .
1.3 Abordagem . . . . . . . .
1.4 Estrutura da Dissertação .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
2 Plataformas Tecnológicas
2.1 IPBrick . . . . . . . . . . . . . . . . . . . . . . . .
2.1.1 IPBrick.I . . . . . . . . . . . . . . . . . . .
2.1.2 IPBrick.C . . . . . . . . . . . . . . . . . . .
2.1.3 Análise Técnica da IPBrick . . . . . . . . .
2.2 Outras Ferramentas de Administração de Sistema .
2.2.1 YaST . . . . . . . . . . . . . . . . . . . . .
2.2.2 Webmin . . . . . . . . . . . . . . . . . . . .
2.2.3 cPanel e WebHost Manager . . . . . . . . .
2.2.4 DirectAdmin . . . . . . . . . . . . . . . . .
2.3 Interoperabilidade em Linux . . . . . . . . . . . . .
2.4 Linux . . . . . . . . . . . . . . . . . . . . . . . . .
2.4.1 Red Hat Enterprise Linux . . . . . . . . . .
2.4.2 Debian . . . . . . . . . . . . . . . . . . . . .
2.4.3 Ubuntu . . . . . . . . . . . . . . . . . . . .
2.4.4 Comparação entre Distribuições . . . . . . .
2.5 Programação . . . . . . . . . . . . . . . . . . . . .
2.5.1 PHP . . . . . . . . . . . . . . . . . . . . . .
2.5.2 JavaScript . . . . . . . . . . . . . . . . . . .
2.5.3 AJAX . . . . . . . . . . . . . . . . . . . . .
2.6 Resumo . . . . . . . . . . . . . . . . . . . . . . . .
3 Requisitos
3.1 Instalação . . . . . . . . . . . . . . . . . . . . . .
3.2 Serviços . . . . . . . . . . . . . . . . . . . . . . .
3.3 Interface e Base de Dados . . . . . . . . . . . . .
3.3.1 Gestão de Pacotes e Actualizações . . . .
3.4 Caracterı́sticas de Desenvolvimento da IPBrick 5
3.5 Resumo dos Requisitos . . . . . . . . . . . . . . .
ix
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
1
1
2
2
3
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
5
5
6
7
8
11
12
13
14
15
15
16
17
18
19
19
24
24
25
26
27
.
.
.
.
.
.
29
29
30
30
30
31
31
x
4 Arquitectura e Projecto da Aplicação
4.1 Análise à IPBrick V4.3 . . . . . . . . .
4.2 Nova Aplicação de Configuração . . .
4.2.1 Camadas . . . . . . . . . . . .
4.2.2 Estrutura de Ficheiros . . . . .
4.2.3 IPBrick Development Standards
4.2.4 Serviços . . . . . . . . . . . . .
4.3 O Pacote IPBrick . . . . . . . . . . . .
4.4 Gestão de Actualizações e Software . .
4.4.1 Pré-instalação . . . . . . . . . .
4.4.2 Pós-instalação . . . . . . . . .
4.4.3 Pós-remoção . . . . . . . . . .
4.5 Planeamento . . . . . . . . . . . . . .
4.6 Resumo . . . . . . . . . . . . . . . . .
CONTEÚDO
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
33
33
34
35
36
37
38
38
39
39
40
40
40
41
5 Implementação
5.1 Exemplo Serviço: Apache2 . . . . . . . . .
5.1.1 Actualização de Definições . . . . . .
5.1.2 Script de Geração . . . . . . . . . .
5.1.3 Templates dos Sites Base da IPBrick
5.1.4 Script de Aplicação . . . . . . . . . .
5.2 Construção do Pacote IPBrick . . . . . . . .
5.3 Testes . . . . . . . . . . . . . . . . . . . . .
5.4 Resumo . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
43
43
43
44
45
46
47
47
47
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
6 Conclusões e Trabalho Futuro
49
6.1 Trabalho Realizado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
6.2 Trabalho Futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
A Testes
51
A.1 Serviços . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
A.2 Resumo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
B Construção do Pacote IPBrick
61
B.1 control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
B.2 preinst . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
B.3 postinst . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Referências
69
Lista de Figuras
2.1
2.2
2.3
2.4
2.5
2.6
2.7
2.8
2.9
2.10
Configuração da IPBrick.IC . . . . . . . . . . . . . . . . . . . .
IPBrick.IC como um servidor de Comunicações . . . . . . . . .
Interface de configuração da IPBrick.I: Listagem de utilizadores
Interface de configuração da IPBrick.C: Funcionalidade VoIP .
Interface de configuração da IPBrick: Configuração avançada .
Interface gráfica do YaST . . . . . . . . . . . . . . . . . . . . .
Interface gráfica do Webmin . . . . . . . . . . . . . . . . . . . .
Interface gráfica do cPanel . . . . . . . . . . . . . . . . . . . . .
Interface gráfica do DirectAdmin . . . . . . . . . . . . . . . . .
Modelo de funcionamento do AJAX [1] . . . . . . . . . . . . . .
4.1
4.2
4.3
Modelo de funcionamento da IPBrick 4.3 . . . . . . . . . . . . . . . . . . . . 34
Abstracção da aplicação de configuração relativamente ao SO . . . . . . . . 35
Novo modelo de funcionamento para IPBrick 5 . . . . . . . . . . . . . . . . 38
xi
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
6
8
9
10
11
13
14
15
16
26
xii
LISTA DE FIGURAS
Lista de Tabelas
2.1
2.2
Serviços da IPBrick.I . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Serviços da IPBrick.C . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
xiii
7
8
xiv
LISTA DE TABELAS
Abreviaturas e Sı́mbolos
AD: Active Directory
AJAX: Asynchronous Javascript And XML
COAS: Caldera OpenLinux Administration Software
CSS: Cascade Style Sheet
DHCP: Dynamic Host Configuration Protocol
DMZ: DeMilitarized Zone
DNS: Domain Name System
FTP: File Transfer Protocol
GUI: Graphical User Interface
HTML: HyperText Markup Language
HTTP: HyperText Transfer Protocol
IDS: Intrusion Detection System
IPSec: IP Security
PAM’s: Pluggable Authentication Modules
PHP/FI: PHP Hypertext Preprocessor / Form Interpretor
RPM: Red Hat Package Manager
SAM: System Administration Manager
SIP: Session Initiation Protocol
SMH: System Manager Homepage
SO: Sistema Operativo
SSL: Secure Sockets Layer
SSH: Secure SHell
TLS: Transport Layer Security
VPN: Virtual Private Network
VoIP: Voice over IP
YaST: Yet another Setup Tool
xv
xvi
ABREVIATURAS E SÍMBOLOS
Capı́tulo 1
Introdução
Na actualidade é uma tendência as empresas estarem cada vez mais suportadas por
plataformas informáticas de redes e de comunicações, onde a velocidade e segurança são
factores importantes. A administração de redes, a gestão dos seus recursos, impressoras,
faxes, ficheiros, contas de e-mail, etc. são ameaçados por virus, worms e intrusões que
põem em risco o sistema de informação da empresa.
O trabalho consiste no desenvolvimento de uma nova versão da IPBrick que, pode dizerse, é uma distribuição de Linux especializada para as necessidades das empresas, com interface de configuração simples integrada. É aliás a sua aplicação de configuração integrada
uma das caracterı́stica que a torna especial, possuindo uma organização própria e separando marcadamente configurações básicas do sistema das suas configurações avançadas.
A IPBrick é um produto desenvolvido pela iPortalMais para satisfazer as necessidades
empresariais ao nivel de redes e comunicações.
1.1
O que se Pretende?
De forma generalizada, o que se pretende é que o servidor integrado IPBrick, que
actualmente é baseado em Debian Linux, passe a estar disponı́vel com diferentes sistemas
operativos de base, também de uma forma integrada. Isto é: tudo o que a IPBrick é
como conceito deve estar preparado para ter qualquer sistema operativo como sua base,
abstraindo a configuração, instalação e funcionamento, da especificidade que possa estar
associada a cada sistema.
Esta disponibilização de diversos sistemas operativos na IPBrick é uma caracteristica
pretendida na nova versão da IPBrick: a IPBrick 5. No entanto esta dissertação vai
cingir-se ao trabalho realizado pelo autor, enquadrando o resto do desenvolvimento de
uma forma mais genérica para que este trabalho fique enquadrado no grande projecto que
é o desenvolvimento da nova versão 5 da IPBrick.
1
2
Introdução
É de realçar também que o ponto de partida a nı́vel quer teórico quer prático é uma
versão anterior de IPBrick: a versão 4.3.
1.2
Enquadramento
Este projecto foi desenvolvido na empresa iPortalMais - Soluções de Engenharia para
Internet e Redes, Lda. Enquadra-se no âmbito da cadeira de dissertação do Mestrado
Integrado de Engenharia Electrotécnica e de Computadores da Faculdade de Engenharia
da Universidade do Porto. Teve inicio em Fevereiro de 2008 e com duração de um semestre.
O autor já tinha trabalhado na empresa anteriormente onde desenvolveu um projecto
relacionado com a FEUP, o que facilitou a integração e permitiu um pronto começo do
projecto. O autor teve participação activa no processo de desenvolvimento geral do projecto da IPBrick 5 com maior responsabilidades na parte da aplicação de configuração
IPBrick.
1.3
Abordagem
Para se conseguir a abstracção do SO pretendida é necessário uma abordagem bem
estruturada que permita lidar com a complexidade do sistema e com a redefinição da sua
plataforma de desenvolvimento.
A abordagem seguida advém primeiramente das necessidades que se encontram para
a busca do objectivo principal. Por isso, logo à partida há a necessidade de conhecer bem
o sistema, o conceito de IPBick, os serviços que integra e a sua filosofia de funcionamento.
Isto implica um estudo da IPBrick e também das tecnologias que esta envolve.
Outro estudo essencial é o dos sistemas operativos que se pretendem usar como base da
IPbrick. Neste caso vão ser usadas três distribuições: o Debian “etch”, o Ubuntu “Gutsy”
e o Red Hat Enterprise Linux. É necessário estudar as suas caracterı́sticas e diferenças
entre eles, abordando mais detalhadamente os pontos que têm mais influência no projecto.
A IPBrick inclui um conjunto de serviços que no geral são baseados em software livre.
Esse software é habitualmente independente das distribuições utilizadas e requer também
o estudo da sua configuração. Mas essa independência não é sempre verificada, sendo
por vezes até uma marca de uma determinada distribuição de Linux a sua maneira de
compilar e configurar um determinado serviço. Além disso, associada a cada versão de
uma distribuição, está associada uma versão de um software. Logo isto implica possiveis
novas funcionalidades e diferentes configurações. É necessário então estudar e documentar
estas diferenças pois são necesssárias para o motor da IPBrick.
Após esse estudo que dará um enquadramento mais real das possibilidades de como
abstrair a configuração e geração da IPBrick do SO de base, proceder-se-á à redefinição
de especificações de uma forma mais detalhada e a um desenho de um protótipo a implementar.
1.4 Estrutura da Dissertação
3
Finalmente realiza-se a implementação propriamente dita de um protótipo que deverá cumprir o requisitos definidos. Todo este processo será acompanhado por testes que
confirmarão as alterações efectuadas.
1.4
Estrutura da Dissertação
Este relatório pretende apresentar o trabalho do autor na iPortalMais. Por isso a a
descrição é mais pormenorizada nas áreas da responsabilidade do autor, como é o caso
do processo de actualização do software para as versões adequadas e a aplicação de configuração da IPBrick No entanto não pode deixar de descrever partes que foram participadas de forma menos pormenorizada mas que são essenciais para a compreensão do
projecto na sua globalidade.
Para além deste capı́tulo, esta dissertação contém mais 5 capı́tulos. No Capı́tulo 2,
são apresentadas as tecnologias relacionadas com este projecto destacando-se o estudo da
IPBrick de forma mais técnica, assim como as diversas distribuições de Linux que serão
incluidas neste projecto. No Capı́tulo 3 definem-se os requisitos que se pretendem implementar. No Capı́tulo 4 descreve-se o projecto do trabalho a implementar. No Capı́tulo 5
apresenta-se o método de implementação e um exemplo do trabalho prático desenvolvido.
No Capı́tulo 6 faz-se uma avaliação do trabalho realizado de forma conclusiva assim como
o trabalho futuro.
4
Introdução
Capı́tulo 2
Plataformas Tecnológicas
O desafio que este trabalho levanta é melhorar uma ferramenta que utiliza um conjunto
de tecnologias que é necessário compreender bem. Por esse motivo, este capı́tulo começa
com uma análise comlpeta da IPBrick desde os serviços fornecidos até a uma análise
mais técnica. Depois disso apresenta-se uma análise de ferramentas de administração
existentes de forma a fazer um enquadramento dos desenvolvimentos que existem a nı́vel
de configuração, especialmente nas caracterı́sticas que se procuram para esta nova versão
da IPbrick, como são a busca de uma configuração integrada, independência do SO e
interoperabilidade com Linux. A última secção do capı́tulo faz uma apresentação de Linux
e uma análise das suas caracterı́sticas que terão importância neste projecto. São também
estudadas as três distribuições de Linux que vão ser usadas neste projecto.
Por último faz-se uma apresentação das linguagens de programação mais importantes
no desenvolvimento da IPBrick e analisa-se a sua influência no projecto da IPBrick 5.
2.1
IPBrick
A IPBrick é o ponto de partida e o ponto de chegada deste projecto.
É um servidor integrado completo, desenvolvido sobre a tecnologia Linux, e possui uma
interface de gestão funcional com acesso via web, que permite efectuar a sua configuração
sem que o seu administrador possua conhecimentos profundos de Linux ou mesmo de redes
e serviços. Para além da interface funcional, a IPBrick tem ainda uma interface avançada,
a partir da qual um administrador de redes e sistemas tem acesso directo a todos os seus
serviços, tais como DNS (Domain Name System), DHCP (Dynamic Host Configuration
Protocol ), LDAP (Lightweight Directory Access Protocol ), servidor de correio electrónico,
servidor de ficheiros, gestor de projectos, VPN (Virtual Private Network ) server, firewall
entre outros.
5
6
Plataformas Tecnológicas
Figura 2.1: Configuração da IPBrick.IC
A IPBrick é um sistema operativo para gestão de redes com administração simples e
funcional, devido à sua interface gráfica GUI (Graphical User Interface - Interface Gráfica
do Utilizador). Desta forma, as empresas não dependem mais de peritos informáticos para
manter a espinha dorsal do negócio em funcionamento com elevada disponibilidade.
A IPBrick estabelece um padrão de estabilidade e segurança na transferência de dados.
Como o centro de todo o trabalho colaborativo, pode ligar-se através do MS Outlook ou
através de um web browser. A tecnologia baseada em Linux garante confiança, velocidade e
eficiência nas transferências de dados. Com a integração do antivı́rus Kaspersky minimizase o risco de perda da integridade dos dados.
Todas as configurações são preservadas, gravando-se inclusive a data e hora das mesmas
para permitir a recuperação de qualquer configuração [2].
2.1.1
IPBrick.I
A IPBrick.I disponibiliza todos os serviços necessários de um servidor de Internet.
IPBrick.I pode ser o servidor de e-mail, ficheiros, domı́nio, fax, impressão e de backup.
Para além do calendário/agenda partilhados e gestor de contactos (sincronizados via MS
Outlook ou browser web), é possı́vel gerir todos os projectos da empresa de um ponto
central.
IPBrick.I integra-se facilmente com serviço de directório. Em termos de escalabilidade
oferece um conceito master/slave baseado em LDAP e MS Active Directory (AD).
O servidor de Intranet IPBrick.I pode ser utilizado em três modos diferentes:
master, slave e AD client. Consequentemente os utilizadores da IPBrick, grupos e dispositivos [terminais e telefones SIP (Session Initiation Protocol )] podem ser definidos na
IPBrick ou no Windows AD (Active Directory). Na Intranet, a tecnologia IPBrick é capaz
de funcionar num ambiente totalmente IPBrick ou integrada com sistemas Windows [2].
A IPBrick.I disponibiliza o seguinte conjunto de serviços, sendo estes apresentados na
Tabela 2.1:
2.1 IPBrick
7
Tabela 2.1: Serviços da IPBrick.I
Serviços
Servidor de áreas de trabalho individuais e de grupo
Servidor LDAP (gestão de máquinas, utilizadores e grupos)
Servidor de Domı́nio (com roaming-profiles e centralized scripting)
Servidor de correio electrónico
Servidor de impressoras
Servidor de base de dados
Servidor de DHCP (Dynamic Host Configuration Protocol )
Servidor de DNS (Dynamic Network Services)
Servidor de imagens de estações de trabalho
Servidor de Groupware (Calendário e Livro de Endereços)
Servidor de Backup (ARKEIA)
Gestor de projectos (dotProject)
Serviços Opcionais
Kaspersky Anti-Malware
Correio Electrónico (AntiVirus, AntiSpam)
Servidor de ficheiros (AntiVirus)
Single sign-on (Autenticação Biométrica)
2.1.2
IPBrick.C
A IPBrick.C garante a segurança na transferência de dados entre Intranet e
Internet. Os dados transferidos (download and upload ) são filtrados, analisados e geridos pela IPBrick.C. Estas operações são executadas pelos principais componentes da
IPBrick.C: Mail-Relay, Servidor-Proxy, IDS (Intrusion Detection System), Antivı́rus e
AntiSpam. A IPBrick.C controla todas as interfaces disponı́veis para a Internet. O objectivo da IPBrick.C é gerir as ligações da empresa com a Internet. Os serviços oferecidos
são: servidor web, servidor FTP (File Transfer Protocol ), VPN (Virtual Private Network )
gateway e telefonia VoIP (voz sobre IP).
A tecnologia VPN não só permite o fluxo de dados seguro mas também permite a
escolha do espaço de trabalho conforme as necessidades. A IPBrick.C gere as ligações permanentes entre diversos pontos através de túneis IPSec (IP Security) assim como através
de túneis OpenSSL (Secure Sockets Layer e TLS Transport Layer Security) para ligações de
confiança. O correio electrónico assim como o tráfego web é continuamente filtrado através
de regras configuráveis. Relatórios com estatı́sticas apresentam a informação essencial em
gráficos de interpretação fácil. Através do web mail podem ser geridos os e-mails de uma
forma segura, mesmo que através de um browser web em qualquer lugar e momento.
A IPBrick.C pode ser colocada numa DMZ (DeMilitarized Zone) protegida por firewall,
como um servidor de comunicações protegida pela firewall, ou mesmo como um servidor
completo de comunicações e sistema de firewall integrado. A IPBrick.C pode importar os
utilizadores, grupos e dispositivos (estações de trabalho e telefones SIP Session Initiation
Protocol ) de uma IPBrick.I ou de um sistema Windows AD. Isto significa que, instalando
8
Plataformas Tecnológicas
Figura 2.2: IPBrick.IC como um servidor de Comunicações
a IPBrick.C como servidor de comunicações, não é necessário redefinir as informações do
sistema já disponı́veis no servidor de Intranet da empresa [2].
A IPBrick.C disponibiliza os seguintes serviços de empresa para a ligar à Internet,
sendo estes representados na Tabela 2.2
Tabela 2.2: Serviços da IPBrick.C
Serviços
Relay de correio electrónico
webmail
Servidor web
Servidor Proxy (HTTP, HTTPS, FTP com estatı́sticas)
Traffic shaping
Port security (packet based firewalling)
IDS (Intrusion Detection System)
Servidor de VoIP (RTP bases routing)
Integração transparente com PBX (ISDN E1/BRI e linhas analógicas)
Serviços Opcionais
Kaspersky Anti-Malware
Correio Electrónico (AntiVirus, AntiSpam)
Servidor de ficheiros (AntiVirus)
Integração transparente com PBX (ISDN E1/BRI e linhas analógicas)
2.1.3
Análise Técnica da IPBrick
Interface Gráfica
A interface de configuração de sistema da IPBrick foi desenhada para ser de fácil
utilização, com o objectivo de poder ser uma ferramenta de administração utilizável por
alguém sem necessáriamente conhecimentos informáticos profundos. No entanto não deixa
de ser uma ferramenta muito extensiva em termos de configurações avançadas. Faz parte
2.1 IPBrick
9
Figura 2.3: Interface de configuração da IPBrick.I: Listagem de utilizadores
da filosofia da IPBrick esta forte separação entre uma configuração básica, que pode ser
gerida de forma fácil e com conhecimentos mı́nimos de administração, e uma configuração
avançada que permite aos utilizadores mais experientes personalizar o seu sistema à sua
maneira.
A interface está organizada por módulos, estando as funcionalidades de cada serviço
separadas consoante a sua função. Por exemplo o serviço de correio electrónico da IPBrick.I
contem configuração de utilizadores enquanto na IPBrick.C já contem a configuração da
funcionalidade mail copy.
São apresentados na Figura 2.3 e na Figura 2.4 da página 10 exemplos da interface de
configuração para um serviço de intranet e outro de comunicações, nas quais podemos ver
o diferente menu.
Seguidamente na Figura 2.5 da página 11 apresenta-se a interface com um exemplo de
configuração avançada, na qual se pode verificar a subdivisão do menu de configurações
avançadas, assim como os serviços disponibilizados neste sub-menu.
Modo de Funcionamento
A IPBrick tem um modo de funcionamento próprio. As suas configurações são efectuadas através da interface de configuração apresentada e guardadas numa base de dados.
No final das modificações efectuadas, para que estas se tornem activas, é necessário fazer
uma aplicação de configurações. Ao efectuar essa aplicação, o motor da IPBrick vai fazer
uma análise ao modificado e encarrega-se de fazer todas as acções necessárias para as
modificações realizadas. Por exemplo, dependendo da modificação podem se necessários,
cópia de ficheiros, modificação de ficheiros, começo ou paragem de serviços, etc.
10
Plataformas Tecnológicas
Figura 2.4: Interface de configuração da IPBrick.C: Funcionalidade VoIP
Organização
Analisando a nı́vel mais técnico, o que é então a IPBrick? Esta questão pode ser
respondida separando por camadas. A IPBrick é:
• I Sistema operativo base
• II Pacotes adicionados e modificados
• III Geração de configurações
• IV Interface de gestão e base de dados
Parte-se de um sistema operativo base, complementa-se esse sistema com alteração e
adição de software, formando um sistema operativo próprio IPBrick. As camadas III e
IV pertencem à aplicação de configuração e estão interligadas e dependentes a nı́vel de
programação.
Olhando esta estrutura por camadas pode-se dizer que o objectivo do projecto da
IPBrick 5 é gerar a instalação de I, II automaticamente a partir da definição do que é uma
IPBrick, depois construir a geração dos ficheiros de configuração para qualquer versão
partindo de um código comum.
Este objectivo implica que a separação entre as camadas III e IV esteja bem definida,
de forma a se poder trabalhar na camada III para que esta faça também a abstracção da
interface de configuração para o SO.
2.2 Outras Ferramentas de Administração de Sistema
11
Figura 2.5: Interface de configuração da IPBrick: Configuração avançada
2.2
Outras Ferramentas de Administração de Sistema
Nesta secção faz-se uma análise a outras ferramentas de administração de sistemas
existentes que se enquadram nas funções e serviços também fornecidos pela IPBrick. Esta
análise além de procurar avaliar o enquadramento tecnológico da IPBrick comparada com
os outros produtos disponı́veis, procura avaliar os produtos existentes na caracterı́stica
especı́fica que a IPBrick procura com este projecto: a interoperabilidade em vários sistemas
operativos, mais propriamente entre distribuições de Linux.
Os sistemas operativos Linux estão ligados, desde a sua criação, à utilização por parte
de pessoal especializado ou com fortes conhecimentos técnicos. Hoje em dia o Linux está
também virado para os utilizadores domésticos e evoluiu muito no sentido de permitir
uma utilização por qualquer pessoa, mesmo sem formação em computadores. No entanto,
a administração de um sistema operativo ou de uma rede de computadores é uma tarefa
que pode ser muito complexa e exigir conhecimentos técnicos profundos.
Muitos defendem que um verdadeiro administrador edita os ficheiros manualmente,
mas a verdade é que as ferramentas que simplificam a configuração sempre foram procuradas e sempre tiveram porta aberta nos mercados. Várias ferramentas surgiram que tinham como objectivo facilitar a tarefa de administração, das quais muitas desenvolveram-se
e continuam hoje em desenvolvimento mas muitas outras estagnaram e foram descontinuadas. Isto pode dever-se a diversos factores, desde a grande evolução em termos de ligações
de Internet que transformaram a realidade de fornecimento de serviços, até ao grande desenvolvimento que se deu a nı́vel gráfico no mundo do Linux, proporcionando a criação
de interfaces gráficas a ferramentas de configuração de serviços. Apesar disso estes desenvolvimentos manifestaram-se mais em ferramentas especı́ficas e não de uma administração
12
Plataformas Tecnológicas
integrada. A nı́vel de Linux para servidores as opções que se desenvolveram foram mais a
nı́vel comercial e vocacionados para administradores com formação especı́fica.
Um dos problemas dos administradores de sistemas sempre foi a diferença entre as
ferramentas diferentes usadas para distribuições diferentes. O OpenLinux usa o COAS,
a SuSE o YAST e o Red Hat usava o LinuxConf. Há ainda outras ferramentas com
uma filosofia diferente e baseadas numa interface web que não estão ligadas a nenhuma
distribuição especı́fica, mas cujos serviços estão mais vocacionados para uma determinada
area.
Vai-se seguidamente averiguar o comportamento das mais relevantes.
2.2.1
YaST
“YaST is the most powerful installation and system management tool in the
Linux environment. It is an open source project sponsored and actively developed by Novell.” [3, About YaST]
Apesar desta afirmação ser proveniente da página oficial do Yast, das ferramentas de
configuração estudadas o YaST é realmente das que tem mais funcionalidades e a mais
evoluida.
O YaST “nasceu” em Janeiro de 1995. Começou por ser escrito em C++ com GUI por
um dos fundadores do SUSE: Thoamas Fehr, e Michael Andres. A primeira distribuiçao
do YaST foi no entanto com o Slackware nesse mesmo ano. Um ano depois sai oficialmente
o YaST 0.53 no SUSE Linux 4.2.
É a ferramenta de instalação e configuração do openSUSE, do SUSE Linux Enterprise e das distribuições de Linux baseadas em SUSE. É famoso por ser uma ferramenta
completa integrada de facil utilização mas principalmente por ter uma interface gráfica
muito atractiva. É uma ferramenta potente e permite uma personalização fácil do sistema
durante e depois da instalação.
O YaST tem um guia para a instalação dividido em passos simples, que permitem a
definição das configurações básicas. Permite também uma instalação com mais detalhe
para utilizadores com maior nı́vel de conhecimento. Pode também configurar todo o
sistema desde hardware, a rede, serviços do sistema, definições de segurança, etc. Uma
diversidade de serviços podem ser alcançados através do YaST. YaST é aliás o nome da
ferramenta inicialmente criada sendo YaST2 o nome da interface gráfica.
Na Figura 2.6 da página 13 podemos ver a interface gráfica do YaST2.
Apresentam-se de seguida os serviços mais importantes do YaST:
• Gestão de actualizações: Instalar e remover pacotes de software, actualização on-line
• Gestão e configuração de hardware
• Interface de configuração: Edição dos ficheiros de configuração através de interface
gráfica facilitada ao serviço
2.2 Outras Ferramentas de Administração de Sistema
13
Figura 2.6: Interface gráfica do YaST
• Ferramenta de particionamento de discos
• Configuração de rede: DHCP servidor e cliente, ISDN, modem, placa de rede, hostname
• Serviços de rede: DNS, servidor HTTP, proxy, Samba, SSH, FTP
• Administração de aplicações Novell
• Segurança e utilizadores: Firewall, utilizadores, grupos, super utilizador, certificados
• Outros: Logs de sistema, configuração de auto-instalação, opções de inicialização,
colocar suporte.
Avaliando os foruns e lista de bugs desta ferramenta podemos verificar que algumas
queixas surgem mais a nı́vel de velocidade e problemas de gestão de dependências entre
pacotes de software. Tem um historial de uma considerável quantidade de bugs.
2.2.2
Webmin
O Webmin nasceu em 1997 pela mão de James Cameron. A sua criação surgiu da
necessidade de dar capacidade a utilizadores menos experientes para adicionar registos
DNS através de uma interface web da empresa. Daı́ surgiu a ideia que um browser podia
servir para configurar muitos mais serviços e o Webmin desenvolveu-se [5].
Segundo a página web oficial [6]o Webmin funciona em mais de 40 distribuições incluindo (Red Hat, SuSE, Sun, Mac OSX, Mandrake e FreeBSD). É distribuı́do sob licença
BSD e por isso pode ser utilizado livremente para fins comerciais e não comerciais.
Uma das vantagens do Webmin é ser uma aplicação web, por isso precisa apenas de
um navegador que lide com o HTML. Inclui também um mini servidor web próprio para
14
Plataformas Tecnológicas
Figura 2.7: Interface gráfica do Webmin
não haver necessidade de ter um instalado ou não estar dependente deste. Tem também
configurações de segurança que permitem uma utilização remota segura da aplicação.
Podemos reparar na avançada e agradável interface de configuração do Webmin, na
Figura 2.7.
Os serviços disponibilizados por esta aplicação são muito vastos, havendo também
módulos que são desenvolvidos pela comunidade.
2.2.3
cPanel e WebHost Manager
O cPanel e o WHM (WebHost Manager) são duas aplicações usadas em conjunto
formando uma ferramenta poderosa de controlo de web hosting servindo tanto clientes
como pessoal administrativo.
Estas duas aplicações disponibilizam:
• Interface gráfica de configuração baseada na web
• Separação de serviços cliente / administrador
• Servidor de mail e webmail
• Administração de domı́nios
• Administração de servidor
• Instalação automática de aplicações
Apresenta-se também na figura 2.8 o aspecto da interface gráfica do cPanel onde se
notam diversos serviços disponibilizados para configuração.
2.3 Interoperabilidade em Linux
15
Figura 2.8: Interface gráfica do cPanel
2.2.4
DirectAdmin
O DirectAdmin é uma ferramenta em tudo idêntica ao cPanel junto com o WebHost
Manager. Muda a interface mas os serviços e a vocação para serviços de web hosting são
praticamente equivalentes.
A aplicação divide os serviços em quatro categorias:
• Gestão para utilizadores
• Gestão para administradores
• Gestão para revendedores
• Opções gerais
A interface gráfica do DirectAdmin é apresentada na Figura 2.9 da página 16.
2.3
Interoperabilidade em Linux
A questão da interoperabilidade acompanha aliás o cosmos do Linux desde há muito. A
liberdade de criar versus a cooperação no desenvolvimento capaz de servir todos, independentemente da sua especificidade, é um tema discutido e com algum trabalho desenvolvido
como é o caso do LSB (Linux Standards Base). Existe aliás muita discussão dentro deste
projecto apesar de ter evoluı́do com o apoio de algumas distribuições de Linux.
Esta questão é mencionada para se ter um enquadramento da situação da interoperabilidade e de como esta questão existe e é necessário ser desenvolvida dentro do mundo
16
Plataformas Tecnológicas
Figura 2.9: Interface gráfica do DirectAdmin
Linux. Este projecto destina-se especı́ficamente à IPBrick que é Linux e deve ter esta
questão presente.
Destaca-se que muitos projectos tinham como objectivo ou mais valia esta ambição de
interoperabilidade, apesar desta questão estar longe de estar respondida e poucos acabam
por fornecer essa interoperabilidade.
2.4
Linux
Linux é o termo geralmente usado para designar qualquer sistema operativo que utilize
o kernel Linux. Foi desenvolvido por Linus Torvalds, inspirado no sistema Minix. O
seu código fonte está disponı́vel sob licença GPL para qualquer pessoa utilizar, estudar,
modificar e distribuir de acordo com os termos da licença.
Inicialmente desenvolvido e utilizado por grupos de entusiastas em computadores pessoais, o sistema Linux passou a ter a colaboração de grandes empresas, como a IBM, a
Sun Microsystems, a Hewlett-Packard, e a Novell [10].
Como foi referido, a IPBrick é uma distribuição especı́fica de Linux. Seguindo o objectivo deste projecto, a IPbrick pretende ser Linux sem se restringir a uma distribuição,
mas idealmente a qualquer plataforma Linux como sua base. Daı́ a procura de estudar o
que caracteriza as diferentes distribuições de Linux.
De forma geral podemos distinguir algumas caracterı́sticas que marcam habitualmente
as diferenças entre as diversas distribuições de linux:
• Gestão de actualizações: Todas as distribuições de Linux têm um ou outro
método para distribuir ficheiros quer seja através de CD ou através de actualizações
via web. Uma usam binários pré-compilados, outras os ficheiros com o código fonte,
2.4 Linux
17
outras ainda metodos diferentes com caracterı́sticas especı́ficas para cada. Muitas
distribuições usam o RPM ( Red Hat Package Manager ) e os debs, abreviatura
usada para os pacotes de software da Debian.
Esta distinção entre a gestão de software das diversas distribuições é importante
por diversas questões, das quais se destacam a compatibilidade e a disponibilidade
resultante da popularidade e consequente rapidez de desenvolvimento.
• Configuração: Ainda que muitas vezes as diferenças sejam poucas, a localização
dos ficheiros de configuração diferem de distribuição para distribuição.
• Software: O software que é disponibilizado de base em cada versão também é
diferente. Ainda que teoricamente se pode compilar qualquer software para qualquer
distribuição, isso pode implicar um esforço considerável. Algumas ferramentas são
mesmo especı́ficas de algumas distribuições que muitas vezes marcam a diferença.
• Comercialização: Por norma o Linux é de código aberto e disponı́vel para qualquer
pessoa. Há no entanto várias distribuições comerciais de base ou que se tornaram
comerciais, vocacionadas para empresas e com mais ou menos disponibilização de
assistência técnica ou outros serviços.
Abordando o trabalho prático a ser desenvolvido, apresentam-se seguidamente as três
distribuições de Linux que vão ser utilizadas para a implementação deste protótipo, procurando realçar as suas caracterı́sticas e especificidades que serão mais crı́ticas neste desenvolvimento.
2.4.1
Red Hat Enterprise Linux
O Red Hat Linux é uma das mais antigas e mais populares distribuições de Linux. Foi
fundado em 1994 por Bob Young e Marc Ewing. tem a sua sede em Raleigh, Carolina do
Norte, nos Estados Unidos da America [11].
Originou o formato de pacotes de software RPM usado por muitas distribuições como
SuSE, Caldera, Mandrake. Esta inovação foi um dos factores importantes da sua fama.
Inicialmente estavam disponı́veis duas distribuições: uma livre e outra virada para o
mercado. Actualmente a escolha é entre o Fedora Core e o Red Hat Entrepise Linux
havendo uma mais clara separação entre a componente comercial e a distribuição aberta
desenvolvida pela comunidade.
O Red Hat Entrepise Linux é usado em milhões de servidores em todo o mundo. A
versão actual é a 5, para a qual a Red Hat prometeu melhorias a nı́vel de aplicações
disponı́veis e certificação destas, melhoramento e facilidade em virtualização e também
em compatibilidade de hardware [11].
O Red Hat Enterprise Linux é famoso por ser certificado por enumeras empresas de
hardware e software, dando a esta distribuição o valor associado ao software livre e a
confiança de uma plataforma empresarial solida.
18
Plataformas Tecnológicas
2.4.2
Debian
O Debian GNU/Linux foi anunciado em 1993. Ian Murdock, o seu fundador, visionou
a criação de um projecto não comercial desenvolvido por centenas de voluntários programadores nos tempos livres. Na altura a ideia parecia destinada ao fracasso pois os que
acreditavam nela estavam em clara minoria relativamente aos cépticos. Mas a realidade
foi bem diferente. O Debian não só sobreviveu como se desenvolveu com grande sucesso,
transformando-se na maior distribuição de Linux no espaço de uma década. Além disso
tornou-se provavelmente na maior comunidade de software colaborativo de todos os tempos [12].
O sucesso da Debian pode ser avaliado pelos seguintes números: 20 000 pacotes de software compilados para 11 arquitecturas de processadores, é desenvolvido por mais de 1000
programadores voluntários e é responsável por inspirar mais de 100 distribuições baseadas
no Debian Linux, incluindo uma das mais famosas distribuições actuais: o Ubuntu [12].
O seu sistema de gestão de pacotes de software: APT, é um dos seus pontos fortes como
acontece com o Red Hat. Em termos de filosofia de desenvolvimento o Debian organiza-se
de uma maneira especı́fica. Existem três ramificações de desenvolvimento:
• Stable (4.0) — Intitulada de etch. Ramificação estável.
• Testing (X.Y) — Intitulada de Lenny. Ramificação com algum grau de estabilidade
mas que ainda exige mais testes.
• Unstable (Sid) — Ramificação instável. Ramificação de desenvolvimento, onde é
incluı́do software proposto com frequência.
[13]
Estes diversos graus de estabilidade definidos no seu desenvolvimento dão-lhe caracterı́sticas próprias. Por um lado é conhecida por ser uma distribuição com elevada
estabilidade e é muito usada em servidores e sistemas que exigem alta fiabilidade. Por
outro lado essa estabilidade é conseguida por um processo de testes que exige tempo e
esse tempo faz com que o Debian Linux, na sua versão stable não esteja a par das ultimas
versões de software. Com este prejuı́zo, o Debian é conhecido como a distribuição melhor
testada e com menos bugs. outro senão desta demora é a falta de acompanhamento no
desenvolvimento, relativamente à evolução do hardware.
Surgem ainda outras questões desta organização de desenvolvimento. Devido à estrutura fortemente democratizada surgiram algumas discussões devido decisões mais polémicas,
que contribuı́ram de certa forma para alguma estagnação e atraso no desenvolvimento,
assim como “lutas” infindáveis entre programadores que não contribuem para o desenvolvimento rápido do projecto.
2.4 Linux
2.4.3
19
Ubuntu
O Ubuntu nasceu em Setembro de 2004 através do multimilionário Sul Africano Mark
Shuttleworth. O projecto ganhou popularidade a uma velocidade fantástica, como não
tinha acontecido com nenhum outro. Em pouco tempo existiam foruns de discussão cheios
de utilizadores e programadores ansiosos. Nos anos que se seguiram o Ubuntu tornou-se a
mias popular distribuição de Linux e contribuiu muito para o desenvolvimento do Linux
fácil de utilizar e divulgação do sistema operativo livre capaz de competir fortemente com
qualquer solução proprietária [12].
O sucesso do Ubuntu deve-se a diversos factores.
Primeiramente foi criado pelo
carismático multimilionário que foi o segundo turista espacial e um dos primeiros programadores ligados ao Debian. A sua empresa, a Canonical Ltd., é a financiadora deste
projecto que devido ao seu abastado fundador, distribuem gratuitamente CD’s para o
mundo inteiro. Além do apoio, da estabilidade financeira e de meios, o Ubuntu criou
uma forte base estrutural baseada na web com documentação, wiki’s, um sistema de bugreporting criativo, assim como uma abordagem profissional para os utilizadores finais.
Com isto o Ubuntu conseguiu contornar os erros cometidos por outras distribuições e
acelerar o seu processo de desenvolvimento [12].
Técnicamente o Ubuntu é baseado na versão instável do Debian: “Sid ”, mas com
alguns pacotes de destaque como o GNOME, Firefox e OpenOffice actualizados para a
suas versões mais recentes. Tem novas versões tendencialmente de 6 em 6 meses com
versoes ocasionais com suporte com updates de segurança para 3 a 5 anos, denominadas
LTS (Long Term Support). As versões não LTS são suportadas até 18 meses.
Outras caracterı́sticas que dão ao Ubuntu caracterı́sticas especiais são o live CD com
uma instalação guiada e facilitada, assitência na migração para utilizadores de Windows,
temas de ambiente de trabalho e suporte para as ultimas tecnologias de efeitos 3D com
instalação simplificada de drivers proprietários da ATI e NVIDIA.
Em termos de criticas ao Ubuntu podemos dizer que são concentradas especialmente
na sua relação com software proprietário. Houve alguma polémica pela relação da ultima
versão do Ubuntu com os drivers proprietários. Esta questão alonga-se a outras aplicações
proprietárias que são suportadas pelo Ubuntu.
Em termos de gestão de pacotes de software, o Ubuntu é uma base Debian e por isso
usa o APT com backgroud do dpkg (Debian package).
2.4.4
Comparação entre Distribuições
Após apresentadas algumas caracterı́sticas sobre as três distribuições que vão ser utilizadas neste projecto, vai-se proceder a uma análise mais comparativa entre elas.
Na verdade interessa detalhar bem estas diferenças para que se possa fazer uma integração correcta da instalação e da aplicação de configuração independentemente de qual
distribuição seja a base operacional da IPbrick. O que acabou de se afirmar é uma vez
20
Plataformas Tecnológicas
mais o reforço do objectivo primordial deste projecto: preparar a IPBrick para ter diversos
sistemas operativos como base. Mais especı́ficamente várias distribuições de Linux como
sistema operativo base.
Tendo em conta que duas das três distribuições que vão ser usadas no prototipo deste
projecto são o Debian e o Ubuntu, que são de alguma forma similares devido ao Ubuntu
ser baseado em Debian, este estudo comparativo vai centrar-se mais entre o Debian e o
Red Hat, sendo posteriormente feitas algumas considerações comparativas relativamente
ao Ubuntu.
Gestão de Pacotes
No que diz respeito às diferenças entre distribuições de Linux, destaca-se e desenvolvese um pouco mais a questão da gestão de software. Além de ser uma das caracterı́sticas
mais importantes na caracterização de uma distribuição, pois contribui para a estabilidade
do sistema, a facilidade de actualização do sistema e integração de novas ferramentas, é
também uma caracterı́stica que é necessário estudar com detalhe para a implementação
deste projecto.
Em Linux o software é distribuı́do em pacotes. Um pacote é um conjunto de ficheiros
e informação sobre o software a ser instalado, com instruções para a sua instalação, configuração e remoção. Um pacote pode conter software diversificado desde aplicações mais
populares como processadores de texto ou programas de edição de imagem, até partes
especı́ficas do sistema operativo e actualizações. Hoje em dia as actualizações do sistema
para uma nova versão são feitas através de pacotes. Outra grande vantagem dos pacotes
é que se trata de uma reorganização dos ficheiros, o que transforma milhares de ficheiros
relacionados em muito menos pacotes. Isto torna o processo de instalação e gestão de
software muito mais organizado e simples de lidar.
Mas ter uma organização simplificada e agradável não é suficiente para garantir um
bom sistema de gestão de pacotes. O núcleo da questão está em como gerir esta organização. Como manter a ligação e registo dos ficheiros e pacotes assim como a relação
entre eles?
Entre as soluções existentes há duas maneiras de abordar a organização interna de
pacotes. Uns concentrar-se mais nos ficheiros que estão envolvidos no pacote, outros
concentrar-se mais nas etapas do processo para instalação dos pacotes vendo o pacote
como um todo. Ambos tem a suas vantagens e desvantagens e o resultado final de qualquer
sistema de pacotes é uma mistura destas duas componentes procurando o melhor processo
para lidar com estas questões.
No enquadramento deste projecto há dois sistemas diferentes. O RPM, usado pela Red
Hat e o APT (que tem o dpkg em mais baixo nı́vel) pelas distribuições Debian e Ubuntu.
Uma das principais diferenças entre o Red Hat e o Debian é na gestão de pacotes.
Aliás esta é uma das mais notórias diferenças para um utilizador domestico de Linux, mas
2.4 Linux
21
para este projecto salta-se essa análise mais especı́fica da visão do utilizador pois, para
este, a configuração da IPBrick deve ser única e independente do SO.
As diferenças técnicas entre os dois sistemas é clara, desde as regras de nomeação até
ao método de organização de ficheiros. Algumas vantagens e desvantagens são atribuidas
a cada um dos sistemas, se bem que a evolução destes tendeu a corrigir esses problemas e
hoje em dia são ambos bastantes estáveis e completos, sendo mais adequados a ser usados
cada um para as distribuições para que estão preparados. Por este motivo pode dizer-se
que as diferenças entre eles na actualidade é muito mais uma preferência do utilizador do
que por uma clara sobreposição de um sobre o outro.
As caracterı́sticas técnicas são no entanto diferentes. No Red Hat as especificações de
um pacote são incluidas num ficheiro com sufixo .spec. Neste são incluidas a informação
relativa ao pacote assim como as instruções de instalação, remoção, mas também as informações necessárias a construção do próprio binário. Podem ser instalados vários pacotes
a partir de uma só especificação, ou seja, de um só ficheiro .spec. O ficheiro de especificações tem uma nomeação própria tendo que ter o nome do pacote a instalar. O seu
conteúdo está dividido por secções cada uma com a sua função. Estas especificações são
as seguintes:
• Preâmbulo - Aqui vão definidas as caracterı́sticas do pacote, como o nome, versão,
revisão, requisitos, etc. É aqui que estão os dados que são apresentados quando
alguém pede informações sobre o pacote.
• Secção de preparação - Inclui as instruções de preparação da construção do pacote.
Estas instruções são executadas habitualmente antes da descompactação da fonte.
• Secção de construção - Esta secção contem todas as instruções necessárias para
compilar o código fonte.
• Secção de instalação - Contem as instruções relativas à instalação.
• Scripts de instalação - Pode conter instruções a serem executas antes ou depois
da instalação, assim como antes ou depois da remoção.
• Secção de verificação - Nesta secção estão definidas verificações extra além das
que o sistema RPM faz por defeito.
• Secção de limpeza - Pode ser incluı́do nesta secção um script de limpeza. Apesar
de já ser efectuada uma limpeza pelo motor do RPM
• Lista de ficheiros - Esta secção é muito importante. Define os ficheiros que o
pacote comporta assim como as suas permissões. Esta lista tem que estar coerente
ou a instalação não será concluı́da.
22
Plataformas Tecnológicas
Nos pacotes .deb em vez de um ficheiro de especificações, existe uma pasta onde são
incluidos os ficheiros todos de instalação. Estes ficheiros estão divididos por funcionalidade,
existindo os seguintes:
• control - Script de controlo. Onde vão o nome, a versão, a listagem de dependências,
a descrição, etc.
• preinst - Script de pré instalação. Será executado antes da instalação.
• postinst - Script a executar depois da instalação
• prerm - Script de pré remoção. A executar antes de efectuara desinstalação.
• postrm - Script de pós remoção. A executar no final da desinstalação
A nomeação standard também é diferente. No Debian o nome do pacote é do tipo
nome ver-rev arq.deb, onde nome é o nome da aplicação, ver é a versão principal, rev
a revisão dentro desta versão e arq a arquitectura para o binário é destinado. No Red
Hat a nomeação é nome-ver-rev.arq.rpm sendo o significado das abreviaturas idênticos ao
explicado para os debs.
Software
Outra diferença entre as distribuições de Linux em geral é o software que estas incluem.
Para o nosso projecto é importante no sentido em que haverá um repositório base que
será o disponibilizado pela distribuição respectiva. Posteriormente este repositório será
completado para passar a ser o repositório IPBrick.
Há que destacar a plataforma Debian que é conhecida por ter uma quantidade fora do
normal de software disponı́vel, enquanto que o Red Hat é mais limitado. O Ubuntu tem
a vantagem de ter a base Debian e recebe os mesmos “louros” que este, neste aspecto já
que há grande compatibilidade entre eles.
A questão principal no que diz respeito ao enquadramento deste trabalho é a das
versoes usadas por cada uma das distribuições. O Ubuntu, como é baseado no Debian
unstable, é o que tem o software mais recente. O Red Hat vem de seguida e o Debian por
ultimo. Isto não significa obrigatóriamente uma grande alteração em termos de estrutura
de ficheiros ou de configuração. Depende das modificações que cada versão acarretar,
ou mais propriamente as alterações entre as diferentes versões que vão ser usadas pelas
diferentes distribuições usadas.
Por exemplo o servidor web Apache 2, que servirá ao longo deste trabalho como serviço
exemplo, tem as seguintes versões nas três distribuições abordadas:
• Debian : apache2.2.3-4+etch1
• Red Hat : httpd-2.2.3-6.el5.0.1
2.4 Linux
23
• Ubuntu : apache2.2.4-3ubuntu0.1
Entre as três pode verificar-se que apesar das pequenas diferenças de versão deste
serviço, tem implicações no seu funcionamento.
Configurações
Enquanto que muitos serviços e aplicações são bastante independentes da distribuição
implicando que a configuração destes é idêntica para qualquer distribuição, alguns serviços
mais básicos são habitualmente diferentes assim como as ferramentas de configuração usadas por cada. Estas diferenças acabam por ser uma marca importante de cada distribuição.
Neste aspecto de configuração dos serviços básicos (nome da maquina, rede, grupos
e utilizadores) o Ubuntu e o Debian partilham as mesmas ferramentas de configuração e
consequentemente a mesma metodologia. O Red Hat precisa de uma configuração diferente.
Noutros serviços e aplicações que vão de base em cada distribuição temos duas situações
distintas. Uma é relativa a aplicações que estão bastante independentes do sistema e por
isso a sua configuração entre distribuições é idêntica. Outra é a especificidade que algumas
aplicações ganham consoante a distribuição em que estão incluidas.
Um exemplo desta ultima é o servidor web apache2. Enquanto que no Red Hat este
se chama http e tem uma compilação e organização de ficheiros de configuração própria,
no Debian e Ubuntu o servidor web chama-se apache2 e os seus ficheiros de configuração
seguem uma organização diferente. Além disso, a IPBrick utiliza os seus próprios módulos
e configurações de base que terão que ser incluidos. Apesar disso esta versão do apache
é muito versátil e uma solução pode passar por tentar aproximar as configurações, com
o risco de afastamento de uma caracterı́stica da distribuição. Para completar a exemplificação resta dar um exemplo básico de um pormenor da configuração: no Red Hat está
definido no httpd.conf (ficheiro de configuraçao principal) as portas que estão a receber
ligações enquanto que no Debian e no Ubuntu existe um ficheiro próprio ports.conf onde
são definidas. Mas em ambos os casos sao definidos da mesma forma:
#file ports.conf
Listen <porta1>
Listen <porta2>
Ubuntu
Nesta analise comparativa entre distribuições o Ubuntu foi já referido relativamente
a algumas caracterı́sticas, mas foi de certa forma deixado de parte. Isto porque as suas
caracterı́sticas são muito idênticas ao Debian, sua distribuição “mãe”. Há no entanto
que realçar algumas caracterı́sticas que terão importância quando da sua integração neste
servidor integrado que é a IPBrick.
24
Plataformas Tecnológicas
O Ubuntu, por ser baseado na ramificação unstable do Debian, é a distribuição que
apresenta as versões mais recentes dos pacotes incluı́dos. Este factor a nı́vel de integração
vai ser tão mais importante quanto maior for o salto entre as versões. Aliás esta é uma
tarefa essencial neste objectivo de integração da IPbrick com várias distribuições de Linux
como SO de base: estudar essas diferenças e actuar consoante elas. Como exemplo, nas
versões usadas, temos alguns módulos configurados de forma diferente que terão que ir
de base no servidor web e uma configuração diferente dos PAM’s, dois pormenores muito
importantes sem os quais a IPBrick não funcionará correctamente.
2.5
Programação
2.5.1
PHP
PHP (PHP: Hypertext Preprocessor) é uma linguagem de script open source de uso
geral, muito utilizada e especialmente preparada para o desenvolvimento de aplicações
Web. É embutı́vel dentro do HTML.
A linguagem surgiu por volta de 1994, como um pacote de programas CGI criados
por Rasmus Lerdof, com o nome Personal Home Page Tools, para substituir um conjunto
de scripts Perl que ele usava no desenvolvimento de sua página pessoal. Em 1997 foi
lançado o novo pacote da linguagem com o nome de PHP/FI, trazendo a ferramenta Forms
Interpreter, um interpretador de comandos SQL. Mais tarde, Zeev Suraski desenvolveu o
analisador do PHP 3 que contava com o primeiro recurso de orientação a objectos [7].
Caracterı́sticas:
• Velocidade e robustez
• Estruturação e orientação a objecto
• Portabilidade - independência de plataforma - escreva uma vez e “corre” em qualquer
lugar.
• Tipos gerados dinâmicamente
• Sintaxe similar a Linguagem C/C++ e PERL
Em Junho de 2004 foi lançada a versão 5 do PHP, introduzindo um novo modelo de
orientação a objecto, como por exemplo:
• Reformulação dos Construtores e adição de Destructores
• Visibilidade de acesso
• Abstracção de objecto
• Interfaces de objectos
2.5 Programação
25
O tratamento de objectos do PHP foi completamente reescrito, permitindo um desempenho melhor e mais vantagens. Enquanto na versão anterior era preciso muito esforço
para atender à orientação a objectos e aos padrões de projectos (alguns não eram possı́veis),
o PHP 5 veio para sanar essa deficiência e facilitar a vida aos programadores.
A interface de configuração da IPBrick é uma aplicação PHP. Daı́ a importância de
explorar esta tecnologia. Mas a influência do PHP na IPBrick vai mais além da mais
comum utilização para a aplicação web. Esta ferramenta é explorada mais profundamente
para diversas tarefas a nı́vel de interacção com o sistema e em diversas tarefas de integração
com outras aplicações.
Relativamente à utilização do PHP neste projecto, é necessário avaliar duas vertentes:
• Actualização: Na versão anterior da IPBrick usava-se o PHP 4.3. É necessário estudar as alterações e implicações na codificação antiga assim como novas funcionalidades que se podem aproveitar.
• Nova estrutura: Como se vai utilizar e modificar o PHP 5 para construir a camada
de abstracção proposta, tornando a IPbrick funcional e idependente, com vários
sistemas operativos de base.
2.5.2
JavaScript
O JavaScript é uma linguagem de scripting utilizada em desenvolvimento web da óptica
do cliente. O seu nome oficial é ECMAScript, cujo desenvolvimento é mantido pela organização ECMA. O standard é baseado em JavaScript (Netscape) e em JScript (Microsoft),
e chama-se ECMA-262.
Esta linguagem foi inventada por Brendan Eich para o Netscape Navigator 2.0 e apareceu em todos os navegadores web da Netscape e da Microsoft desde 1996. Foi influenciada
por muitas linguagens e desenhada para se parecer com Java, só que mais fácil para se
trabalhar com ela [8].
Algumas caracterı́sticas de destaque:
• Desenhada para dar interactividade às páginas HTML
• É uma linguagem de scripting
• Embutivel no HTML
• Linguagem interpretada e leve.
• É livre. Qualquer um pode usar.
Na IPBrick o JavaScript é uma tecnologia muito usada e com tendência a ser mais usado
e de forma mais complexa. Na versão da IPBrick da qual se parte para este projecto, o
JavaScript é usado embebido no HTML com uma estrutura definida e é utilizado de uma
forma bastante simplificada maioritariamente para validação e popups de confirmação.
26
Plataformas Tecnológicas
Figura 2.10: Modelo de funcionamento do AJAX [1]
Relativamente à implementação que se pretende para a nova versão, o JavaScript
de estar organizado de uma forma estruturada desde a organização de ficheiros até à
organização do código. Isto enquadrado obviamente na arquitectura que se definir. A
nı́vel de interactividade com o sistema não terá influência visto que se esta a falar de um
linguagem que é interpretada no cliente, no navegador.
2.5.3
AJAX
AJAX (Asynchronous JavaScript And XML) é o uso sistemático de tecnologias, como
Javascript e XML, providas por navegadores web para tornar páginas mais interactivas com
o usuário, utilizando-se de solicitações assı́ncronas ao servidor. AJAX não é somente um
novo modelo, é também uma iniciativa na construção de aplicações web mais dinâmicas e
criativas. AJAX não é uma tecnologia, são realmente várias tecnologias conhecidas juntas,
cada uma fazendo sua parte, oferecendo novas funcionalidades e uma maior dinâmica às
páginas e aplicações web [9].
É AJAX é uma ferramenta muito importante no desenvolvimento web actual, permitindo dar dinamismo e eficácia à utilização de páginas e aplicações web. Isto acontece
principalmente porque existem frameworks e bibliotecas de efeitos que facilitam a vida aos
programadores. O modelo de funcionamento do AJAX é apresentado na Figura 2.10.
As primeiras inclusões de AJAX na IPBrick foram feitas apenas recentemente, não
tendo saı́do numa versão final comercializada com esta tecnologia. No entanto, tendo
em conta a atitude da iPortalMais em estar na vanguarda tecnológica, adivinha-se uma
IPBrick mais ao estilo AJAX num futuro próximo. Isto implica que a versão que se está
a desenvolver com este trabalho prepare esta inclusão, de acordo com a nova estrutura e
os parâmetros que estão a ser estabelecidos.
2.6 Resumo
27
Relativamente à parte de abstracção do SO, não terá que haver preocupações nesta
integração, pois estamos a falar de tecnologias que funcionam praticamente no lado do
cliente. Ao preparar a nova organização é necessário ter em conta que a utilização de
AJAX vai exigir a inclusão de diversos scripts organizados de uma forma especı́fica, assim
como estarem com permissões de acesso do browser. Um exemplo é apresentado de seguida:
/frameworks
/js
/ajax
/css
Neste exemplo de organização, mostram-se as diferentes componentes de uma estrutura
AJAX onde /frameworks contem os ficheiros relativos às frameworks que se utilizarem, /js
inclui os scripts de JavaScript de efeitos, comportamentos, etc. e a pasta /ajax contem
scripts que vão lidar com a base de dados e construir o XML necessário. A pasta /css já
é utilizada e contem os CSS’s necessários utilizados para apresentação.
2.6
Resumo
Neste capı́tulo fez-se uma introdução às tecnologias envolvidas mais importantes, que
serão a base deste projecto.
Nesta altura da dissertação já se deve conseguir prever de que forma cada tecnologia
vai influenciar o desenvolvimento deste projecto. Deve também ser possı́vel ter uma ideia
clara do que é a IPBrick como conceito e conhecer a filosofia e modo de funcionamento da
aplicação de configuração.
Foi apresentada uma secção de outras soluções de administração de sistemas presentes
no mercado, para se poder avaliar a posição da IPBrick a nı́vel tecnológico e compará-la
com outras soluções existentes.
Outra secção apresenta sucintamente algumas linguagens de programação usadas e a
sua influência no projecto.
Destaca-se ainda que foram apresentadas as três distribuições que vão ser usadas para o
desenvolvimento do prototipo da IPBrick 5. Destacou-se também os pontos que distinguem
estas distribuições e as áreas mais criticas de análise inter-distribuição.
28
Plataformas Tecnológicas
Capı́tulo 3
Requisitos
Neste capı́tulo vai-se fazer uma aproximação ao problema a nı́vel mais técnico. Apresenta-se aqui uma descrição geral do que se pretende implementar, separando por secções
funcionais. Cada uma dessas secções é analisada separadamente e daı́ resultarão os requisitos deste projecto como um todo. Um resumo dos requisitos será apresentado no fim
do capı́tulo com a especificação dos que vão ser implementados pelo autor e que serão
desenvolvidos nos capı́tulos seguintes desta dissertação.
Pretende-se que a IPBrick seja configurada de forma independente do sistema operativo
base. Na prática, a IPBrick deverá existir não apenas com o Debian Linux como sistema
operativo mas também com outras distribuições de Linux. Quer isso dizer que, quando
se instala a IPBrick, deverá poder-se escolher a distribuição de Linux que queremos como
sistema operativo.
Em termos de funcionamento não deverá haver alterações. Os serviços vigentes na
versão 4.3 da aplicação são mantidos, assim como a aplicação de configuração que deverá
ser usada de forma única pelo utilizador independentemente do SO de base. Isto implica
que a nova versão da IPBrick será construı́da sobre a versão actual, a versão 4.3.
A IPBrick 5 deverá ter uma instalação e configuração de forma automática com diversos
sistemas operativos à escolha. Mais propriamente várias distribuições de Linux à escolha,
nomeadamente o Debian, Ubuntu ou Red Hat.
3.1
Instalação
A IPBrick é distribuı́da para os clientes e parceiros num DVD, o qual, quando inserido
num computador, deverá efectuar toda a instalação automática após escolhido o sistema
operativo base pretendido.
29
30
Requisitos
No inı́cio da instalação deve ser ”perguntado”ao utilizador qual a distribuição Linux a
instalar. A restante instalação será feita de forma automática sendo o disco ejectado no
caso da instalação ser bem sucedida.
Após a finalização deste processo o computador requer um reinı́cio do sistema, depois
do qual estará instalado e funcional um sistema operativo IPBrick baseado na distribuição
Linux escolhida e uma configuração base padrão da IPBrick.
3.2
Serviços
Os serviços que a IPBrick inclui devem ser disponibilizados nas versões que o novo
sistema operativo base dispõe.
Em caso de ser um serviço que não conste no repositório de uma distribuição, passa a
ser incluı́do no secção “IPBrick” do repositório.
Os serviços que a IPBrick tem que disponibilizar são os disponibilizados na versão
anterior. Estes serviços foram apresentados na Tabela 2.1 e Tabela 2.2, no Capı́tulo 2. Os
serviços opcionais apresentados não são incluidos na implementação deste protótipo.
3.3
Interface e Base de Dados
A interface de configuração da IPBrick deverá manter-se e ser independente do sistema.
Aliás, será igual para qualquer sistema e comunicará com este sempre de forma igual.
A aplicação de configuração da IPBrick deverá funcionar em PHP 5.
Neste fase do trabalho a abordagem limitar-se-á a garantir que a aplicação é operacional
nos diferentes sistemas e nas actualizações que foram efectuadas. É necessário uma especial
atenção para algumas tecnologias que sofreram uma maior actualização ou alteração como
é o caso do PHP 5, que tem uma forte influencia no motor de configuração da IPBrick e
sofreu alterações que implicam modificação do código.
A nova versão incluirá todo o desenvolvimento feito até ao update 19 da versão 4.3.
3.3.1
Gestão de Pacotes e Actualizações
O sistema deverá poder ser actualizado pela interface da IPbrick.
A IPBrick dispõe de uma interface de actualização que é um front-end para o gestor
de actualizações do sistema operativo base instalado. Esta interface / front-end devem
estar preparados para interagir com o gestor de actualizações adequado: dpkg no caso do
Debian e Ubuntu, e RPM no caso de Red Hat.
As actualizações devem garantir a estabilidade do sistema assim como a estabilidade
da aplicação de configuração da IPBrick.
3.4 Caracterı́sticas de Desenvolvimento da IPBrick 5
3.4
31
Caracterı́sticas de Desenvolvimento da IPBrick 5
A nova versão da IPBrick deverá ter as seguintes caracterı́sticas:
• Manter o conceito de IPBrick, equivalente à versão anterior.
• Ter um motor de criação de um DVD com a IPBrick, contendo os diversos sistemas
operativos suportados
• Ter uma instalação automatizada de todo o sistema com permissão para escolher o
sistema operativo que lhe servirá de base.
• Ter um motor de criação de pacotes de software, tendo este que suportar os diversos
sistemas disponibilizados pela IPBrick.
• Ter o repositório actual da IPBrick/Debian actualizado para a nova versão estável
(etch) e construir uma estrutura de repositórios adequada para os diversos SO’s
também incluidos. Isto é: Ubuntu Gutsy e Red Hat Enterprise Linux.
• A aplicação de configuração IPBrick deverá configurar qualquer serviço e sistema
operativo suportado de forma idêntica ao que acontecia com a versão anterior.
• A estrutura de desenvolvimento da IPBrick deverá estar preparada de forma a que
haja uma abstracção entre a configuração de cada serviço e o sistema operativo de
base, para que a configuração por parte do utilizador seja sempre a mesma independentemente do SO instalado.
• O repositório da aplicação de configuração deve estar de forma a incluir uma separação clara da nova estrutura definida, assim como de toda a documentação de
desenvolvimento deste processo.
3.5
Resumo dos Requisitos
Seguidamente apresentam-se um resumo dos requisitos:
• Deve ser mantido o conceito de IPBrick.
• A IPBrick deverá incluir possibilidade de configuração para três distribuições de
Linux de base: Debian etch, o Ubuntu Gutsy e Red Hat Enterprise Linux.
• A configuração da IPBrick deve ser feita de forma igual pelo utilizador, independentemente do sistema operativo que estiver como base.
• A IPBrick 5 e as aplicações que vão integradas de base deverão usar PHP 5
• Os serviços fornecidos pela IPBrick devem ser os mesmos que são disponibilizados
na IPBrick 4.3.
32
Requisitos
• A interface web nao deverá ser alterada. Deve manter o aspecto e funcionalidades
da IPBrick 4.3.
Capı́tulo 4
Arquitectura e Projecto da
Aplicação
Neste capı́tulo apresenta-se a modelação para o que se quer da IPBrick 5 assim como
a abordagem prática seguida para satisfazer os requisitos definidos.
4.1
Análise à IPBrick V4.3
Começa-se com uma análise da estrutura e modo de funcionamento da versão anterior
da IPBrick para se perceber o que é necessário alterar. Dá-se também destaque aos pontos
mais fracos da aplicação para que se possa actuar nesses aspectos e corrigi-los.
A IPBrick 4.3 está estruturada de uma forma integrada, sendo pouco clara a distinção
entre as várias camadas que a constituem.
A organização dos ficheiros da IPBrick 4.3 é a seguinte:
/opt/ipbox/include
/opt/ipbox/LIB
/opt/ipbox/PHP
/opt/ipbox/scripts
/opt/ipbox/libs
/opt/ipbox/log
/opt/ipbox/site
Pela estrutura de ficheiros pode notar-se uma organização própria da IPBrick. Nesta
versão os ficheiros relativos à apresentação estão na pasta include, dentro da qual estão
separados por serviços e dentro destes encontram-se os ficheiros de apresentação, assim
como os de acção.
Esta versão apresenta algumas incoerência notórias como a nomeação dos ficheiros.
Por exemplo os ficheiros .php de acções, apresentam tanto nomes em inglês como em
33
34
Arquitectura e Projecto da Aplicação
Figura 4.1: Modelo de funcionamento da IPBrick 4.3
português e sufixos que não seguem um padrão. Isto é devido à origem da IPBrick, que
é uma evolução de um produto anterior chamado IPBox e daı́ até o nome da pasta que
contém a aplicação se ter mantido.
Outra caracterı́stica de funcionamento importantes é a forma como a aplicação submete as configurações. A IPBrick tem um motor de configuração que é responsável pela
geração e aplicação de configurações no sistema, assim como outras alterações necessárias
à configuração propriamente dita do sistema. Esta é uma caracterı́stica muito importante
neste trabalho, porque é a parte em que há mais modificações.
Na versão 4.3 há uma mistura do motor de configuração propriamente dito com a
aplicação vista pelo utilizador e a apresentação. Além disso, o acesso à base de dados é
feito de uma forma diversificada por ficheiros de acção, scripts e ficheiros de apresentação.
Os templates de configuração são scripts PHP e estão localizados na raı́z. Na raı́z
estão também localizados ficheiros de configuração geral da IPBrick.
Em relação ao funcionamento a IPBrick usa uma base de dados onde guarda todas a
configurações efectuadas. Após efectuar a confirmação de configurações, é executado um
script que gere a sequência de ordens a ser executadas no sistema.
É importante realçar este funcionamento da IPBrick: o facto de se fazer uma configuração determinada de um ou vários serviços e no final, para que as configurações
façam efeito, há a necessidade de submeter as definições. Isto demonstra a estrutura do
funcionamento da actual interface de configuração e é também este funcionamento que se
vai manter na nova versão. Apresenta-se na Figura 4.1 o explicado.
4.2
Nova Aplicação de Configuração
Na Figura 4.2 da página 35 apresenta-se o esquema da nova arquitectura. Pode-se
verificar que há uma clara separação entre a interface de gestão da configuração para o
interpretador, que representa o motor de configuração.
Na definição da nova arquitectura para a IPBrick é necessário ter em conta não só
as funcionalidades pretendidas por este projecto mas também as restantes caracterı́sticas
idealizadas para a nova versão 5 da IPBrick. Esta análise mais geral é necessária pois estáse a trabalhar na base e definir propriedades que vão ter influência em todo o sistema.
4.2 Nova Aplicação de Configuração
35
Figura 4.2: Abstracção da aplicação de configuração relativamente ao SO
Redefiniram-se então diversos parâmetros de modo a formar padões que servirão de
base para todo o novo desenvolvimento da IPBrick 5.
4.2.1
Camadas
O código do software IPBrick está dividido nas seguintes camadas:
• Gráfico
• Tratamento de dados e JavaScript
• Núcleo ou Dados e Base de dados
• Sistema Operativo
Gráfico
Esta camada é responsável unicamente pela aspecto gráfico da aplicação. Encontra-se
no nı́vel 4. É uma camada que não vai estar presente nos desenvolvimentos abrangidos
por esta dissertação.
Tratamento de Dados
Esta camada prepara, controla e passa os dados à camada gráfica. Encontra-se no
nı́vel 3.
JavaScript
Esta camada prepara, controla e passa os dados a camada gráfica em Java script/AJAX,
ou por outras palavras do lado do cliente. Encontra-se no nı́vel 3.
36
Arquitectura e Projecto da Aplicação
Núcleo ou Dados
Esta camada tem as funções, binários e scripts necessárias para interagir com o sistema
operativo e base de dados. Encontra-se no nı́vel 2.
Base de Dados
Esta camada tem as funções necessárias para aceder e consultar dados das base de
dados necessárias. Encontra-se no nı́vel 2.
Sistema Operativo
Esta camada é a base do sistema. Encontra-se no nı́vel 1.
4.2.2
Estrutura de Ficheiros
Esta arquitectura conduziu à seguinte estrutura de ficheiros:
Aplicação
/opt/ipbrick/temp
/opt/ipbrick/data
/opt/ipbrick/core
/opt/ipbrick/core/LIB
/opt/ipbrick/core/libs
/opt/ipbrick/core/lang
/opt/ipbrick/core/tpl
/opt/ipbrick/core/scripts
/opt/ipbrick/graphic
/opt/ipbrick/JS
/opt/ipbrick/PHP
/opt/ipbrick/site
/opt/ipbrick/log
/home1/_ipbrick/backupDB
/home1/_ipbrick/log
Outras: Desenvolvimento
~/public_html/work/ipbrick/Software/DEBIAN
~/public_html/work/ipbrick/Software/REDHAT
~/public_html/work/ipbrick/Software/UBUNTU
~/public_html/work/ipbrick/SQL
4.2 Nova Aplicação de Configuração
4.2.3
37
IPBrick Development Standards
Na restruturação do código tendo em vista as novas especificações e alterações, há a
necessidade de criar uma base de definições e padrões que garantam um desenvolvimento
coerente pela equipa de desenvolvimento actual e futura.
Existe portanto um documento nascido de uma reunião de ideias, necessidades e discussão, de padrões para o desenvolvimento da IPBrick. Este documento é actualizado no
decorrer desta implementação e é uma documentação essencial tendo em vista a evolução
e trabalho futuro deste software.
Este documento inclui basicamente os padrões e definições que este novo modelo agrega
e que se exemplifica de seguida:
Variáveis
Usar sempre nomes em inglês
Variável global
$_IPBRICK
$_IPBRICK["field"]["specific_var"]
exemplos:
$_IPBRICK["dbremote"]["srvipbrick"] = $dbsrvipbrick_remoto
Prefixos de Scripts
lst
view
act
ins
ins_act
mod
mod_act
del
del_act
Nomes dos Ficheiros Geradores de Configuração
As funç~
oes de export tem nomes padronizados da seguinte forma:
export_serviço_distribuiç~
ao
exemplo:
export_hosts_debian
tags para Templates de Configuração
Os templates de configuraç~
ao s~
ao apenasd e texto e cont^
em tags com nomes no seguinte formato:
38
Arquitectura e Projecto da Aplicação
Figura 4.3: Novo modelo de funcionamento para IPBrick 5
---nometag--exemplo:
---ipbrickhostname---
4.2.4
Serviços
Abstrair a IPBrick do sistema operativo base é abstrair cada serviço fornecido e configurável por ela. Assim faz sentido desenvolver este projecto seguindo essa mesma filosofia:
abordando serviço a serviço e trabalhando serviço a serviço.
As alterações necessárias vão ser realizadas mantendo a lógica funcional da versão 4.3.
A abordagem para conseguir que a aplicação se comportasse de forma a configurar
o sistema consoante o SO instalado foi reestruturar o código do motor configuração. A
consequência foi “partir” o código em funções e separar o quanto possı́vel funcionalidades, retirando as acções própriamente ditas desse script principal e agrupar as acções
em ficheiros, que serão chamados pelo script principal consoante as necessidades.
O que eram scripts mais extensos, que englobavam o processo de configuração total
do sistema passam a ser pequenos funções ou grupos de funções que ou são genéricos ou
chamam a especificidade necessária para o que estão destinados. Estas funções usam a
nova variável global que identifica o SO. O objectivo é poder, para cada ordem dada pelo
utilizador, assegurar que a função chamada é orientada ao SO instalado.
Para melhor esclarecer a abordagem, apresentam-se de seguida na Figura 4.3 o novo
modelo para a IPBrick 5, que se pode comparar com o modelo da versão 4.3 anteriormente
apresentado na Figura 4.1 da página 34.
4.3
O Pacote IPBrick
O pacote IPBrick inclui à aplicação de configuração e interface web. Este pacote além
de representar um dos blocos da IPBrick, é ainda a componente mais especı́fica deste
servidor integrado.
4.4 Gestão de Actualizações e Software
39
Instala todas as bases de dados que servem de base ao funcionamento da interface
de configuração de todos os serviços fornecidos pela IPBrick. São também instalados
os ficheiros da interface de configuração e todas as aplicações que vão integrados com a
IPBrick de base:
• Contacts (Gestão de contactos da IPBrick)
• Ibquota (gestão de quotas por utilizador)
• Horde (plataforma de webmail, calendário e gestão de contactos)
• Wcalendar (web agenda ADN calendar)
• myIPBrick (módulo de administração por utilizador da IPBrick)
É necessária a construção deste pacote que será incluido no processo de instalação da
IPBrick.
4.4
Gestão de Actualizações e Software
Para se conseguir o especificado em termos da actualização da IPBrick, é necessário
ter um motor de construção de pacotes que aborde genéricamente os pacotes IPBrick e
contemple a especificidade de cada distribuição de Linux.
Entre as três distribuições que se abordam, a gestão de pacotes é baseada na mesma
ferramenta (dpkg) no Debian e no Ubuntu, enquanto que no Red Hat é um sistema completamente diferente (rpm). Isto implica que a geração de pacotes tem que estar automatizada
de forma a criar a estrutura vocacionada para o sistema de destino ou pacotes genéricos
que contenham todos os ficheiros necessários a qualquer distribuição.
Nesta dissertação vai-se apenas analisar a estruturação para a criação de pacotes IPBrick, especificando o modelo utilizado, que vai ser utilizado para construir o pacote
IPBrick para Debian e Ubuntu.
Na construção de pacotes IPBrick distinguem-se três fases: pré-instalação, pós-instalação
e pós-remoção. Como o próprio nome indica e foi explicado no Capı́tulo 2, Secção 2.4.4,
estas diferentes partes referem-se às instruções a efectuar antes da instalação, depois da
instalação e depois da remoção de cada pacote. A instalação própriamente dita é gerida
automáticamente pelo dpkg (ou rpm no caso do Red Hat).
Apresentam-se de seguida, as diversas fases da instalação assim como a descrição das
tarefas caracterı́sticas de um pacote IPBrick, para cada uma.
4.4.1
Pré-instalação
A secção de pré-instalação deverá começar com um cabeçalho que contenha as caracterı́sticas do pacote, o seu nome, a sua versão, a descrição e variáveis IPBrick necessárias.
40
Arquitectura e Projecto da Aplicação
Deverá também conter uma verificação das dependências especı́ficas de pacotes IPBrick, assim como de conflitos. Uma verificação de dependências e conflitos já é utilizada
por omissão pelo proprio motor do dpkg. Esta é uma verificação extra para uma possivel
especificidade interna da IPBrick.
Outra secção presente na pré e também nos outros scripts de instalação é um conjunto
de variáveis e funções que são fixas. Elas vão ser responsáveis por diversas tarefas durante
o processo de instalação do pacote, como por exemplo, ligação à base de dados, obtenção
de variáveis, tratamento de dados, etc.
Outra secção que também está presente nos três scripts de instalação do pacote é a
secção de base de dados. Nesta secção são definidas as ordens a executar. Isto é: as
alterações pretendidas para as diversas fases da instalação. Nesta secção de pré-instalação
devem ser inseridas as modificações especı́ficas da aplicação ou serviço que o pacote inclui.
Esta secção de base de dados deve estar preparada para desfazer as alterações caso algum
erro ocorra, e é por este motivo que está nesta fase de pré-instalação.
4.4.2
Pós-instalação
O script de pós-instalação contém também a mesma parte de variáveis equivalente ao
de pré-instalação por uma questão de validação.
A secção de funções genéricas também é igual ou muito idêntica pois são funções
necessárias para as diversas partes do script.
Na secção de base de dados estão as instruções que guardam a confirmação da instalação. Para que fique o registo e a condição do pacote instalado.
4.4.3
Pós-remoção
No script de pós-remoção as secções são idênticas. Nele vão todas as tarefas a ser
executadas após a remoção de um pacote IPBrick.
4.5
Planeamento
Como a aplicação é complexa procurou-se definir e escalonar tarefas de forma a ser
exequı́vel de implementar e testar por patamares. Seguiu-se então a seguinte lista de
tarefas, que foi usada como plano de projecto:
• Instalar um computador com cada distribuição de Linux.
• Estudar e documentar as configurações dos serviços a disponibilizar para cada distribuição.
• Construir o procedimento automatizado de configuração, serviço a serviço.
• Instalar a versão anterior da aplicação de configuração da IPBrick (a 4.3) com updates
até ao 19.
4.6 Resumo
41
• Modificar o código da aplicação de configuração IPBrick para que esta esteja funcional nas novas versões de tecnologia que a suportam, assim como as modificações
que se definiram ser necessárias para a nova arquitectura.
• Configurar e construir um procedimento para automatizar a configuração de cada
um dos serviços.
• Testar geração e aplicação de configurações de serviços.
• Instalar as aplicações integradas de base na IPBrick. Adaptar estas às novas caracterı́sticas do software.
4.6
Resumo
Neste capı́tulo descreve-se o modelo a implementar para a satisfação dos requisitos
definidos para a aplicação de configuração da IPBrick 5.
É feita uma análise por partes para uma melhor compreensão das várias áreas de acção
e as definições feitas para cada uma.
Conclui-se este capı́tulo com um resumo dar tarefas definidas para a implementação.
42
Arquitectura e Projecto da Aplicação
Capı́tulo 5
Implementação
Neste capı́tulo apresenta-se a implementação da solução descrita no capı́tulo anterior
através de um exemplo: o servidor Web Apache.
5.1
Exemplo Serviço: Apache2
Este serviço tem a particularidade de ser um dos serviços com maiores alterações, pois
sofreu uma actualização fortı́ssima da versão 1.3 para a versão 2. Esta alteração exigiu
uma grande restruturação no código da IPBrick pois a filosofia de geração teve que ser
completamente remodelada.
O processo da submissão das configurações que se explica é da responsabilidade do
motor de configuração da IPBrick. Este motor tem um script principal chamado “actualização de definições” que vai gerir o processo, chamando outros scripts especı́ficos de
geração, aplicação e outras ordens ao sistema.
5.1.1
Actualização de Definições
Como foi já explicado, depois de fazer alterações na configuração do sistema é necessário
aplicar definições para que as alterações provoquem efeito. Quando o utilizador carrega em
actualizar definições é chamado o script actualiza_def que está dividido em três partes
fundamentais: geração, aplicação e reinı́cio de serviços.
Apresenta-se de seguida excerto exemplificativo de como este script vai chamar os
exemplificados antes para aplicara configuração:
<?
// GERAÇ~
AO
...
//**************************** Apache *******************************//
if (count($alterado_apache2)>0)
43
44
Implementação
{
include ("../include/apache/export_webserver.php");
if ($debian) export_apache2_debian ($socket_gcf, $dominio, $nome_serv, $ip_novo);
if ($ubuntu) export_apache2_ubuntu ($socket_gcf, $dominio, $nome_serv, $ip_novo);
if ($redhat) export_apache2_redhat ($socket_gcf, $dominio, $nome_serv, $ip_novo);
...
}
// APLICAÇ~
AO
if (count($alterado_apache2)>0)
{
include ("../include/apache/config_webserver.php");
if ($debian) apply_apache2_debian ($ipsocket);
if ($ubuntu) apply_apache2_ubuntu ($ipsocket);
if ($redhat) apply_apache2_redhat ($ipsocket);
}
// REINICIO DE SERVIÇOS
if (count($alterado_apache2)>0)
{
$ipsocket->IpSocket_Write("/etc/init.d/apache2 reload");
}
?>
Nas subsecções que se seguem descreve-se a implementação de cada uma das 3 partes
acima mencionada.
5.1.2
Script de Geração
A componente da geração dos ficheiros de configuração do Apache2 diz respeito à
configuração de virtualhosts, os quais podem ser criados, modificados e removidos através
da aplicação de configuração da IPBrick.
Apresentam-se excertos do código de forma a perceber-se a sua estrutura:
<?
function export_apache2_mainsites_debian ($socket, $domain, $servername, $int_ip)
{
//instruç~
oes necessárias para utilizar os templates e gerar os sites..
...
}
function export_apache2_mainsites_ubuntu ($socket, $domain, $servername, $int_ip)
{
export_apache2_mainsites_debian ($socket, $domain, $servername, $int_ip);
5.1 Exemplo Serviço: Apache2
45
}
function export_apache2_mainsites_redhat ($socket, $domain, $servername, $int_ip)
{
export_apache2_mainsites_debian ($socket, $domain, $servername, $int_ip);
}
?>
Como se pode verificar, a maneira de lidar com as configurações é idêntica para as três
distribuições.
5.1.3
Templates dos Sites Base da IPBrick
A IPBrick usa templates de configuração que na versão anterior eram compostos por
partes de texto e partes dinâmicas de PHP mas que, para a versão 5, se definiu serem completamente ficheiros de texto com tags que serão substituidas pelo motor de configuração
da IPBrick.
Estes templates são usados pelo script de geração para gerar os ficheiros de configuração
com as caracterı́sticas pretendidas.
Como exemplo apresenta-se um excerto do template de um dos sites base da IPBrick:
<VirtualHost *:443 >
ServerAdmin webadmin@---fullhostname--DocumentRoot ---ipbrickrootpath---site
ServerName ---fullhostname--ErrorLog ---ipbrickrootpath---log/apache/error.log
TransferLog ---ipbrickrootpath---log/apache/access.log
SSLEngine on
SSLCertificateFile /etc/apache2/apache.pem
Alias /ssh ---ipbrickrootpath---data/utilitarios/ssh
Alias /vnc-java ---ipbrickrootpath---data/utilitarios/vnc-java
Alias /awstatsicons /usr/share/awstats/icon
php_admin_value safe_mode 0
php_admin_value open_basedir none
php_admin_value upload_max_filesize 500M
php_admin_value post_max_size 500M
---setenvif--ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/
<Directory "/usr/lib/cgi-bin">
AllowOverride None
Options ExecCGI -MultiViews +SymLinksIfOwnerMatch
Order deny,allow
46
Implementação
---allowdeny--</Directory>
---aclrestrict--</VirtualHost>
5.1.4
Script de Aplicação
Este script é responsável por substituir a configuração existente no sistema, pela gerada pelo script de geração. Muitas vezes só é necessário copiar os ficheiros para locais
determinados, outras vezes é necessário realizar outras tarefas como alteração de variáveis,
modificação de outros ficheiros além dos gerados, alteração de permissões, etc.
Apresenta-se de seguida um exemplo da sua codificação:
<?
function apply_apache2_debian ($ipsocket)
{
// instruç~
oes necessária à aplicaç~
ao das configuraç~
oes
while(..) {
install_main_sitefiles ($ipsocket);
install_specific_sitefiles ($ipsocket, $idapache, $servername);
install_awstats ($ipsocket, $idapache, $servername);
}
}
function install_main_sitefiles ($ipsocket)
{
//copia sites principais
}
function install_specific_sitefiles ($ipsocket, $idapache, $servername)
{
// copia sites especificos
}
function install_awstats ($ipsocket, $idapache, $servername)
{
//copia estatisticas para o sitio respectivo.
}
?>
5.2 Construção do Pacote IPBrick
5.2
47
Construção do Pacote IPBrick
Como tarefa final apresenta-se o modo de criação do pacote IPBrick.
Primeiramente é necessário criar a estrutura de ficheiros desde a raiz. Depois trata-se
da compilação necessária dos ficheiros e definição das permissões adequadas para cada
ficheiro.
Após esta preparação é necessário criar os scripts de instalação.
No final obteremos uma estrutura como se indica de seguida:
/ipbrick_5_0/
/ipbrick_5_0/DEBIAN/
/ipbrick_5_0/DEBIAN/control
/ipbrick_5_0/DEBIAN/preinst
/ipbrick_5_0/DEBIAN/postinst
/ipbrick_5_0/opt
/ipbrick_5_0/opt/<...>
/ipbrick_5_0/...
Apresentam-se exemplos dos scripts de instalação no Anexo B
5.3
Testes
Neste projecto os testes foram efectuados repetidamente em cada fase do trabalho,
diversas vezes. Este é um trabalho de experimentação que exigiu uma verificação constante
a cada passo, cada definição e alteração de configuração que se realizaram.
Salienta-se que ao longo do tempo de desenvolvimento do projecto, efectuaram-se reuniões semanais nas quais se discutia mais as questões de projecto, sendo o restante tempo
dedicado à implementação e testes. Daı́ a relevância dos testes neste trabalho e a sua
constância.
Apresenta-se uma lista dos testes mais relevantes efectuados no Anexo A
5.4
Resumo
Este capı́tulo ilustrou o modelo de implementação da arquitectura definida anteriormente através dum exemplo: o serviço Web Apache.
Obviamente os pormenores da implementação variam de serviço para serviço, mas o
processo é suficientemente uniforme para poder ser aplicado a todos os serviços e tomar
em consideração o sistema operativo base instalado.
48
Implementação
Capı́tulo 6
Conclusões e Trabalho Futuro
O panorama a nı́vel de ferramentas integradas de administração de sistema para Linux
é diversificado. As soluções comerciais idênticas à IPBrick estão habitualmente dependentes de um hardware especı́fico. As caracterı́sticas de independência de hardware e uma
interface de configuração com uma clara separação entre uma configuração simples e uma
avançada, marcam uma diferença da IPBrick para outras soluções de administração de
sistema.
A IPBrick é muito mais que um sistema operativo. É um servidor integrado completo que tem alguns anos de desenvolvimento e que partiu das necessidades concretas de
empresas em todo o mundo. É um produto com caracterı́sticas próprias, em constante
desenvolvimento que está a ganhar popularidade em Portugal e pelo mundo, havendo cada
vez mais parcerias entre a iPortalMais e empresas estrangeiras.
Para a iPortalMais a IPBrick é uma base de desenvolvimento muito importante. Além
do valor do produto por si, é uma base de desenvolvimento para outros produtos que a
empresa fornece como é o caso do gestor documental iPortalDoc.
Ter a IPBrick disponı́vel em diversos sistemas operativos base surgiu da interacção
com diversas entidades empresariais. É uma ideia inovadora que poderá abrir novas oportunidades de negócio para a iPortalMais.
O projecto abordado nesta dissertação é parte de um projecto mais geral que é o
desenvolvimento da versão 5 da IPBrick em todas as suas áreas.
6.1
Trabalho Realizado
Neste projecto trabalhou-se essencialmente sobre a aplicação de configuração da IPBrick e a preparação desta para funcionar com três distribuições de Linux: Debian etch,
o Ubuntu Gutsy e Red Hat Enterprise Linux.
49
50
Conclusões e Trabalho Futuro
Primeiramente actualizaram-se os serviços para as versões pretendidas das três distribuições e estudou-se as diferenças de configuração para estas. Sendo este trabalho
desenvolvido em equipa.
Modificou-se a estrutura do código existente na versão 4.3 de forma a permitir uma
configuração adequada ao sistema operativo que estiver instalado de base. Desta modificação resultou uma maior separação do código em funções especı́ficas para cada sistema
operativo. O script responsável que incluı́a todas as instruções de submissão das aplicações
passou a ter um papel mais de gestão, sendo as acções propriamente ditas chamadas através
deste, consoante as necessidades do sistema instalado.
O desenvolvimento foi acompanhado de testes que permitiram o ajuste de configuração
e a confirmação do funcionamento desta ferramenta.
6.2
Trabalho Futuro
A IPBrick como servidor integrado completo é um produto para servir organizações.
Este trabalho originou uma abertura de portas a nı́vel de interacção com outras plataformas.
No seguimento desta maior abrangência da IPBrick há oportunidade de integrar ferramentas especı́ficas que apenas trabalham noutras plataformas.
Outro trabalho de interesse é utilizar os motores e procedimentos criados para inserir
outros sistemas operativos como o FreeBSD.
Estando a base da IPBrick preparada, há trabalho a fazer a outros nı́veis como a
nı́vel gráfico que tem estado em constante desenvolvimento. A utilização de AJAX é um
exemplo disso. O desenho da nova versão, com uma maior independência entre as diversas
camadas de desenvolvimento, facilitará essa evolução.
Anexo A
Testes
A.1
Serviços
Rede
IP
• Configurar IP numa placa de rede.
• Configurar IP um ou mais alias numa placa de rede.
• Configurar o mapeamento de interface fı́sicas em devices logicos.
• Configurar um interface por DHCP.
• Configurar uma ligação ADSL (pppoe).
Domı́nio
• Configurar o nome e domı́nio da maquina.
Rotas
• Rota por defeito.
• Configurar rotas de rede.
• Configurar rotas de serviços.
VPN
IPSEC
• Activar e parar o serviço.
• ipsec verify
51
52
Testes
• Estabelecer uma ligação VPN.
VPN SSL
• Activar e parar o serviço.
• Criar um certificado.
• Revogar um certificado.
• Estabelecer uma vpn com o servidor.
• Testar conectividade.
• Verificar configurações atribuidas dinamicamente: servidor de dns, servidor de netbios e rotas.
• Verificar ligações activas.
PPTP
• Activar e parar o serviço.
• Configurar um acesso.
• Estabelecer uma ligação VPN.
• Verificação se o servidor de WINS atribuido funciona.
• Verificação se o servidor de DNS atribuido funciona.
• Aceder a um share smb.
• Aceder a um site web.
SSH
• Acesso ao servidor unicamente com o utilizador operator.
• Verificação que não é possivel aceder com mais nenhum utilizador para alem do
operator.
Mail
Qmail
• Activar e parar o serviço.
• Envio de email para dominio local.
A.1 Serviços
53
• Envio de email para dominio remoto pertencendo a rede de relay.
• Envio de email para dominio remoto não pertencendo a rede de relay (com autenticação).
• Rotas por dns e por smtp.
• Verificação no MX do dominio de envio.
• Verificação do HELO.
• Tamanho maximo dos emails globalmente.
• Destinarios validos.
• Remetentes invalidos.
• Gerir fila de espera dos emails.
• Relay por dominio e por email.
• Alias de mails por utilizador.
• Forward de mails por utilizador.
• Quota de mails por utilizador.
• Respostas automaticas por utilizador.
• Tamanho maximo dos emails por utilizador.
• Activar e desactivar contas de mail.
• Configurar listas de distribuição de mail.
• Copia de email.
Fetchmail
• Activar e parar o serviço.
• Push mail de um servidor POP3 caixas individuais.
• Push mail de um servidor POP3 caixas de grupo.
• Push mail de um servidor IMAP caixas individuais.
• Push mail de um servidor IMAP caixas de grupo
• Push mail de um servidor APOP (testado unicamente a sintaxe).
54
Testes
Courier IMAP e POP
• Activar e parar os serviços.
• Configurar uma conta em IMAP e IMAPs.
• Configurar uma conta em POP e POPs.
• Gerir pastas e emails.
• Testar o envio e recepção de mails.
Webmail
• Gerir pastas e emails.
• Testar o envio e recepção de mails.
• Gerir os contactos.
• Configurar o servidor de IMAP e SMTP.
Gestão de utilizadores e maquinas
• Criar utilizadores no servidor local em varias areas de trabalho.
• Criar grupos.
• Criar maquinas.
• Criar grupos de maquinas.
• Criar utilizadores no servidor remoto em varias areas de trabalho.
• Testar quota de um utilizador local e remoto.
Servidor de ficheiros e dominio
Samba
• Activar e parar o serviço.
• Aceder aos shares sem ter a máquina no dominio.
• Criar shares nas varias areas de trabalho.
• Criar shares visiveis.
• Criar shares com reciclagem.
• Criar shares com acesso de leitura por utilizador.
A.1 Serviços
55
• Criar shares com acesso de leitura e escrita por utilizador.
• Criar shares com acesso de leitura por grupo.
• Criar shares com acesso de leitura e escrita por grupo.
• Testar autenticação nas partilhas com os utilizadores (partilhas criadas e partilhas
do utilizadores).
• Colocar uma maquina no dominio.
• Testar permissões do perfil.
• Testar mapeamento das drives das homes dos utilizadores.
• Testar perfil ambulante e local.
• Testar alterar a password a partir da estação cliente.
• Testar modo PDC (com domain logon).
• Testar modo BDC com e sem domain logon.
• Testar modo STANDALONE (sem domain logon).
• Testar a biometria.
Automount
• Verificar automontagem localmente.
• Verificar automontagem entre master/slave.
Proxy
SQUID
• Activar e parar o serviço.
• Testar acesso web em modo proxy padrão.
• Testar acesso web em modo proxy transparente.
• Testar acesso web em modo proxy com autenticação LDAP.
• Configuração de proxy remotos e dominios que não usam os proxy remotos.
• Configurar o numero de processos para filtragem.
• Activar e desactivar a cache do proxy.
56
Testes
• Modificar tamanho da cache.
• Modificar localização da cache.
• Configurar endereço para as actualizações das listas negras.
• Verificar que as actualizações estão a ser realizadas com sucesso.
• Configurar as listas de acesso (ACLs).
• Testar acesso web em modo proxy com autenticação NTLM.
• Testar com anti-virus para proxy (ICAP).
Frox
• Activar e parar o serviço.
• Testar o ftp em modo transparente.
Estatisticas
• Testar estatisticas globais do proxy.
• Testar estatisticas por maquinas do proxy.
• Testar estatisticas por utilizadores do proxy.
• Geração das estatisticas globais, por maquina e por utilizador na rotação dos logs.
• Geração das estatisticas globais, por maquina e por utilizador pelo cron.
LDAP
• Configuração do ldap em modo standalone.
• Administração dos dados do ldap em modo standalone.
• Configuração do ldap em modo slave.
FTP
• Activar e parar o serviço.
• Criar, modificar e apagar contas ftp nas diferentes areas de trabalho em modo escrita
e leitura.
• Criar, modificar e apagar contas ftp nas diferentes areas de trabalho em modo leitura.
• Gerir conta/acesso ftp de acesso aos sites web.
A.1 Serviços
57
HTTP
apache2
• Activar e parar o serviço.
• Configurar para disponibilizar o site da ipbrick na interface externa ou só na interface
interna.
• Gerir sites web disponiveis na internet.
• Gerir safe mode dos sites web.
• Gerir pastas que o php pode aceder dos sites web.
• Gerir endereços dos sites web.
• Gerir endereços alternativos dos sites web.
• Gerir email do administrador os sites web.
• Gerir conta/acesso ftp de acesso aos sites web.
• Gerir localização dos sites web.
• Gerir codificação dos sites web.
• Gerir url escrito no site.
• Gerir o protocolo de acesso aos sites web: http ou https.
• Gerir alias dos sites web.
• Gerir redireccionamentos dos sites web.
• Gerir proxy inverso dos sites web.
Estatı́sticas
• Testar estatisticas do sites.
• Geração das estatisticas dos sites na rotação dos logs.
• Geração das estatisticas dos sites pelo cron.
58
Testes
DNS
• Activar e parar o serviço.
• Configurar o servidor para resolver num servidor de dns local ou remoto.
• Configurar uma zona de resolução directa master.
• Configurar uma zona de resolução directa master.
• Configurar um nome (IN A e IN PTR).
• Configurar um alias (CNAME).
• Configurar um servidor de mail (IN MX).
• Configurar uma zona de resolução inversa slave.
• Configurar uma zona de resolução inversa slave.
• Configurar forwarders.
DHCP
• Activar e parar o serviço.
• Configurar intervalos de redes para atribuição de IP dinamicamente a maquinas
desconhecidas.
• Configurar maquinas conhecidas.
• Configurar o dhcp em varias interfaces de redes.
• Configurar o Dynamic DNS.
• Configurar master/slave dhcp.
Trafego
Firewall
• Activar e parar o serviço.
• Gerir novas regras.
• Bloquear msn.
A.2 Resumo
59
QOS
• Activar e desactivar Qos.
• Gerir novas regras.
• Configuração do url de actualizações do apt.
• Configuração das chaves conhecidas dos apt.
cron
• Geração das estatisticas do proxy e dos sites.
A.2
Resumo
Neste capitulo mostram-se os testes os testes mais relevantes efectuados ao longo deste
projecto.
60
Testes
Anexo B
Construção do Pacote IPBrick
B.1
control
Source: ipbrick
Section: admin
Priority: optional
Maintainer: Support IPBrick <[email protected]>
Package: ipbrick
Architecture: all
Pre-Depends:
Version: 5.0
Description: IPBrick v5.
B.2
preinst
#!/usr/bin/php
<?php
/////////////////////////////////////////////////////////////
//
Variaveis proprias deste patch
/////
/////////////////////////////////////////////////////////////
$idbugfixes="0000001";
$idbugfixesname="ipbrick";
$controlname="ipbrick";
$title=$idbugfixesname." - IPBrick";
$description="<br>
IPBrick.
<br>
";
$datestart="123456789";
$dateapply=time();
$version="5";
61
62
Construção do Pacote IPBrick
///////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
//
Verificaç~
ao da autenticidade deste script
/////
////////////////////////////////////////////////////////////////////////
$included_files = get_included_files();
if ($_SERVER["SCRIPT_FILENAME"]!="/var/lib/dpkg/tmp.ci/preinst" ||
$included_files[0]!="/var/lib/dpkg/tmp.ci/preinst" || count($included_files)!=1)
{
echo "ACCESS IS NOT ALLOWED!\r\n";
exit (1);
}
else
{
$_ipbrick_certificate_key = "xxxxxxxxxxxxxxxx";
}
////////////////////////////////////////////////////////
//
Dependencias e conflitos
///
////////////////////////////////////////////////////////
$predepends = array ();
$conflicts = array ();
///////////////////////////////////////////////////////////
//
Variaveis fixas dum patch
////
///////////////////////////////////////////////////////////
$dbhost="127.0.0.1";
$dbport="5433";
$dbname="ipbrick";
$dbuser="admin";
$dbpass="passadmin";
///////////////////////////////////////////////////////////
//////////////////////////////////////////////////////////
//
Funcoes genericas
////
//////////////////////////////////////////////////////////
function parseResultObj($resultado)
{
$n_rows = pg_numrows($resultado);
B.2 preinst
unset($entidades);
for($i=0; $i<$n_rows; $i++)
{
$entidades[$i]=pg_fetch_Object($resultado,$i);
}
return $entidades;
}
function exitwitherror()
{
global $dbconn;
@pg_close ($dbconn);
@pg_close ($dbconndefaultconf);
echo
echo
echo
exit
"\r\n";
"\r\n";
"\r\n";
(1);
}
/////////////////////////////////////////////////////////////////
//
Funç~
oes especı́ficas deste update
/////
/////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////
//
Patch codigo fixo
////////
////////////////////////////////////////////////////////////////
echo "\r\n";
echo "\r\n";
echo "\r\n";
//Codigo para verificar se ainda está dentro do periodo de actualizaç~
oes.
if (is_file (’erro_acesso2.php’))
{
...
if ($_key_ipbrick_version_info!="ipbrick-version-trial")
{
...
if ($key_expires_day<$datestart)
{
echo "Update period has expired!\r\n";
exit (1);
}
63
64
Construção do Pacote IPBrick
}
}
else
{
echo "IPBrick licence not found!\r\n";
exit (1);
}
//Liga a BD
$dbconn = @pg_connect ( ... );
if (!$dbconn)
{
echo "Unable connect to database! - 0x0001!\r\n";
echo "\r\n";
echo "\r\n";
echo "\r\n";
exit (1);
}
//Verifica se este patch é para a versao desta ipbrick
$query="select valor from ipbrickconfig where idipbrickconfig=2";
$resultado = @pg_exec($dbconn, $query);
if (!$resultado)
{
echo "Unable connect to database! - 0x0002!\r\n";
exitwitherror();
}
$versioncheck = parseResultObj ($resultado);
//Verifica em que vers~
oes pode ser aplicado
if ($versioncheck[0]->valor!= $version)
{
echo "This update isn’t for this version!\r\n";
exitwitherror();
}
//Verifica se este patch já foi instalado
$query="select * from bugfixes where idbugfixes=’".$idbugfixes."’";
$resultado = @pg_exec($dbconn, $query);
if (!$resultado)
{
echo "Unable connect to database! - 0x0003!\r\n";
exitwitherror();
}
B.2 preinst
65
$bugfixescheck = parseResultObj ($resultado);
if ($bugfixescheck[0]->idbugfixes==$idbugfixes)
{
echo "This update is already installed!\r\n";
exitwitherror();
}
$erropredepends = 0;
for ($i=0; $i<count($predepends); $i++)
{
$query = "select * from bugfixes where idbugfixes=’".$predepends[$i]->idbugfix."’";
$resultado = @pg_exec($dbconn, $query);
if (!$resultado)
{
echo "Unable connect to database! - 0x0004!\r\n";
exitwitherror();
}
$predependscheck = parseResultObj ($resultado);
if ($predependscheck[0]->idbugfixes!=$predepends[$i]->idbugfix)
{
echo $idbugfixesname." depends on ".$predepends[$i]->idbugfixname."!\r\n";
echo "However: Package ".$predepends[$i]->idbugfixname." is not installed.\r\n";
$erropredepends = 1;
}
}
if ($erropredepends!=0)
{
exitwitherror();
}
$erroconflicts = 0;
for ($i=0; $i<count($conflicts); $i++)
{
$query = "select * from bugfixes where idbugfixes=’".$conflicts[$i]->idbugfix."’";
$resultado = @pg_exec($dbconn, $query);
if (!$resultado)
{
echo "Unable connect to database! - 0x0005!\r\n";
exitwitherror();
}
$conflictscheck = parseResultObj ($resultado);
if ($conflictscheck[0]->idbugfixes==$conflicts[$i]->idbugfix)
{
66
Construção do Pacote IPBrick
echo $idbugfixesname." conflicts with ".$conflicts[$i]->idbugfixname.",
which is already installed!\r\n";
echo "Installation cancelled.";
$erroconflicts = 1;
}
}
if ($erroconflicts!=0)
{
exitwitherror();
}
//Cria base de dados temporaria para a migraç~
ao das configuraç~
oes predefinidas
...
//Liga a BD das configuraç~
oes predefinidas
$dbconndefaultconf = @pg_connect ( ...
);
if (!$dbconndefaultconf)
{
echo "Unable connect to database! - 0x0007!\r\n";
echo "\r\n";
echo "\r\n";
echo "\r\n";
exit (1);
}
////////////////////////////////////////////////////////////////////////////
//
BASE DE DADOS MYSQL
/////
////////////////////////////////////////////////////////////////////////////
///////////////////////////////////////////////////////////////////////////
//
BASE DE DADOS POSTGRESQL
/////
///////////////////////////////////////////////////////////////////////////
// cria base de dados da IPBrick
///////////////////////////////////////////////////////////////////////////
@pg_close ($dbconn);
@pg_close ($dbconndefaultconf);
echo "\r\n";
B.3 postinst
67
echo "\r\n";
echo "\r\n";
exit (0);
?>
B.3
postinst
Neste script apresenta-se a parte que difere do script de pré-instalação.
/////////////////////////////////////////////////////////////////////////////
//
BASE DE DADOS POSTGRESQL
////
/////////////////////////////////////////////////////////////////////////////
///////////////////////////////////////////////////////////////////////////
//Insere registo da instalacao deste patch
$bugfixes_query = "
insert into bugfixes (idbugfixes, title, description, datestart,
dateapply, version) values (’".$idbugfixes."’, ’".addslashes ($title)."’,
’".addslashes ($description)."’, ’".$datestart."’, ’".$dateapply."’, ’".$version."’)
";
$resultado = @pg_exec($dbconn, $bugfixes_query);
if (!$resultado)
{
echo "Error executing bugfixes query\r\n";
$erro=1;
}
$resultado = @pg_exec($dbconndefaultconf, $bugfixes_query);
if (!$resultado)
{
echo "Error executing bugfixes query\r\n";
$erro=1;
}
@pg_close ($dbconndefaultconf);
//actualiza o ficheiro de configuraç~
oes predefinida e apaga a base de dados temporaria.
...
68
Construção do Pacote IPBrick
////////////////////////////////////////
//Alteraç~
oes sistema
////////////////////////////////////////
/////////////////////////////////////////
// Restart dos serviços
/////////////////////////////////////////
echo "Update $idbugfixes was successfully installed!\r\n";
echo "<br>IPBrick successfully instaled.\r\n";
@pg_close ($dbconn);
echo
echo
echo
exit
?>
"\r\n";
"\r\n";
"\r\n";
(0);
Referências
[1] Philipp Hoschka. Multimodal web applications for embedded systems, Junho 2006.
http://www.w3.org/2005/Talks/200506-Toulouse/slide3-0.html.
[2] Lda. iPortalMais Soluções de Engenharia para Internet e Redes. Manual da ipbrick,
2008. http://www.ipbrick.com.
[3] openSuSE. Página oficial do YaST, Junho 2008. http://en.opensuse.org/YaST/
About.
[4] solucorp. Página Oficial do Linuxconf, 2005.
linuxconf/.
http://www.solucorp.qc.ca/
[5] Keith Pettit. Managing Services with Webmin, Outubro 2003. http://www.samag.
com/documents/s=8892/sam0310d/sam0310d.htm.
[6] Webmin. Página Oficial do Webmin, Junho 2008. http://www.webmin.com.
[7] PHP Documentation Group.
manual/en/.
Php manual, Junho 2008.
http://www.php.net/
[8] W3Schools. Introduction to javascript, Junho 2005. http://www.w3schools.com/
JS/js_intro.asp.
[9] Wikipedia, the free encyclopedia. Ajax (programming), Junho 2008. http://en.
wikipedia.org/wiki/Ajax_%28programming%29.
[10] Wikipedia, the free encyclopedia. Linux, Junho 2008. http://en.wikipedia.org/
wiki/Linux.
[11] Red Hat Inc. Aboute Red Hat Enterprise, 2008. http://www.redhat.com.
[12] Distrowatch, Junho 2005. http://distrowatch.com.
[13] Debian GNU/Linux. Página oficial da debian, 2008. http://www.debian.org.
69