Virtualiza˘c~ao da instala˘c~ao e con gura˘c~ao da IPBrick integral.pdfthe IPBrick, which is a...

Faculdade de Engenharia da Universidade do Porto

Virtualizacao da instalacao e

configuracao da IPBrick

Pedro Miguel Pereira Serra

Tese submetida no ambito do

Mestrado Integrado em Engenharia Electrotecnica e de Computadores

Major de Telecomunicacoes

Orientador: Pedro Souto (Professor Auxıliar)

Junho de 2008

c© Pedro Serra, 2008

Resumo

Este projecto enquadrou-se no desenvolvimento de uma nova versao da IPBrick, que euma distribuicao de Linux especıfica vocacionada para as necessidades das empresas. Temcomo especial foco a preparacao deste servidor integrado para usar diversas distribuicoesde Linux como sistema operativo de base, ao inves uma unica, a Debian, como acontecianas versoes anteriores. Esta nova IPBrick e um produto que permitira a iPortalMais atin-gir novos mercados que trabalham com diferentes plataformas de software.

Partindo da ultima versao disponıvel, alterou-se a aplicacao de configuracao IPBrick parauma nova arquitectura que permite a abstraccao do sistema operativo que a sustenta.Esta restruturacao significa que embora a IPBrick possa usar diferente sistemas oper-ativos, a configuracao do sistema e independente do sistema operativo instalado. Poroutras palavras, para o utilizador da IPBrick, o sistema operativo usado e transparente.

i

Abstract

This project was carried out in the context of the development of a new version ofthe 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 differentoperating 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 wasrewritten according to a new architecture that allows the abstraction of the operating sys-tem that supports it. This change on the IPBrick structure will allow the use of differentoperating systems as a base for IPBrick, while keeping the configuration the same for thefinal users, independently of the base operating system used.

iii

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

“Eu sei que tenho limite, so nao sei qual e.”

Carlos Braga

vii

Conteudo

1 Introducao 11.1 O que se Pretende? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Enquadramento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.3 Abordagem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.4 Estrutura da Dissertacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2 Plataformas Tecnologicas 52.1 IPBrick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.1.1 IPBrick.I . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.1.2 IPBrick.C . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.1.3 Analise Tecnica da IPBrick . . . . . . . . . . . . . . . . . . . . . . . 8

2.2 Outras Ferramentas de Administracao de Sistema . . . . . . . . . . . . . . . 112.2.1 YaST . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.2.2 Webmin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.2.3 cPanel e WebHost Manager . . . . . . . . . . . . . . . . . . . . . . . 142.2.4 DirectAdmin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.3 Interoperabilidade em Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . 152.4 Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.4.1 Red Hat Enterprise Linux . . . . . . . . . . . . . . . . . . . . . . . . 172.4.2 Debian . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182.4.3 Ubuntu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192.4.4 Comparacao entre Distribuicoes . . . . . . . . . . . . . . . . . . . . . 19

2.5 Programacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242.5.1 PHP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242.5.2 JavaScript . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252.5.3 AJAX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

2.6 Resumo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

3 Requisitos 293.1 Instalacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293.2 Servicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303.3 Interface e Base de Dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

3.3.1 Gestao de Pacotes e Actualizacoes . . . . . . . . . . . . . . . . . . . 303.4 Caracterısticas de Desenvolvimento da IPBrick 5 . . . . . . . . . . . . . . . 313.5 Resumo dos Requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

ix

x CONTEUDO

4 Arquitectura e Projecto da Aplicacao 334.1 Analise a IPBrick V4.3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334.2 Nova Aplicacao de Configuracao . . . . . . . . . . . . . . . . . . . . . . . . 34

4.2.1 Camadas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354.2.2 Estrutura de Ficheiros . . . . . . . . . . . . . . . . . . . . . . . . . . 364.2.3 IPBrick Development Standards . . . . . . . . . . . . . . . . . . . . 374.2.4 Servicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

4.3 O Pacote IPBrick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384.4 Gestao de Actualizacoes e Software . . . . . . . . . . . . . . . . . . . . . . . 39

4.4.1 Pre-instalacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394.4.2 Pos-instalacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 404.4.3 Pos-remocao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

4.5 Planeamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 404.6 Resumo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

5 Implementacao 435.1 Exemplo Servico: Apache2 . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

5.1.1 Actualizacao de Definicoes . . . . . . . . . . . . . . . . . . . . . . . . 435.1.2 Script de Geracao . . . . . . . . . . . . . . . . . . . . . . . . . . . . 445.1.3 Templates dos Sites Base da IPBrick . . . . . . . . . . . . . . . . . . 455.1.4 Script de Aplicacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

5.2 Construcao do Pacote IPBrick . . . . . . . . . . . . . . . . . . . . . . . . . . 475.3 Testes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 475.4 Resumo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

6 Conclusoes e Trabalho Futuro 496.1 Trabalho Realizado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 496.2 Trabalho Futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

A Testes 51A.1 Servicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51A.2 Resumo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

B Construcao do Pacote IPBrick 61B.1 control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61B.2 preinst . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61B.3 postinst . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

Referencias 69

Lista de Figuras

2.1 Configuracao da IPBrick.IC . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.2 IPBrick.IC como um servidor de Comunicacoes . . . . . . . . . . . . . . . . 82.3 Interface de configuracao da IPBrick.I: Listagem de utilizadores . . . . . . . 92.4 Interface de configuracao da IPBrick.C: Funcionalidade VoIP . . . . . . . . 102.5 Interface de configuracao da IPBrick: Configuracao avancada . . . . . . . . 112.6 Interface grafica do YaST . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.7 Interface grafica do Webmin . . . . . . . . . . . . . . . . . . . . . . . . . . . 142.8 Interface grafica do cPanel . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152.9 Interface grafica do DirectAdmin . . . . . . . . . . . . . . . . . . . . . . . . 162.10 Modelo de funcionamento do AJAX [1] . . . . . . . . . . . . . . . . . . . . . 26

4.1 Modelo de funcionamento da IPBrick 4.3 . . . . . . . . . . . . . . . . . . . . 344.2 Abstraccao da aplicacao de configuracao relativamente ao SO . . . . . . . . 354.3 Novo modelo de funcionamento para IPBrick 5 . . . . . . . . . . . . . . . . 38

xi

xii LISTA DE FIGURAS

Lista de Tabelas

2.1 Servicos da IPBrick.I . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.2 Servicos da IPBrick.C . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

xiii

xiv LISTA DE TABELAS

Abreviaturas e Sımbolos

AD: Active DirectoryAJAX: Asynchronous Javascript And XMLCOAS: Caldera OpenLinux Administration SoftwareCSS: Cascade Style SheetDHCP: Dynamic Host Configuration ProtocolDMZ: DeMilitarized ZoneDNS: Domain Name SystemFTP: File Transfer ProtocolGUI: Graphical User InterfaceHTML: HyperText Markup LanguageHTTP: HyperText Transfer ProtocolIDS: Intrusion Detection SystemIPSec: IP SecurityPAM’s: Pluggable Authentication ModulesPHP/FI: PHP Hypertext Preprocessor / Form InterpretorRPM: Red Hat Package ManagerSAM: System Administration ManagerSIP: Session Initiation ProtocolSMH: System Manager HomepageSO: Sistema OperativoSSL: Secure Sockets LayerSSH: Secure SHellTLS: Transport Layer SecurityVPN: Virtual Private NetworkVoIP: Voice over IPYaST: Yet another Setup Tool

xv

xvi ABREVIATURAS E SIMBOLOS

Capıtulo 1

Introducao

Na actualidade e uma tendencia as empresas estarem cada vez mais suportadas porplataformas informaticas de redes e de comunicacoes, onde a velocidade e seguranca saofactores importantes. A administracao de redes, a gestao dos seus recursos, impressoras,faxes, ficheiros, contas de e-mail, etc. sao ameacados por virus, worms e intrusoes quepoem em risco o sistema de informacao da empresa.

O trabalho consiste no desenvolvimento de uma nova versao da IPBrick que, pode dizer-se, e uma distribuicao de Linux especializada para as necessidades das empresas, com inter-face de configuracao simples integrada. E alias a sua aplicacao de configuracao integradauma das caracterıstica que a torna especial, possuindo uma organizacao propria e sepa-rando marcadamente configuracoes basicas do sistema das suas configuracoes avancadas.A IPBrick e um produto desenvolvido pela iPortalMais para satisfazer as necessidadesempresariais ao nivel de redes e comunicacoes.

1.1 O que se Pretende?

De forma generalizada, o que se pretende e que o servidor integrado IPBrick, queactualmente e baseado em Debian Linux, passe a estar disponıvel com diferentes sistemasoperativos de base, tambem de uma forma integrada. Isto e: tudo o que a IPBrick ecomo conceito deve estar preparado para ter qualquer sistema operativo como sua base,abstraindo a configuracao, instalacao e funcionamento, da especificidade que possa estarassociada a cada sistema.

Esta disponibilizacao de diversos sistemas operativos na IPBrick e uma caracteristicapretendida na nova versao da IPBrick: a IPBrick 5. No entanto esta dissertacao vaicingir-se ao trabalho realizado pelo autor, enquadrando o resto do desenvolvimento deuma forma mais generica para que este trabalho fique enquadrado no grande projecto quee o desenvolvimento da nova versao 5 da IPBrick.

1

2 Introducao

E de realcar tambem que o ponto de partida a nıvel quer teorico quer pratico e umaversao anterior de IPBrick: a versao 4.3.

1.2 Enquadramento

Este projecto foi desenvolvido na empresa iPortalMais - Solucoes de Engenharia paraInternet e Redes, Lda. Enquadra-se no ambito da cadeira de dissertacao do MestradoIntegrado de Engenharia Electrotecnica e de Computadores da Faculdade de Engenhariada Universidade do Porto. Teve inicio em Fevereiro de 2008 e com duracao de um semestre.

O autor ja tinha trabalhado na empresa anteriormente onde desenvolveu um projectorelacionado com a FEUP, o que facilitou a integracao e permitiu um pronto comeco doprojecto. O autor teve participacao activa no processo de desenvolvimento geral do pro-jecto da IPBrick 5 com maior responsabilidades na parte da aplicacao de configuracaoIPBrick.

1.3 Abordagem

Para se conseguir a abstraccao do SO pretendida e necessario uma abordagem bemestruturada que permita lidar com a complexidade do sistema e com a redefinicao da suaplataforma de desenvolvimento.

A abordagem seguida advem primeiramente das necessidades que se encontram paraa busca do objectivo principal. Por isso, logo a partida ha a necessidade de conhecer bemo sistema, o conceito de IPBick, os servicos que integra e a sua filosofia de funcionamento.Isto implica um estudo da IPBrick e tambem das tecnologias que esta envolve.

Outro estudo essencial e o dos sistemas operativos que se pretendem usar como base daIPbrick. Neste caso vao ser usadas tres distribuicoes: o Debian “etch”, o Ubuntu “Gutsy”e o Red Hat Enterprise Linux. E necessario estudar as suas caracterısticas e diferencasentre eles, abordando mais detalhadamente os pontos que tem mais influencia no projecto.

A IPBrick inclui um conjunto de servicos que no geral sao baseados em software livre.Esse software e habitualmente independente das distribuicoes utilizadas e requer tambemo estudo da sua configuracao. Mas essa independencia nao e sempre verificada, sendopor vezes ate uma marca de uma determinada distribuicao de Linux a sua maneira decompilar e configurar um determinado servico. Alem disso, associada a cada versao deuma distribuicao, esta associada uma versao de um software. Logo isto implica possiveisnovas funcionalidades e diferentes configuracoes. E necessario entao estudar e documentarestas diferencas pois sao necesssarias para o motor da IPBrick.

Apos esse estudo que dara um enquadramento mais real das possibilidades de comoabstrair a configuracao e geracao da IPBrick do SO de base, proceder-se-a a redefinicaode especificacoes de uma forma mais detalhada e a um desenho de um prototipo a imple-mentar.

1.4 Estrutura da Dissertacao 3

Finalmente realiza-se a implementacao propriamente dita de um prototipo que de-vera cumprir o requisitos definidos. Todo este processo sera acompanhado por testes queconfirmarao as alteracoes efectuadas.

1.4 Estrutura da Dissertacao

Este relatorio pretende apresentar o trabalho do autor na iPortalMais. Por isso a adescricao e mais pormenorizada nas areas da responsabilidade do autor, como e o casodo processo de actualizacao do software para as versoes adequadas e a aplicacao de con-figuracao da IPBrick No entanto nao pode deixar de descrever partes que foram partic-ipadas de forma menos pormenorizada mas que sao essenciais para a compreensao doprojecto na sua globalidade.

Para alem deste capıtulo, esta dissertacao contem mais 5 capıtulos. No Capıtulo 2,sao apresentadas as tecnologias relacionadas com este projecto destacando-se o estudo daIPBrick de forma mais tecnica, assim como as diversas distribuicoes de Linux que seraoincluidas neste projecto. No Capıtulo 3 definem-se os requisitos que se pretendem imple-mentar. No Capıtulo 4 descreve-se o projecto do trabalho a implementar. No Capıtulo 5apresenta-se o metodo de implementacao e um exemplo do trabalho pratico desenvolvido.No Capıtulo 6 faz-se uma avaliacao do trabalho realizado de forma conclusiva assim comoo trabalho futuro.

4 Introducao

Capıtulo 2

Plataformas Tecnologicas

O desafio que este trabalho levanta e melhorar uma ferramenta que utiliza um conjuntode tecnologias que e necessario compreender bem. Por esse motivo, este capıtulo comecacom uma analise comlpeta da IPBrick desde os servicos fornecidos ate a uma analisemais tecnica. Depois disso apresenta-se uma analise de ferramentas de administracaoexistentes de forma a fazer um enquadramento dos desenvolvimentos que existem a nıvelde configuracao, especialmente nas caracterısticas que se procuram para esta nova versaoda IPbrick, como sao a busca de uma configuracao integrada, independencia do SO einteroperabilidade com Linux. A ultima seccao do capıtulo faz uma apresentacao de Linuxe uma analise das suas caracterısticas que terao importancia neste projecto. Sao tambemestudadas as tres distribuicoes de Linux que vao ser usadas neste projecto.

Por ultimo faz-se uma apresentacao das linguagens de programacao mais importantesno desenvolvimento da IPBrick e analisa-se a sua influencia 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 umainterface de gestao funcional com acesso via web, que permite efectuar a sua configuracaosem que o seu administrador possua conhecimentos profundos de Linux ou mesmo de redese servicos. Para alem da interface funcional, a IPBrick tem ainda uma interface avancada,a partir da qual um administrador de redes e sistemas tem acesso directo a todos os seusservicos, tais como DNS (Domain Name System), DHCP (Dynamic Host ConfigurationProtocol), LDAP (Lightweight Directory Access Protocol), servidor de correio electronico,servidor de ficheiros, gestor de projectos, VPN (Virtual Private Network) server, firewallentre outros.

5

6 Plataformas Tecnologicas

Figura 2.1: Configuracao da IPBrick.IC

A IPBrick e um sistema operativo para gestao de redes com administracao simples efuncional, devido a sua interface grafica GUI (Graphical User Interface - Interface Graficado Utilizador). Desta forma, as empresas nao dependem mais de peritos informaticos paramanter a espinha dorsal do negocio em funcionamento com elevada disponibilidade.

A IPBrick estabelece um padrao de estabilidade e seguranca na transferencia de dados.Como o centro de todo o trabalho colaborativo, pode ligar-se atraves do MS Outlook ouatraves de um web browser. A tecnologia baseada em Linux garante confianca, velocidade eeficiencia nas transferencias de dados. Com a integracao do antivırus Kaspersky minimiza-se o risco de perda da integridade dos dados.

Todas as configuracoes sao preservadas, gravando-se inclusive a data e hora das mesmaspara permitir a recuperacao de qualquer configuracao [2].

2.1.1 IPBrick.I

A IPBrick.I disponibiliza todos os servicos necessarios de um servidor de Internet.IPBrick.I pode ser o servidor de e-mail, ficheiros, domınio, fax, impressao e de backup.Para alem do calendario/agenda partilhados e gestor de contactos (sincronizados via MSOutlook ou browser web), e possıvel gerir todos os projectos da empresa de um pontocentral.

IPBrick.I integra-se facilmente com servico de directorio. Em termos de escalabilidadeoferece um conceito master/slave baseado em LDAP e MS Active Directory (AD).

O servidor de Intranet IPBrick.I pode ser utilizado em tres modos diferentes:master, slave e AD client. Consequentemente os utilizadores da IPBrick, grupos e dis-positivos [terminais e telefones SIP (Session Initiation Protocol)] podem ser definidos naIPBrick ou no Windows AD (Active Directory). Na Intranet, a tecnologia IPBrick e capazde funcionar num ambiente totalmente IPBrick ou integrada com sistemas Windows [2].

A IPBrick.I disponibiliza o seguinte conjunto de servicos, sendo estes apresentados naTabela 2.1:

2.1 IPBrick 7

Tabela 2.1: Servicos da IPBrick.IServicosServidor de areas de trabalho individuais e de grupoServidor LDAP (gestao de maquinas, utilizadores e grupos)Servidor de Domınio (com roaming-profiles e centralized scripting)Servidor de correio electronicoServidor de impressorasServidor de base de dadosServidor de DHCP (Dynamic Host Configuration Protocol)Servidor de DNS (Dynamic Network Services)Servidor de imagens de estacoes de trabalhoServidor de Groupware (Calendario e Livro de Enderecos)Servidor de Backup (ARKEIA)Gestor de projectos (dotProject)Servicos OpcionaisKaspersky Anti-Malware

Correio Electronico (AntiVirus, AntiSpam)Servidor de ficheiros (AntiVirus)

Single sign-on (Autenticacao Biometrica)

2.1.2 IPBrick.C

A IPBrick.C garante a seguranca na transferencia de dados entre Intranet eInternet. Os dados transferidos (download and upload) sao filtrados, analisados e geri-dos pela IPBrick.C. Estas operacoes sao executadas pelos principais componentes daIPBrick.C: Mail-Relay, Servidor-Proxy, IDS (Intrusion Detection System), Antivırus eAntiSpam. A IPBrick.C controla todas as interfaces disponıveis para a Internet. O ob-jectivo da IPBrick.C e gerir as ligacoes da empresa com a Internet. Os servicos oferecidossao: servidor web, servidor FTP (File Transfer Protocol), VPN (Virtual Private Network)gateway e telefonia VoIP (voz sobre IP).

A tecnologia VPN nao so permite o fluxo de dados seguro mas tambem permite aescolha do espaco de trabalho conforme as necessidades. A IPBrick.C gere as ligacoes per-manentes entre diversos pontos atraves de tuneis IPSec (IP Security) assim como atravesde tuneis OpenSSL (Secure Sockets Layer e TLS Transport Layer Security) para ligacoes deconfianca. O correio electronico assim como o trafego web e continuamente filtrado atravesde regras configuraveis. Relatorios com estatısticas apresentam a informacao essencial emgraficos de interpretacao facil. Atraves do web mail podem ser geridos os e-mails de umaforma segura, mesmo que atraves 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 comunicacoes protegida pela firewall, ou mesmo como um servidorcompleto de comunicacoes e sistema de firewall integrado. A IPBrick.C pode importar osutilizadores, grupos e dispositivos (estacoes de trabalho e telefones SIP Session InitiationProtocol) de uma IPBrick.I ou de um sistema Windows AD. Isto significa que, instalando


Figura 2.2: IPBrick.IC como um servidor de Comunicacoes

a IPBrick.C como servidor de comunicacoes, nao e necessario redefinir as informacoes dosistema ja disponıveis no servidor de Intranet da empresa [2].

A IPBrick.C disponibiliza os seguintes servicos de empresa para a ligar a Internet,sendo estes representados na Tabela 2.2

Tabela 2.2: Servicos da IPBrick.CServicosRelay de correio electronicowebmailServidor webServidor Proxy (HTTP, HTTPS, FTP com estatısticas)Traffic shapingPort security (packet based firewalling)IDS (Intrusion Detection System)Servidor de VoIP (RTP bases routing)Integracao transparente com PBX (ISDN E1/BRI e linhas analogicas)Servicos OpcionaisKaspersky Anti-Malware

Correio Electronico (AntiVirus, AntiSpam)Servidor de ficheiros (AntiVirus)

Integracao transparente com PBX (ISDN E1/BRI e linhas analogicas)

2.1.3 Analise Tecnica da IPBrick

Interface Grafica

A interface de configuracao de sistema da IPBrick foi desenhada para ser de facilutilizacao, com o objectivo de poder ser uma ferramenta de administracao utilizavel poralguem sem necessariamente conhecimentos informaticos profundos. No entanto nao deixade ser uma ferramenta muito extensiva em termos de configuracoes avancadas. Faz parte

2.1 IPBrick 9

Figura 2.3: Interface de configuracao da IPBrick.I: Listagem de utilizadores

da filosofia da IPBrick esta forte separacao entre uma configuracao basica, que pode sergerida de forma facil e com conhecimentos mınimos de administracao, e uma configuracaoavancada que permite aos utilizadores mais experientes personalizar o seu sistema a suamaneira.

A interface esta organizada por modulos, estando as funcionalidades de cada servicoseparadas consoante a sua funcao. Por exemplo o servico de correio electronico da IPBrick.Icontem configuracao de utilizadores enquanto na IPBrick.C ja contem a configuracao dafuncionalidade mail copy.

Sao apresentados na Figura 2.3 e na Figura 2.4 da pagina 10 exemplos da interface deconfiguracao para um servico de intranet e outro de comunicacoes, nas quais podemos vero diferente menu.

Seguidamente na Figura 2.5 da pagina 11 apresenta-se a interface com um exemplo deconfiguracao avancada, na qual se pode verificar a subdivisao do menu de configuracoesavancadas, assim como os servicos disponibilizados neste sub-menu.

Modo de Funcionamento

A IPBrick tem um modo de funcionamento proprio. As suas configuracoes sao efectu-adas atraves da interface de configuracao apresentada e guardadas numa base de dados.No final das modificacoes efectuadas, para que estas se tornem activas, e necessario fazeruma aplicacao de configuracoes. Ao efectuar essa aplicacao, o motor da IPBrick vai fazeruma analise ao modificado e encarrega-se de fazer todas as accoes necessarias para asmodificacoes realizadas. Por exemplo, dependendo da modificacao podem se necessarios,copia de ficheiros, modificacao de ficheiros, comeco ou paragem de servicos, etc.


Figura 2.4: Interface de configuracao da IPBrick.C: Funcionalidade VoIP

Organizacao

Analisando a nıvel mais tecnico, o que e entao a IPBrick? Esta questao pode serrespondida separando por camadas. A IPBrick e:

• I Sistema operativo base

• II Pacotes adicionados e modificados

• III Geracao de configuracoes

• IV Interface de gestao e base de dados

Parte-se de um sistema operativo base, complementa-se esse sistema com alteracao eadicao de software, formando um sistema operativo proprio IPBrick. As camadas III eIV pertencem a aplicacao de configuracao e estao interligadas e dependentes a nıvel deprogramacao.

Olhando esta estrutura por camadas pode-se dizer que o objectivo do projecto daIPBrick 5 e gerar a instalacao de I, II automaticamente a partir da definicao do que e umaIPBrick, depois construir a geracao dos ficheiros de configuracao para qualquer versaopartindo de um codigo comum.

Este objectivo implica que a separacao entre as camadas III e IV esteja bem definida,de forma a se poder trabalhar na camada III para que esta faca tambem a abstraccao dainterface de configuracao para o SO.

2.2 Outras Ferramentas de Administracao de Sistema 11

Figura 2.5: Interface de configuracao da IPBrick: Configuracao avancada

2.2 Outras Ferramentas de Administracao de Sistema

Nesta seccao faz-se uma analise a outras ferramentas de administracao de sistemasexistentes que se enquadram nas funcoes e servicos tambem fornecidos pela IPBrick. Estaanalise alem de procurar avaliar o enquadramento tecnologico da IPBrick comparada comos outros produtos disponıveis, procura avaliar os produtos existentes na caracterısticaespecıfica que a IPBrick procura com este projecto: a interoperabilidade em varios sistemasoperativos, mais propriamente entre distribuicoes de Linux.

Os sistemas operativos Linux estao ligados, desde a sua criacao, a utilizacao por partede pessoal especializado ou com fortes conhecimentos tecnicos. Hoje em dia o Linux estatambem virado para os utilizadores domesticos e evoluiu muito no sentido de permitiruma utilizacao por qualquer pessoa, mesmo sem formacao em computadores. No entanto,a administracao de um sistema operativo ou de uma rede de computadores e uma tarefaque pode ser muito complexa e exigir conhecimentos tecnicos profundos.

Muitos defendem que um verdadeiro administrador edita os ficheiros manualmente,mas a verdade e que as ferramentas que simplificam a configuracao sempre foram procu-radas e sempre tiveram porta aberta nos mercados. Varias ferramentas surgiram que tin-ham como objectivo facilitar a tarefa de administracao, das quais muitas desenvolveram-see continuam hoje em desenvolvimento mas muitas outras estagnaram e foram descontinu-adas. Isto pode dever-se a diversos factores, desde a grande evolucao em termos de ligacoesde Internet que transformaram a realidade de fornecimento de servicos, ate ao grande de-senvolvimento que se deu a nıvel grafico no mundo do Linux, proporcionando a criacaode interfaces graficas a ferramentas de configuracao de servicos. Apesar disso estes desen-volvimentos manifestaram-se mais em ferramentas especıficas e nao de uma administracao


integrada. A nıvel de Linux para servidores as opcoes que se desenvolveram foram mais anıvel comercial e vocacionados para administradores com formacao especıfica.

Um dos problemas dos administradores de sistemas sempre foi a diferenca entre asferramentas diferentes usadas para distribuicoes diferentes. O OpenLinux usa o COAS,a SuSE o YAST e o Red Hat usava o LinuxConf. Ha ainda outras ferramentas comuma filosofia diferente e baseadas numa interface web que nao estao ligadas a nenhumadistribuicao especıfica, mas cujos servicos estao mais vocacionados para uma determinadaarea.

Vai-se seguidamente averiguar o comportamento das mais relevantes.

2.2.1 YaST

“YaST is the most powerful installation and system management tool in theLinux environment. It is an open source project sponsored and actively devel-oped by Novell.” [3, About YaST]

Apesar desta afirmacao ser proveniente da pagina oficial do Yast, das ferramentas deconfiguracao estudadas o YaST e realmente das que tem mais funcionalidades e a maisevoluida.

O YaST “nasceu” em Janeiro de 1995. Comecou por ser escrito em C++ com GUI porum dos fundadores do SUSE: Thoamas Fehr, e Michael Andres. A primeira distribuicaodo YaST foi no entanto com o Slackware nesse mesmo ano. Um ano depois sai oficialmenteo YaST 0.53 no SUSE Linux 4.2.

E a ferramenta de instalacao e configuracao do openSUSE, do SUSE Linux Enter-prise e das distribuicoes de Linux baseadas em SUSE. E famoso por ser uma ferramentacompleta integrada de facil utilizacao mas principalmente por ter uma interface graficamuito atractiva. E uma ferramenta potente e permite uma personalizacao facil do sistemadurante e depois da instalacao.

O YaST tem um guia para a instalacao dividido em passos simples, que permitem adefinicao das configuracoes basicas. Permite tambem uma instalacao com mais detalhepara utilizadores com maior nıvel de conhecimento. Pode tambem configurar todo osistema desde hardware, a rede, servicos do sistema, definicoes de seguranca, etc. Umadiversidade de servicos podem ser alcancados atraves do YaST. YaST e alias o nome daferramenta inicialmente criada sendo YaST2 o nome da interface grafica.

Na Figura 2.6 da pagina 13 podemos ver a interface grafica do YaST2.Apresentam-se de seguida os servicos mais importantes do YaST:

• Gestao de actualizacoes: Instalar e remover pacotes de software, actualizacao on-line

• Gestao e configuracao de hardware

• Interface de configuracao: Edicao dos ficheiros de configuracao atraves de interfacegrafica facilitada ao servico

2.2 Outras Ferramentas de Administracao de Sistema 13

Figura 2.6: Interface grafica do YaST

• Ferramenta de particionamento de discos

• Configuracao de rede: DHCP servidor e cliente, ISDN, modem, placa de rede, host-name

• Servicos de rede: DNS, servidor HTTP, proxy, Samba, SSH, FTP

• Administracao de aplicacoes Novell

• Seguranca e utilizadores: Firewall, utilizadores, grupos, super utilizador, certificados

• Outros: Logs de sistema, configuracao de auto-instalacao, opcoes de inicializacao,colocar suporte.

Avaliando os foruns e lista de bugs desta ferramenta podemos verificar que algumasqueixas surgem mais a nıvel de velocidade e problemas de gestao de dependencias entrepacotes de software. Tem um historial de uma consideravel quantidade de bugs.

2.2.2 Webmin

O Webmin nasceu em 1997 pela mao de James Cameron. A sua criacao surgiu danecessidade de dar capacidade a utilizadores menos experientes para adicionar registosDNS atraves de uma interface web da empresa. Daı surgiu a ideia que um browser podiaservir para configurar muitos mais servicos e o Webmin desenvolveu-se [5].

Segundo a pagina web oficial [6]o Webmin funciona em mais de 40 distribuicoes in-cluindo (Red Hat, SuSE, Sun, Mac OSX, Mandrake e FreeBSD). E distribuıdo sob licencaBSD e por isso pode ser utilizado livremente para fins comerciais e nao comerciais.

Uma das vantagens do Webmin e ser uma aplicacao web, por isso precisa apenas deum navegador que lide com o HTML. Inclui tambem um mini servidor web proprio para


Figura 2.7: Interface grafica do Webmin

nao haver necessidade de ter um instalado ou nao estar dependente deste. Tem tambemconfiguracoes de seguranca que permitem uma utilizacao remota segura da aplicacao.

Podemos reparar na avancada e agradavel interface de configuracao do Webmin, naFigura 2.7.

Os servicos disponibilizados por esta aplicacao sao muito vastos, havendo tambemmodulos que sao desenvolvidos pela comunidade.

2.2.3 cPanel e WebHost Manager

O cPanel e o WHM (WebHost Manager) sao duas aplicacoes usadas em conjuntoformando uma ferramenta poderosa de controlo de web hosting servindo tanto clientescomo pessoal administrativo.

Estas duas aplicacoes disponibilizam:

• Interface grafica de configuracao baseada na web

• Separacao de servicos cliente / administrador

• Servidor de mail e webmail

• Administracao de domınios

• Administracao de servidor

• Instalacao automatica de aplicacoes

Apresenta-se tambem na figura 2.8 o aspecto da interface grafica do cPanel onde senotam diversos servicos disponibilizados para configuracao.

2.3 Interoperabilidade em Linux 15

Figura 2.8: Interface grafica do cPanel

2.2.4 DirectAdmin

O DirectAdmin e uma ferramenta em tudo identica ao cPanel junto com o WebHostManager. Muda a interface mas os servicos e a vocacao para servicos de web hosting saopraticamente equivalentes.

A aplicacao divide os servicos em quatro categorias:

• Gestao para utilizadores

• Gestao para administradores

• Gestao para revendedores

• Opcoes gerais

A interface grafica do DirectAdmin e apresentada na Figura 2.9 da pagina 16.

2.3 Interoperabilidade em Linux

A questao da interoperabilidade acompanha alias o cosmos do Linux desde ha muito. Aliberdade de criar versus a cooperacao no desenvolvimento capaz de servir todos, indepen-dentemente da sua especificidade, e um tema discutido e com algum trabalho desenvolvidocomo e o caso do LSB (Linux Standards Base). Existe alias muita discussao dentro desteprojecto apesar de ter evoluıdo com o apoio de algumas distribuicoes de Linux.

Esta questao e mencionada para se ter um enquadramento da situacao da interoper-abilidade e de como esta questao existe e e necessario ser desenvolvida dentro do mundo


Figura 2.9: Interface grafica do DirectAdmin

Linux. Este projecto destina-se especıficamente a IPBrick que e Linux e deve ter estaquestao presente.

Destaca-se que muitos projectos tinham como objectivo ou mais valia esta ambicao deinteroperabilidade, apesar desta questao estar longe de estar respondida e poucos acabampor fornecer essa interoperabilidade.

2.4 Linux

Linux e o termo geralmente usado para designar qualquer sistema operativo que utilizeo kernel Linux. Foi desenvolvido por Linus Torvalds, inspirado no sistema Minix. Oseu codigo fonte esta disponıvel sob licenca GPL para qualquer pessoa utilizar, estudar,modificar e distribuir de acordo com os termos da licenca.

Inicialmente desenvolvido e utilizado por grupos de entusiastas em computadores pes-soais, o sistema Linux passou a ter a colaboracao de grandes empresas, como a IBM, aSun Microsystems, a Hewlett-Packard, e a Novell [10].

Como foi referido, a IPBrick e uma distribuicao especıfica de Linux. Seguindo o ob-jectivo deste projecto, a IPbrick pretende ser Linux sem se restringir a uma distribuicao,mas idealmente a qualquer plataforma Linux como sua base. Daı a procura de estudar oque caracteriza as diferentes distribuicoes de Linux.

De forma geral podemos distinguir algumas caracterısticas que marcam habitualmenteas diferencas entre as diversas distribuicoes de linux:

• Gestao de actualizacoes: Todas as distribuicoes de Linux tem um ou outrometodo para distribuir ficheiros quer seja atraves de CD ou atraves de actualizacoesvia web. Uma usam binarios pre-compilados, outras os ficheiros com o codigo fonte,

2.4 Linux 17

outras ainda metodos diferentes com caracterısticas especıficas para cada. Muitasdistribuicoes usam o RPM ( Red Hat Package Manager ) e os debs, abreviaturausada para os pacotes de software da Debian.

Esta distincao entre a gestao de software das diversas distribuicoes e importantepor diversas questoes, das quais se destacam a compatibilidade e a disponibilidaderesultante da popularidade e consequente rapidez de desenvolvimento.

• Configuracao: Ainda que muitas vezes as diferencas sejam poucas, a localizacaodos ficheiros de configuracao diferem de distribuicao para distribuicao.

• Software: O software que e disponibilizado de base em cada versao tambem ediferente. Ainda que teoricamente se pode compilar qualquer software para qualquerdistribuicao, isso pode implicar um esforco consideravel. Algumas ferramentas saomesmo especıficas de algumas distribuicoes que muitas vezes marcam a diferenca.

• Comercializacao: Por norma o Linux e de codigo aberto e disponıvel para qualquerpessoa. Ha no entanto varias distribuicoes comerciais de base ou que se tornaramcomerciais, vocacionadas para empresas e com mais ou menos disponibilizacao deassistencia tecnica ou outros servicos.

Abordando o trabalho pratico a ser desenvolvido, apresentam-se seguidamente as tresdistribuicoes de Linux que vao ser utilizadas para a implementacao deste prototipo, procu-rando realcar as suas caracterısticas e especificidades que serao mais crıticas neste desen-volvimento.

2.4.1 Red Hat Enterprise Linux

O Red Hat Linux e uma das mais antigas e mais populares distribuicoes de Linux. Foifundado em 1994 por Bob Young e Marc Ewing. tem a sua sede em Raleigh, Carolina doNorte, nos Estados Unidos da America [11].

Originou o formato de pacotes de software RPM usado por muitas distribuicoes comoSuSE, Caldera, Mandrake. Esta inovacao foi um dos factores importantes da sua fama.

Inicialmente estavam disponıveis duas distribuicoes: uma livre e outra virada para omercado. Actualmente a escolha e entre o Fedora Core e o Red Hat Entrepise Linuxhavendo uma mais clara separacao entre a componente comercial e a distribuicao abertadesenvolvida pela comunidade.

O Red Hat Entrepise Linux e usado em milhoes de servidores em todo o mundo. Aversao actual e a 5, para a qual a Red Hat prometeu melhorias a nıvel de aplicacoesdisponıveis e certificacao destas, melhoramento e facilidade em virtualizacao e tambemem compatibilidade de hardware [11].

O Red Hat Enterprise Linux e famoso por ser certificado por enumeras empresas dehardware e software, dando a esta distribuicao o valor associado ao software livre e aconfianca de uma plataforma empresarial solida.


2.4.2 Debian

O Debian GNU/Linux foi anunciado em 1993. Ian Murdock, o seu fundador, visionoua criacao de um projecto nao comercial desenvolvido por centenas de voluntarios progra-madores nos tempos livres. Na altura a ideia parecia destinada ao fracasso pois os queacreditavam nela estavam em clara minoria relativamente aos cepticos. Mas a realidadefoi bem diferente. O Debian nao so sobreviveu como se desenvolveu com grande sucesso,transformando-se na maior distribuicao de Linux no espaco de uma decada. Alem dissotornou-se provavelmente na maior comunidade de software colaborativo de todos os tem-pos [12].

O sucesso da Debian pode ser avaliado pelos seguintes numeros: 20 000 pacotes de soft-ware compilados para 11 arquitecturas de processadores, e desenvolvido por mais de 1000programadores voluntarios e e responsavel por inspirar mais de 100 distribuicoes baseadasno Debian Linux, incluindo uma das mais famosas distribuicoes actuais: o Ubuntu [12].

O seu sistema de gestao de pacotes de software: APT, e um dos seus pontos fortes comoacontece com o Red Hat. Em termos de filosofia de desenvolvimento o Debian organiza-sede uma maneira especıfica. Existem tres ramificacoes de desenvolvimento:

• Stable (4.0) — Intitulada de etch. Ramificacao estavel.

• Testing (X.Y) — Intitulada de Lenny. Ramificacao com algum grau de estabilidademas que ainda exige mais testes.

• Unstable (Sid) — Ramificacao instavel. Ramificacao de desenvolvimento, onde eincluıdo software proposto com frequencia.

[13]

Estes diversos graus de estabilidade definidos no seu desenvolvimento dao-lhe car-acterısticas proprias. Por um lado e conhecida por ser uma distribuicao com elevadaestabilidade e e muito usada em servidores e sistemas que exigem alta fiabilidade. Poroutro lado essa estabilidade e conseguida por um processo de testes que exige tempo eesse tempo faz com que o Debian Linux, na sua versao stable nao esteja a par das ultimasversoes de software. Com este prejuızo, o Debian e conhecido como a distribuicao melhortestada e com menos bugs. outro senao desta demora e a falta de acompanhamento nodesenvolvimento, relativamente a evolucao do hardware.

Surgem ainda outras questoes desta organizacao de desenvolvimento. Devido a estru-tura fortemente democratizada surgiram algumas discussoes devido decisoes mais polemicas,que contribuıram de certa forma para alguma estagnacao e atraso no desenvolvimento,assim como “lutas” infindaveis entre programadores que nao contribuem para o desen-volvimento rapido do projecto.

2.4 Linux 19

2.4.3 Ubuntu

O Ubuntu nasceu em Setembro de 2004 atraves do multimilionario Sul Africano MarkShuttleworth. O projecto ganhou popularidade a uma velocidade fantastica, como naotinha acontecido com nenhum outro. Em pouco tempo existiam foruns de discussao cheiosde utilizadores e programadores ansiosos. Nos anos que se seguiram o Ubuntu tornou-se amias popular distribuicao de Linux e contribuiu muito para o desenvolvimento do Linuxfacil de utilizar e divulgacao do sistema operativo livre capaz de competir fortemente comqualquer solucao proprietaria [12].

O sucesso do Ubuntu deve-se a diversos factores. Primeiramente foi criado pelocarismatico multimilionario que foi o segundo turista espacial e um dos primeiros pro-gramadores ligados ao Debian. A sua empresa, a Canonical Ltd., e a financiadora desteprojecto que devido ao seu abastado fundador, distribuem gratuitamente CD’s para omundo inteiro. Alem do apoio, da estabilidade financeira e de meios, o Ubuntu criouuma forte base estrutural baseada na web com documentacao, wiki’s, um sistema de bug-reporting criativo, assim como uma abordagem profissional para os utilizadores finais.Com isto o Ubuntu conseguiu contornar os erros cometidos por outras distribuicoes eacelerar o seu processo de desenvolvimento [12].

Tecnicamente o Ubuntu e baseado na versao instavel do Debian: “Sid”, mas comalguns pacotes de destaque como o GNOME, Firefox e OpenOffice actualizados para asuas versoes mais recentes. Tem novas versoes tendencialmente de 6 em 6 meses comversoes ocasionais com suporte com updates de seguranca para 3 a 5 anos, denominadasLTS (Long Term Support). As versoes nao LTS sao suportadas ate 18 meses.

Outras caracterısticas que dao ao Ubuntu caracterısticas especiais sao o live CD comuma instalacao guiada e facilitada, assitencia na migracao para utilizadores de Windows,temas de ambiente de trabalho e suporte para as ultimas tecnologias de efeitos 3D cominstalacao simplificada de drivers proprietarios da ATI e NVIDIA.

Em termos de criticas ao Ubuntu podemos dizer que sao concentradas especialmentena sua relacao com software proprietario. Houve alguma polemica pela relacao da ultimaversao do Ubuntu com os drivers proprietarios. Esta questao alonga-se a outras aplicacoesproprietarias que sao suportadas pelo Ubuntu.

Em termos de gestao de pacotes de software, o Ubuntu e uma base Debian e por issousa o APT com backgroud do dpkg (Debian package).

2.4.4 Comparacao entre Distribuicoes

Apos apresentadas algumas caracterısticas sobre as tres distribuicoes que vao ser uti-lizadas neste projecto, vai-se proceder a uma analise mais comparativa entre elas.

Na verdade interessa detalhar bem estas diferencas para que se possa fazer uma inte-gracao correcta da instalacao e da aplicacao de configuracao independentemente de qualdistribuicao seja a base operacional da IPbrick. O que acabou de se afirmar e uma vez


mais o reforco do objectivo primordial deste projecto: preparar a IPBrick para ter diversossistemas operativos como base. Mais especıficamente varias distribuicoes de Linux comosistema operativo base.

Tendo em conta que duas das tres distribuicoes que vao ser usadas no prototipo desteprojecto sao o Debian e o Ubuntu, que sao de alguma forma similares devido ao Ubuntuser baseado em Debian, este estudo comparativo vai centrar-se mais entre o Debian e oRed Hat, sendo posteriormente feitas algumas consideracoes comparativas relativamenteao Ubuntu.

Gestao de Pacotes

No que diz respeito as diferencas entre distribuicoes de Linux, destaca-se e desenvolve-se um pouco mais a questao da gestao de software. Alem de ser uma das caracterısticasmais importantes na caracterizacao de uma distribuicao, pois contribui para a estabilidadedo sistema, a facilidade de actualizacao do sistema e integracao de novas ferramentas, etambem uma caracterıstica que e necessario estudar com detalhe para a implementacaodeste projecto.

Em Linux o software e distribuıdo em pacotes. Um pacote e um conjunto de ficheirose informacao sobre o software a ser instalado, com instrucoes para a sua instalacao, con-figuracao e remocao. Um pacote pode conter software diversificado desde aplicacoes maispopulares como processadores de texto ou programas de edicao de imagem, ate partesespecıficas do sistema operativo e actualizacoes. Hoje em dia as actualizacoes do sistemapara uma nova versao sao feitas atraves de pacotes. Outra grande vantagem dos pacotese que se trata de uma reorganizacao dos ficheiros, o que transforma milhares de ficheirosrelacionados em muito menos pacotes. Isto torna o processo de instalacao e gestao desoftware muito mais organizado e simples de lidar.

Mas ter uma organizacao simplificada e agradavel nao e suficiente para garantir umbom sistema de gestao de pacotes. O nucleo da questao esta em como gerir esta orga-nizacao. Como manter a ligacao e registo dos ficheiros e pacotes assim como a relacaoentre eles?

Entre as solucoes existentes ha duas maneiras de abordar a organizacao interna depacotes. Uns concentrar-se mais nos ficheiros que estao envolvidos no pacote, outrosconcentrar-se mais nas etapas do processo para instalacao dos pacotes vendo o pacotecomo um todo. Ambos tem a suas vantagens e desvantagens e o resultado final de qualquersistema de pacotes e uma mistura destas duas componentes procurando o melhor processopara lidar com estas questoes.

No enquadramento deste projecto ha dois sistemas diferentes. O RPM, usado pela RedHat e o APT (que tem o dpkg em mais baixo nıvel) pelas distribuicoes Debian e Ubuntu.

Uma das principais diferencas entre o Red Hat e o Debian e na gestao de pacotes.Alias esta e uma das mais notorias diferencas para um utilizador domestico de Linux, mas

2.4 Linux 21

para este projecto salta-se essa analise mais especıfica da visao do utilizador pois, paraeste, a configuracao da IPBrick deve ser unica e independente do SO.

As diferencas tecnicas entre os dois sistemas e clara, desde as regras de nomeacao ateao metodo de organizacao de ficheiros. Algumas vantagens e desvantagens sao atribuidasa cada um dos sistemas, se bem que a evolucao destes tendeu a corrigir esses problemas ehoje em dia sao ambos bastantes estaveis e completos, sendo mais adequados a ser usadoscada um para as distribuicoes para que estao preparados. Por este motivo pode dizer-seque as diferencas entre eles na actualidade e muito mais uma preferencia do utilizador doque por uma clara sobreposicao de um sobre o outro.

As caracterısticas tecnicas sao no entanto diferentes. No Red Hat as especificacoes deum pacote sao incluidas num ficheiro com sufixo .spec. Neste sao incluidas a informacaorelativa ao pacote assim como as instrucoes de instalacao, remocao, mas tambem as in-formacoes necessarias a construcao do proprio binario. Podem ser instalados varios pacotesa partir de uma so especificacao, ou seja, de um so ficheiro .spec. O ficheiro de especi-ficacoes tem uma nomeacao propria tendo que ter o nome do pacote a instalar. O seuconteudo esta dividido por seccoes cada uma com a sua funcao. Estas especificacoes saoas seguintes:

• Preambulo - Aqui vao definidas as caracterısticas do pacote, como o nome, versao,revisao, requisitos, etc. E aqui que estao os dados que sao apresentados quandoalguem pede informacoes sobre o pacote.

• Seccao de preparacao - Inclui as instrucoes de preparacao da construcao do pacote.Estas instrucoes sao executadas habitualmente antes da descompactacao da fonte.

• Seccao de construcao - Esta seccao contem todas as instrucoes necessarias paracompilar o codigo fonte.

• Seccao de instalacao - Contem as instrucoes relativas a instalacao.

• Scripts de instalacao - Pode conter instrucoes a serem executas antes ou depoisda instalacao, assim como antes ou depois da remocao.

• Seccao de verificacao - Nesta seccao estao definidas verificacoes extra alem dasque o sistema RPM faz por defeito.

• Seccao de limpeza - Pode ser incluıdo nesta seccao um script de limpeza. Apesarde ja ser efectuada uma limpeza pelo motor do RPM

• Lista de ficheiros - Esta seccao e muito importante. Define os ficheiros que opacote comporta assim como as suas permissoes. Esta lista tem que estar coerenteou a instalacao nao sera concluıda.


Nos pacotes .deb em vez de um ficheiro de especificacoes, existe uma pasta onde saoincluidos os ficheiros todos de instalacao. Estes ficheiros estao divididos por funcionalidade,existindo os seguintes:

• control - Script de controlo. Onde vao o nome, a versao, a listagem de dependencias,a descricao, etc.

• preinst - Script de pre instalacao. Sera executado antes da instalacao.

• postinst - Script a executar depois da instalacao

• prerm - Script de pre remocao. A executar antes de efectuara desinstalacao.

• postrm - Script de pos remocao. A executar no final da desinstalacao

A nomeacao standard tambem e diferente. No Debian o nome do pacote e do tiponome ver-rev arq.deb, onde nome e o nome da aplicacao, ver e a versao principal, reva revisao dentro desta versao e arq a arquitectura para o binario e destinado. No RedHat a nomeacao e nome-ver-rev.arq.rpm sendo o significado das abreviaturas identicos aoexplicado para os debs.

Software

Outra diferenca entre as distribuicoes de Linux em geral e o software que estas incluem.Para o nosso projecto e importante no sentido em que havera um repositorio base quesera o disponibilizado pela distribuicao respectiva. Posteriormente este repositorio seracompletado para passar a ser o repositorio IPBrick.

Ha que destacar a plataforma Debian que e conhecida por ter uma quantidade fora donormal de software disponıvel, enquanto que o Red Hat e mais limitado. O Ubuntu tema vantagem de ter a base Debian e recebe os mesmos “louros” que este, neste aspecto jaque ha grande compatibilidade entre eles.

A questao principal no que diz respeito ao enquadramento deste trabalho e a dasversoes usadas por cada uma das distribuicoes. O Ubuntu, como e baseado no Debianunstable, e o que tem o software mais recente. O Red Hat vem de seguida e o Debian porultimo. Isto nao significa obrigatoriamente uma grande alteracao em termos de estruturade ficheiros ou de configuracao. Depende das modificacoes que cada versao acarretar,ou mais propriamente as alteracoes entre as diferentes versoes que vao ser usadas pelasdiferentes distribuicoes usadas.

Por exemplo o servidor web Apache 2, que servira ao longo deste trabalho como servicoexemplo, tem as seguintes versoes nas tres distribuicoes 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 tres pode verificar-se que apesar das pequenas diferencas de versao desteservico, tem implicacoes no seu funcionamento.

Configuracoes

Enquanto que muitos servicos e aplicacoes sao bastante independentes da distribuicaoimplicando que a configuracao destes e identica para qualquer distribuicao, alguns servicosmais basicos sao habitualmente diferentes assim como as ferramentas de configuracao us-adas por cada. Estas diferencas acabam por ser uma marca importante de cada dis-tribuicao.

Neste aspecto de configuracao dos servicos basicos (nome da maquina, rede, grupose utilizadores) o Ubuntu e o Debian partilham as mesmas ferramentas de configuracao econsequentemente a mesma metodologia. O Red Hat precisa de uma configuracao difer-ente.

Noutros servicos e aplicacoes que vao de base em cada distribuicao temos duas situacoesdistintas. Uma e relativa a aplicacoes que estao bastante independentes do sistema e porisso a sua configuracao entre distribuicoes e identica. Outra e a especificidade que algumasaplicacoes ganham consoante a distribuicao em que estao incluidas.

Um exemplo desta ultima e o servidor web apache2. Enquanto que no Red Hat estese chama http e tem uma compilacao e organizacao de ficheiros de configuracao propria,no Debian e Ubuntu o servidor web chama-se apache2 e os seus ficheiros de configuracaoseguem uma organizacao diferente. Alem disso, a IPBrick utiliza os seus proprios modulose configuracoes de base que terao que ser incluidos. Apesar disso esta versao do apachee muito versatil e uma solucao pode passar por tentar aproximar as configuracoes, como risco de afastamento de uma caracterıstica da distribuicao. Para completar a exempli-ficacao resta dar um exemplo basico de um pormenor da configuracao: no Red Hat estadefinido no httpd.conf (ficheiro de configuracao principal) as portas que estao a receberligacoes enquanto que no Debian e no Ubuntu existe um ficheiro proprio ports.conf ondesao definidas. Mas em ambos os casos sao definidos da mesma forma:

#file ports.conf

Listen <porta1>

Listen <porta2>

Ubuntu

Nesta analise comparativa entre distribuicoes o Ubuntu foi ja referido relativamentea algumas caracterısticas, mas foi de certa forma deixado de parte. Isto porque as suascaracterısticas sao muito identicas ao Debian, sua distribuicao “mae”. Ha no entantoque realcar algumas caracterısticas que terao importancia quando da sua integracao nesteservidor integrado que e a IPBrick.


O Ubuntu, por ser baseado na ramificacao unstable do Debian, e a distribuicao queapresenta as versoes mais recentes dos pacotes incluıdos. Este factor a nıvel de integracaovai ser tao mais importante quanto maior for o salto entre as versoes. Alias esta e umatarefa essencial neste objectivo de integracao da IPbrick com varias distribuicoes de Linuxcomo SO de base: estudar essas diferencas e actuar consoante elas. Como exemplo, nasversoes usadas, temos alguns modulos configurados de forma diferente que terao que irde base no servidor web e uma configuracao diferente dos PAM’s, dois pormenores muitoimportantes sem os quais a IPBrick nao funcionara correctamente.

2.5 Programacao

2.5.1 PHP

PHP (PHP: Hypertext Preprocessor) e uma linguagem de script open source de usogeral, muito utilizada e especialmente preparada para o desenvolvimento de aplicacoesWeb. E embutıvel dentro do HTML.

A linguagem surgiu por volta de 1994, como um pacote de programas CGI criadospor Rasmus Lerdof, com o nome Personal Home Page Tools, para substituir um conjuntode scripts Perl que ele usava no desenvolvimento de sua pagina pessoal. Em 1997 foilancado o novo pacote da linguagem com o nome de PHP/FI, trazendo a ferramenta FormsInterpreter, um interpretador de comandos SQL. Mais tarde, Zeev Suraski desenvolveu oanalisador do PHP 3 que contava com o primeiro recurso de orientacao a objectos [7].

Caracterısticas:

• Velocidade e robustez

• Estruturacao e orientacao a objecto

• Portabilidade - independencia de plataforma - escreva uma vez e “corre” em qualquerlugar.

• Tipos gerados dinamicamente

• Sintaxe similar a Linguagem C/C++ e PERL

Em Junho de 2004 foi lancada a versao 5 do PHP, introduzindo um novo modelo deorientacao a objecto, como por exemplo:

• Reformulacao dos Construtores e adicao de Destructores

• Visibilidade de acesso

• Abstraccao de objecto

• Interfaces de objectos

2.5 Programacao 25

O tratamento de objectos do PHP foi completamente reescrito, permitindo um desem-penho melhor e mais vantagens. Enquanto na versao anterior era preciso muito esforcopara atender a orientacao a objectos e aos padroes de projectos (alguns nao eram possıveis),o PHP 5 veio para sanar essa deficiencia e facilitar a vida aos programadores.

A interface de configuracao da IPBrick e uma aplicacao PHP. Daı a importancia deexplorar esta tecnologia. Mas a influencia do PHP na IPBrick vai mais alem da maiscomum utilizacao para a aplicacao web. Esta ferramenta e explorada mais profundamentepara diversas tarefas a nıvel de interaccao com o sistema e em diversas tarefas de integracaocom outras aplicacoes.

Relativamente a utilizacao do PHP neste projecto, e necessario avaliar duas vertentes:

• Actualizacao: Na versao anterior da IPBrick usava-se o PHP 4.3. E necessario es-tudar as alteracoes e implicacoes na codificacao antiga assim como novas funcional-idades que se podem aproveitar.

• Nova estrutura: Como se vai utilizar e modificar o PHP 5 para construir a camadade abstraccao proposta, tornando a IPbrick funcional e idependente, com variossistemas operativos de base.

2.5.2 JavaScript

O JavaScript e uma linguagem de scripting utilizada em desenvolvimento web da opticado cliente. O seu nome oficial e ECMAScript, cujo desenvolvimento e mantido pela orga-nizacao 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 apare-ceu em todos os navegadores web da Netscape e da Microsoft desde 1996. Foi influenciadapor muitas linguagens e desenhada para se parecer com Java, so que mais facil para setrabalhar com ela [8].

Algumas caracterısticas de destaque:

• Desenhada para dar interactividade as paginas 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 tendencia a ser mais usadoe de forma mais complexa. Na versao da IPBrick da qual se parte para este projecto, oJavaScript e usado embebido no HTML com uma estrutura definida e e utilizado de umaforma bastante simplificada maioritariamente para validacao e popups de confirmacao.


Figura 2.10: Modelo de funcionamento do AJAX [1]

Relativamente a implementacao que se pretende para a nova versao, o JavaScriptde estar organizado de uma forma estruturada desde a organizacao de ficheiros ate aorganizacao do codigo. Isto enquadrado obviamente na arquitectura que se definir. Anıvel de interactividade com o sistema nao tera influencia visto que se esta a falar de umlinguagem que e interpretada no cliente, no navegador.

2.5.3 AJAX

AJAX (Asynchronous JavaScript And XML) e o uso sistematico de tecnologias, comoJavascript e XML, providas por navegadores web para tornar paginas mais interactivas como usuario, utilizando-se de solicitacoes assıncronas ao servidor. AJAX nao e somente umnovo modelo, e tambem uma iniciativa na construcao de aplicacoes web mais dinamicas ecriativas. AJAX nao e uma tecnologia, sao realmente varias tecnologias conhecidas juntas,cada uma fazendo sua parte, oferecendo novas funcionalidades e uma maior dinamica aspaginas e aplicacoes web [9].

E AJAX e uma ferramenta muito importante no desenvolvimento web actual, per-mitindo dar dinamismo e eficacia a utilizacao de paginas e aplicacoes web. Isto aconteceprincipalmente porque existem frameworks e bibliotecas de efeitos que facilitam a vida aosprogramadores. O modelo de funcionamento do AJAX e apresentado na Figura 2.10.

As primeiras inclusoes de AJAX na IPBrick foram feitas apenas recentemente, naotendo saıdo numa versao final comercializada com esta tecnologia. No entanto, tendoem conta a atitude da iPortalMais em estar na vanguarda tecnologica, adivinha-se umaIPBrick mais ao estilo AJAX num futuro proximo. Isto implica que a versao que se estaa desenvolver com este trabalho prepare esta inclusao, de acordo com a nova estrutura eos parametros que estao a ser estabelecidos.

2.6 Resumo 27

Relativamente a parte de abstraccao do SO, nao tera que haver preocupacoes nestaintegracao, pois estamos a falar de tecnologias que funcionam praticamente no lado docliente. Ao preparar a nova organizacao e necessario ter em conta que a utilizacao deAJAX vai exigir a inclusao de diversos scripts organizados de uma forma especıfica, assimcomo estarem com permissoes de acesso do browser. Um exemplo e apresentado de seguida:

/frameworks

/js

/ajax

/css

Neste exemplo de organizacao, mostram-se as diferentes componentes de uma estruturaAJAX onde /frameworks contem os ficheiros relativos as frameworks que se utilizarem, /jsinclui os scripts de JavaScript de efeitos, comportamentos, etc. e a pasta /ajax contemscripts que vao lidar com a base de dados e construir o XML necessario. A pasta /css jae utilizada e contem os CSS’s necessarios utilizados para apresentacao.

2.6 Resumo

Neste capıtulo fez-se uma introducao as tecnologias envolvidas mais importantes, queserao a base deste projecto.

Nesta altura da dissertacao ja se deve conseguir prever de que forma cada tecnologiavai influenciar o desenvolvimento deste projecto. Deve tambem ser possıvel ter uma ideiaclara do que e a IPBrick como conceito e conhecer a filosofia e modo de funcionamento daaplicacao de configuracao.

Foi apresentada uma seccao de outras solucoes de administracao de sistemas presentesno mercado, para se poder avaliar a posicao da IPBrick a nıvel tecnologico e compara-lacom outras solucoes existentes.

Outra seccao apresenta sucintamente algumas linguagens de programacao usadas e asua influencia no projecto.

Destaca-se ainda que foram apresentadas as tres distribuicoes que vao ser usadas para odesenvolvimento do prototipo da IPBrick 5. Destacou-se tambem os pontos que distinguemestas distribuicoes e as areas mais criticas de analise inter-distribuicao.

Capıtulo 3

Requisitos

Neste capıtulo vai-se fazer uma aproximacao ao problema a nıvel mais tecnico. Apre-senta-se aqui uma descricao geral do que se pretende implementar, separando por seccoesfuncionais. Cada uma dessas seccoes e analisada separadamente e daı resultarao os req-uisitos deste projecto como um todo. Um resumo dos requisitos sera apresentado no fimdo capıtulo com a especificacao dos que vao ser implementados pelo autor e que seraodesenvolvidos nos capıtulos seguintes desta dissertacao.

Pretende-se que a IPBrick seja configurada de forma independente do sistema operativobase. Na pratica, a IPBrick devera existir nao apenas com o Debian Linux como sistemaoperativo mas tambem com outras distribuicoes de Linux. Quer isso dizer que, quandose instala a IPBrick, devera poder-se escolher a distribuicao de Linux que queremos comosistema operativo.

Em termos de funcionamento nao devera haver alteracoes. Os servicos vigentes naversao 4.3 da aplicacao sao mantidos, assim como a aplicacao de configuracao que deveraser usada de forma unica pelo utilizador independentemente do SO de base. Isto implicaque a nova versao da IPBrick sera construıda sobre a versao actual, a versao 4.3.

A IPBrick 5 devera ter uma instalacao e configuracao de forma automatica com diversossistemas operativos a escolha. Mais propriamente varias distribuicoes de Linux a escolha,nomeadamente o Debian, Ubuntu ou Red Hat.

3.1 Instalacao

A IPBrick e distribuıda para os clientes e parceiros num DVD, o qual, quando inseridonum computador, devera efectuar toda a instalacao automatica apos escolhido o sistemaoperativo base pretendido.

29

30 Requisitos

No inıcio da instalacao deve ser ”perguntado”ao utilizador qual a distribuicao Linux ainstalar. A restante instalacao sera feita de forma automatica sendo o disco ejectado nocaso da instalacao ser bem sucedida.

Apos a finalizacao deste processo o computador requer um reinıcio do sistema, depoisdo qual estara instalado e funcional um sistema operativo IPBrick baseado na distribuicaoLinux escolhida e uma configuracao base padrao da IPBrick.

3.2 Servicos

Os servicos que a IPBrick inclui devem ser disponibilizados nas versoes que o novosistema operativo base dispoe.

Em caso de ser um servico que nao conste no repositorio de uma distribuicao, passa aser incluıdo no seccao “IPBrick” do repositorio.

Os servicos que a IPBrick tem que disponibilizar sao os disponibilizados na versaoanterior. Estes servicos foram apresentados na Tabela 2.1 e Tabela 2.2, no Capıtulo 2. Osservicos opcionais apresentados nao sao incluidos na implementacao deste prototipo.

3.3 Interface e Base de Dados

A interface de configuracao da IPBrick devera manter-se e ser independente do sistema.Alias, sera igual para qualquer sistema e comunicara com este sempre de forma igual.

A aplicacao de configuracao da IPBrick devera funcionar em PHP 5.

Neste fase do trabalho a abordagem limitar-se-a a garantir que a aplicacao e operacionalnos diferentes sistemas e nas actualizacoes que foram efectuadas. E necessario uma especialatencao para algumas tecnologias que sofreram uma maior actualizacao ou alteracao comoe o caso do PHP 5, que tem uma forte influencia no motor de configuracao da IPBrick esofreu alteracoes que implicam modificacao do codigo.

A nova versao incluira todo o desenvolvimento feito ate ao update 19 da versao 4.3.

3.3.1 Gestao de Pacotes e Actualizacoes

O sistema devera poder ser actualizado pela interface da IPbrick.

A IPBrick dispoe de uma interface de actualizacao que e um front-end para o gestorde actualizacoes do sistema operativo base instalado. Esta interface / front-end devemestar preparados para interagir com o gestor de actualizacoes adequado: dpkg no caso doDebian e Ubuntu, e RPM no caso de Red Hat.

As actualizacoes devem garantir a estabilidade do sistema assim como a estabilidadeda aplicacao de configuracao da IPBrick.

3.4 Caracterısticas de Desenvolvimento da IPBrick 5 31

3.4 Caracterısticas de Desenvolvimento da IPBrick 5

A nova versao da IPBrick devera ter as seguintes caracterısticas:

• Manter o conceito de IPBrick, equivalente a versao anterior.

• Ter um motor de criacao de um DVD com a IPBrick, contendo os diversos sistemasoperativos suportados

• Ter uma instalacao automatizada de todo o sistema com permissao para escolher osistema operativo que lhe servira de base.

• Ter um motor de criacao de pacotes de software, tendo este que suportar os diversossistemas disponibilizados pela IPBrick.

• Ter o repositorio actual da IPBrick/Debian actualizado para a nova versao estavel(etch) e construir uma estrutura de repositorios adequada para os diversos SO’stambem incluidos. Isto e: Ubuntu Gutsy e Red Hat Enterprise Linux.

• A aplicacao de configuracao IPBrick devera configurar qualquer servico e sistemaoperativo suportado de forma identica ao que acontecia com a versao anterior.

• A estrutura de desenvolvimento da IPBrick devera estar preparada de forma a quehaja uma abstraccao entre a configuracao de cada servico e o sistema operativo debase, para que a configuracao por parte do utilizador seja sempre a mesma indepen-dentemente do SO instalado.

• O repositorio da aplicacao de configuracao deve estar de forma a incluir uma sep-aracao clara da nova estrutura definida, assim como de toda a documentacao dedesenvolvimento 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 configuracao para tres distribuicoes deLinux de base: Debian etch, o Ubuntu Gutsy e Red Hat Enterprise Linux.

• A configuracao da IPBrick deve ser feita de forma igual pelo utilizador, independen-temente do sistema operativo que estiver como base.

• A IPBrick 5 e as aplicacoes que vao integradas de base deverao usar PHP 5

• Os servicos fornecidos pela IPBrick devem ser os mesmos que sao disponibilizadosna IPBrick 4.3.

32 Requisitos

• A interface web nao devera ser alterada. Deve manter o aspecto e funcionalidadesda IPBrick 4.3.

Capıtulo 4

Arquitectura e Projecto da

Aplicacao

Neste capıtulo apresenta-se a modelacao para o que se quer da IPBrick 5 assim comoa abordagem pratica seguida para satisfazer os requisitos definidos.

4.1 Analise a IPBrick V4.3

Comeca-se com uma analise da estrutura e modo de funcionamento da versao anteriorda IPBrick para se perceber o que e necessario alterar. Da-se tambem destaque aos pontosmais fracos da aplicacao para que se possa actuar nesses aspectos e corrigi-los.

A IPBrick 4.3 esta estruturada de uma forma integrada, sendo pouco clara a distincaoentre as varias camadas que a constituem.

A organizacao 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 organizacao propria da IPBrick. Nestaversao os ficheiros relativos a apresentacao estao na pasta include, dentro da qual estaoseparados por servicos e dentro destes encontram-se os ficheiros de apresentacao, assimcomo os de accao.

Esta versao apresenta algumas incoerencia notorias como a nomeacao dos ficheiros.Por exemplo os ficheiros .php de accoes, apresentam tanto nomes em ingles como em

33

34 Arquitectura e Projecto da Aplicacao

Figura 4.1: Modelo de funcionamento da IPBrick 4.3

portugues e sufixos que nao seguem um padrao. Isto e devido a origem da IPBrick, quee uma evolucao de um produto anterior chamado IPBox e daı ate o nome da pasta quecontem a aplicacao se ter mantido.

Outra caracterıstica de funcionamento importantes e a forma como a aplicacao sub-mete as configuracoes. A IPBrick tem um motor de configuracao que e responsavel pelageracao e aplicacao de configuracoes no sistema, assim como outras alteracoes necessariasa configuracao propriamente dita do sistema. Esta e uma caracterıstica muito importanteneste trabalho, porque e a parte em que ha mais modificacoes.

Na versao 4.3 ha uma mistura do motor de configuracao propriamente dito com aaplicacao vista pelo utilizador e a apresentacao. Alem disso, o acesso a base de dados efeito de uma forma diversificada por ficheiros de accao, scripts e ficheiros de apresentacao.

Os templates de configuracao sao scripts PHP e estao localizados na raız. Na raızestao tambem localizados ficheiros de configuracao geral da IPBrick.

Em relacao ao funcionamento a IPBrick usa uma base de dados onde guarda todas aconfiguracoes efectuadas. Apos efectuar a confirmacao de configuracoes, e executado umscript que gere a sequencia de ordens a ser executadas no sistema.

E importante realcar este funcionamento da IPBrick: o facto de se fazer uma con-figuracao determinada de um ou varios servicos e no final, para que as configuracoesfacam efeito, ha a necessidade de submeter as definicoes. Isto demonstra a estrutura dofuncionamento da actual interface de configuracao e e tambem este funcionamento que sevai manter na nova versao. Apresenta-se na Figura 4.1 o explicado.

4.2 Nova Aplicacao de Configuracao

Na Figura 4.2 da pagina 35 apresenta-se o esquema da nova arquitectura. Pode-severificar que ha uma clara separacao entre a interface de gestao da configuracao para ointerpretador, que representa o motor de configuracao.

Na definicao da nova arquitectura para a IPBrick e necessario ter em conta nao soas funcionalidades pretendidas por este projecto mas tambem as restantes caracterısticasidealizadas para a nova versao 5 da IPBrick. Esta analise mais geral e necessaria pois esta-se a trabalhar na base e definir propriedades que vao ter influencia em todo o sistema.

4.2 Nova Aplicacao de Configuracao 35

Figura 4.2: Abstraccao da aplicacao de configuracao relativamente ao SO

Redefiniram-se entao diversos parametros de modo a formar padoes que servirao debase para todo o novo desenvolvimento da IPBrick 5.

4.2.1 Camadas

O codigo do software IPBrick esta dividido nas seguintes camadas:

• Grafico

• Tratamento de dados e JavaScript

• Nucleo ou Dados e Base de dados

• Sistema Operativo

Grafico

Esta camada e responsavel unicamente pela aspecto grafico da aplicacao. Encontra-seno nıvel 4. E uma camada que nao vai estar presente nos desenvolvimentos abrangidospor esta dissertacao.

Tratamento de Dados

Esta camada prepara, controla e passa os dados a camada grafica. Encontra-se nonıvel 3.

JavaScript

Esta camada prepara, controla e passa os dados a camada grafica em Java script/AJAX,ou por outras palavras do lado do cliente. Encontra-se no nıvel 3.


Nucleo ou Dados

Esta camada tem as funcoes, binarios e scripts necessarias para interagir com o sistemaoperativo e base de dados. Encontra-se no nıvel 2.

Base de Dados

Esta camada tem as funcoes necessarias para aceder e consultar dados das base dedados necessarias. 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:

Aplicacao

/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 Aplicacao de Configuracao 37

4.2.3 IPBrick Development Standards

Na restruturacao do codigo tendo em vista as novas especificacoes e alteracoes, ha anecessidade de criar uma base de definicoes e padroes que garantam um desenvolvimentocoerente pela equipa de desenvolvimento actual e futura.

Existe portanto um documento nascido de uma reuniao de ideias, necessidades e dis-cussao, de padroes para o desenvolvimento da IPBrick. Este documento e actualizado nodecorrer desta implementacao e e uma documentacao essencial tendo em vista a evolucaoe trabalho futuro deste software.

Este documento inclui basicamente os padroes e definicoes que este novo modelo agregae que se exemplifica de seguida:

Variaveis

Usar sempre nomes em ingles

Variavel 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 Configuracao

As func~oes de export tem nomes padronizados da seguinte forma:

export_servico_distribuic~ao

exemplo:

export_hosts_debian

tags para Templates de Configuracao

Os templates de configurac~ao s~ao apenasd e texto e contem tags com nomes no seguinte formato:


Figura 4.3: Novo modelo de funcionamento para IPBrick 5

---nometag---

exemplo:

---ipbrickhostname---

4.2.4 Servicos

Abstrair a IPBrick do sistema operativo base e abstrair cada servico fornecido e con-figuravel por ela. Assim faz sentido desenvolver este projecto seguindo essa mesma filosofia:abordando servico a servico e trabalhando servico a servico.

As alteracoes necessarias vao ser realizadas mantendo a logica funcional da versao 4.3.A abordagem para conseguir que a aplicacao se comportasse de forma a configurar

o sistema consoante o SO instalado foi reestruturar o codigo do motor configuracao. Aconsequencia foi “partir” o codigo em funcoes e separar o quanto possıvel funcionali-dades, retirando as accoes propriamente ditas desse script principal e agrupar as accoesem ficheiros, que serao chamados pelo script principal consoante as necessidades.

O que eram scripts mais extensos, que englobavam o processo de configuracao totaldo sistema passam a ser pequenos funcoes ou grupos de funcoes que ou sao genericos ouchamam a especificidade necessaria para o que estao destinados. Estas funcoes usam anova variavel global que identifica o SO. O objectivo e poder, para cada ordem dada peloutilizador, assegurar que a funcao chamada e orientada ao SO instalado.

Para melhor esclarecer a abordagem, apresentam-se de seguida na Figura 4.3 o novomodelo para a IPBrick 5, que se pode comparar com o modelo da versao 4.3 anteriormenteapresentado na Figura 4.1 da pagina 34.

4.3 O Pacote IPBrick

O pacote IPBrick inclui a aplicacao de configuracao e interface web. Este pacote alemde representar um dos blocos da IPBrick, e ainda a componente mais especıfica desteservidor integrado.

4.4 Gestao de Actualizacoes e Software 39

Instala todas as bases de dados que servem de base ao funcionamento da interfacede configuracao de todos os servicos fornecidos pela IPBrick. Sao tambem instaladosos ficheiros da interface de configuracao e todas as aplicacoes que vao integrados com aIPBrick de base:

• Contacts (Gestao de contactos da IPBrick)

• Ibquota (gestao de quotas por utilizador)

• Horde (plataforma de webmail, calendario e gestao de contactos)

• Wcalendar (web agenda ADN calendar)

• myIPBrick (modulo de administracao por utilizador da IPBrick)

E necessaria a construcao deste pacote que sera incluido no processo de instalacao daIPBrick.

4.4 Gestao de Actualizacoes e Software

Para se conseguir o especificado em termos da actualizacao da IPBrick, e necessarioter um motor de construcao de pacotes que aborde genericamente os pacotes IPBrick econtemple a especificidade de cada distribuicao de Linux.

Entre as tres distribuicoes que se abordam, a gestao de pacotes e baseada na mesmaferramenta (dpkg) no Debian e no Ubuntu, enquanto que no Red Hat e um sistema comple-tamente diferente (rpm). Isto implica que a geracao de pacotes tem que estar automatizadade forma a criar a estrutura vocacionada para o sistema de destino ou pacotes genericosque contenham todos os ficheiros necessarios a qualquer distribuicao.

Nesta dissertacao vai-se apenas analisar a estruturacao para a criacao de pacotes IP-Brick, especificando o modelo utilizado, que vai ser utilizado para construir o pacoteIPBrick para Debian e Ubuntu.

Na construcao de pacotes IPBrick distinguem-se tres fases: pre-instalacao, pos-instalacaoe pos-remocao. Como o proprio nome indica e foi explicado no Capıtulo 2, Seccao 2.4.4,estas diferentes partes referem-se as instrucoes a efectuar antes da instalacao, depois dainstalacao e depois da remocao de cada pacote. A instalacao propriamente dita e geridaautomaticamente pelo dpkg (ou rpm no caso do Red Hat).

Apresentam-se de seguida, as diversas fases da instalacao assim como a descricao dastarefas caracterısticas de um pacote IPBrick, para cada uma.

4.4.1 Pre-instalacao

A seccao de pre-instalacao devera comecar com um cabecalho que contenha as carac-terısticas do pacote, o seu nome, a sua versao, a descricao e variaveis IPBrick necessarias.


Devera tambem conter uma verificacao das dependencias especıficas de pacotes IP-Brick, assim como de conflitos. Uma verificacao de dependencias e conflitos ja e utilizadapor omissao pelo proprio motor do dpkg. Esta e uma verificacao extra para uma possivelespecificidade interna da IPBrick.

Outra seccao presente na pre e tambem nos outros scripts de instalacao e um conjuntode variaveis e funcoes que sao fixas. Elas vao ser responsaveis por diversas tarefas duranteo processo de instalacao do pacote, como por exemplo, ligacao a base de dados, obtencaode variaveis, tratamento de dados, etc.

Outra seccao que tambem esta presente nos tres scripts de instalacao do pacote e aseccao de base de dados. Nesta seccao sao definidas as ordens a executar. Isto e: asalteracoes pretendidas para as diversas fases da instalacao. Nesta seccao de pre-instalacaodevem ser inseridas as modificacoes especıficas da aplicacao ou servico que o pacote inclui.Esta seccao de base de dados deve estar preparada para desfazer as alteracoes caso algumerro ocorra, e e por este motivo que esta nesta fase de pre-instalacao.

4.4.2 Pos-instalacao

O script de pos-instalacao contem tambem a mesma parte de variaveis equivalente aode pre-instalacao por uma questao de validacao.

A seccao de funcoes genericas tambem e igual ou muito identica pois sao funcoesnecessarias para as diversas partes do script.

Na seccao de base de dados estao as instrucoes que guardam a confirmacao da in-stalacao. Para que fique o registo e a condicao do pacote instalado.

4.4.3 Pos-remocao

No script de pos-remocao as seccoes sao identicas. Nele vao todas as tarefas a serexecutadas apos a remocao de um pacote IPBrick.

4.5 Planeamento

Como a aplicacao e complexa procurou-se definir e escalonar tarefas de forma a serexequıvel de implementar e testar por patamares. Seguiu-se entao a seguinte lista detarefas, que foi usada como plano de projecto:

• Instalar um computador com cada distribuicao de Linux.

• Estudar e documentar as configuracoes dos servicos a disponibilizar para cada dis-tribuicao.

• Construir o procedimento automatizado de configuracao, servico a servico.

• Instalar a versao anterior da aplicacao de configuracao da IPBrick (a 4.3) com updatesate ao 19.

4.6 Resumo 41

• Modificar o codigo da aplicacao de configuracao IPBrick para que esta esteja fun-cional nas novas versoes de tecnologia que a suportam, assim como as modificacoesque se definiram ser necessarias para a nova arquitectura.

• Configurar e construir um procedimento para automatizar a configuracao de cadaum dos servicos.

• Testar geracao e aplicacao de configuracoes de servicos.

• Instalar as aplicacoes integradas de base na IPBrick. Adaptar estas as novas carac-terısticas do software.

4.6 Resumo

Neste capıtulo descreve-se o modelo a implementar para a satisfacao dos requisitosdefinidos para a aplicacao de configuracao da IPBrick 5.

E feita uma analise por partes para uma melhor compreensao das varias areas de accaoe as definicoes feitas para cada uma.

Conclui-se este capıtulo com um resumo dar tarefas definidas para a implementacao.

Capıtulo 5

Implementacao

Neste capıtulo apresenta-se a implementacao da solucao descrita no capıtulo anterioratraves de um exemplo: o servidor Web Apache.

5.1 Exemplo Servico: Apache2

Este servico tem a particularidade de ser um dos servicos com maiores alteracoes, poissofreu uma actualizacao fortıssima da versao 1.3 para a versao 2. Esta alteracao exigiuuma grande restruturacao no codigo da IPBrick pois a filosofia de geracao teve que sercompletamente remodelada.

O processo da submissao das configuracoes que se explica e da responsabilidade domotor de configuracao da IPBrick. Este motor tem um script principal chamado “actu-alizacao de definicoes” que vai gerir o processo, chamando outros scripts especıficos degeracao, aplicacao e outras ordens ao sistema.

5.1.1 Actualizacao de Definicoes

Como foi ja explicado, depois de fazer alteracoes na configuracao do sistema e necessarioaplicar definicoes para que as alteracoes provoquem efeito. Quando o utilizador carrega emactualizar definicoes e chamado o script actualiza_def que esta dividido em tres partesfundamentais: geracao, aplicacao e reinıcio de servicos.

Apresenta-se de seguida excerto exemplificativo de como este script vai chamar osexemplificados antes para aplicara configuracao:

<?

// GERAC~AO

...

//**************************** Apache *******************************//

if (count($alterado_apache2)>0)

43

44 Implementacao

{

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


{

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 SERVICOS


{

$ipsocket->IpSocket_Write("/etc/init.d/apache2 reload");

}

?>

Nas subseccoes que se seguem descreve-se a implementacao de cada uma das 3 partesacima mencionada.

5.1.2 Script de Geracao

A componente da geracao dos ficheiros de configuracao do Apache2 diz respeito aconfiguracao de virtualhosts, os quais podem ser criados, modificados e removidos atravesda aplicacao de configuracao da IPBrick.

Apresentam-se excertos do codigo de forma a perceber-se a sua estrutura:

<?

function export_apache2_mainsites_debian ($socket, $domain, $servername, $int_ip)

{

//instruc~oes necessarias 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 Servico: 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 configuracoes e identica para as tresdistribuicoes.

5.1.3 Templates dos Sites Base da IPBrick

A IPBrick usa templates de configuracao que na versao anterior eram compostos porpartes de texto e partes dinamicas de PHP mas que, para a versao 5, se definiu serem com-pletamente ficheiros de texto com tags que serao substituidas pelo motor de configuracaoda IPBrick.

Estes templates sao usados pelo script de geracao para gerar os ficheiros de configuracaocom 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 Implementacao

---allowdeny---

</Directory>

---aclrestrict---

</VirtualHost>

5.1.4 Script de Aplicacao

Este script e responsavel por substituir a configuracao existente no sistema, pela ger-ada pelo script de geracao. Muitas vezes so e necessario copiar os ficheiros para locaisdeterminados, outras vezes e necessario realizar outras tarefas como alteracao de variaveis,modificacao de outros ficheiros alem dos gerados, alteracao de permissoes, etc.

Apresenta-se de seguida um exemplo da sua codificacao:

<?

function apply_apache2_debian ($ipsocket)

{

// instruc~oes necessaria 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 Construcao do Pacote IPBrick 47

5.2 Construcao do Pacote IPBrick

Como tarefa final apresenta-se o modo de criacao do pacote IPBrick.Primeiramente e necessario criar a estrutura de ficheiros desde a raiz. Depois trata-se

da compilacao necessaria dos ficheiros e definicao das permissoes adequadas para cadaficheiro.

Apos esta preparacao e necessario criar os scripts de instalacao.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 instalacao 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 experimentacao que exigiu uma verificacao constantea cada passo, cada definicao e alteracao de configuracao que se realizaram.

Salienta-se que ao longo do tempo de desenvolvimento do projecto, efectuaram-se re-unioes semanais nas quais se discutia mais as questoes de projecto, sendo o restante tempodedicado a implementacao e testes. Daı a relevancia dos testes neste trabalho e a suaconstancia.

Apresenta-se uma lista dos testes mais relevantes efectuados no Anexo A

5.4 Resumo

Este capıtulo ilustrou o modelo de implementacao da arquitectura definida anterior-mente atraves dum exemplo: o servico Web Apache.

Obviamente os pormenores da implementacao variam de servico para servico, mas oprocesso e suficientemente uniforme para poder ser aplicado a todos os servicos e tomarem consideracao o sistema operativo base instalado.

48 Implementacao

Capıtulo 6

Conclusoes e Trabalho Futuro

O panorama a nıvel de ferramentas integradas de administracao de sistema para Linuxe diversificado. As solucoes comerciais identicas a IPBrick estao habitualmente depen-dentes de um hardware especıfico. As caracterısticas de independencia de hardware e umainterface de configuracao com uma clara separacao entre uma configuracao simples e umaavancada, marcam uma diferenca da IPBrick para outras solucoes de administracao desistema.

A IPBrick e muito mais que um sistema operativo. E um servidor integrado com-pleto que tem alguns anos de desenvolvimento e que partiu das necessidades concretas deempresas em todo o mundo. E um produto com caracterısticas proprias, em constantedesenvolvimento que esta a ganhar popularidade em Portugal e pelo mundo, havendo cadavez mais parcerias entre a iPortalMais e empresas estrangeiras.

Para a iPortalMais a IPBrick e uma base de desenvolvimento muito importante. Alemdo valor do produto por si, e uma base de desenvolvimento para outros produtos que aempresa fornece como e o caso do gestor documental iPortalDoc.

Ter a IPBrick disponıvel em diversos sistemas operativos base surgiu da interaccaocom diversas entidades empresariais. E uma ideia inovadora que podera abrir novas opor-tunidades de negocio para a iPortalMais.

O projecto abordado nesta dissertacao e parte de um projecto mais geral que e odesenvolvimento da versao 5 da IPBrick em todas as suas areas.

6.1 Trabalho Realizado

Neste projecto trabalhou-se essencialmente sobre a aplicacao de configuracao da IP-Brick e a preparacao desta para funcionar com tres distribuicoes de Linux: Debian etch,o Ubuntu Gutsy e Red Hat Enterprise Linux.

49

50 Conclusoes e Trabalho Futuro

Primeiramente actualizaram-se os servicos para as versoes pretendidas das tres dis-tribuicoes e estudou-se as diferencas de configuracao para estas. Sendo este trabalhodesenvolvido em equipa.

Modificou-se a estrutura do codigo existente na versao 4.3 de forma a permitir umaconfiguracao adequada ao sistema operativo que estiver instalado de base. Desta modi-ficacao resultou uma maior separacao do codigo em funcoes especıficas para cada sistemaoperativo. O script responsavel que incluıa todas as instrucoes de submissao das aplicacoespassou a ter um papel mais de gestao, sendo as accoes propriamente ditas chamadas atravesdeste, consoante as necessidades do sistema instalado.

O desenvolvimento foi acompanhado de testes que permitiram o ajuste de configuracaoe a confirmacao do funcionamento desta ferramenta.

6.2 Trabalho Futuro

A IPBrick como servidor integrado completo e um produto para servir organizacoes.Este trabalho originou uma abertura de portas a nıvel de interaccao com outras platafor-mas.

No seguimento desta maior abrangencia da IPBrick ha oportunidade de integrar fer-ramentas especıficas que apenas trabalham noutras plataformas.

Outro trabalho de interesse e utilizar os motores e procedimentos criados para inseriroutros sistemas operativos como o FreeBSD.

Estando a base da IPBrick preparada, ha trabalho a fazer a outros nıveis como anıvel grafico que tem estado em constante desenvolvimento. A utilizacao de AJAX e umexemplo disso. O desenho da nova versao, com uma maior independencia entre as diversascamadas de desenvolvimento, facilitara essa evolucao.

Anexo A

Testes

A.1 Servicos

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 ligacao ADSL (pppoe).

Domınio

• Configurar o nome e domınio da maquina.

Rotas

• Rota por defeito.

• Configurar rotas de rede.

• Configurar rotas de servicos.

VPN

IPSEC

• Activar e parar o servico.

• ipsec verify

51

52 Testes

• Estabelecer uma ligacao VPN.

VPN SSL


• Criar um certificado.

• Revogar um certificado.

• Estabelecer uma vpn com o servidor.

• Testar conectividade.

• Verificar configuracoes atribuidas dinamicamente: servidor de dns, servidor de net-bios e rotas.

• Verificar ligacoes activas.

PPTP


• Configurar um acesso.

• Estabelecer uma ligacao VPN.

• Verificacao se o servidor de WINS atribuido funciona.

• Verificacao 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.

• Verificacao que nao e possivel aceder com mais nenhum utilizador para alem dooperator.

Mail

Qmail


• Envio de email para dominio local.

A.1 Servicos 53

• Envio de email para dominio remoto pertencendo a rede de relay.

• Envio de email para dominio remoto nao pertencendo a rede de relay (com auten-ticacao).

• Rotas por dns e por smtp.

• Verificacao no MX do dominio de envio.

• Verificacao 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 distribuicao de mail.

• Copia de email.

Fetchmail


• 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 servicos.

• Configurar uma conta em IMAP e IMAPs.

• Configurar uma conta em POP e POPs.

• Gerir pastas e emails.

• Testar o envio e recepcao de mails.

Webmail

• Gerir pastas e emails.

• Testar o envio e recepcao de mails.

• Gerir os contactos.

• Configurar o servidor de IMAP e SMTP.

Gestao 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


• Aceder aos shares sem ter a maquina 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 Servicos 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 autenticacao nas partilhas com os utilizadores (partilhas criadas e partilhasdo utilizadores).

• Colocar uma maquina no dominio.

• Testar permissoes do perfil.

• Testar mapeamento das drives das homes dos utilizadores.

• Testar perfil ambulante e local.

• Testar alterar a password a partir da estacao 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


• Testar acesso web em modo proxy padrao.

• Testar acesso web em modo proxy transparente.

• Testar acesso web em modo proxy com autenticacao LDAP.

• Configuracao de proxy remotos e dominios que nao 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 localizacao da cache.

• Configurar endereco para as actualizacoes das listas negras.

• Verificar que as actualizacoes estao a ser realizadas com sucesso.

• Configurar as listas de acesso (ACLs).

• Testar acesso web em modo proxy com autenticacao NTLM.

• Testar com anti-virus para proxy (ICAP).

Frox


• Testar o ftp em modo transparente.

Estatisticas

• Testar estatisticas globais do proxy.

• Testar estatisticas por maquinas do proxy.

• Testar estatisticas por utilizadores do proxy.

• Geracao das estatisticas globais, por maquina e por utilizador na rotacao dos logs.

• Geracao das estatisticas globais, por maquina e por utilizador pelo cron.

LDAP

• Configuracao do ldap em modo standalone.

• Administracao dos dados do ldap em modo standalone.

• Configuracao do ldap em modo slave.

FTP


• Criar, modificar e apagar contas ftp nas diferentes areas de trabalho em modo escritae 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 Servicos 57

HTTP

apache2


• Configurar para disponibilizar o site da ipbrick na interface externa ou so na interfaceinterna.

• Gerir sites web disponiveis na internet.

• Gerir safe mode dos sites web.

• Gerir pastas que o php pode aceder dos sites web.

• Gerir enderecos dos sites web.

• Gerir enderecos alternativos dos sites web.

• Gerir email do administrador os sites web.

• Gerir conta/acesso ftp de acesso aos sites web.

• Gerir localizacao dos sites web.

• Gerir codificacao 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.

• Geracao das estatisticas dos sites na rotacao dos logs.

• Geracao das estatisticas dos sites pelo cron.

58 Testes

DNS


• Configurar o servidor para resolver num servidor de dns local ou remoto.

• Configurar uma zona de resolucao directa master.

• Configurar uma zona de resolucao 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 resolucao inversa slave.

• Configurar uma zona de resolucao inversa slave.

• Configurar forwarders.

DHCP


• Configurar intervalos de redes para atribuicao de IP dinamicamente a maquinasdesconhecidas.

• Configurar maquinas conhecidas.

• Configurar o dhcp em varias interfaces de redes.

• Configurar o Dynamic DNS.

• Configurar master/slave dhcp.

Trafego

Firewall


• Gerir novas regras.

• Bloquear msn.

A.2 Resumo 59

QOS

• Activar e desactivar Qos.

• Gerir novas regras.

• Configuracao do url de actualizacoes do apt.

• Configuracao das chaves conhecidas dos apt.

cron

• Geracao das estatisticas do proxy e dos sites.

A.2 Resumo

Neste capitulo mostram-se os testes os testes mais relevantes efectuados ao longo desteprojecto.

60 Testes

Anexo B

Construcao 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 Construcao 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 63

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 "\r\n";

echo "\r\n";

echo "\r\n";

exit (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);

}


}

}

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)

{


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."’";


if (!$resultado)

{


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."’";


if (!$resultado)

{


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."’";


if (!$resultado)

{


exitwitherror();

}

$conflictscheck = parseResultObj ($resultado);

if ($conflictscheck[0]->idbugfixes==$conflicts[$i]->idbugfix)

{


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 "\r\n";

echo "\r\n";

echo "\r\n";

exit (1);

}

////////////////////////////////////////////////////////////////////////////

// BASE DE DADOS MYSQL /////

////////////////////////////////////////////////////////////////////////////

///////////////////////////////////////////////////////////////////////////

// BASE DE DADOS POSTGRESQL /////

///////////////////////////////////////////////////////////////////////////

// cria base de dados da IPBrick

///////////////////////////////////////////////////////////////////////////



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-instalacao.

/////////////////////////////////////////////////////////////////////////////

// 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;

}


//actualiza o ficheiro de configurac~oes predefinida e apaga a base de dados temporaria.

...


////////////////////////////////////////

//Alterac~oes sistema

////////////////////////////////////////

/////////////////////////////////////////

// Restart dos servicos

/////////////////////////////////////////

echo "Update $idbugfixes was successfully installed!\r\n";

echo "<br>IPBrick successfully instaled.\r\n";


echo "\r\n";

echo "\r\n";

echo "\r\n";

exit (0);

?>

Referencias

[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 Solucoes de Engenharia para Internet e Redes. Manual da ipbrick,2008. http://www.ipbrick.com.

[3] openSuSE. Pagina oficial do YaST, Junho 2008. http://en.opensuse.org/YaST/About.

[4] solucorp. Pagina Oficial do Linuxconf, 2005. http://www.solucorp.qc.ca/linuxconf/.

[5] Keith Pettit. Managing Services with Webmin, Outubro 2003. http://www.samag.com/documents/s=8892/sam0310d/sam0310d.htm.

[6] Webmin. Pagina Oficial do Webmin, Junho 2008. http://www.webmin.com.

[7] PHP Documentation Group. Php manual, Junho 2008. http://www.php.net/manual/en/.

[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. Pagina oficial da debian, 2008. http://www.debian.org.

69

Virtualiza˘c~ao da instala˘c~ao e con gura˘c~ao da IPBrick integral.pdfthe IPBrick, which is a...

Documents

Transcript of Virtualiza˘c~ao da instala˘c~ao e con gura˘c~ao da IPBrick integral.pdfthe IPBrick, which is a...