INTEGRAÇÃO DE UBUNTU LINUX EM AMBIENTES...
-
Upload
nguyenngoc -
Category
Documents
-
view
221 -
download
0
Transcript of INTEGRAÇÃO DE UBUNTU LINUX EM AMBIENTES...
UNIVERSIDADE DE LISBOA Faculdade de Ciências Departamento de Informática
INTEGRAÇÃO DE UBUNTU LINUX EM
AMBIENTES MICROSOFT
Susana Bela Vinhas Pereira
DISSERTAÇÃO
MESTRADO EM INFORMÁTICA
2013
UNIVERSIDADE DE LISBOA Faculdade de Ciências Departamento de Informática
INTEGRAÇÃO DE UBUNTU LINUX EM
AMBIENTES MICROSOFT
Susana Bela Vinhas Pereira
DISSERTAÇÃO
MESTRADO EM INFORMÁTICA
Trabalho orientado pelo Prof. Doutor Hugo Alexandre Tavares Miranda
e co-orientado por Engenheiro Gustavo Alberto Vouga de Carvalho Homem
2013
Agradecimentos
Esta tese representa a conclusão de mais um ciclo de vida cujos resultados não seriam
possíveis de alcançar sem a ajuda e o apoio de várias pessoas. É desta forma que
expresso a minha gratidão.
Em primeiro lugar quero agradecer à minha família por todo o apoio incondicional que
me deram durante a realização deste ciclo de estudos. Pai, Mãe, Paula e Lara obrigada
pelo apoio, pela partilha das alegrias e dos momentos menos bons que me ajudaram a
ultrapassar.
Em segundo lugar quero agradecer a um grande amigo, Diogo Cruchinho, pelo apoio e
ajuda na pesquisa de soluções para o desenvolvimento do estágio.
Em terceiro lugar quero agradecer a todos os meus amigos pela partilha de bons e
momentos menos bons. Obrigada pelo voto de confiança no meu projeto.
Em terceiro lugar, mas não menos importante, quero agradecer ao meu orientador,
Professor Hugo Miranda, pelo apoio e sobretudo paciência durante a realização da
minha tese. As suas sugestões contribuiram em larga escala para aumentar os meus
conhecimentos na realização de estágio e para trabalho futuro.
Em quarto lugar, quero agradecer à empresa Ângulo Sólido, especialmente ao meu co-
orientador Gustavo Homem, pelo conhecimento técnico transmitido e pelas discussões
construtivas que me permitiram evoluir profissionalmente.
Finalmente, e não menos importante, quero agradecer aos elementos da Unidade de
Informática da Faculdade de Ciências da Universidade de Lisboa pelo apoio dado
durante a realização desta tese.
“When we build, let us think that we build forever”. John Ruskin
i
Resumo
A constante procura por parte das empresas de soluções aplicacionais e de sistemas
com menor custo faz com que, cada vez mais, as empresas acabem por optar por
aplicações e sistemas de código aberto em detrimento de soluções proprietárias. Para
que estas soluções tenham algum sucesso no mercado empresarial é necessário que
muitas das aplicações sejam parametrizadas e adequadas a essa mesma realidade (tal
como já é feito em ambientes proprietários).
A missão da Ângulo Sólido é proporcionar às organizações portuguesas soluções
“chave na mão” que garantam a segurança, fiabilidade e interoperabilidade de
qualquer parque informático a um custo inferior ao dos seus concorrentes.
Para concretizar os objectivos acima descritos, a Ângulo Sólido optou por sistemas
abertos baseados em Linux.
Este relatório descreve o esforço de melhoria e a automatização de integração do
posto de trabalho Ubuntu em ambientes Microsoft realizado no âmbito do Projeto em
Informática. Devido à empresa ter optado por um sistema aberto, foi necessário
proceder a algumas alterações de modo a que fosse compatível com serviços
exclusivos em ambientes proprietários, de que é exemplo o tipo de autenticação usado
para iniciar sessões.
Com este objetivo em mente foi inicialmente explorada a forma de gerar um ambiente
de desenvolvimento (ao nível do servidor e das formas de empacotamento), de criação
e alteração de pacotes, parametrizando-os consoante as necessidades das organizações
clientes e que foram posteriormente certificados pela Ângulo Sólido e pelos seus
parceiros de negócio, de forma a garantir um comportamento fiável.
Palavras-chave: Ubuntu, código aberto, pacotes, parametrização, certificação
iii
Abstract
The constant search for more economical and flexible application solutions has
increased the number of companies that opt for open source systems as an alternative
to proprietary solutions. In order to open source solutions to succeed in the business
market, it is necessary for many applications to be parameterized and adapted to a
new reality, something that is common in proprietary environments.
The mission of Ângulo Sólido is to provide "turnkey" solution to organizations,
ensuring security, reliability and interoperability of any computer facilities at low cost
compared to its competitors.
Ângulo Sólido opted for the Ubuntu Linux distribution.
This document the efforts made to improve and automate the integration process
using Ubuntu 10.04 in Microsoft environments. Since the company has choosed to
use a open source system, it was necessary to make some changes to make the system
compatible with exclusive services in proprietary environments, such as the
authentication type used to logon.
For this purpose, it was first explored how to generate a development environment (at
the server level and forms of packaging) to create, modify and parameterize packages
according to the needs of clientes organizations. This tasks were certified by the
Ângulo Sólido and its business parterns to ensure a reliable system.
Keywords: Ubuntu, open source, packaging, parametrization, certification
v
Índice 1 Introdução ...................................................................................................................... 1 1.1 Motivação ........................................................................................................................... 1 1.2 Objectivos ........................................................................................................................... 1 1.3 Trabalho realizado .......................................................................................................... 2 1.4 Instituição de acolhimento ........................................................................................... 3 1.5 Planeamento ...................................................................................................................... 4
1.5.1 Tarefas realizadas ....................................................................................................................... 5 1.5.2 Sub-Tarefas de Implementação de Soluções ..................................................................... 5
1.6 Estrutura do documento ............................................................................................... 6 2 Sistema de pacotes Debian .......................................................................................... 8 2.1 Sistemas de Pacotes ........................................................................................................ 8 2.2 Sistema de Pacotes e o Projeto Debian ..................................................................... 9 2.3 Ambiente de geração de pacotes Debian – packaging ...................................... 10
2.3.1 Ferramentas de empacotamento ......................................................................................... 10 2.3.2 Processo de empacotamento ................................................................................................ 12
2.4 Resumo ............................................................................................................................. 19 3 Personalização de Pacotes ......................................................................................... 20 3.1 Ambiente para geração de pacote .deb do X11RDP .......................................... 20
3.1.1 Definição de X11RDP ........................................................................................................... 20 3.1.2 Geração do pacote ................................................................................................................... 20 3.1.3 Problemas e resolução ............................................................................................................ 20 3.1.4 Compilação e construção do pacote X11RDP ............................................................... 22 3.1.5 Teste de integração do pacote X11RDP .......................................................................... 22
3.2 Ambiente para geração de pacote .deb do XRDP ............................................... 23 3.2.1 Definição de XRDP ................................................................................................................ 23 3.2.2 Geração do pacote ................................................................................................................... 23 3.2.3 Problemas e resolução ............................................................................................................ 23 3.2.4 Compilação e construção do pacote XRDP .................................................................... 27 3.2.5 Testes de integração do pacote XRDP ............................................................................. 28
3.3 Ambiente para geração de pacote .deb Firefox e Samba ................................. 33 3.3.1 Definição de Firefox ............................................................................................................... 33 3.3.2 Definição de Samba ................................................................................................................ 34 3.3.3 Geração dos pacotes Firefox e Samba .............................................................................. 35 3.3.4 Problemas e resolução do pacote do Firefox ................................................................. 35 3.3.5 Problemas e resolução do pacote Samba ......................................................................... 37 3.3.6 Compilação e construção do pacote Samba .................................................................... 39 3.3.7 Teste de integração do Firefox ............................................................................................ 39 3.3.8 Teste de integração do Samba ............................................................................................. 40
3.4 Activar blacklist de pacotes ....................................................................................... 40 3.4.1 Definição de blacklist ............................................................................................................. 40 3.4.2 Problemas e resolução ............................................................................................................ 41 3.4.3 Teste da aplicação da blacklist ............................................................................................ 41
3.5 Pré-‐requisitos para administração remota automatizada ............................. 42 3.5.1 Definição de administração remota automatizada ........................................................ 42 3.5.2 Problemas e resolução ............................................................................................................ 42 3.5.3 Teste da implementação da administração remota automatizada ............................ 43
3.6 Testar integração com AD via winbind ................................................................. 43 3.6.1 Definição de Winbind ............................................................................................................ 43 3.6.2 Teste de integração com a AD via Winbind ................................................................... 43
4 Personalização de Postos de Trabalho e Servidores ........................................... 44
vi
4.1 Descrição ......................................................................................................................... 44 4.2 Instalação e operação de sistemas .......................................................................... 44
4.2.1 Instalação do Sistema ............................................................................................................. 45 4.2.2 Operação do sistema: configuração de perfis baseada em políticas ....................... 47 4.2.3 Administração remota automatizada ................................................................................. 51
4.3 Portar os scripts do Ubuntu 10.04 para o 12.04 ................................................ 54 4.3.1 Necessidade de portar o script ............................................................................................. 54 4.3.2 Problemas encontrados inicialmente ................................................................................. 54 4.3.3 Funcionalidades ....................................................................................................................... 55 4.3.4 Testes da integração do script na versão 12.04 LTS .................................................... 55
4.4 Avaliação e Resultados ................................................................................................ 56 5 Conclusão e trabalho futuro ..................................................................................... 58 5.1 Trabalho Futuro ............................................................................................................ 59
6 Bibliografia ................................................................................................................... 60
vii
Índice de Tabelas e Figuras
Tabela 1: Plano inicial de tarefas ..................................................................................... 4 Tabela 2: Sub-tarefas da Implementação de Soluções .................................................... 6 Figura 1: Fluxograma do processo de empacotamento ................................................. 12
1
1 Introdução Atualmente, cada vez mais empresas optam por usar sistemas abertos não só ao nível
dos servidores mas também ao nível dos postos de trabalho. Apesar de optarem por
este tipo de sistemas, por vezes é necessário utilizar serviços disponíveis apenas em
sistemas proprietários. Uma das dificuldades frequentes é a integração de serviços
entre sistemas abertos e os diversos ambientes proprietários. Um dos objetivos deste
relatório é apresentar os desafios que foram surgindo durante a inclusão de serviços
proprietários em plataformas abertas e a forma como as mesmas foram solucionadas.
1.1 Motivação
Conhecendo a realidade do mercado, os seus receios relativos a grandes alterações de
metodologias ou ferramentas de trabalho, e pretendendo, simultaneamente, reduzir
custos com licenciamento, considera-se o projeto de integração de serviços
proprietários em sistemas abertos aliciante, ao nível da motivação pessoal, pois
permite demonstrar que é possível integrar num sistema operativo aberto os mesmos
serviços e funcionalidades existentes em sistemas operativos proprietários.
1.2 Objectivos
O estágio enquadra-se no objetivo da Ângulo Sólido de desenvolver uma solução de
integração de postos de trabalho Linux, mais concretamente Ubuntu[1] na versão
10.04 LTS[2], num ambiente empresarial baseado em tecnologias Microsoft.
Embora não sendo o foco principal do estágio, pretende-se também analisar qual o
comportamento na aplicação da solução criada para o ambiente Ubuntu versão 10.04
na versão 12.04.
2
1.3 Trabalho realizado
Com o trabalho realizado foi criado uma solução configurável para os postos de
trabalho em ambiente GNU/Linux de acordo com os requisitos de cada cliente da
entidade de acolhimento. Com esta solução, e através de um script parametrizado
podem ser instalados e configurados postos de trabalho minimizando o esforço e
tempo de instalação e integração com sistemas proprietários.
A aplicação da solução personalizada desta plataforma foi realizada em vários postos
de trabalho sendo o conjunto constituído por postos físicos e virtuais (postos de
trabalho de um ambiente virtual simulado num ambiente físico). Esta solução não só
consistia em personalizar os postos de trabalho mas também o perfil do utilizador
através da gestão de perfis por políticas, tal como é explicado mais detalhadamente na
secção 4. Um exemplo da aplicação de políticas no perfil de utilizador é a alteração da
imagem de fundo do ambiente de trabalho associado ao utilizador em questão. Um
exemplo da personalização dos postos de trabalho é a aplicação de um conjunto de
pacotes de software modificados de modo a que fosse possível usar diversos serviços
baseados em tecnologias Microsoft. A título exemplificativo podem destacar-se os
seguintes serviços:
• usar um posto de trabalho Linux de forma a ser possível fazer uma ligação
remota a outros postos de trabalho Windows ou Linux através do protocolo
Remote Desktop Protocol (RDP)[3][4];
• aceder a Groupware[5] Exchange[6] (versão 2010);
• autenticar sessões de utilizadores utilizando Kerberos[7][8];
• aceder a diretorias partilhadas em ambientes Microsoft (automatizado e
personalizado em função de utilizador e grupo);
• autenticar automaticamente em páginas Web via Kerberos e NTLM[9].
Outras metas desta solução foram as seguintes:
• atualização remota automatizada de aplicações instaladas nos postos de
trabalho;
• adaptação e desenvolvimento de pacotes modificados consoante as
necessidades dos clientes da instituição de acolhimento.
3
Durante a implementação da solução surgiu a necessidade de atualizar a versão do
sistema operativo instalado nos clientes da instituição de acolhimento e verificar se as
soluções anteriormente criadas também eram compatíveis com a nova versão,
modificando-as se necessário. Algumas das metas a atingir neste novo enquadramento
passam por:
• testar as ligações entre o Microsoft Exchange 2010 e o Ubuntu versão 12.04;
• modificar o ficheiro que permitia, de forma automatizada, a customização dos
postos de trabalho com o sistema operativo Ubuntu 10.04 para que fosse
também suportado pelo Ubuntu 12.04.
1.4 Instituição de acolhimento
A empresa Ângulo Sólido, criada em 2005, com 100% de capitais nacionais, é
especializada em Tecnologias de Informação e apresenta-se no mercado português
como fornecedora de serviços à medida em open source.
A missão desta empresa é proporcionar às organizações portuguesas soluções “chave
na mão” que permitam garantir a segurança, fiabilidade e interoperabilidade de
qualquer parque informático a baixo custo comparado com os seus concorrentes.
A Ângulo Sólido tem várias equipas, uma das quais é a de Administração de
Sistemas. Esta equipa tem de garantir que a integração de diversos sistemas, serviços
e aplicações funcionam de forma correta, independentemente do sistema operativo em
que se está a trabalhar. Por exemplo, um dos objetivos desta equipa é parametrizar
postos de trabalho que funcionem em Ubuntu, mas com integração num ambiente
onde coexistam serviços Windows.
Para a equipa conseguir garantir a interação entre diversos sistemas, a mesma usa a
seguinte infraestrutura:
• servidores de Domain Host Configuration Protocol (DHCP)[10]/
Domain Name Server (DNS)[11]/ Proxy[12]/Servidor Web em Linux;
• um servidor de Domain Control (DC)[13]/DNS em Windows 2003;
• um servidor Web/Exchange em Windows 2008;
• um encaminhador (router)[14];
4
• um servidor onde são desenvolvidos os vários pacotes modificados;
• um computador de testes em Ubuntu;
• um servidor Vmware[15].
O estágio surge no âmbito da realização do Projeto de Informática do Mestrado em
Informática em parceria com o Departamento de Informática da Faculdade de
Ciências da Universidade de Lisboa.
Dado o currículo e percurso profissional na área de Administração de Sistemas optou-
se por um tema que permitisse adicionar valor aos conhecimentos já adquiridos,
podendo aprofundá-los e evoluir nesta área.
1.5 Planeamento
De acordo com a proposta submetida ao Departamento de Informática da Faculdade
de Ciências, as tarefas a realizar e o tempo de duração do período de estágio na
empresa Ângulo Sólido estavam estipuladas da seguinte forma:
Tarefas Tempo previsto (em meses)
Análise global do projeto de integração e seleção de
tópicos de trabalho
0.5
Análise dos vários tópicos e respectiva estimativa de
esforço
0.5
Implementação de soluções 6
Testes 1
Dissertação 1
Total 9
Tabela 1: Plano inicial de tarefas
5
1.5.1 Tarefas realizadas
A metodologia de desenvolvimento que foi utilizada para a realização das tarefas
durante o período de estágio na empresa Ângulo Sólido foi a seguinte:
• inicialmente, pela instituição de acolhimento, foram recolhidos os
requisitos junto de um cliente com necessidade específicas de
integração. A primeira tarefa atribuída no estágio foi a de analisar quais
as incompatibilidades na utilização de serviços entre os ambientes de
sistema aberto e proprietários, procurando uma forma de as resolver;
• após a primeira análise, foram efectuadas alterações ao código-fonte dos
pacotes de forma a corrigir alguns erros que os mesmos apresentavam e
adicionadas as funcionalidades necessárias. Posteriormente, foram
criados os novos pacotes debian com as alterações;
• para a validação da solução foi utilizada uma ou mais máquinas virtuais
instaladas de raiz apenas com o Ubuntu 10.04 e foi também testado um
script, indicado na secção 4. Este script foi inicialmente disponibilizado
pela Ângulo Sólido e continha algumas alterações ao nível de
configurações e pacotes. Posteriormente, foram adicionadas outras
alterações, sobretudo ao nível de correções do código-fonte dos pacotes,
de forma a verificar se o pacote alterado resolveria o problema.
1.5.2 Sub-Tarefas de Implementação de Soluções
Como a maior parte do tempo de estágio foi consumido pela tarefa “Implementação
de Soluções“, optou-se por detalhar melhor quais as sub-tarefas associadas
diretamente a esta tarefa.
As sub-tarefas realizadas na implementação de soluções associadas à integração da
plataforma Linux (Ubuntu) foram as seguintes:
6
Tarefas
1 – Preparação do ambiente para a geração do pacote debian relativo ao XRDP;
2 - Preparação do ambiente para a geração do pacote debian relativo ao X11RDP;
3 - Preparação do ambiente para a geração dos pacotes debian relativos ao Firefox
e ao Samba;
4 - Integração com NTLM;
5 – Ativação da blacklist para um determinado conjunto de pacotes pré-definidos
no script (evitar que o sistema faça a atualização desses pacotes);
6 – Implementação de uma lista de pré-requisitos para administração remota
automatizada;
7 – Conexão do Ubuntu 12.04 com o Microsoft Exchange 2010;
8 – Modificação do script da versão 10.04 de forma a ser compatível com a versão
12.04, garantindo que o mesmo funcione para as duas versões.
Tabela 2: Sub-tarefas da Implementação de Soluções
1.6 Estrutura do documento
Este documento está organizado em cinco capítulos. No primeiro capítulo é feita a
introdução e enquadramento do estágio. No segundo capítulo, Sistema de Pacotes
Debian, são introduzidos o conceito de pacote de software e os passos necessários
desde a obtenção do código-fonte até à criação de um pacote. O terceiro capítulo,
Personalização de Pacotes, apresenta o conjunto de pacotes gerados no âmbito deste
trabalho, descrevendo para cada um a motivação para as alterações realizadas e os
testes que permitiram validar as alterações. No quarto capítulo são descritas as
contribuições para o sistema de administração remota de postos de trabalhos e os
testes de migração dos pacotes da versão 10.04 LTS para a versão 12.04 LTS. Por
último, o quinto capítulo, designado de Conclusão e Trabalho Futuro, encerra este
7
relatório. Nesse capítulo são indicadas as conclusões possíveis durante a realização do
projeto e apresentadas as sugestões para o trabalho futuro.
8
2 Sistema de pacotes Debian O projeto “GNU’s Not Unix!” (GNU)[16] foi publicamente anunciado em 1983 por
Richard Stallman como um sistema operativo livre, de forma a que todos os
utilizadores pudessem controlar e configurar o computador à sua maneira.
O Linux[17] foi criado por um estudante finlandês chamado Linus Torvals em 1991.
Inicialmente, este foi criado para satisfazer as necessidades de acesso a servidores
Unix da universidade onde Linus estudava. O objetivo do desenvolvimento do Linux
era apenas ser um emulador de terminal, mas rapidamente Linus apercebeu-se de que
este poderia ser utilizado como o núcleo de um sistema operativo. Posteriormente,
este núcleo passou a ser usado com as aplicações do GNU.
Ao longo do tempo foram surgindo diversas distribuições que utilizam como base as
aplicações GNU e o núcleo do sistema operativo Linux. Designa-se por distribuição
(também conhecida como distro) um conjunto de programas, serviços e controladores
que facilitam o utilizador a interagir e realizar tarefas com o computador. São
exemplos de distribuição o projeto Debian e o projeto Ubuntu.
2.1 Sistemas de Pacotes
Um pacote de software é um programa/serviço que está acondicionado num formato
de arquivo e que está disponível para ser instalado através de um sistema de gestão de
pacotes ou através de um instalador autónomo.
A utilização de sistemas de pacotes, como qualquer outro sistema, como por exemplo
o esquema que é utilizado em sistemas Microsoft, apresenta as suas vantagens e
desvantagens.
As principais vantagens associadas à utilização de pacotes de sistemas são a
simplicidade e rapidez na instalação do software, a estabilidade das versões, a
facilidade de atualização e ainda a possibilidade dos pacotes funcionarem em
diferentes distribuições que suportem o mesmo sistema de pacotes.
Contudo, a manutenção de um sistema de pacotes obriga a algum esforço, por parte
da equipa de Administração de Sistemas, de forma a evitar obsolescências por
9
incompatibilidade com novas versões de outros pacotes e a garantir que os pacotes
são preparados com os conjuntos de documentação adequada.
A maioria das distribuições GNU/Linux assenta sobre um de dois sistemas de pacotes.
Um deles é o sistema de pacotes desenvolvido no âmbito da distribuição Debian,
conhecidos como pacotes .deb e o outro sistema designa-se RPM Package Manager
(RPM), desenvolvido pela Red Hat, que utiliza o formato de ficheiros .rpm.
O sistema de pacotes da distribuição Debian utiliza formatos bem definidos de
ficheiros compactados, como o tar (tape archive) e o gzip (GNU Zip), o que permite
que sejam facilmente verificados e adicionadas pequenas alterações.
A oferta de pacotes disponíveis nos repositórios Debian é maior e mais diversificada
do que a existente nos repositórios Red Hat[18] essencialmente devido ao número de
versões disponibilizadas por cada uma das empresas no mercado[19].
A atualização dos pacotes disponibilizados pela Red Hat tem um custo associado ao
contrário da atualização dos pacotes disponibilizados nos repositórios Debian.
2.2 Sistema de Pacotes e o Projeto Debian O projeto Debian[20] foi iniciado em 1993 por Ian Murdock, com o objetivo de criar
e desenvolver uma distribuição gratuita seguindo a filosofia do Linux e do GNU. A
combinação da filosofia Debian e da metodologia das ferramentas GNU e
adicionando o núcleo de Linux[21] (kernel) e outras aplicações gratuitas, tais como o
Firefox [22](browser) ou o Libreoffice[23], formam a distribuição designada de
Debian GNU/Linux. Ian pretendia que a distribuição Debian mantivesse um
desenvolvimento e suporte estáveis. Esta distribuição tem origem num grande número
de pacotes de software. Cada pacote disponibilizado na distribuição contém ficheiros
executáveis, scripts, documentação e informação de configuração. Estes pacotes têm
um gestor associado que é o principal responsável por: manter este atualizado,
verificar os relatórios de anomalias e comunicar as mesmas ao(s) autor(es) do
software original do pacote. Ainda a referir que a distribuição Debian possui um
conjunto de programas básicos e utilitários estáveis que permitem o bom
funcionamento de um computador ou servidor.
Uma grande parte das ferramentas básicas que formam o sistema operativo são
originais do projeto GNU.
10
O Ubuntu[24] foi lançado oficialmente em Outubro de 2004 pela empresa
Canonical[25]. O objetivo do seu fundador, Mark Shuttleworth, era transformar o
Linux, conhecido até então como uma plataforma de servidores empresarias, numa
distribuição estável para postos de trabalho. Para isso escolheu como base o projeto
Debian, por ser um dos projetos alicerçados em GNU/Linux mais desenvolvidos na
época, tendo reunido uma equipa de desenvolvimento para concretizar essa tarefa. O
que Mark Shuttleworth pretendia para o Ubuntu era atingir duas partes importantes na
introdução de uma nova distribuição, sendo uma delas a parte social (de forma a que a
sociedade aceitasse, interagisse e utilizasse esta distribuição) e a outra a parte
económica (disponibilizar gratuitamente a distribuição, fornecer software livre de
custos e que fosse financiado através de um portefólio de serviços prestados pela
Canonical).
2.3 Ambiente de geração de pacotes Debian – packaging
A preparação de pacotes de software (também conhecida como packaging)[26]
consiste em criar um pacote a partir do código-fonte da aplicação.
Este processo é facilitado por um ambiente de empacotamento. Por norma, o
ambiente de empacotamento de software é instalado num computador configurando
um ambiente controlado em que apenas se instala a versão base da distribuição e as
ferramentas necessárias para que se possa proceder ao empacotamento, como por
exemplo as ferramentas gcc, make, debuild e autoconf que se encontram definidas na
secção 3.
2.3.1 Ferramentas de empacotamento
Para a preparação do empacotamento de software é necessário proceder à
transferência do código-fonte do pacote e verificar quais os pré-requisitos que são
necessários instalar e configurar de forma a ser possível criar um novo pacote. O
ambiente de empacotamento é composto pelas ferramentas necessárias à compilação
11
do código-fonte e por um conjunto de utilitários que fazem parte da instalação base da
distribuição, nomeadamente:
• make: lê ficheiros do tipo Makefile para saber o que é necessário compilar;
• apt/dpkg: para além da sua utilização básica de instalar pacotes, estes
comandos têm muitas funcionalidades úteis para o empacotamento, como por
exemplo, ver o conteúdo dos pacotes, procurar um pacote no repositório e
fazer a atualização da lista de pacotes existentes nos repositórios;
• grep-dctrl - procura uma determinada palavra no pacote;
• diff - compara dois ficheiros, apresentando as diferenças entre eles e é
utilizado frequentemente para a criação de correções (patches) no código-
fonte;
• patch é criado para aplicar atualizações, criadas pelo diff ou por um programa
semelhante, a múltiplos ficheiros ou diretórios;
• debhelper são scripts que executam tarefas comuns do empacotamento;
• dh_make este comando permite iniciar o processo de empacotamento criando
as diretorias e os ficheiros necessários;
• gnupg é um substituto completo e livre para o PGP usado para assinar
digitalmente ficheiros (incluindo pacotes);
• fakeroot simula a execução de um comando com privilégios de root;
• lintian verifica as inconsistências e erros existentes num determinado pacote
Debian.
A lista básica de pacotes necessária para obtermos o ambiente Packaging do Ubuntu é
a seguinte:
• build-essential é um conjunto de ferramentas necessárias para o
empacotamento que inclui as aplicações básicas de compilação (gcc, g++ e
make) e as bibliotecas de desenvolvimento (libc6-dev e dpkg-dev) no
empacotamento;
• devscripts contém muitos dos scripts utilizados, dos quais são exemplo
debdiff (mostra a diferença entre dois pacotes debian), dch (permite editar o
ficheiro debian/changelog) e debuild (cria pacotes debian);
• ubuntu-dev-tools é uma coleção de scripts, tal como o devscripts, sendo
12
específico para Ubuntu; contém algumas ferramentas, como o pbuilder-dist
que permite construir pacotes indicando as suas dependências, ou seja, os
pacotes que são necessários para a sua instalação.
2.3.2 Processo de empacotamento
Apesar de existirem diferentes pacotes debian disponíveis para as distribuições e
versões onde são utilizados, é possível utilizar um desses pacotes e personalizar de
acordo com as necessidades do ambiente de utilização. A personalização do pacote
terá sempre associada a particularidade do ambiente de utilização e o facto de
poderem existir diferentes formas de desenvolver o processo de empacotamento. Esta
situação poderá causar dificuldades na modificação do pacote por pessoas externas a
este novo pacote, pois estas podem não conhecer a forma como o pacote foi
construído e dado que esta tarefa é muito especializada.
No geral, o processo de empacotamento consiste na execução das seguintes etapas:
Figura 1: Fluxograma do processo de empacotamento
De seguida vão ser analisadas as etapas indicadas no fluxograma.
13
2.3.2.1 Obtenção do código-fonte
A forma mais simples de fazer o empacotamento é fazer a criação do pacote a partir
do código-fonte. Esse código-fonte por norma está disponível nos repositórios do
Ubuntu. As versões do código-fonte nos repositórios do Ubuntu vêm optimizadas
para a distribuição, o que permite realizar de uma forma mais rápida e eficaz o
empacotamento. Por vezes é necessário proceder à alteração do pacote para adicionar
funcionalidades não previstas ou para corrigir problemas/erros da aplicação. Se os
pacotes não existirem pode ser usado o código-fonte disponibilizado no sítio oficial
do software, sendo necessário, posteriormente, realizar algumas alterações de modo a
que o software seja compatível com a distribuição usada.
Outro mecanismo que se pode utilizar para descarregar o código-fonte diretamente do
sítio da aplicação, é utilizar a ferramenta wget. Esta ferramenta permite descarregar
um ou vários ficheiros da internet. No entanto, o utilizador necessita de saber o
endereço exato da localização dos ficheiros do código-fonte para conseguir
descarregar com sucesso. Para transferir o código-fonte diretamente do repositório do
Ubuntu, também é possível utilizar a ferramenta apt que permite obter o código-fonte
utilizado na geração dos pacotes oficiais.
Quando se obtém o código-fonte através da ferramenta apt ou através do repositório
oficial do Ubuntu são descarregados três ficheiros: um com a extensão .orig.tar.gz,
outro com a extensão .dsc e, por fim, o terceiro ficheiro com a extensão .diff.gz. Estes
ficheiros têm sempre a seguinte designação: packagename_version.extension
(exemplo: samba_3.4.7.orig.taz.gz).
O ficheiro .orig.tar.gz contém o código-fonte do(s) autor(es), o ficheiro .dsc descreve
o pacote e fornece a soma de controlo (md5sums) da fonte do pacote e o ficheiro
.diff.gz contém os ficheiros (no diretório debian/) e as correções determinadas pelo
maintainer para serem aplicadas ao código-fonte original. Posteriormente, deve
descompactar-se o ficheiro .orig.taz.gz no diretório onde estão as alterações do
pacote. O código-fonte do ficheiro .orig.tar.gz será descompactado para um diretório
com a seguinte designação packagename-version (exemplo: samba-3.4.7).
14
2.3.2.2 Configuração de pacote
A configuração de pacotes pode ser feita de duas formas. A configuração de pacotes
usando um método tradicional ou a forma considerada mais comum que é a
configuração via CDBS.
A forma de configurar cada uma delas é descrita nos pontos seguintes.
2.3.2.2.1 Configuração de pacote usando método tradicional
Após a obtenção do código-fonte e a extração do mesmo, é necessário proceder às
alterações dos ficheiros do código-fonte. Caso ainda não exista a diretoria debian,
deve executar-se o comando dh_make para criar a diretoria debian, a qual irá conter
pelo menos quatro ficheiros fulcrais que, posteriormente, devem ser editados de forma
a personalizar o comportamento do pacote. São eles: control, changelog, copyright e
rules.
O ficheiro control contém informações de controlo de pacote, tais como: a fonte do
código, a descrição, o sítio oficial e o seu gestor do pacote (representado pelo nome e
email do mesmo), bem como os pacotes dos quais depende e os conflitos com outros
pacotes.
O ficheiro copyright contém informações sobre os direitos de autor.
O ficheiro changelog indica todas as alterações que foram efectuadas ao longo das
várias versões. Este tem uma formatação especial, a qual está descrita no manual de
políticas Debian. Esta formatação é utilizada por diversos programas, entre eles o
dpkg, para obter o nome do pacote, o número da versão, o tipo de distribuição, a
urgência e as mudanças feitas na revisão do pacote.
O ficheiro rules é interpretado pelo comando dpkg-buildpackage e contém o conjunto
de instruções a seguir para a geração do pacote. Este ficheiro é, na realidade, outro
tipo de makefile e, ao contrário dos outros ficheiros indicados anteriormente, é criado
um ficheiro com permissões de execução. Com este tipo de ficheiro pretende-se,
essencialmente, automatizar uma ordem de compilação entre etapas ou pacotes.
Algumas etapas do ficheiro de regras são indicadas pelos seguintes comandos:
• clean – remove tudo o que foi compilado anteriormente (etapa obrigatória);
15
• build – compila o código-fonte e processa as etapas de criação do pacote
(etapa obrigatória);
• install – cria todas as diretorias necessárias (dentro da diretória debian) ao
funcionamento da aplicação e coloca nessas diretorias os ficheiros gerados
relativos à instalação do pacote (etapa opcional);
• binary - cria todos os pacotes binários necessários para a aplicação funcionar;
• binary-arch - constrói os pacotes binários para uma determinada arquitetura;
• binary-indep – constrói os pacotes binários para as restantes arquiteturas não
compatíveis com o binary-arch.
As variáveis mais comuns que se encontram disponíveis para utilização no ficheiro
debian/rules são:
• DEB_SOURCE_PACKAGE: nome do código-fonte do pacote;
• DEB_VERSION: versão completa do Debian;
• DEB_ALL_PACKAGES: lista de todos os pacotes binários;
• DEB_PACKAGES: lista dos pacotes binários com exceção dos pacotes micro
debian (estes pacotes apenas contém ficheiros essenciais à sua execução,
omitindo toda a documentação);
• DEB_ARCH: indica qual a arquitetura do processador para qual o pacote vai
ser gerado.
Outros ficheiros existentes na diretoria debian são os seguintes:
• README.Debian - descrição textual do software que poderá incluir, caso
existam, informações sobre diferenças entre a versão original e a versão no
pacote debian;
• Conffiles - contém uma lista com os caminhos dos ficheiros de configuração
de um pacote, o que permite que estes não possam ser substituídos quando o
pacote é atualizado.
• Dirs - especifica os diretórios necessários, mas que não são criados pelo
processo de instalação normal (make install DESTDIR=... invocado por
dh_auto_install).
16
Existe ainda outro tipo de ficheiros que são criados na diretoria debian quando se
executa o comando dh_make. Estes ficheiros são scripts executados
automaticamente antes ou depois de um pacote ser instalado e são os seguintes:
• preinst - script executado antes do pacote debian ser instalado, permitindo por
exemplo parar um determinado serviço até que a instalação deste pacote esteja
completa;
• postinst - este script é executado após a instalação do pacote Debian. Como
exemplos de utilização indicam-se a criação de um utilizador local associado
ao pacote instalado e o reinício do serviço interrompido por preinst;
• prerm – tipicamente, este script termina quaisquer serviços que estão
associados a um pacote. O comando é executado antes da remoção do pacote;
• postrm – normalmente, este script é executado depois de os ficheiros criados
pelo pacote terem sido removidos ou substituídos.
2.3.2.2.2 Configuração do pacote via CDBS
O Common Debian Build System (CDBS) foi inicialmente desenvolvido por Jeff
Bailey e Colin Walters em março de 2003.
O CDBS foi desenvolvido para simplificar as tarefas dos responsáveis por manter os
pacotes, de forma a que estes aos mesmos apenas se preocupem com o processo de
empacotamento em si, uma vez que o ficheiro debian/rules é atualizado de forma
automática. O CDBS deteta a maior parte da configuração necessária para o pacote e
preenche automaticamente o ficheiro debian/rules com as regras mais comuns de
empacotamento.
No empacotamento o CDBS utiliza apenas regras simples do makefile mas facilmente
se podem utilizar classes, para por exemplo, aplicar alterações na criação do pacote ou
instalar outros pacotes. No empacotamento podem destacar-se como principais
vantagens na utilização do CDBS a optimização do ficheiro debian/rules, tornando-o
mais legível e eficiente, e a automatização do debhelper e do autotools, de forma a
não ser necessário repetir os mesmos comandos várias vezes.
17
O CDBS funciona, na maioria das vezes, com ficheiros do tipo Makefile (.mk) em
debian/rules.
Um dos maiores problemas encontrados na utilização deste tipo de empactomento foi
o facto de a documentação estar muito incompleta ou, em alguns casos, ser
inexististente.
O pacote CDBS fornece ficheiros em /usr/share/cdbs/1/ que permitem simplificar a
maioria das tarefas de empacotamento. Os módulos mais utilizados incluídos no
CDBS são:
• rules/debhelper.mk: chama o debhelper em todas as secções obrigatórias;
• rules/dpatch.mk: permite utilizar o dpatch de forma a facilitar o patching do
código-fonte;
• rules/simple-patchsys.mk: fornece uma forma mais simples de colocar um
patch no código-fonte;
• class/autotools.mk: chama o autotools nas secções necessárias;
• class/gnome.mk: cria programas GNOME;
• class/kde.mk: cria programas KDE;
• class/python-distutils.mk: facilita o empacotamento de programas Python.
2.3.2.3 Compilar o Código-Fonte
Finalizada a etapa anterior referente à configuração do pacote, é necessário realizar a
compilação do mesmo. Regra geral, nesta etapa é preciso executar o script configure
e, de seguida, compilar o código-fonte do pacote com a ferramenta make.
O script configure está incluído em quase todo o código-fonte disponível para Linux,
especialmente para o software desenvolvido em linguagens compiladas, como é o
caso das linguagens C e C++. Este script é utilizado para gerar ficheiros do tipo
Makefile (necessário na utilização da ferramenta make). Os ficheiros do tipo Makefile
contêm regras de compilação e dependências necessárias na compilação do código-
fonte da aplicação.
A ferramenta make[27], desenvolvida por Stuart Feldman em 1977, permite compilar
de forma automática as aplicações e as bibliotecas correspondentes ao código-fonte,
através das instruções armazenadas nos ficheiros do tipo Makefile.
18
Esta ferramenta permite ao utilizador comum compilar e instalar uma aplicação sem a
conhecer detalhadamente e não sendo necessário saber quais os ficheiros a compilar,
já que estas informações estão guardadas no ficheiro do tipo Makefile. O make
também consegue reconhecer automaticamente que foram realizadas alterações em
determinados ficheiros do código-fonte, procedendo apenas à compilação dos
ficheiros modificados. Esta ferramenta não é exclusiva de uma linguagem de
programação específica e também não está limitada à construção de um pacote, uma
vez que a mesma também pode ser usada na remoção de uma aplicação.
2.3.2.4 Criar o pacote
A construção de pacotes pode ser feita através da utilização de um dos seguintes
comandos: dpkg-buildpackage, debuild ou dpkg-deb.
O comando dpkg-buildpackage executa os seguintes passos para construir o pacote:
remove tudo o que foi previamente compilado (através do ficheiro debian/rules
clean), cria a fonte do pacote sob a diretoria debian (através do comando dpkg-source
-b), compila o programa (através do ficheiro debian/rules build) e assina o ficheiro
.dsc utilizando o GPG.
Em primeiro lugar, o comando debuild verifica se todos os build-depends estão
instalados, de seguida utiliza o comando dpkg-buildpackage para compilar e instalar
os ficheiros .deb, usando as regras do ficheiro rules, e, por fim, assina os pacotes com
o GPG.
A ferramenta dpkg-deb permite a manipulação de ficheiros do tipo debian, sendo
possível a criação de um pacote debian através de um sistema de ficheiros e diretorias
em árvore. Por norma, esta ferramenta é utilizada quando o código-fonte não engloba
o script rules.
19
2.4 Resumo
Esta secção descreve, genericamente, o sistema de pacotes e o ambiente de geração de
pacotes Debian (as suas ferramentas e o processo de empacotamento). Os pacotes são
aplicações ou serviços configurados e preparados para instalação numa determinada
distribuição Linux. A utilização de pacotes tem como vantagens a identificação e a
possibilidade de gestão automática de dependências de software, a simplicidade na
atualização do sistema, a rapidez na sua instalação e a garantia de que existe
estabilidade dos pacotes entre as diferentes versões. O processo de criação de pacotes
passa por obter o código-fonte, configurar o pacote de acordo com as necessidades do
cliente, compilar o código-fonte e, por fim, reunir todos os ficheiros necessários num
único arquivo, com uma sintaxe e um formato de acordo com o software de gestão de
pacotes da distribuição.
20
3 Personalização de Pacotes
3.1 Ambiente para geração de pacote .deb do X11RDP
3.1.1 Definição de X11RDP
O X11 é uma aplicação que fornece um protocolo base para a interface gráfica do
sistema, sendo o principal gestor de interfaces gráficas em distribuições de Linux.
O X11RDP é uma aplicação que gere remotamente janelas através do protocolo RDP.
3.1.2 Geração do pacote O pacote X11 foi desenvolvido para suportar o pacote do XRDP e construído tendo
por base o código obtido através de svn (controlo de versões aplicativas e controlo de
revisão distribuídas do código-fonte):
svn co svn://server1.xrdp.org/srv/svn/repos/main/x11rdp_xorg71
3.1.3 Problemas e resolução
O código-fonte obtido do X11RDP[29] não estava a funcionar devido ao problema
descrito na secção seguinte. De forma a ser possível corrigir a anomalia e recompilar
o pacote, seguindo os passos indicados nas secções 2.2.2.1 e 2.2.2.2, foi necessário
proceder à instalação de alguns pacotes essenciais à compilação descritos na secção
2.2.2.3. Os pacotes em foco são: o pacote subversion para garantir que o gestor de
repositório está instalado, o pacote autotools que instala uma versão atualizada dos
ficheiros config.guess e config.sub (que são utilizados pelos pacotes automake e
libtool), a ferramenta automake que gera automaticamente ficheiros do tipo
“Makefile.in” a partir de ficheiros do tipo “Makefile.am”, o pacote libtool, o pacote
pkg-config que permite um sistema de gestão de “flags” de compilação e funciona
como conector entre o pacote do automake e autoconf (permite a construção
21
automática do script configure), o pacote make e o pacote gcc (compilador de
linguagem C da GNU).
3.1.3.1 Falha na execução do serviço do XRDP e do X11 O pacote do X11RDP não iniciava corretamente porque os pacotes do XRDP e do X11
estavam instalados em diretorias que não eram reconhecidas como as suas diretorias
por omissão. Para que o pacote do X11RDP funcionasse foi necessário proceder à sua
modificação para que o mesmo suportasse essas diretorias. Para tal foram executados
os seguintes passos:
a) criar a diretoria /opt/X11rdp e atribuir as permissões máximas (todos os
utilizadores podem ler, escrever e executar ficheiros) usando o comando
chmod 777 /opt/X11rdp
b) descarregar do repositório a última versão do código-fonte do X11rdp
executando o comando
svn co svn://server1.xrdp.org/srv/svn/repos/main/x11rdp_xorg71
c) criar a diretoria debian e, consequentemente, a diretoria opt de forma a
organizar a estrutura de diretorias e ficheiros a serem copiados na instalação
da aplicação
d) editar o ficheiro control que se encontra na diretoria debian, indicando o nome
da aplicação, a versão, a prioridade na instalação, o maintainer do pacote e
uma breve descrição da aplicação
Package: X11rdp
Version: 0.6.0-1
Section: unknown
Priority: optional
Architecture: all
Maintainer: Angulo Solido <[email protected]>
Description: X11rdp backend for the xrdp remote access server
a) criar a diretoria usr (dentro da diretoria debian) e, consequentemente, a
diretoria bin
22
b) editar o ficheiro buildx.sh para criar o link simbólico em /usr/bin/
o no início do ficheiro tem de ser declarado o caminho onde se
encontra fisicamente o ficheiro (LNORIG) e onde estará o
caminho simbólico (LNDEST)
LNORIG=/opt/X11rdp/bin/X11rdp
LNDEST=/build/package/X11rdp/x11rdp_xorg71/debian/usr/bin/
o adicionar o comentário e o comando no fim do ficheiro
# make a symbolic link to your local /usr/bin
ln -s $LNORIG $LNDEST
3.1.4 Compilação e construção do pacote X11RDP Após a obtenção do código-fonte, da verificação das anomalias e da correção das
mesmas é necessário proceder à compilação do pacote seguindo os passos indicados
na secção 2.2.2.3 e, de seguida, construir o pacote tal como indicado na secção
2.2.2.4. Para compilar e construir o pacote foram efetuados os seguintes passos:
• compilar o X11rdp executando o comando sh buildx.sh /opt/X11rdp
• copiar o resultado para a diretoria com a estrutura de preparação do
pacote executando o comando cp -R /opt/X11rdp/
/build/package/X11rdp/debian/opt/
• construir o pacote executando o comando dpkg-deb --build
X11rdp_0.6.0-1
3.1.5 Teste de integração do pacote X11RDP
O X11RDP foi testado simultaneamente com o pacote do XRDP (o pacote X11RDP é
dependente do pacote XRDP). Os testes podem ser verificados e analisados na secção
3.1.5.
23
3.2 Ambiente para geração de pacote .deb do XRDP
3.2.1 Definição de XRDP O pacote X Remote Desktop Protocol (XRDP) é uma aplicação que permite aos
clientes acederem remotamente ao computador via protocolo Remote Desktop
Protocol (RDP).
O pacote XRDP foi dos pacotes mais trabalhosos para reconstruir porque não continha
várias funcionalidades, as quais tiveram de ser adicionadas posteriormente, como por
exemplo o facto de o pacote não incluir os ficheiros de definição do teclado
português, por parte dos clientes, do layout do teclado em português (Portugal) ou o
pacote não incluir scripts de inicialização ou paragem do serviço.
O X11rdp foi utilizado como interface gráfico na utilização do XRDP.
3.2.2 Geração do pacote
O XRDP foi construído tendo por base o código-fonte mais recente (na altura a versão
0.6.0), disponibilizado no sítio do XRDP.
O código-fonte mais recente foi obtido utilizando a ferramenta git (controlo de
revisões distribuídas e gestão do código-fonte). Para a obtenção do código foi usado o
comando: git clone git://github.com/FreeRDP/XRDP.git
3.2.3 Problemas e resolução
O código-fonte obtido do XRDP não estava a funcionar devido aos problemas
descritos nas secções seguintes. De forma a poder ser possível corrigir as anomalias e
recompilar o pacote, seguindo os passos indicados nas secções 2.2.2.1 e 2.2.2.2, foi
necessário proceder à instalação de alguns pacotes essenciais à compilação descritos
na secção 2.2.2.3. Os pacotes referidos são: o pacote libtool que é uma aplicação que
cria bibliotecas portáveis entre diferentes distribuições, o pacote libssl-dev que é um
conjunto de bibliotecas de desenvolvimento e documentação relativa ao protocolo
24
Secure Sockets Layer (SSL) e o pacote libpam0g-dev que é um conjunto de bibliotecas
para integração do mecanismo Pluggable Authentication Module[28] (PAM).
3.2.3.1 Script de gestão do serviço XRDP No pacote original do XRDP não existiam scripts para iniciar ou parar o serviço em
/etc/init.d (diretoria onde se encontram os ficheiros de execução para
parar/iniciar/reiniciar serviços) pelo que foi necessário proceder à criação do script e,
posteriormente, adicioná-lo o mesmo na configuração do pacote através dos seguintes
passos:
• modificar a variável “SUBDIRS” no ficheiro Makefile.am, existente na
diretoria xrdp/instfiles, criando uma referência à diretoria init.d (a
diretoria instfiles contém ficheiros que têm de ser copiados na criação
do pacote);
• adicionar dois ficheiros à diretoria init.d
o xrdp (é o script para parar/iniciar o serviço do XRDP)
o Makefile.am (que indica qual o caminho do ficheiro xrdp)
EXTRA_DIST = xrdp
startscriptdir=$(sysconfdir)/init.d
startscript_DATA = \
xrdp
• adicionar na variável AC_CONFIG_FILES do ficheiro configure.ac
(que se encontra na raíz da diretoria do XRDP) a seguinte linha
instfiles/init.d/Makefile, de forma a que quando o pacote for
recompilado também seja incluído o ficheiro Makefile.am referente à
diretoria init.d.
25
3.2.3.2 Criação do utilizador XRDP
Na instalação do pacote XRDP não era adicionado à distribuição o utilizador XRDP o
que impedia que a aplicação funcionasse, tendo sido adicionado, posteriormente, este
utilizador no ficheiro postinst na diretoria Debian.
3.2.3.3 Pidfiles
O XRDP tentava escrever os pidfiles (ficheiros do processo) na diretoria /var/run em
vez de /var/run/xrdp e falhava no arranque, pelo que teve de ser alterado o caminho
na configuração do pacote do ficheiro:
• alterar o caminho XRDP_PID_PATH no ficheiro common/file_loc.h
para o seguinte:
#if !defined(XRDP_PID_PATH)
#define XRDP_PID_PATH "/var/run/xrdp"
#endif
3.2.3.4 Layout do teclado português e configuração do gestor de sessões No código-fonte do pacote do XRDP faltava o ficheiro do layout do teclado
português, bem como as configuração do gestor de sessões Sesman. Estes ficheiros
foram adicionados às diretorias do código-fonte e também foram feitas as seguintes
alterações:
a) copiar o ficheiro km-0816.ini referente ao teclado português para a diretoria
instfiles (xrdp/instfiles) do código-fonte, para que o executável compilado
contenha a definição de teclado português;
b) modificar a variável “SUBDIRS” no ficheiro Makefile.am, na diretoria
xrdp/instfiles, criando uma referência à diretoria default (diretoria criada para
adicionar ficheiros que têm de ser copiados na criação do pacote). Adicionar
ao mesmo ficheiro uma referência ao teclado português e outra referência à
26
diretoria default (que contém ficheiros de configuração das aplicações que
indicam quais os parâmetros usados por omissão):
o adicionar km-0816.ini na variável EXTRA_DIST e em
startscript_DATA;
c) adicionar dois ficheiros à diretoria xrdp/instfiles/default:
o o ficheiro xrdp.ini (ficheiro de configuração geral), de
forma a indicar qual o gestor de sessão do xrdp a ser
utilizado, neste caso o sesman, utilizando a seguinte
configuração:
# Do we need to start sesman ?
SESMAN_START=yes
# Do we restart XRDP on upgrade ? If not set to no, any XRDP
session will
# be shutdown on upgrade.
# RESTART_ON_UPGRADE=no
o o ficheiro Makefile.am, de forma a que o ficheiro de
configurações do XRDP (indicado no ponto anterior)
fosse colocado na diretoria default da distribuição
EXTRA_DIST = xrdp
startscriptdir=$(sysconfdir)/default
startscript_DATA = \
xrdp
d) adicionar as linhas referentes ao “name” (nome) e à “lib” (tipo) abaixo
indicadas no ficheiro xrdp.ini, na diretoria xrdp, de forma a que o servidor
utilizasse as mesmas nas ligações ao cliente remoto
[sesman-X11rdp]
name=Linux RDP Service
lib=libxup.so
username=ask
password=ask
27
ip=127.0.0.1
port=-1
xserverbpp=24
e) substituir o conteúdo do ficheiro startwm.sh na diretoria sesman pelo indicado
de seguida, de forma a que quando houver ligações a clientes remotos via X11,
seja carregado o locale que estiver definido
#!/bin/sh
if [ -r /etc/default/locale ]; then
. /etc/default/locale
export LANG LANGUAGE
fi
. /etc/X11/Xsession
f) adicionar na variável AC_CONFIG_FILES ao ficheiro configure.ac (que se
encontra na raíz da diretoria do XRDP) a linha instfiles/default/Makefile, para
que quando o pacote for recompilado também seja incluído o ficheiro
Makefile.am referente à diretoria default;
g) adicionar a seguinte informação ao ficheiro dump-keymaps.sh, na diretoria
genkeymap, para indicar qual o ficheiro correspondente ao layout português
# Portuguese -PT 'pt-pt' 0x0816
setxkbmap -model pc104 -layout pt
./xrdp-genkeymap ../instfiles/km-0816.ini.
3.2.4 Compilação e construção do pacote XRDP Após a obtenção do código-fonte, da verificação das anomalias e da correção das
mesmas é necessário proceder à compilação do pacote seguindo os passos indicados
na secção 2.2.2.3. Posteriormente, deve construir-se o pacote tal como indicado na
secção 2.2.2.4. Para construir o pacote foram realizados os seguintes passos:
28
o renomear a diretoria depois de alterar as diretorias e ficheiros pacote do XRDP
(diretoria principal) para xrdp-versão, neste caso específico xrdp-0.6.0;
o criar o ficheiro orig.tar.gz do pacote XRDP com o comando tar -czvf
xrdp_0.6.0.orig.tar.gz XRDP-0.6.0;
o entrar na diretoria xrdp-0.6.0 e executar o comando dh_make no terminal, para
ser criada a diretoria debian, com os seguintes parâmetros dh_make -S -c gpl;
o modificar na diretoria debian os seguintes ficheiros de forma atualizar a
informação dos mesmos:
a) Changelog – indicando o nome do pacote, o número da versão, o tipo de
distribuição, a urgência da atualização e uma descrição das mudanças
feitas na revisão do pacote;
b) Copyright – alterando para o nome da instituição de acolhimento os
direitos de autor;
c) Control – indicando a fonte, o gestor, o nome e a descrição do pacote;
o ir para raíz do xrdp-0.6.0 e executar o comando debuild para que o pacote seja
criado.
3.2.5 Testes de integração do pacote XRDP
Neste tópico sumariza-se um conjunto de testes efectuados após a modificação e
atualização do pacote do XRDP sendo que este tinha capacidades de resize de sessões,
adaptação de colour depth e disconnect a partir da própria sessão. O backend usado é
o X11RDP.
Terminologia
• Retomar sessão - ligar um cliente RDP a uma sessão activa que não tem cliente
ligado
• Substituir sessão - ligar um cliente RDP a uma sessão activa à qual está ligado
um cliente que perderá a ligação
29
3.2.5.1 Teste número 1
o Objetivo – efetuar teste básico de ligação e reposição de situação inicial;
o Resultado esperado – iniciar e terminar sessões no cliente remoto;
o Passos efectuados
a) abrir nova sessão com tamanho 1024x768 e profundidade de cor de 16
bits, executando o comando rdesktop -g 1024x768 -a 16 192.168.1.53 -u
demo -p abc
b) sair da sessão com a opção logout
c) abrir nova sessão com tamanho 1024x768 e profundidade de cor de 16
bits, executando o comando rdesktop -g 1024x768 -a 16 192.168.1.53 -u
demo -p abc
d) sair da sessão fechando a janela (a sessão mantém-se activa)
o Resultado obtido – foram iniciadas e terminadas as sessões no cliente remoto.
3.2.5.2 Teste número 2
o Objetivo – efetuar teste básico de ligação e retoma de sessões com a alteração
de tamanho e profundidade de cor;
o Resultado esperado – retomar sessões no cliente remoto;
o Passos efectuados
c) retomar a sessão que se manteve ativa no teste número 1, mas usando o
tamanho 1366x768 e profundidade de cor de 24 bits, executando o
comando rdesktop -g 1366x768 -a 24 192.168.1.53 -u demo -p abc
d) iniciar um vídeo no site http://www.youtube.com de forma a verificar se o
mesmo era executado com a profundidade de cor de 24 bits
e) sair da sessão fechando a janela (a sessão mantém-se activa)
f) retomar a sessão anterior mas usando o tamanho 1152x864 e profundidade
de cor de 15 bits, executando o comando rdesktop -g 1152x864 -a 15
192.168.1.53 -u demo -p abc
o Resultado obtido – foram retomadas as sessões no cliente remoto, onde se
verificou que o vídeo se mantinha a correr a 15 bits sem anomalias visuais.
30
3.2.5.3 Teste número 3
o Objetivo – efetuar teste básico de ligação e substituição de sessões;
o Resultado esperado – substituir sessões ativas mencionadas anteriormente;
o Passos efectuados
a) abrir uma nova janela de terminal, mantendo a do teste anterior, fazer a
substituição da sessão com tamanho 1024x768 e profundidade de cor de
16 bits e executar o comando rdesktop -g 1024x768 -a 16 192.168.1.53 -u
demo -p abc
b) abrir um terceiro terminal e substituir a sessão que se manteve ativa mas
usando o tamanho 1024x768 e profundidade de cor de 8 bits, executando o
comando rdesktop -g 1024x768 -a 8 192.168.1.53 -u demo -p abc
c) sair de sessão com a opção logout
o Resultado obtido – foram substituídas as sessões no cliente remoto.
3.2.5.4 Teste número 4
o Objetivo – efetuar testes de ligação com dois utilizadores em simultâneo;
o Resultado esperado – permitir que dois utilizadores estejam ligados
remotamente ao mesmo computador;
o Passos efectuados
a) abrir nova sessão com tamanho 1024x768 e profundidade de cor de 16
bits, executando o comando rdesktop -g 1024x768 -a 16 192.168.1.53 -u
demo -p abc
b) abrir uma nova janela de terminal, mantendo a anterior, e fazer a ligação
de uma sessão com outro utilizador com tamanho 1311x768 e
profundidade de cor de 24 bits, executando o comando rdesktop -g
1311x768 -a 24 192.168.1.53 -u demo2 -p abc
o Resultado obtido – os dois utilizadores conseguiram manter as duas sessões
em simultâneo no cliente remoto.
31
3.2.5.5 Teste número 5
o Objetivo – testar a interoperabilidade com o cliente de Terminal Services da
Microsoft;
o Resultado esperado – um posto de trabalho em Ubuntu ou em Windows
deverá conseguir ligar-se a um cliente remoto em Ubuntu;
o Passos efectuados
a) abrir um terminal num computador com Ubuntu instalado, iniciar uma
nova ligação com tamanho 1024x768 e profundidade de cor de 24 bits e
executar o comando rdesktop -g 1024x768 -a 24 192.168.1.53 -u demo -p
abc
b) sair de sessão fechando a janela (a sessão mantém-se activa)
c) retomar a sessão a partir do Windows Server 2003 através do command
prompt, executando o comando cmd e de seguida executar mstsc
/v:192.168.1.53 /w:900 /h:600
d) sair de sessão fechando a janela (a sessão mantém-se activa)
e) retomar a sessão a partir do Windows Server 2008 através do command
prompt, executando o comando cmd e, de seguida, executar o comando
mstsc /v:192.168.1.53 /w:800 /h:600
f) a partir de um computador com Ubuntu instalado substituir a sessão
utilizando o tamanho 1024x768 e profundidade de cor 24 e executar o
comando rdesktop -g 1024x768 -a 24 192.168.1.53 -u demo -p abc
g) voltar ao Windows 2003 e substituir a sessão existente executando o
comando mstsc /v:192.168.1.53 /w:1024 /h:700
h) voltar ao Windows 2008 e substituir a sessão existente e executar o
comando mstsc /v:192.168.1.53 /w:700 /h:480
i) sair de sessão fechando a janela (a sessão mantém-se activa)
j) retomar a sessão num computador com Ubuntu instalado com tamanho
1024x768 e profundidade de cor de 16 bits e executar o comando rdesktop
-g 1024x768 -a 16 192.168.1.53 -u demo -p abc
o Resultado obtido – todas as execuções dos comando rdesktop e mstsc nas
sequência anteriores resultaram em sessões com o tamanho e profundidade de
32
cor indicadas e sem anomalias visuais. Foi possível fazer ligações e trabalhar
nas sessões abertas com diversos utilizadores em simultâneo.
3.2.5.6 Teste número 6
o Objetivo – testar a aceitação de caracteres do teclado português;
o Resultado esperado – o cliente remoto apresenta os caracteres do layout
Português;
o Passos efectuados
a) após efetuar uma ligação de área de trabalho remota, abrir um terminal e
executar o seguinte comando setxkbmap -layout pt
b) abrir um terminal e verificar se os caracteres presentes num teclado
Português aparecem no ecrã da mesma forma que no teclado
c) abrir o Firefox e verificar se os caracteres presentes num teclado Português
aparecem no ecrã da mesma forma que no teclado
d) abrir o OpenOffice Writer e verificar se os caracteres presentes num
teclado Português aparecem no ecrã da mesma forma que no teclado
o Resultado obtido – os caracteres dispostos num teclado português estavam a
funcionar na sessão remota exatamente da mesma forma que funcionariam
numa sessão local.
3.2.5.7 Teste número 7
o Objetivo – testar a possibilidade de desligar a sessão dentro da própria sessão;
o Resultado esperado – verificar se é possível desconectar a sessão estando
ligado no cliente remoto;
|\!"#$%&/()=?»@£§{[]}*aáສaãâç
|\!"#$%&/()=?»@£§{[]}*aáສaãâç
|\!"#$%&/()=?»@£§{[]}*aáສaãâç
33
o Passos efectuados
a) abrir nova sessão com tamanho 1024x768 e profundidade de cor de 16
bits, executando o comando rdesktop -g 1024x768 -a 16 192.168.1.53 -u
demo -p abc
b) sair da sessão executando num terminal o comando xrdp-dis
c) retomar a sessão anterior executando o comando rdesktop -g 1024x768 -a
16 192.168.1.53 -u demo -p abc
o Resultado obtido – foi possível interromper a ligação a uma sessão através de
um comando executado dentro da própria sessão. A sessão permaneceu ativa e
foi possível retomá-la posteriormente.
3.3 Ambiente para geração de pacote .deb Firefox e Samba
3.3.1 Definição de Firefox
O Firefox é um navegador gratuito que está disponível nos vários sistemas operativos
existentes. Este navegador foi desenvolvido e apresentado a 9 de novembro de 2004
pela Fundação Mozilla e é conhecido por ter o código-fonte aberto (software livre)
muito personalizável e extensível.
O Single Sign On é um sistema de controlo de acessos independente dos sistemas de
software. Este sistema permite que após o utilizador ter efectuado login uma vez,
possa aceder a todos os sistemas abrangidos pelo SSO sem as suas credenciais serem
pedidas novamente. Assim, como o login é feito apenas uma vez e o utilizador fica
autenticado em todos os sistemas, o logout funciona da mesma forma. Se o utilizador
fizer logout num site deixará de ter acesso aos restantes, porque deixa de ter sessão
ativa.
O NT Lan Manager (NTLM), numa rede Windows, é um conjunto de protocolos de
segurança da Microsoft que permite autenticação, integridade e confidencialidade dos
utilizadores.
34
O NTLM versão 2 (NTLMv2) introduzido no Windows NT 4.0 SP4 (e nativamente
suportado no Windows 2000), aumentou a segurança NTLM por endurecimento do
protocolo contra muitos ataques de spoofing.
A Active Directory[30] é a implementação de um serviço de diretoria criado pela
Microsoft que permite o armazenamento de informações sobre objetos de uma rede de
computadores, tais como computadores, impressoras, utilizadores e grupos.
O Kerberos tem vindo a substituir o NTLM como protocolo de autenticação padrão
em AD com base num esquema Single Sign-On[31]. O NTLM ainda é amplamente
usado em situações onde um controlador de domínio não está disponível ou está
inacessível. A título de exemplo, o NTLM será usado se o cliente não for capaz de
suportar Kerberos ou se o servidor não fizer parte de um domínio.
Uma das motivações que contribuiu para que fosse necessário alterar o pacote do
Firefox foi o facto de, normalmente, não integrar o serviço de Single Sign On em
NTLM.
Na instalação customizada (feita para a instituição de acolhimento) do Ubuntu 10.04
LTS verificou-se que na sua instalação base o pacote do Firefox não estava
preparado/configurado para fazer autenticação automatizada de forma a evitar o
preenchimento dos campos de “utilizador” e “palavra-chave” quando o utilizador
fazia login. Para que fosse possível aceder via browser a páginas internas da
instituição sem ser necessário proceder à introdução das credenciais do utilizador, foi
essencial proceder à alteração do pacote do Firefox para que fosse viável integrar este
com o Single Sign On em NTLM.
3.3.2 Definição de Samba
O Samba[32], originalmente desenvolvido por Andrew Tridgell, é uma aplicação para
sistemas Unix que permite a existência de uma partilha de ficheiros/impressoras entre
sistemas Unix e Microsoft.
35
3.3.3 Geração dos pacotes Firefox e Samba
Os pacotes do Firefox (versão 3.6.xx) e do Samba (3.4.xx) foram reconstruídos tendo
por base os respetivos códigos-fonte obtidos pela ferramenta apt-get com os
comandos apt-get source firefox e apt-get source samba.
3.3.4 Problemas e resolução do pacote do Firefox
De forma a poder ser possível corrigir a anomalia e recompilar o pacote, seguindo os
passos indicados nas secções 2.2.2.1 e 2.2.2.2, foi necessário proceder à instalação de
alguns pacotes essenciais à compilação descritos na secção 2.2.2.3. Trata-se do pacote
mozilla-devscripts que cria extensões de empacotamento para ficheiros XUL
(linguagem de interface do utilizador), baseado em aplicações simples, do pacote
sharutils que cria ficheiros do tipo shell, baseado noutros ficheiros do mesmo tipo, do
pacote autoconf2.13 e da biblioteca zlib1g-dev (implementa o método de compressão
de ficheiros do tipo gzip e pkzip e contém ficheiros de suporte ao desenvolvimento).
3.3.4.1 Integração do Firefox com o serviço SSO em NTLM No caso do Firefox, o pacote teve de ser refeito dado que o mesmo não integra, por
norma, o serviço de Single Sign On em NTLM.
Para que fosse possível que o NTLM funcionasse com o Firefox foi necessário
proceder à alteração de um ficheiro do código-fonte do Firefox que está relacionado
com a autenticação em Samba, sendo que o ficheiro em questão denomina-se de
nsAuthSambaNtlm.cpp. Este ficheiro permite que as credenciais utilizadas no início
da sessão do posto de trabalho sejam usadas automaticamente no acesso de algumas
páginas internas da empresa.
De forma a acrescentar esta funcionalidade foi necessário proceder à realização dos
seguintes passos:
• descarregar o código-fonte do Firefox executando o comando apt-get
source firefox
36
o irá ser criada a diretoria firefox-3.6.23+build1+nobinonly que
contêm três ficheiros
i. firefox_3.6.23+build1+nobinonly-0Ubuntu0.10.04.1.diff.gz
ii. firefox_3.6.23+build1+nobinonly-0Ubuntu0.10.04.1.dsc
iii. firefox_3.6.23+build1+nobinonly.orig.tar.gz
• entrar na diretoria firefox-3.6.23+build1+nobinonly e criar a diretoria
denominada de build-tree
• copiar o ficheiro mozilla-1.9.2-3.6.23+build1-source.tar.bz2 para a
diretoria build-tree e extrair o ficheiro executando o comando tar jxf
mozilla-1.9.2-3.6.23+build1-source.tar.bz2
• remover o ficheiro mozilla-1.9.2-3.6.23+build1-source.tar.bz2
• modificar o caminho do NTLM no ficheiro nsAuthSambaNTLM.cpp,
que está sob a estrutura de diretorias mozilla/extensions/auth
o editar o caminho do NTLM na linha 208, para que fosse possível
executar o SSO em NTLM. A função deverá ter o seguinte
conteúdo:
char* args[] = {
"/usr/bin/ntlm_auth",
"--helper-protocol", "ntlmssp-client-1",
"--use-cached-creds",
"--username", const_cast<char*>(username),
nsnull
};
• voltar a compactar a diretoria Mozilla executando o comando tar jcf
mozilla-1.9.2-3.6.23+build1-source.tar.bz2 mozilla/
• eliminar a diretoria mozilla e copiar o ficheiro mozilla-1.9.2-
3.6.23+build1-source.tar.bz2 para o seu local original
• eliminar a diretoria build_tree
• executar o comando dh_make para criar a diretoria debian
• actualizar a versão do pacote no ficheiro debian/changelog da seguinte
forma:
37
vim debian/changelog
firefox (3.6.23+build1+nobinonly-0ubuntu0.10.04.2) lucid-security;
urgency=low
* New upstream release v3.6.23 (FIREFOX_3_6_23_BUILD1)
- change ntlm_auth path in file nsAuthSambaNTLM.cpp
-- Angulo Solido <[email protected]> Tue, 08 Nov 2011 01:44:31 -
0500
• eliminar o arquivo original e compactar o novo arquivo modificado
como firefox_3.6.23+build1+nobinonly.orig.tar.gz
3.3.4.2 Compilação e construção do pacote Firefox Após a obtenção do código-fonte, da verificação das anomalias e da correção das
mesmas é necessário proceder à compilação do pacote seguindo os passos indicados
na secção 2.2.2.3 e, de seguida, construir o pacote tal como indicado na secção
2.2.2.4. Para construir o pacote foi executado o comando debuild.
3.3.5 Problemas e resolução do pacote Samba O código-fonte obtido do Samba não estava a funcionar devido ao problema descrito
na secção seguinte. Para corrigir as anomalias e recompilar o pacote, seguindo os
passos indicados nas secções 2.2.2.1 e 2.2.2.2, foi necessário instalar alguns pacotes e
ferramentas essenciais à compilação descritos na secção 2.2.2.3. Entre os quais foi
necessário proceder à instalação: da ferramenta debhelper que reconhece o código do
ficheiro debian/rules e ajuda na criação do pacote, da biblioteca libpam0g-dev, do
pacote libcups2-dev que incluí as bibliotecas de desenvolvimento e drivers para o
sistema de impressão, do pacote libacl1-dev que incluí as bibliotecas de
desenvolvimento da lista do controlo de acessos, do pacote libkrb5-dev que incluí as
bibliotecas de desenvolvimento do Kerberos, do pacote libldap2-dev que incluí as
bibliotecas de desenvolvimento do ldap, da ferramenta po-debconf que gere os
ficheiros do debconf (é uma aplicação que permite gerir as configurações de uma
38
aplicação, após a sua instalação), do pacote libtalloc-dev que incluí as bibliotecas de
desenvolvimento de alocação de memória, do pacote libkeyutils-dev que incluí as
bibliotecas de desenvolvimento que permite a retenção de credenciais no kernel e do
pacote pkg-config.
3.3.5.1 Integração de Samba com NTLM
O pacote Samba teve de ser reconstruído a partir do código-fonte para ser possível
integrar o pacote Samba com o NTLM. Neste caso, foi necessário integrar a
funcionalidade do NTLM com o sistema de impressão da instituição, evitando, assim,
que cada vez que fosse feita uma impressão fossem pedidas as credenciais ao
utilizador. Para executar as alterações necessárias ao funcionamento do pacote com as
novas funcionalidades foi necessário realizar os seguintes passos:
a) descarregar o código-fonte do Firefox executando o comando apt-get
source samba
o irá ser criada a diretoria samba-3.4.7~dfsg que contêm dois ficheiros
samba_3.4.7~dfsg-1ubuntu3.8.dsc
samba_3.4.7~dfsg-1ubuntu 3.8.debian.tar.gz samba_3.4.7~dfsg.orig.tar.bz2
b) editar o ficheiro winbindd_pam.c na diretoria source3/winbindd, de forma
a adicionar a nova funcionalidade associada ao winbind
if (NT_STATUS_IS_OK(name_map_status) ||
NT_STATUS_EQUAL(name_map_status,
NT_STATUS_FILE_RENAMED)) {
fstrcpy(state->request.data.auth.user, mapped);
}
if (!canonicalize_username(state->request.data.auth.user, name_domain,
name_user)) {
result = NT_STATUS_NO_SUCH_USER;
goto done;
}
39
c) editar o ficheiro debian/changelog indicando a atualização realizada
vim debian/changelog
samba (2:3.4.7~dfsg-1ubuntu3.8.1) lucid-security; urgency=low
* Update file source3/winbindd/winbindd_pam.c to work with NTLM
-- Angulo Solido <[email protected]> Tue, 08 Nov 2011 11:51:06
-0400
3.3.6 Compilação e construção do pacote Samba Após a obtenção do código-fonte, da verificação da anomalia e da correcção da
mesma é necessário proceder à compilação do pacote seguindo os passos indicados na
secção 2.2.2.3 e, de seguida, construir o pacote tal como indicado na secção 2.2.2.4.
Para construir o pacote foi executado o comando debuild.
3.3.7 Teste de integração do Firefox
3.3.7.1 Teste número 1
o Objetivo – testar se ao abrir uma página da intranet, através do navegador
Firefox, são pedidas as credenciais ao utilizador;
o Resultado esperado – abrir a página da intranet e não serem pedidas as
credenciais ao utilizador;
o Passos efectuados
a) realizar o login (utilizando uma conta de domínio da instituição de
acolhimento) num computador que estava registado no domínio da página a
que o Firefox iria aceder;
b) abrir a aplicação Firefox;
c) escrever o endereço de uma página da intranet que iria necessitar que fossem
colocadas as credenciais de um utilizador da empresa, no Firefox.
o Resultado obtido – a página abriu sem pedir credenciais.
40
3.3.8 Teste de integração do Samba
3.3.8.1 Teste número 1 o Objetivo – testar se ao imprimir um ficheiro são pedidas as credenciais;
o Resultado esperado – imprimir um ficheiro e não serem pedidas as credenciais
ao utilizador;
o Passos efectuados
a) realizar o login (utilizando uma conta de domínio da instituição de
acolhimento) num computador que estava registado no mesmo domínio para
onde seriam enviados documentos para o sistema de impressão;
b) abrir um documento em LibreOffice;
c) efetuar a impressão para a impressora de rede que iria necessitar que fossem
colocadas as credenciais de um utilizador da empresa, através do cups (pacote
que gere as impressoras);
o Resultado obtido – a página imprimiu sem pedir credenciais.
3.4 Activar blacklist de pacotes
3.4.1 Definição de blacklist
Blacklist[33] é uma lista que impossibilita algum utilizador ou serviço de executar
determinadas tarefas ou ações em determinada situação.
Neste caso, a ideia base para a utilização de blacklist em pacotes é evitar a atualização
de pacotes. Apesar das vantagens associadas à manutenção de versões atualizadas dos
pacotes (estabilidade das aplicações e segurança), a atualização pode não ser
desejável nos pacotes que foram modificados e onde as novas versões não
contemplam essas modificações.
41
3.4.2 Problemas e resolução
Para que o pacote Samba não fosse atualizado (para não perder as configurações da
integração com o NTLM), foi necessário ativar a blacklist de um conjunto de pacotes
pré-definidos no script, de forma a que o sistema nunca fizesse a atualização desses
pacotes, como é exemplo o pacote do Samba e o pacote do Cups.
De forma a evitar que o pacote fizesse a atualização foi executado o comando echo
samba hold | dpkg --set-selections.
3.4.3 Teste da aplicação da blacklist Para que a distribuição seja atualizada será sempre utilizada a opção apt-get install –y,
de forma a garantir que não é necessária a intervenção humana durante a instalação de
um pacote.
Quando se tentar actualizar de forma automática/automatizada os pacotes do Ubuntu
que estejam marcados para não fazerem actualizações, os pacotes serão impedidos de
instalar no sistema, uma vez que estão selecionados na blacklist, dando um erro que
não é possível proceder à instalação dos pacotes em questão.
Apenas se conseguiria fazer a actualização destes pacotes se fosse utilizada a opção --
force-yes com o comando apt-get install e este não é o procedimento comum, por
questões de segurança do próprio sistema.
3.4.3.1 Teste número 1
o Objetivo – verificar se é possível instalar as novas versões do pacote cups e
do pacote samba;
o Resultado esperado – os pacotes não serem atualizados;
o Passos efectuados
a) abrir um terminal;
b) executar o comando apt-get install –y samba cups;
o Resultado obtido – o terminal mostra uma mensagem de erro indicando que
os pacotes não foram atualizados.
42
3.5 Pré-requisitos para administração remota automatizada
3.5.1 Definição de administração remota automatizada A um sistema que permite que seja gerido remotamente e de forma automática
designamos de administração remota automatizada.
A administração remota automatizada permite eliminar tarefas repetitivas, tais como a
actualização ou a instalação de software num elevado número de máquinas.
Para proceder à administração remota automatizada o administrador deve executar
uma aplicação ou um script no servidor que vai automatizar as tarefas nos postos de
trabalho.
3.5.2 Problemas e resolução
De forma a poder resolver questões, instalar aplicações ou outro tipo de tarefas que
pudessem ser executadas remotamente foi adicionada esta funcionalidade que,
inicialmente, ainda não estava integrada na distribuição do Ubuntu. Esta nova
funcionalidade permitiu que, através do servidor, fosse possível administrar os postos
de trabalho (clientes) remotamente via protocolo Secure SHell[34] (ssh) replicando os
passos repetitivos automaticamente entre várias máquinas.
A automatização da administração remota (que seria, posteriormente, integrada no
script, indicado na secção 4) deveria contemplar a criação do utilizador de sistema
(designadamente support) que tivesse privilégios de administração nos postos de
trabalho remotos, a criação do ficheiro ~/.ssh/authorized_keys para que esse utilizador
obtivesse uma chave privada (que seria passada como variável no script) e a
configuração do ficheiro sudoers (lista de quem tem permissões para gerir um
determinado ficheiro ou aplicação), de forma a que esse utilizador pudesse utilizar o
comando apt-get sem que fosse pedida a password.
43
3.5.3 Teste da implementação da administração remota automatizada
o Objetivo – executar comandos de instalação de aplicações sem ser pedida a
password de administrador;
o Resultado esperado – fazer a instalação do Firefox sem ser pedida a
password;
o Passos efectuados
a) abrir um terminal no servidor;
b) executar o script pkg-debian da seguinte forma: ./pkg-debian.sh install
firefox IP_máquina_1 IP_máquina_2
o Resultado obtido – fez a instalação do Firefox sem ser pedida a password.
3.6 Testar integração com AD via winbind
3.6.1 Definição de Winbind
O Winbind[35] é uma ferramenta que permite que computadores com sistemas UNIX
realizem a autenticação numa Active Directory, sendo que este é um pacote opcional
do Samba.
Neste caso específico pretendia-se a utilização do Winbind em vez do Likewise,
porque o pacote do Samba necessita do Winbind para fazer autenticação via NTLM.
Nesta secção apenas foi testada a integração da AD com o Winbind para confirmar
que as novas funcionalidades adicionadas ao pacote do Samba executavam
corretamente e não interferiam com as já existentes, como por exemplo o login nos
postos de trabalho.
3.6.2 Teste de integração com a AD via Winbind
Este teste foi realizado utilizando os passos (referente ao tópico dos testes) indicados
no pacote do Firefox.
44
4 Personalização de Postos de Trabalho e Servidores
4.1 Descrição A personalização de postos de trabalho/servidores é um conjunto de scripts que
permitem simplificar a configuração dos diferentes postos de trabalho. Com estes
scripts é possível configurar de forma automática os serviços necessários para o posto
de trabalho funcionar na rede da empresa e para ficar disponível para, posteriormente,
ser possível fazer manutenção de forma remota.
De forma a ser possível a personalização de postos de trabalho/servidores, foi
implementado um script de pós-instalação que transforma o Ubuntu num posto de
trabalho com várias funcionalidades permitindo, por exemplo, a possibilidade de
execução de políticas enviadas através do servidor. Também foi criada uma biblioteca
de políticas e scripts de aplicação de políticas dividida em 3 secções: scripts comuns,
scripts de grupos e os de utilizadores como se pode verificar na próxima secção 4.2.
4.2 Instalação e operação de sistemas A Ângulo Sólido tem um sistema desenvolvido para permitir de forma automatizada a
instalação, configuração e manutenção do posto de trabalho Linux, bem como o do
servidor de suporte à gestão. No âmbito deste trabalho, foram desenvolvidas algumas
funcionalidades referidas na secção 3, tais como a customização de políticas por
utilizador e grupos, a adição de computadores ao domínio e o mapeamento
automático (que funcionasse em versões de Ubuntu 10.04 e 12.04) de diretorias
partilhadas. Os procedimentos foram desenvolvidos no âmbito dos quais se encontram
as funcionalidades de automatizar a integração do posto de trabalho na infraestrutura
existente, minimizando o conjunto de passos manuais. Nesta secção estão cobertos os
seguintes tópicos:
• Instalação do sistema
o Instalação de servidor
o Instalação de posto de trabalho
• Operação do sistema: configuração de perfis baseada em políticas
45
• Administração remota automatizada
4.2.1 Instalação do Sistema
4.2.1.1 Instalação de servidor
O servidor foi instalado com a versão Ubuntu Server 10.04 LTS. Foi colocado um
arquivo que continha o script e todos os ficheiros de configuração necessários à
personalização do servidor. Dentro do arquivo existiam dois ficheiros que continham
as configurações relativas à personalização, dos quais se podem destacar o ficheiro
ubuntu.conf (ficheiro que contém as definições do script de configuração automática
do Ubuntu Server) e o ficheiro install.sh (script de configuração automática do
Ubuntu Server).
A configuração do servidor faz-se executando o ficheiro install.sh. Quando este
ficheiro é executado surge no ecrã a informação que a instalação está a decorrer.
Durante a execução é pedida uma password que serve para cifrar a chave pública que
é utilizada para permitir a administração centralizada dos postos de trabalho. Esta
password é necessária, posteriormente, na instalação de cada posto de trabalho
administrado.
Após a execução do script install.sh devem ser definidas as passwords UNIX e
SAMBA para o utilizador de administração designado por support. Estas definições
são necessárias para a gestão dos sistemas instalados, como se pode verificar nas
próximas secções deste capítulo.
4.2.1.2 Instalação do posto de trabalho O posto de trabalho foi instalado com a versão Ubuntu Desktop 10.04 LTS. Foi
colocado um arquivo em cada posto de trabalho que continha o script e todos os
ficheiros de configuração necessários à personalização do posto de trabalho. Dentro
do arquivo existiam dois ficheiros que continham as configurações relativas à
personalização, dos quais se podem destacar o ficheiro ubuntu.conf (ficheiro que
46
contém as definições do script de configuração automática do Ubuntu Desktop) e o
ficheiro install.sh (script de configuração automática do Ubuntu Desktop).
Algumas das variáveis mais relevantes contidas no ficheiro ubuntu.conf são:
# Domain and AD related variables
SERVER=w2k3
NETBIOSNAME=TESTEAD
TLD=INTRANET
JOINUSER=administrator
JOINPASSWORD=lisboa.1
# define the proxy server
PROXYHOST="http://192.168.1.2"
PROXYPORT=3128
# remote management related variables
SUPUSER=support
KEYHOST=ubuntusrv.$NETBIOSNAME.$TLD
# other variables
SCRIPTHOST= ubuntusrv.$NETBIOSNAME.$TLD
PRINTUSER=winprintuser
PRINTPASSWORD=lisboa.1
Deste conjunto de variáveis, aquelas que devem ser editadas em qualquer
circunstância são: SERVER (nome do servidor), NETBIOSNAME (nome do sub-
domínio), TLD (nome do domínio), JOINUSER (utilizador a adicionar ao domínio),
JOINPASSWORD (password do utilizador a adicionar ao domínio), PROXYHOST
(caminho da Proxy) e PROXYPORT (porto da proxy). No caso de a impressão ser
autenticada deveriam ser definidas as credenciais de serviço nas variáveis
PRINTUSER (username que permite que os utilizadores dos postos de trabalho
possam imprimir) e PRINTPASSWORD (contém a senha do username guardado em
PRINTUSER). Também foi necessário modificar as variáveis SCRIPTHOST E
KEYHOST que continham o caminho do servidor de domínio.
A configuração do posto de trabalho faz-se executando o ficheiro install.sh. Quando
este ficheiro é executado surge no ecrã a informação que a instalação está a decorrer.
47
Durante a instalação é pedida uma password que serve para decifrar a chave pública
do utilizador support. Esta chave pública é criada durante a instalação do servidor e
obtida automaticamente pelos postos de trabalho.
4.2.2 Operação do sistema: configuração de perfis baseada em políticas De forma a ser possível gerir de forma centralizada as configurações dos utilizadores,
optou-se por criar uma estrutura de gestão de políticas. A cada login, as políticas que
estão definidas no servidor são aplicadas de acordo com a hierarquia de políticas
globais, de grupo e de utilizador existente no servidor.
As políticas podem ser aplicadas das seguintes formas:
• global - políticas aplicadas a todos os utilizadores;
• por grupo - políticas aplicadas aos utilizadores em função da sua pertença a
determinados grupos;
• por utilizador - políticas específicas aplicadas individualmente a utilizadores.
Estas políticas são aplicadas por scripts que, após a instalação e configuração do
servidor, podem ser criados numa diretoria específica. Estes scripts aplicam as
políticas no processo de login pela seguinte ordem:
• é aplicado o script global a todos os utilizadores da AD;
• são aplicados, quando existem, os scripts dos grupos a que o utilizador
pertence na ordem pela qual o Active Directory os lista;
• é aplicado, caso exista, o script específico de cada utilizador.
Desta forma, as políticas mais específicas prevalecem sobre as mais gerais, o que
significa que as políticas de utilizador irão prevalecer sobre as políticas atribuídas
pelos grupos e estas sobre as políticas globais.
Exemplo: se a política global indicar que a homepage do firefox é a página
www.google.pt e se a política de utilizador indicar que a homepage do firefox para o
utilizador usertest é a página www.sapo.pt então quando o utilizador usertest fizer
login no computador e abrir o browser firefox, a sua página inicial será a página
www.sapo.pt
48
4.2.2.1 Acesso e edição de políticas Para poder criar, editar ou eliminar políticas é necessário que o utilizador tenha acesso
ao servidor com permissões de leitura/escrita. O acesso ao servidor pode ser feito por
SSH ou Samba. Todas as políticas gerais do domínio encontram-se no ficheiro
global.sh, o qual engloba todas as definições comuns referentes aos postos de
trabalho.
4.2.2.2 Estrutura de scripts O conteúdo da diretoria de scripts reflete a hierarquia de políticas já descrita na
secção 4.2.2. Na diretoria principal (dos scripts) existe um script global, designado de
global.sh, e um conjunto de scripts englobados nas diretorias GROUPS e USERS.
Também existe uma diretoria chamada COMMON dentro da qual o ficheiro common
reúne as funções comuns usadas na aplicação de políticas de grupo/utilizadores. Este
ficheiro é, essencialmente, uma biblioteca de funções que pode ser desenvolvida ao
longo do tempo e à medida que surge a necessidade de criar diferentes políticas.
4.2.2.3 Tipos de políticas Podem ser aplicadas políticas a diferentes tipos de serviços. Os tipos implementados
foram os seguintes:
• definições do Firefox: podem definir-se a homepage, a whitelist (lista com
todos os sites permitidos) para SSO, a configuração de proxy ou qualquer
preferência individualmente;
• definições dos mapeamentos de diretorias efectuados durante o login;
• gestão de impressoras adicionadas durante o login e definição da impressora
default;
• outras definições.
Na próxima secção apresenta-se um conjunto de exemplos de aplicação de políticas.
49
A empresa Ângulo Sólido utiliza um conjunto de políticas para a configuração de
funcionalidades dos postos de trabalho, tais como a definição da página inicial do
navegador Firefox ou o mapeamento de uma área partilhada.
4.2.2.3.1 Definições do Firefox
• Para definir a página inicial do Firefox é necessário aplicar uma política que
execute o comando firefox_set_homepage <homepage>
• Para definir uma whitelist para Single Sign On (SSO)
o de forma a permitir que o SSO seja feito nos seguintes sites
http://servidor1.exemplo.pt e https://servidor2.exemplo.pt é necessário
executar o comando
firefox_set_sso http://servidor1.exemplo.pt,https://servidor2.exemplo.pt
o de forma a permitir que o SSO seja feito em todos os sites com
domínio intranet é necessário executar o comando firefox_set_sso
intranet
• Para definir vários tipos de Proxy (tipo de proxy e respectivo endereço) de
forma a:
o aceder directamente à internet, sem proxy, é necessário executar o
comando firefox_set_proxy 0
o configurar manualmente o proxy é necessário executar o comando
firefox_set_proxy 1 192.168.1.2 3128
o configurar manualmente o proxy com excepção para uma lista de
domínios para os quais o proxy não é usado é necessário executar o
comando firefox_set_proxy 1 192.168.1.2 3128 "testead.intranet,
google.com"
o configurar automaticamente o proxy utilizando os dados que se
encontram no ficheiro wpad.dat é necessário executar o comando
firefox_set_proxy 2 http://192.168.1.2/wpad.dat
o detetar automaticamente as definições de proxy. O objetivo desta
configuração é o Firefox localizar, na rede onde se encontra, o ficheiro
50
proxy.pac (proxy auto configuration) e assumir as suas definições, para
o que é necessário executar o comando firefox_set_proxy 4
o utilizar as definições da proxy de sistema. Estas definições estão
disponíveis no menu System --> Preferences --> Network Proxy.
Também é possível executar este comando manualmente da seguinte
forma firefox_set_proxy 5
4.2.2.3.2 Mapeamento de diretorias Para definir o mapeamento de diretorias é necessário criar variáreis que facilitem a
legibilidade e, de seguida, chamar a função mountshare (que permite carregar as
diretorias partilhadas) que se encontra definida no ficheiro common na diretoria
COMMON no servidor. Exemplo de aplicação de um mapeamento de diretorias:
SERVER=fileshare
SHARENAME="Arquivo"
mountshare $SERVER "$SHARENAME" $USERNAME $PASSWORD
4.2.2.3.3 Gestão de impressoras
• Mapeamento de impressoras
Para mapear impressoras Windows através de políticas será necessário saber o
endereço do servidor de impressão, o controlador a utilizar e o conjunto de opções
pretendidas.
O Ubuntu disponibiliza controladores para impressoras compatíveis com os
protocolos de impressão mais comuns (via cups). Exemplo de aplicação de um
mapeamento de uma impressora:
PRINTSERVER=W2K3-AD
NETBIOSNAME=TESTEAD
SHARENAME=HPWindowsSRV
OPTIONS="-o media=A4 -o printer-is-shared=false"
51
DRIVER="/usr/share/ppd/cups-included/postscript.ppd"
sudo lpadmin -p HPPS_AUTO $OPTIONS –v
"smb://$NETBIOSNAME/$PRINTSERVER/$SHARENAME" -P $DRIVER -E
• Definição da impressora por omissão
O sufixo "_AUTO" obriga a que as impressoras sejam removidas sempre que um
utilizador faça logout do sistema. Deve ser usado este sufixo para as impressoras
definidas por política, as quais, desta forma, se distinguem das impressoras
adicionadas manualmente que nunca são removidas pelo sistema.
4.2.2.3.4 Outras definições
• Para definir o wallpaper é necessário executar o comando
gnome_set_wallpaper /usr/share/backgrounds/space-05.jpg
• Para definir outras preferências do GNOME
o para definir qualquer preferência do GNOME a sintaxe genérica é a
seguinte gnome_set_pref PATH VALUE TYPE
o para desactivar os visibilidade dos volumes montados no desktop é
necessário executar o comando gnome_set_pref
/apps/nautilus/desktop/volumes_visible false bool
• Para executar políticas a partir de outro script
COMMONPATH=`dirname $3`
runScript $COMMONPATH/../PRINTERS/common-bep.sh
4.2.3 Administração remota automatizada A administração remota automatizada permite eliminar tarefas repetitivas, tais como a
atualização ou instalação de software num elevado número de postos de trabalho.
52
Para proceder à administração remota automatizada o administrador deve aceder ao
servidor via SSH com o utilizador support. Este utilizador tem acesso aos postos de
trabalho logo após a instalação de cada um destes. Isto acontece porque a criação e
disponibilização da sua chave pública - sob forma cifrada - é feita automaticamente na
instalação do servidor e os postos de trabalho descarregam-na automaticamente.
Sendo assim, a password do utilizador support do servidor dá acesso às funções de
administração centralizada e as mesmas podem ser executadas de forma síncrona, as
quais se descrevem de seguida.
4.2.3.1 Instalação e atualização de pacotes Após aceder ao servidor via SSH o utilizador tem de garantir que está na diretoria
onde se encontra o script pkg-debian.sh (script que permite realizar a administração
remotamente) e, de seguida, executar o script com os seguintes parâmetros: ./pkg-
debian.sh install|update package_name host1 host2 ... hostn
Exemplo 1 - Instalar o pacote pdfedit nos postos de trabalho com os IPs 192.168.1.52
192.168.1.53
./pkg-debian.sh install pdfedit 192.168.1.52 192.168.1.53
Exemplo 2 - Atualizar o pacote firefox em todos os postos de trabalho listados no
ficheiro GP-TESTES.txt
./pkg-debian.sh update firefox `cat GP-TESTES.txt`
4.2.3.2 Ativação de políticas por posto de trabalho Para além das tarefas executáveis, simultaneamente, em múltiplos postos de trabalho,
conforme descrito na secção anterior, é possível impor configurações e executar ações
em cada posto de trabalho na altura do arranque do sistema. Este mecanismo é
conceptualmente análogo às políticas dos utilizadores. De facto, enquanto os perfis
dos utilizadores são impostos por política a cada login, os "perfis" dos postos de
trabalho podem ser impostos por política no momento do arranque do sistema.
53
As políticas podem então ser aplicadas de forma:
• global - políticas aplicadas a todos os postos de trabalho;
• por grupo - políticas aplicadas ao postos de trabalho de um determinado grupo
da AD;
• por posto de trabalho - políticas aplicadas ao posto de trabalho com um
determinado hostname.
As políticas aplicáveis a todos os postos são definidas no script COMPUTERS/all.sh,
presente na mesma diretoria partilhada das políticas dos utilizadores. As políticas
aplicáveis a cada posto em particular ficam definidas em ficheiros da forma
<HOSTNAME>.sh. No final do arranque o posto de trabalho executa o script all.sh e
o script relativo ao seu hostname caso esse esteja presente.
Algumas ações facilmente definíveis são:
• garantir a presença de um determinado pacote;
• garantir a ausência de um determinado pacote;
• testar a presença de determinada aplicação não empacotada e lançar o
instalador caso este não esteja presente.
4.2.3.3 Atualizações automáticas nos postos de trabalho O instalador dos postos de trabalho disponibiliza uma configuração pré-definida de
atualizações automáticas para software da distribuição Linux. Essa configuração foi
realizada com as seguintes características:
• utilização exclusiva dos repositórios de segurança;
• periodicidade diária com início às 03:00;
• aviso de necessidade de reboot a todos os utilizadores ligados por X ou XRDP,
sempre que as atualizações o exigirem;
• tempo entre o aviso e o reboot de 10 minutos.
Exemplo da configuração pré-definida no ficheiro /etc/crontab:
0 3 * * * root su - -c "/usr/local/AR/bin/deb-do-updates.sh" >& /tmp/updates.log
54
Esta configuração assenta no princípio do risco mínimo, utilizando apenas os
repositórios de segurança, mesmo que haja pacotes com correção de erros que sejam
mais recentes e que estejam disponíveis. A atualização para essas versões nunca é
feita automaticamente e só se fazem atualizações automáticas para a correção de
vulnerabilidades. Devido ao elevado risco associado às atualizações do kernel, estas
apenas deverão ser feitas através do comando pkg-debian.sh descrito na secção
anterior.
4.3 Portar os scripts do Ubuntu 10.04 para o 12.04
Estes scripts são compostos por vários comandos que automatizam a configuração
dos postos de trabalho, o que permite que sejam configurados vários postos de
trabalho ao mesmo tempo. Este conjunto de scripts foi inicialmente produzido com
base na estrutura e nos pacotes do Ubuntu 10.04 LTS.
4.3.1 Necessidade de portar o script
Com os constantes avanços tecnológicos e com as atualizações bianuais lançadas pela
empresa Canonical surgiu a necessidade de proceder à migração do trabalho realizado
para a nova versão 12.04 LTS.
Ao migrar para a uma nova versão garante-se um acréscimo de cinco anos de suporte
e atualizações de pacotes e um nível de segurança superior.
4.3.2 Problemas encontrados inicialmente
De forma a poder identificar quais as principais diferenças e problemas ao nível dos
pacotes reconstruídos foi necessário proceder à listagem de funcionalidades do
trabalho desenvolvido, podendo assim atualizar as mesmas para funcionarem na nova
versão. Por fim, foi necessário realizar testes de integração das funcionalidades para
verificar o seu correto funcionamento.
55
4.3.3 Funcionalidades
As funcionalidades listadas da versão 10.04 LTS são as seguintes:
• aceder via rdesktop a um posto de trabalho Linux (utilizando os pacotes do
XRDP e do X11RDP);
• autenticar um utilizador existente na AD (utilizando o pacote do Winbind);
• aplicar políticas via administração remota automatizada;
• configurar as impressoras locais e impressão de documentos sem ser
necessário colocar a password (utilizando o pacote do Samba);
• verificar se as impressoras são instaladas e removidas corretamente;
• verificar se as diretorias partilhadas da rede são instaladas e removidas
corretamente;
• confirmar que o Exchange funciona corretamente ao nível do correio
electrónico, do calendário, da marcação de reuniões via correio
electrónico, dos contactos pessoais e da lista global de endereços;
• identificar se o Evolution funciona corretamente ao nível do correio
electrónico, do calendário, da marcação de reuniões via correio
electrónico, dos contactos pessoais e da lista global de endereços;
• verificar se o Firefox abre uma página de intranet específica sem pedir
credenciais;
• confirmar se os pacotes colocados em blacklist se mantêm nesse estado.
4.3.4 Testes da integração do script na versão 12.04 LTS
o Objetivo – confirmar se a migração dos scripts da versão 10.04 LTS para a
versão 12.04 LTS foi realizada com sucesso;
o Resultado esperado – todas as funcionalidades mencionadas na secção 4.2.3
sejam migradas/atualizadas para a versão 12.04 LTS com sucesso;
o Passos efectuados
a) criar um utilizador na active directory;
o aceder ao servidor que tem uma active directory a funcionar; demonstrar a
autenticação desse utilizador num remote desktop; demonstrar a
56
autenticação desse user directamente na máquina virtual;
b) demonstrar a alteração de password por parte do utilizador;
c) desligar a sessão, deixando-a activa, e retomá-la a partir da máquina virtual;
d) desligar a sessão, deixando-a activa, e retomá-la com o cliente RDP de um
outro computador, verificar que é possível retomá-la com diferentes
tamanhos e profundidades de cor;
e) demonstrar o push de políticas: proxy e whitelist SSO NTLM e Kerberos
(usar o script global), homepage do firefox e shares de rede (exemplo com
dois grupos individuais), impressoras de rede (exemplos para dois
utilizadores individuais);
f) demonstrar que a autenticação num site com NTLM funciona
automaticamente (comparar com um user não autenticado no AD mostrando
que neste caso é pedida a password);
g) demonstrar que o push das políticas é aplicável tanto instalações feitas
numa máquina virtual como as máquinas virtuais acessíveis por RDP;
h) fazer a demonstração dos passos 5 e 6 no terminal RDP;
i) demonstrar a configuração manual de uma impressora SMB sem necessitar
da password de root;
j) demonstrar que é possível instalar pacotes no computador do cliente através
de administração remota;
o Resultado obtido – todas as funcionalidades mencionadas na secção 4.2.3
foram migradas/atualizadas para a versão 12.04 LTS com sucesso.
4.4 Avaliação e Resultados O trabalho realizado no âmbito de um sistema desenvolvido pela Ângulo Sólido para
a automatização da gestão de postos de trabalho. Este sistema assenta num script que
personaliza e atualiza os postos de trabalho de acordo com as necessidades de cada
pessoa/organização, facilitando largamente as tarefas de administração de sistemas.
A alteração dos pacotes do Firefox e do Samba permitiu a integração de autenticação
por NTLM, reduzindo o esforço individual dos utilizadores, dado que a autenticação
para aceder a páginas da intranet ou para enviar documentos para impressão passou a
57
ser omitida. Desta forma, evitou-se que os utilizadores tivessem que colocar sempre
as suas credenciais quando pretendiam realizar algumas destas tarefas.
A introdução da administração remota automatizada, através de execução de tarefas a
partir de um servidor para os postos de trabalho, permitiu eliminar tarefas repetitivas
como, por exemplo, a instalação de uma aplicação em vários postos de trabalho. A
adopção deste método facilitou as tarefas aos administradores de sistemas, evitando
que os mesmos necessitassem de estar fisicamente presentes para executar os
comandos, uma vez que estas tarefas podiam ser agendadas.
Durante o estágio efetuado na empresa Ângulo Sólido existiu a necessidade de portar
o trabalho desenvolvido para a nova versão LTS, devido às atualizações bianuais
lançadas pela empresa Canonical. Este trabalho permitiu utilizar uma versão mais
atualizada do Ubuntu do sistema de administração da Ângulo Sólido, estendendo o
suporte de Canonical por mais cinco anos. Esta migração para a versão 12.04 LTS foi
relativamente simples, tendo apenas sido feitos pequenos ajustes aos pacotes
alterados, de forma a que os mesmos pudessem manter as suas novas funcionalidades.
Em todos os passos referidos anteriormente, tais como as tarefas realizadas e a adição
de novas funcionalidades, foram realizados testes exaustivos a cada um dos pacotes e
tarefas, conforme referido na secção 3.7.4. Estes testes visaram garantir que as
principais funcionalidades já existentes continuassem a funcionar corretamente na
versão 12.04 LTS e que os serviços das duas versões fossem compatíveis.
Com a atualização dos postos de trabalho para a nova versão foi necessário proceder a
alterações nos scripts do servidor que eram aplicados por utilizador, posto de
trabalho, grupo ou, de forma geral, a todos utilizadores/postos de trabalho. Estes
scripts tinham de manter a coerência em ambas as versões, independentemente do
utilizador fazer login num posto de trabalho na versão 10.04 ou na versão 12.04.
Relativamente aos restantes pacotes e tarefas foram realizados testes individuais às
funcionalidades introduzidas com a modificação de pacotes/tarefas, de forma a
garantir que essas funcionavam corretamente.
58
5 Conclusão e trabalho futuro Os objetivos inicialmente propostos pela Ângulo Sólido foram cumpridos com
sucesso.
Inicialmente, não tinha experiência no desenvolvimento de pacotes. Porém, à medida
do desenrolar do estágio, fui aumentando gradualmente os meus conhecimentos sobre
ferramentas de controlo de versões (git e svn), correção de anomalias, introdução de
novas funcionalidades, compilação de código-fonte e criação de pacotes, como
descritos na secção 2.
Com o trabalho realizado ao longo deste estágio, fui desenvolvendo pacotes de acordo
com as normas dos repositórios oficiais, como descrevo na secção 3, de forma a que
os mesmos pudessem ser aprovados e integrados, posteriormente, nos repositórios do
código-fonte.
Este estágio permitiu a interação e a integração do trabalho desenvolvido não só nas
empresas-cliente da entidade acolhedora, mas também nos repositórios oficiais dos
pacotes em que foi dada a possibilidade de colaborar neste âmbito, destaca-se o caso
do pacote do XRDP em que os ficheiros criados/modificados surgem sob o nome de
Gustavo Homem (nome de utilizador “ghomem”) que era o elo de ligação entre o
trabalho desenvolvido neste pacote específico e Jay Sorg (nome de utilizador
“jsorg71”) que é o responsável pela manutenção do pacote XRDP. As modificações
realizadas neste pacote permitiram que todos os utilizadores de sistemas Unix que
obtenham a última versão do pacote XRDP possam utilizar, por exemplo, o teclado
com layout português ou o gestor sesman.
Após a modificação dos pacotes de acordo com as necessidades da empresa, os
mesmos foram adicionados ao script de personalização dos postos de trabalho.
No final do estágio todo o trabalho realizado para a versão 10.04 LTS teve de ser
adaptado para ser utilizado na versão 12.04 LTS, de forma a garantir que a empresa
Ângulo Sólido mantinha os postos de trabalho com a versão LTS mais recente. Desta
forma, os postos de trabalho tornaram-se mais seguros e com pacotes mais
atualizados. Este objetivo não estava inicialmente previsto, mas foi adicionado
posteriormente e testado como se pode verificar na secção 4.3.4.
Em suma, este estágio foi benéfico para mim, pois foi-me dada a possibilidade de
trabalhar num ambiente empresarial, com pessoas acessíveis e dispostas a ajudar-me e
59
a progredir profissionalmente. Também tive a possibilidade de explorar a área de
packaging, uma área na qual não tinha muita experiência.
5.1 Trabalho Futuro
Após a finalização deste estágio é importante avançar com possibilidades de trabalho
futuro para que a adopção das ideias formuladas seja feita de uma forma mais
sustentada. Assim sendo, considero que numa futura extensão ou conclusão deste
estágio deve proceder-se à adaptação do script personalizado para que também fosse
instalado o ambiente gráfico K Desktop Environment (KDE). Assim, os utilizadores
menos experientes de sistemas operativos Unix teriam a possibilidade de optar por um
ambiente gráfico semelhante ao encontrado em sistemas operativos Microsoft,
acelerando e facilitando a sua adaptação à nova realidade.
60
6 Bibliografia
[1] Canonical Ltd (2013). About Ubuntu The Ubuntu story. Disponível em:
http://www.ubuntu.com/project/about-ubuntu.
[2] Ubuntu Team Wiki (2013). LTS. Disponível em: https://wiki.ubuntu.com/LTS.
[3] Wikipédia (2013). Remote Desktop Protocol. Disponível em:
http://pt.wikipedia.org/wiki/Remote_Desktop_Protocol.
[4] Microsoft Corporation, "Remote Desktop Protocol : Basic Connectivity and
Graphics Remoting", 2013.
[5] Wikipédia (2013). Groupware. Disponível em:
http://pt.wikipedia.org/wiki/Groupware.
[6] Wikipédia (2013). Microsoft Exchange Server. Disponível em:
http://pt.wikipedia.org/wiki/Microsoft_Exchange_Server.
[7] Wikipédia (2013). Kerberos. Disponível em:
http://pt.wikipedia.org/wiki/Kerberos.
[8] C. Neuman, S. Hartman, T. Yu, K. Raeburn, “The Kerberos Network
Authentication Service (V5)”, 2005.
[9] Wikipédia (2013). NTLM. Disponível em: http://pt.wikipedia.org/wiki/NTLM.
[10] Wikipédia (2013). Dynamic Host Configuration Protocol. Disponível em:
http://pt.wikipedia.org/wiki/Dynamic_Host_Configuration_Protocol.
[11] Wikipédia (2013). Domain Name System. Disponível em:
http://pt.wikipedia.org/wiki/DNS.
[12] Wikipédia (2013). Proxy. Disponível em: http://pt.wikipedia.org/wiki/Proxy.
[13] Microsoft Corporation (2010). Domain Controller Roles. Disponível em:
http://technet.microsoft.com/en-us/library/cc786438(WS.10).aspx.
61
[14] Wikipédia (2013). Roteador. Disponível em:
http://pt.wikipedia.org/wiki/Roteador.
[15] Wikipédia (2013). VMware. Disponível em:
http://pt.wikipedia.org/wiki/Vmware.
[16] Free Software Foundation Inc. (2012). Overwiew of the GNU System.
Disponível em: http://www.gnu.org/gnu/gnu-history.html
[17] Wikipédia (2013). Linux. Disponível em: http://pt.wikipedia.org/wiki/Linux.
[18] Wikipédia (2013). Debian. Disponível em: http://pt.wikipedia.org/wiki/Debian.
[19] Wikipédia (2013). List of Linux distributions. Disponível em: http://en.wikipedia.org/wiki/List_of_Linux_distributions.
[20] Wikipédia (2013). Núcleo (software). Disponível em:
http://pt.wikipedia.org/wiki/Núcleo_(software).
[21] Wikipédia (2013). Mozilla Firefox. Disponível em:
http://pt.wikipedia.org/wiki/Firefox.
[22] Wikipédia (2013). LibreOffice. Disponível em:
http://pt.wikipedia.org/wiki/LibreOffice.
[23] Wikipédia (2013). Ubuntu. Disponível em:
http://pt.wikipedia.org/wiki/Ubuntu.
[24] Wikipédia (2013). Canonical Ltd. Disponível em:
http://pt.wikipedia.org/wiki/Canonical.
[25] A. Kumar (2013). 10 Linux Distributions and Their Targeted Users.
Disponível em: http://www.tecmint.com/10-linux-distributions-and-their-
targeted-users/.
[26] Ubuntu Team Wiki (2011). PackagingGuide/Complete. Disponível em:
http://web.archive.org/web/20110721233809/https://wiki.ubuntu.com/Packagin
gGuide/Complete.
62
[27] D. Morse (1989). UNIX man pages : make (). Disponível em: http://unixhelp.ed.ac.uk/CGI/man-cgi?make.
[28] S. Samar (1995). PAM. Disponível em: http://www.opengroup.org/rfc/mirror-
rfc/rfc86.0.txt.
[29] Jay Sorg (2009). xrdp. Disponível em: http://www.xrdp.org/.
[30] Wikipédia (2013). Active Directory. Disponível em:
http://pt.wikipedia.org/wiki/Active_Directory.
[31] Wikipédia (2013). Single Sign-On. Disponível em:
http://en.wikipedia.org/wiki/Single_sign-on.
[32] Wikipédia (2013). Samba. Disponível em:
http://pt.wikipedia.org/wiki/Samba_(servidor).
[33] Wikipédia (2013). Lista Negra. Disponível em:
http://pt.wikipedia.org/wiki/Lista_negra.
[34] T. Yloren, C. Lonvick (Ed), “The Secure Shell (SSH) Protocol Architecture",
Request for Comments 4251, IETF, Jan 2006
[35] Samba Wiki (2007). Winbind. Disponível em: http://wiki.samba.org/index.php/Winbind.