Estudo de Caso para a implementação de Desktop's Virtuais com OVD (Open Virtual Desktop) no 5 Batalhão de Engenharia de Combate Blindado

Transcrição

1 Estudo de Caso para a implementação de Desktop's Virtuais com OVD (Open Virtual Desktop) no 5 Batalhão de Engenharia de Combate Blindado Samuel Graeff Curso de Pós-Graduação em Redes e Segurança de Sistemas Pontifícia Universidade Católica do Paraná Curitiba, novembro de 2009 Resumo Em decorrência da complexidade e heterogeneidade dos atuais ambientes de Tecnologia de Informação, a busca pelo suporte na interoperabilidade das tecnologias de aplicações utilizadas nesses ambientes tem ganhado maior atenção nos últimos tempos. Incentivos do Governo Federal no Brasil em favor da migração para Software Livre desencadearam diversos projetos em âmbito Federal, destacando-se o Plano de Migração para Software Livre no Exército Brasileiro, que têm por objetivo a redução ao máximo das aplicações legadas utilizadas pela Força. O Open Virtual Desktop como solução de desktop virtual capaz de disponibilizar aplicações Linux e Windows em um mesmo ambiente, se mostra preparado para auxiliar no processo de migração, em fase que ainda os sistemas de gestão específicos do Exército Brasileiro não foram completamente migrados. 1 Introdução A mudança na cultura da TI de entidades e instituições públicas federais no Brasil, frente ao forte incentivo do Governo Federal para a adoção do Software Livre como plataforma única e exclusiva de utilização em substituição ao legado, está ocorrendo em processo acelerado. Juntamente com a mudança na cultura da TI, a complexidade gerada pela necessidade de uso de novas aplicações neste mercado, vem forçando cada vez mais a utilização de componentes desenvolvidos em plataformas diferentes, criando ambientes heterogêneos dentro das organizações, e implicando em uma corrida na busca por um ambiente de interoperabilidade ou mesmo de compatibilidade entre os sistemas. Ambientes complexos e esforços para a migração de sistemas proprietários são tema de discussão e muito trabalho nas três forças: Exército, Marinha e Aeronáutica. O Exército conta com um Plano de Migração que detalha os procedimentos relativos ao assunto, com diretrizes bastante específicas e como não haveria de ser, a liberdade de escolha das aplicações utilizadas para o auxílio neste processo, desde que sejam Software Livre. Um grande passo para o avanço na migração de sistemas proprietários, é a utilização de aplicações em ambientes virtualizados, onde os acessos podem ser feitos com segurança, não deixando a experiência do usuário ser afetada por conta da complexidade e falta de transparência no uso dessas aplicações. Muitos softwares hoje buscam, de certa forma, a interoperabilidade com a virtualização de aplicações, porém são baseados em protocolos e plataformas proprietárias, o que acaba afetando na escolha de aplicações para um projeto de migração. Com o crescimento e avanço do Software Livre no mercado de TI mundial, novas empresas, bem como novos projetos e aplicações passaram a ser criados para suprirem esta

2 demanda, e isto não foi diferente no campo da virtualização de aplicações em ambientes heterogêneos. 1.1 Objetivo Este artigo têm por objetivo apresentar uma ferramenta de consolidação de aplicações Linux e Windows, disponibilizadas em um ambiente de desktop virtual e acessadas via web browser, chamada Open Virtual Desktop, como uma solução de auxílio na migração de sistemas proprietários para Software Livre no 5 Batalhão de Engenharia de Combate Blindado (5 BE Cmb Bld), baseados na proposta do Plano de Migração para Software Livre, elaborado pelo Departamento de Ciência e Tecnologia do Exército Brasileiro. Este objetivo está embasado em testes de laboratório realizados como pré-requisito para a implantação em um ambiente de produção, o que inclui a instalação, acesso, soluções de interoperabilidade entre os sistemas Linux e Windows, e resolução dos problemas encontrados. 1.2 Justificativa Seguir o modelo previsto em [1] cuja finalidade é de regular a estratégia para a consolidação da implantação do Software Livre em todos os escalões do Exército Brasileiro, tendo como objetivo fim, a migração de sistemas proprietários em sua totalidade, desde os servidores até os computadores pessoais, o qual foi incumbido às Seções de Informática e a todos os responsáveis por estas, incluindo suas equipes, de todas as Organizações Militares no Brasil. 1.3 Conceitos, Embasamento e Proposta Os Projetos de Lei focados na migração para Software Livre no Brasil começaram a surgir no fim da década de 90, como o PL 2269/99, que pode ser encontrado em [2], do Deputado Walter Pinheiro PT/BA, que dispõe sobre a utilização de programas abertos na administração pública. Nos anos seguintes, vários outros PL foram criados por autores também de cunho político, com um objetivo comum de tornar padrão o uso do Software Livre em repartições públicas federais ou estatais, dos quais, a grande maioria foi apensada ao PL 2269/99. Como ação prioritária do Governo Federal, em 02 de Outubro de 2002, foi aprovado o Planejamento Estratégico do Comitê Técnico de Implementação do Software Livre no Governo Federal, cujas diretrizes e objetivos podem ser encontradas em [3], e que, dentre outras, destacam-se as seguintes: Priorizar soluções, programas e serviços baseados em software livre que promovam a otimização de recursos e investimentos em tecnologia da informação; Priorizar a plataforma Web no desenvolvimento de sistemas e interfaces de usuários; Buscar a interoperabilidade com os sistemas legados; Restringir o crescimento do legado baseado em tecnologia proprietária; e Realizar a migração gradativa dos sistemas proprietários. Como resposta à ação do Governo Federal, diversas iniciativas começaram a surgir, como decretos e planos de migração, sendo destacados o Plano de Migração para Software Livre no Exército Brasileiro, com a sua primeira edição lançada em Novembro de 2004, e o Decreto n [4], de 19 de Julho de 2005, assinado pelo Governador do Estado do Paraná, Roberto Requião.

3 O Plano de Migração para Software Livre no Exército Brasileiro atualmente encontrase em sua terceira edição, e dentre outras diretrizes e objetivos, prevê a utilização de até 5 (cinco) computadores com sistema operacional proprietário, no caso o Microsoft Windows, por Organização Militar (OM), devidamente licenciados, utilizando ao máximo programas e aplicativos abertos, isso, enquanto forem possíveis. O restante dos computadores, deverão utilizar sistemas operacionais abertos, no caso o Linux, incluindo todos os aplicativos necessários para a utilização em um ambiente de escritório, bem como aplicativos específicos para funções específicas diversas, todos eles sendo de fonte aberta. Atualmente a grande maioria das aplicações utilizadas na administração, logística, pagamento e controle de pessoal não foram completamente migradas. Tais aplicações destacam-se por terem sido desenvolvidas na linguagem object pascal utilizando Delphi, bem como, aplicações desenvolvidas no banco de dados MS Access nas versões 2000 e 2003, e que acarretam na utilização de computadores instalados com sistemas e aplicações proprietárias, que muitas vezes superam o número máximo previsto no Plano de Migração. Com base nas diretrizes do Planejamento Estratégico do Comitê Técnico de Implementação do Software Livre no Governo Federal no que se refere à priorização da plataforma web com aplicações baseadas em software livre, evitando o crescimento do legado e buscando a interoperabilidade nos sistemas e, focados nos objetivos propostos no Plano de Migração para Software Livre no Exército Brasileiro, a proposta apresenta a definição de um modelo padrão no acesso à aplicativos que integrem aplicações Linux e Windows, em um ambiente web, acessado remotamente, de qualquer lugar, com qualquer navegador web, executados em quaisquer dispositivos, obviamente, desde que estes tenham suporte. Este modelo de acesso pode ser conseguido através de uma ferramenta de Desktop Virtual, recentemente lançada no mercado de Software Livre, chamada Open Virtual Desktop, de forma a reduzir ao máximo o número de computadores instalados com sistemas proprietários. 2 Soluções de Acesso Remoto Atualmente existem muitas alternativas e soluções de acesso remoto. Algumas delas Software Livre e outras baseadas em protocolos e fontes proprietárias. Destas soluções, a grande maioria visa o acesso a uma área de trabalho remota através de protocolos específicos, como o que ocorre no Linux com o X Display Manager Control Protocol XDMCP [5], ou no Microsoft Windows, com o Remote Desktop Protocol RDP [6]. Porém, quando se trata de soluções para a interoperabilidade e acesso a aplicativos proprietários baseados no Microsoft Windows, as alternativas existentes são drasticamente reduzidas. O acesso remoto ao Microsoft Windows Terminal Services pelo Linux, é realizado por um cliente chamado rdesktop [7]. Este cliente necessita de uma sessão X em execução e se encontra em sua versão estável 1.6.0, no momento em que este artigo é escrito. Para muitos projetos e propostas de acesso remoto o rdesktop possui um inconveniente, que é o acesso a uma área de trabalho completa, e não a aplicativos específicos. Neste caso existe um esforço da própria Microsoft, na última versão do Terminal Services, incluído em seu novo sistema para servidores, Microsoft Windows Server 2008, que visa a utilização de aplicações Windows específicas acessadas via web browser e apresentadas ao usuário de forma transparente, como se estas estivessem instaladas em seu próprio sistema. O acesso via navegador ao Terminal Services do Windows Server 2008, mostrado na figura 1, implica em um ambiente completamente compatível com sistemas baseados no Microsoft Windows. Uma das barreiras para a implementação desta solução visando a interoperabilidade entre sistemas Linux e Windows, é a necessidade de suporte do navegador para os controles do ActiveX, que é exclusivo para o navegador Internet Explorer. A alternativa seria a utilização do Internet Explorer no Linux, com o ies4linux [8], um aplicativo

4 que instala o navegador da Microsoft emulado no Wine [9], contudo, não é aconselhável usar um sistema livre como base para aplicativos proprietários, ainda mais, tendo como objetivo fim um plano de migração para Software Livre. Figura 1: Acesso web ao Terminal Services 2008 Uma outra solução bastante utilizada e com suporte ao acesso remoto de aplicações Windows individuais é a XenApp [10,11], desenvolvida pela Citrix [12]. Esta solução consiste na virtualização de aplicações seguindo o modelo cliente/servidor, onde uma parte é instalada no servidor Windows, que é responsável pela centralização e gerenciamento de aplicações, as quais são liberadas sob demanda ao usuário, e outra parte no cliente, usada para acessar as aplicações no servidor. Esta comunicação é realizada através de um protocolo proprietário criado pela Citrix, chamado Independent Computing Architecture ICA [13] que, como o nome sugere, é independente de plataforma. A Citrix possui suporte a clientes, para o acesso ao XenApp de diversos sistemas operacionais, o que inclui várias versões do Windows, distribuições Linux, e algumas distribuições específicas UNIX, além do acesso via navegador. Esta solução têm se mostrado eficiente na virtualização de aplicações, conquistando aproximadamente 100 milhões de usuários ao redor do mundo, de forma a estar se tornando um padrão de facto [11], porém é proprietária, e sua utilização como uma solução de apoio à migração para Software Livre, assim como a solução proposta pela Microsoft através do Terminal Services do Windows Server 2008, acabam sendo impraticáveis. 3 Open Virtual Desktop O Open Virtual Desktop é, em tese, a união de recursos para o acesso web às aplicações Windows, que assemelha-se ao que ocorre com o Terminal Services do Windows Server 2008, ou do acesso virtual às aplicações Windows realizadas pelo XenApp da Citrix, somados com a flexibilidade de poder disponibilizar inclusive aplicações Linux ao mesmo ambiente, apresentadas ao usuário final através de um desktop virtual, acessado via web browser, também conhecido como web desktop, open source, seguro, e de fácil administração.

5 Um web desktop, ou webtop, segundo [14], é um ambiente de área de trabalho embarcado em um web browser, ou seja, é um ambiente virtual acessado via navegador, onde as aplicações, dados, arquivos, configurações, ajustes e privilégios de acesso se localizam em computadores remotos conectados à rede. 3.1 Breve História O Open Virtual Desktop foi criado e é patrocinado por uma empresa francesa chamada Ulteo. Esta empresa, segundo consta em [15], foi fundada por Gaël Duval e Thierry Koehrlen. O primeiro é um empresário veterano que fundou o Mandrake Linux e o segundo, é cofundador da Intalio, líder open source em sistemas de automatização em gestão de processos de negócio. A Ulteo lançou a primeira versão do OVD em 22 de Abril de 2009 [16]. Com este projeto, em 29 de outubro, foi premiada entre as cinco melhores empresas open source do mundo, reconhecidas por seus projetos altamente originais em termos de inovação, qualidade de execução e potencial valor de criação, num evento denominado Open Innovation Summit realizado pelo Open World Forum [17] na cidade de Paris França [18]. Este evento contou com mais de 1500 pessoas oriundas de 30 países distintos, interessadas no ecossistema open source e na sua expansão [19], bem como, contou com jurados renomados no mundo do Software Livre, como Mark Shuttleworth, fundador da Canonical, empresa que promove o Ubuntu Linux e Andrew Aitken, fundador do renomado Olliance Group, líder em consultoria de gestão open source [18]. O objetivo principal da Ulteo é se tornar dentro de cinco anos, um dos líderes globais no setor de desktops virtuais em ambientes corporativos, desenvolvendo e distribuindo soluções open source para desktops virtuais que possam se encaixar tanto em pequenos como em grandes sistemas de informações, gerando o melhor retorno sob investimento, do inglês ROI (Return On Investment), do mercado [18]. 3.2 Requisitos de Sistema O OVD requer, em uma infra-estrutura mínima, pelo menos um servidor gerenciador de sessões ou Session Manager (SM), e um servidor de aplicação, ou Application Server (ApS). Os requisitos recomendados seguem abaixo, conforme [20]: Session Manager (SM): Máquinas de classe Pentium x86 com 512 Mb de memória RAM ou mais; Sistemas Operacionais Linux baseados em pacotes pré-compilados: Ubuntu 8.04, Red Hat Enterprise Linux 5.2, CentOS 5.2 e Fedora 10; Instalações genéricas LAMP (Linux + Apache + MySQL + PHP); Application Server (ApS) Linux: Máquinas x86 com dois ou quatro núcleos e 1 Gb o de RAM ou mais para suportarem 20 (vinte) usuários concorrentes; Sistemas Operacionais Linux baseados em pacotes pré-compilados: Ubuntu 8.04, Red Hat Enterprise Linux 5.2, CentOS 5.2 e Fedora 10; Instalações genéricas LAMP (Linux + Apache + MySQL + PHP);

6 Application Server (ApS) Windows: Qualquer infra-estrutura de hardware; Sistema operacional Windows Server 2003; Terminal Services; Active Directory (AD); Além do serviço de diretório da Microsoft (Active Directory), o OVD suporta o Lightweight Directory Access Protocol LDAP. Para a utilização do OVD, o cliente deve possuir o plugin do java (Sun Java 1.5/1.6) habilitado no navegador, sendo os seguintes suportados: Mozilla Firefox 2 ou superior e Internet Explorer 7 ou superior, instalados em qualquer plataforma. É necessário também, que a rede seja fast ethernet (100 Mbps) ou superior. 4 Laboratório de Testes O laboratório de testes foi criado e configurado com o intuito de fazer um reconhecimento do serviço, verificando os prós e contras, bem como as dificuldades a serem superadas na implementação, o que inclui a instalação, publicação e gerenciamento de aplicações no OVD. O laboratório conta ainda com uma estrutura lógica semelhante à que será aplicada na implementação no ambiente de produção, porém com uma configuração inferior. Esta estrutura está baseada em sistemas virtualizados com Xen [21], tendo como domínio 0 (Dom0) o sistema operacional Linux opensuse 11.0, instalado em uma máquina AMD Turion X2 TL-52 de 1.6 GHz com 3 Gb de memória RAM, sendo 1536 Mb alocados ao Dom0. As configurações das demais máquinas seguem abaixo: SM / ApS: Sistema Operacional Ubuntu Linux , paravirtualizado, criado com debootstrap [22,23] (DomU); Imagem de disco esparso de 12 Gb; Processador AMD Turion 1.6 Ghz com 512 Mb de RAM (1 núcleo); Apache, MySQL e PHP; ApS Windows: Sistema Operacional Windows Server 2003 Service Pack 1, virtualização completa (DomU + drivers paravirtualizados GPLPV [24]); Processador AMD Turion 1.6 Ghz com 512 Mb de RAM (1 núcleo); Active Directory, Terminal Services e Microsoft DNS Server; Servidor DNS: Sistema Operacional Ubuntu Linux 9.04, paravirtualizado (DomU, imagem baixada de [25]); Processador AMD Turion 1.6 Ghz com 64 Mb de RAM (1 núcleo); Bind 9.5.1; Observação: a instalação dos sistemas operacionais acima em uma infra-estrutura de

7 virtualização com Xen, bem como a instalação e configuração genérica do servidor DNS Bind, a instalação do LAMP e a instalação das aplicações Windows estão fora do escopo deste artigo. 4.1 Instalação do OVD Session Manager e Application Server Linux O OVD é baseado no Ubuntu 8.04, e por esse motivo, este foi o sistema operacional utilizado como base para a instalação do SM e do ApS. O ApS pode ser instalado tanto em servidores Linux remotos como no mesmo servidor SM. Para o laboratório proposto, o ApS será instalado juntamente com o SM. O primeiro passo a ser efetuado é adicionar a seguinte linha no arquivo /etc/apt/sources.list : deb ovd polaris main É necessário adicionar o pacote de chaves públicas da Ulteo [26] ao sistema, utilizado para a instalação dos pacotes OVD com apt-get. # dpkg i ulteo keyring_ _all.deb Logo após, deve ser realizado a atualização da lista de repositórios do apt-get. # apt get update Os demais procedimentos da instalação podem ser encontrados no manual de instalação para o Ubuntu 8.04, localizado em [27]. Conforme descrito no manual, a instalação e configuração do servidor MySQL devem ser realizadas antes da instalação do SM. Como padrão, as configurações da base de dados permanecem as mesmas do manual, cujo o nome é ulteo_sm. Caso o MySQL já esteja instalado em um servidor de banco de dados da organização, basta criar a base de dados para a utilização do OVD. A instalação do SM é realizada via apt-get, com o seguinte comando: # apt get install ulteo ovd session manager Antes de finalizar a instalação, é aberta uma janela onde devem ser inseridos o nome do administrador, cujo padrão é admin, a senha, que é pedida duas vezes, e por último uma url contendo o caminho completo para baixar o pacote base-polaris-1.0-latest.tar.gz de aproximadamente 500 Mb, que é o pacote que contém o Ubuntu Linux modificado, utilizado pelo ApS. Caso não haja conexão com a internet, este pacote poderá ser baixado posteriormente, através do link em [28], e copiado com o nome base.tar.gz para o diretório /usr/share/ulteo/sessionmanager/. A partir daqui as configurações do SM são realizadas completamente pela interface web. Para acessá-lo basta digitar o endereço do SM, seguido de /sessionmanager/admin conforme abaixo: Onde: ovdsm.5becbld.eb.mil.br é o nome do servidor SM, previamente definido no servidor DNS Bind.

8 Caso seja necessário a reconfiguração do usuário administrador do SM, basta executar o seguinte comando no terminal: # dpkg reconfigure ulteo ovd session manager A primeira configuração a ser feita é a conexão com a base de dados criada no MySQL, descrito detalhadamente em [27]. Nesta configuração, são adicionados ao SM o endereço de host da base de dados, o nome de usuário da base de dados, a senha deste usuário, o nome da base de dados e o prefixo das tabelas desta base. Caso o MySQL esteja instalado no mesmo servidor que o SM, o endereço de host deve ser localhost. O nome da base de dados definida por padrão, criada anteriormente conforme sugestão da Ulteo, é ulteo_sm. Após realizadas as configurações de conexão com a base de dados, o SM está pronto para gerenciar os servidores de aplicações (ApS). O primeiro ApS será instalado no mesmo sistema em que se encontra o SM. Para tanto, deve ser executado o seguinte comando no terminal: # apt get install ulteo ovd Este comando instalará os pacotes necessários para o ApS dos repositórios da Ulteo, incluindo suas dependências. Um dos pacotes necessários para a utilização do ApS, é o base.tar.gz, baixado anteriormente na instalação do SM. Como o ApS se encontra no mesmo servidor do SM, o pacote mencionado será descompactado para o diretório /opt com o nome ulteo. Caso o ApS estivesse localizado em outro servidor na rede, o mesmo efetuaria o download do pacote base.tar.gz diretamente do SM e não da internet. Assim como na instalação do SM, antes de completar a instalação do ApS, é aberta uma janela, onde deverão ser inseridos o caminho completo (Fully Qualified Domain Name FQDN) para o ApS, e noutra o caminho para o SM, conforme descrito abaixo. Endereço do ApS Linux: Endereço do SM: Como o ApS está sendo instalado no mesmo servidor que o SM, ao invés do endereço FQDN, deverá ser inserido o endereço de localhost como endereço completo para o ApS, substituindo ainda, o endereço FQDN do SM por Esta é uma regra e deverá ser cumprida, com a pena de que o SM jamais encontre o ApS para poder registrá-lo e utilizá-lo. Se ocorrer de inserir um endereço FQDN para um ApS instalado juntamente com o SM, basta editar o arquivo de configuração do OVD, que está localizado em /opt/ulteo/etc/ulteoovd.conf, alterando o valor das opções SERVERNAME e SESSION_MANAGER_URL, que se encontram logo no começo do arquivo, para as opções descritas anteriormente. A figura 2 ilustra o ApS não registrado. É possível que ocorra a não visualização do servidor ApS para registrá-lo, mesmo tendo sido feitas, de forma correta, as configurações necessárias para levantá-lo no mesmo servidor SM. Neste caso basta reiniciar o serviço executando: # /etc/init.d/ulteo ovd restart

9 Figura 2: Servidor ApS Linux não registrado Outro importante detalhe, após o registro do servidor ApS, é a alteração da opção Redirection name of this server, que está configurada com o endereço de localhost, para o endereço FQDN do servidor, configurado no DNS. 4.2 Instalação e configuração do ApS Windows A instalação do ApS Windows já exige um pouco mais de conhecimento por parte do administrador, tendo em vista que diversas configurações não acabam sendo tão triviais quanto a instalação do ApS com Linux. Para poder rodar aplicações Windows no ambiente virtual é necessário que o SM seja ligado ao MS Active Directory (AD) [29]. O AD necessita de um DNS dinâmico disponível para poder armazenar informações sobre quais funções estão sendo desempenhadas e em quais servidores elas se localizam [30]. Este pré-requisito pode causar alguns transtornos na hora de configurá-lo, principalmente se a estrutura de nomes da organização estiver baseada em DNS estático configurado em um servidor UNIX, no caso o Bind. Para resolver o problema, a Microsoft publicou um white paper, documentando quatro modelos de configuração DNS para o gerenciamento de informações DNS do AD na presença de um servidor Bind [30]: Rodar o Servidor Bind em modo dinâmico; Usar uma combinação do Servidor Bind com o Servidor DNS da Micrsoft; Mover todas as atividades DNS do AD para zonas DNS separadas; ou Gerenciar manualmente as informações DNS, editando as tabelas DNS na mão. Dentre as alternativas, a de número 2 foi a escolhida, pois não há um interesse na modificação das configurações DNS do Bind no 5 BE Cmb Bld, para utiliza-lo em modo dinâmico. No modelo proposto pela alternativa 2, as configurações do Bind permanecem inalteradas, delegando ao DNS da Microsoft, no arquivo da zona primária, apenas as zonas necessárias para a utilização do AD.

10 Ao promover o Member Server, as configurações de DNS pedidas no momento da instalação do AD não deverão ser selecionadas. É muito provável que ocorrerá um erro durante a instalação pois o AD não encontrará nenhuma infra-estrutura DNS configurada corretamente para suportá-lo. Neste caso a opção escolhida deverá ser a Vou corrigir o problema mais tarde configurando o DNS manualmente. (Avançado). O MS Active Directory do Windows Server 2003 utiliza seis zonas DNS para atualizações dinâmicas de informações, são elas: _msdcs, _sites, _tcp, _udp, DomainDnsZones e ForestDnsZones. Elas devem ser configuradas manualmente para a integração com o Bind. Se a instalação do DNS da Microsoft for realizada após a instalação do AD, duas zonas são criadas, uma iniciando com _msdcs mais o nome do domínio e outra somente com o nome de domínio, que neste caso específico são: _msdcs.5becbld.eb.mil.br e 5becbld.eb.mil.br. Para o funcionamento correto da combinação dos servidores de nomes, elas deverão ser excluídas. A partir de então, as seis zonas deverão ser adicionadas conforme a seguir [31]: > Em Menu Iniciar > Painel de Controle > Ferramentas Administrativas > DNS > Zonas de pesquisa direta; > Adicionar uma nova Zona Primária com o check list ativado para Armazenar a Zona no Active Directory > selecionar o item Para todos os controladores de domínio..., no Escopo de duplicação de Zona do Active Directory > inserir o nome da zona seguido do nome de domínio, ex.: _sites.5becbld.eb.mil.br > selecionar o item Permitir apenas atualizações dinâmicas seguras > concluir; > Repetir esse procedimento com as seis Zonas descritas anteriormente. Durante a instalação do DNS da Microsoft, é necessário configurar um endereço IP estático para o servidor. Após esta configuração, o servidor DNS preferencial geralmente fica com o endereço IP de localhost no Windows. Para que a combinação entre os servidores de nomes funcione é imprescindível que o endereço de DNS preferencial seja configurado para o endereço do servidor Bind. Um outro detalhe importante é a adição de uma DWORD, chamada RegisterDnsARecords com valor 0, no registro do Windows, para prevenir que não haja a tentativa do AD registrar ele mesmo [31]. Esta DWORD deve ser adicionada em: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters Após realizadas as configurações no DNS da Microsoft, basta apenas criar os registros das seis zonas no arquivo de zona primária do domínio no Bind, para canalizar todo o tráfego de informações manipuladas pelo AD para o servidor Windows, conforme abaixo: _msdcs _tcp _udp _sites DomainDnsZones ForestDnsZones IN IN IN IN IN IN NS NS NS NS NS NS winsrv2003 app.5becbld.eb.mil.br. winsrv2003 app.5becbld.eb.mil.br. winsrv2003 app.5becbld.eb.mil.br. winsrv2003 app.5becbld.eb.mil.br. winsrv2003 app.5becbld.eb.mil.br. winsrv2003 app.5becbld.eb.mil.br. A figura 3 ilustra um teste que pode ser realizado para certificar-se de que as configurações dos servidores DNS em combinação estão corretas e funcionando em perfeitas condições, para a atualização dinâmica de informações nas zonas do AD. O último serviço a ser configurado é o Terminal Services. É através dele que as aplicações Windows serão acessadas no ambiente virtual. Vale lembrar que todas as aplicações instaladas antes da configuração do Terminal Services deverão ser reinstaladas.

11 Figura 3: Teste de configuração de zonas do AD A integração do ApS Windows com o OVD, é feita usando um agente chamado ovdagent, que após instalado atua como um serviço, sendo iniciado juntamente com o sistema. No lançamento da versão 1.0 do OVD pela Ulteo, o agente suportava apenas a versão do Microsoft Windows Server 2003 no idioma inglês, usando caminhos estáticos ao invés de variáveis de ambiente. A primeira correção foi publicada em junho de 2009, porém continha alguns bugs para a publicação das aplicações no desktop virtual, a segunda veio em seguida, suportando o sistema da Microsoft em qualquer idioma, podendo ser baixado em [32]. A instalação do ovd-agent é relativamente fácil, bastando executá-lo. Assim como na instalação do ApS Linux, o agente necessita saber apenas o endereço FQDN do ApS Windows e do SM, sendo elas: ApS Windows winsrv2003-app.5becbld.eb.mil.br e SM ovdsm.5becbld.eb.mil.br/sessionmanager/. Figura 4: ApS Windows registrado e pronto para produção

12 A figura 4 ilustra o ApS Windows registrado, pronto para ser colocado em produção. Nota-se também o ApS Linux em produção. Maiores detalhes sobre a instalação do ovd-agent no Windows podem ser encontrados em [29]. 4.3 Configuração do OVD para o ambiente de produção Para levantar o OVD em um ambiente de produção são necessárias ainda algumas configurações específicas, como a criação de um perfil de usuários e grupos de aplicações. Outra importante configuração é adicionar o SM para autenticar em uma base de informações do AD. Esta configuração é necessária para a utilização de aplicações Windows no ambiente virtual. O OVD dispõe de cinco menus para seu gerenciamento: Index, Servers, Users, Applications, Configuration e Status. Dentre estes menus, os mais importantes usados para levantar o serviços de desktop virtual são: o menu de configuração, o menu de usuários e o menu de aplicações. Por default o OVD traz em sua base alguns usuários pré cadastrados no sistema, dando a opção de utilizá-los ou inserir novos usuários localmente. Além das opções de configuração de usuários locais, o OVD suporta autenticação em uma base de dados do MS Active Directory ou LDAP. A configuração dos perfis de usuário são realizadas no sub-menu Profile settings do menu Configuration. É através dele que são feitas as configurações para o uso do AD, LDAP ou base de usuários locais. No ambiente proposto, a configuração dos usuários é realizada pelo AD. A figura 5 ilustra o cadastro do SM em uma base AD. Maiores detalhes sobre a configuração do SM para a conexão em um servidor AD ou LDAP podem ser obtidas em [33]. Figura 5: Cadastro do SM em uma base AD Nesta configuração, os usuários são automaticamente selecionados e autenticados pelo AD, mantendo apenas seu diretório home, bem como seus grupos, na base local, ou seja, estes não são exportados. Um detalhe importante é que, a partir desse momento, o cadastro dos usuários passa a ser realizado completamente pelo Windows Server, através do snap-in Usuários e computadores do Active Directory, localizado em:

13 Menu Iniciar > Painel de Controle > Ferramentas Administrativas Somente os grupos desses usuários são adicionados localmente, realizados através do sub-menu Users groups do menu Users. Efetuadas as configurações de integração do SM com o AD e o cadastro dos grupos de usuários, restam as configurações relacionadas à sessão, à interface web e aos aplicativos que serão publicados para os usuários. As configurações relacionadas à sessão encontram-se no sub-menu Session-settings do menu Configuration. Nela podem ser configurados por exemplo, itens como a qualidade na profundidade de cor da sessão, tempo de expiração da sessão, personalização de mensagens para sessões com prazo de expiração excedendo, se o usuário pode acessar seu desktop virtual sem aplicações publicadas, ou até mesmo, se os ícones das aplicações disponibilizadas ao usuário estarão habilitados ou não em sua área de trabalho virtual. As configurações da interface web podem ser acessadas no sub-menu Web interface settings no menu Configuration. Neste item existem algumas opções de relativa importância, como o cabeçalho, o ícone padrão, que pode ser adaptado ao da organização, bem como se a sessão será iniciada na mesma janela do navegador ou em uma pop-up. Após realizadas as configurações básicas, um último item a ser configurado para poder lançar sessões virtuais, de forma essencial, são as aplicações. O menu Applications possui quatro sub-menus, sendo eles: Applications, Applications Groups, Publications e Publication Wizard. O sub-menu Applications mostra todas as aplicações de todos os servidores, Linux e Windows, registrados, que podem ser publicadas no desktop virtual. Em Applications Groups, como o nome sugere, são criados grupos de aplicações. Estes grupos dizem respeito sobre quais aplicações estarão disponíveis e a quais grupos de usuários, o que torna flexível a administração bem como o acesso de forma segura às aplicações. Em Publications, são apresentados os grupos de usuários e seus respectivos grupos de aplicações, onde é possível gerenciá-los, de forma a adicionar um grupo de usuários a um grupo de aplicações previamente cadastrados no sistema, bem como excluir uma publicação já realizada, na qual um grupo de usuários já está amarrado a um grupo de aplicações. Em Publication Wizard, como o nome sugere, é uma opção que facilita a administração na hora da criação de um grupo de usuários, de um grupo de aplicações e sua publicação, através de um wizard bastante intuitivo e prático. Os demais itens de configuração são dispensáveis para levantar o servidor em um ambiente de testes, porém imprescindíveis para o gerenciamento do servidor. Nelas incluem logs da base de dados e demais logs do sistema, a configuração do sistema em si, como o cadastro de para o envio de mensagens após algum evento ter sido disparado. São incluídos também gráficos sobre a utilização dos recursos do sistema e do acesso às aplicações nos ApS registrados, filtrados por período. Podem ser realizados ainda a configuração de políticas de balanceamento de carga a respeito da utilização de memória RAM, CPU e número de sessões concorrentes no SM, bem como realizar o controle das sessões ativas, podendo visualizar a ação dos usuários em seus desktops virtuais, juntar-se a um desktop virtual a fim de auxiliar o usuário final em alguma tarefa específica, verificar os aplicativos abertos e utilizados pelo usuário num dado momento ou encerrar uma sessão de usuário. Depois de configuradas as opções de usuários e suas respectivas aplicações, o acesso ao desktop virtual é liberado. O endereço de acesso é o mesmo prefixo do acesso à gerência do SM, com exceção de admin, ficando semelhante ao endereço a seguir:

14 A figura 6 ilustra a tela de login, já personalizada para o 5 BE Cmb Bld. Nota-se o endereço iniciado por ovdapp. Este prefixo é simplesmente um CNAME configurado no Bind, apontando para o mesmo endereço citado acima. Outro detalhe importante a respeito do acesso, é que ele pode ser efetuado tando pela rede local quanto pela Internet. Figura 6: Tela de login do OVD Figura 7: Desktop virtual com aplicações disponibilizadas no menu A figura 7 ilustra o desktop virtual, carregado em uma pop-up após o login ter sido efetuado com sucesso. A área de trabalho do OVD é baseada no gerenciador de janelas xfce4

15 [34], customizado para o acesso via web, que é realizado através de um cliente VNC [35] java, criado pela Ulteo, bem como o acesso realizado às aplicações Windows, que é através do protocolo RDP. Nesta ilustração, são disponibilizadas no menu somente aplicações específicas ao usuário, sendo elas baseadas tanto em Linux quanto em Windows, publicadas e acessadas no mesmo ambiente. A figura 8 ilustra uma aplicação de logística utilizada pelo Exército Brasileiro chamada Siscofis Subsistema de Controle Físico, que é um programa aplicativo do Simatex Sistema de Material do Exército, cujo propósito é de atender as necessidades das Organizações Militares no que tange à administração do material carga. Este é um exemplo de aplicativo legado que ainda não foi migrado, e portando, necessita do sistema operacional Windows para rodar sem maiores problemas. Neste caso, ele está sendo acessado via OVD como uma aplicação específica, publicada única e exclusivamente a militares credenciados no sistema. Figura 8: Sicofis OM acessado pelo OVD Novas aplicações instaladas no servidor Windows são automaticamente atualizadas no SM, porém é necessário registrá-las através do menu Servers antes de utilizá-las no OVD. Este menu possui no sub-menu de mesmo nome, uma lista de todos os servidores registrados no SM, sendo que suas respectivas configurações podem ser acessadas através de um link de endereço IP ou nome na coluna FQDN. Ao acessar o link referente ao servidor Windows, é aberta uma janela onde podem ser configuradas algumas opções como o número de sessões disponíveis para o servidor, bem como o nome e a porta do servidor. Nesta mesma janela são apresentadas todas as aplicações disponíveis para publicação no OVD, incluindo as novas aplicações instaladas diretamente no servidor. Para torná-las disponíveis para a publicação é necessário fazer a seleção da aplicação e acionar o botão Install on this server. Para a instalação de novas aplicações Linux, basta acessar o servidor correspondente através do menu Servers, e digitar o nome da aplicação no campo Install an application from a package name, acionando o botão Install em seguida. Este campo é um front-end para a ferramenta de linha de comando apt-get. Maiores informações sobre as configurações do OVD podem ser encontradas em um

16 site recentemente lançado por um membro da comunidade, o qual possui diversos vídeos do projeto, podendo ser encontrado em [36]. Demais informações sobre possíveis erros e suas respectivas correções, bem como assuntos gerais relacionados ao OVD podem ser encontrados na FAQ do projeto em [37]. 5 Considerações Finais O Ulteo Open Virtual Desktop, mesmo sendo uma aplicação extremamente nova, têm se mostrado surpreendentemente capaz de suprir necessidades organizacionais simples, relativas à consolidação de múltiplas aplicações baseadas tando em Linux quanto em Windows em um ambiente de desktop web virtual. Como este é um projeto que está apenas no começo, necessita de muitas melhorias e ajustes para poder suprir de forma completa e abrangente, necessidades organizacionais complexas. Uma dessas melhorias está relacionada ao compartilhamento de arquivos e diretórios através de Common Internet File System CIFS, que na versão 1.0 do OVD, possui suporte apenas em modo assíncrono para diretórios home, através de perfis móveis (Roaming Profiles) [33]. A versão 1.0 do OVD lançada em Abril do corrente ano, somente possuía suporte ao sistema operacional Windows Server Uma nova versão, em faze de Release Candidate foi lançada no dia 13 de Novembro de 2009 para testes. Esta versão já possui suporte ao Windows Server 2008, bem como melhorias relacionadas ao CIFS. Como o 5 BE Cmb Bld não possui interesse em aplicações baseadas no Windows Server 2008, por utilizar ainda e apenas aplicações legadas específicas de uso do Exército Brasileiro, baseadas no Windows 2k3, que por hora ainda não foram completamente migradas, o OVD, frente aos testes realizados, atualmente têm se mostrado em condições de suprir as necessidades não só a respeito das atuais configurações de plataforma segura de webtop para a consolidação de aplicações Linux e Windows em um mesmo ambiente virtual, mas também como uma ferramente de auxílio na migração de sistemas e aplicativos proprietários, para Software Livre, podendo reduzir até mesmo o número de máquinas permitidas para a utilização de sistemas e aplicações proprietárias pelo Plano de Migração para Software Livre no Exército Brasileiro, que atualmente é de 05 (cinco), para apenas 01 (uma) ou no máximo 02 (duas) máquinas. Vida longa ao Open Virtual Desktop. 6 Referências [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16]

17 [17] [18] [19] [20] [21] [22] [23] [24] [25] [26] _all.deb [27] lang=en [28] [29] tions?autolang=en [30] [31] [32] [33] on?autolang=en [34] [35] [36] [37]