\part*{Parte III \\ \ \\ DIRETRIZES TÉCNICAS}
\addcontentsline{toc}{part}{PARTE III -- DIRETRIZES TÉCNICAS}

\chapter{Arquitetura de Referência}
\label{arq_ref}

\section{Arquiteturas genéricas}
\label{arq_generica}

Atualmente para se desenvolver \emph{software} computacional, tem sido largamente usado o modelo de três camadas. Esse modelo separa os aplicativos em 3 partes\footnote{
Mais detalhes sobre este modelo podem ser encontradas em
\wwn{http://www.corba.ch/e/3tier.html}.}:

\begin{enumerate}
	\item Camada de acesso aos dados, aos sistemas de arquivos e aos bancos de dados;
	\item Camada de código do aplicativo e lógica do negócio;
	\item Camada da interface humana, da tela, do teclado e do \emph{mouse}.
\end{enumerate}

\figura{fig:diagrama_3_camadas}{9-1.png}{.5}{Diagrama 3 Camadas}

Cada camada do aplicativo deve preocupar-se em realizar
suas tarefas específicas, interoperando com as outras
camadas de \emph{software}. Isso traz o benefício de que o código do aplicativo pode ser mais simples em cada camada, trabalhando facilmente em ambientes heterogênios, porque sua dependência em relação ao acesso específico à máquina é reduzida. 

Na figura \ref{fig:diagrama_3_camadas}, as
setas indicam o fluxo da informação entre as diversas camadas do aplicativo. É interessante que estes fluxos de informação utilizem padrões abertos e bem definidos. Dessa forma se torna mais fácil portar, ou migrar, o aplicativo para arquiteturas alternativas de \emph{hardware} e \emph{software}; além disso, o uso de padrões abertos promove com maior facilidade
a interoperabilidade entre diversos sistemas.

Este modelo em 3 camadas foi generalizado para \emph{n}-camadas, em que os componentes são ainda mais refinados, e é tipicamente desenvolvido utilizando-se a tecnologia de objetos ou componentes.

Muitos aplicativos Cliente/Servidor, no passado, só usavam um modelo de 2 camadas. A migração de tais aplicativos poderá 
ser mais trabalhosa do que os modelos desenvolvidos em 
3/\emph{n}-camadas, porque provavelmente a interface humana irá requerer alterações -- uma vez que o modelo de 2 camadas apresenta, em sua grande maioria, o código da interface humana combinado com a lógica do negócio.

A comunicação entre as três partes de um modelo de três camadas normalmente usa protocolos que permitem a cada camada trabalhar em uma máquina ou um sistema diferente do das outras duas camadas, caso isso seja desejado. Algumas vezes, as partes também são divididas entre outras máquinas. A escolha de como essa divisão é feita dá origem a várias arquiteturas genéricas, criando plataformas de \emph{hardware} com configurações bem diferenciadas.

No ponto de vista da estação de trabalho, em que no mínimo alguma parte do código da interface humana é realizada, são usualmente utilizadas as arquiteturas: 


\subsubsection{1 -- Cliente Leve (Thin Client)}
\label{cliente_leve}

Nesta arquitetura, a estação de trabalho não precisa de dispositivos de armazenamento, tais como drive de CDROM, disquete, disco rígido etc. O cliente normalmente é um ``terminal burro'', um computador antigo e/ou um dispositivo especifico para Cliente Leve. As vantagens desta arquitetura são o baixo custo e a possibilidade de se reutilizarem \emph{hardware} antigo e tecnologicamente defasado. Além disso, como um servidor remoto armazena todos os dados e executa todas as aplicações, existe mais facilidade de manutenção e atualização dos sistemas. Alguns exemplos dessa arquitetura são terminais gráficos, \emph{Terminal Services}, \emph{WebService}, terminais VT100, dispositivo de navegador embutido, emuladores de terminal 3270, dentre outros.


\subsubsection{2 -- Cliente Pesado (Fat Client)}

O código e os dados são mantidos na estação de trabalho sem conectividade de rede. As aplicações são executadas localmente, exigindo maior capacidade de processamento, memória RAM, armazenamento em disco rígido, e ainda, utilização de \emph{drive} de disquete e CDROM. As vantagens são independência de outros computadores e servidores. Já as desvantagens constituem custo elevado, dificuldade em atualizar e dar manutenção ao sistema por ser descentralizado.


\subsubsection{3 -- Arquiteturas intermediárias}

Existem diversas formas de se desenvolver, executar e utilizar aplicações intermediárias nas arquiteturas Cliente Leve e Cliente Pesado, tais como armazenar a aplicação em um servidor e depois transferir para a estação de trabalho, para que ela seja executada quando necessário. Por exemplo, essa é a forma como trabalham \emph{applets} Java. Outra variante é o acesso remoto a servidores de arquivos. Os dados ficam armazenados remotamente, mas são acessados e executados localmente na estação de trabalho. Como exemplo dessa variante, temos a tecnologia de compartilhamento de arquivos NFS.



\subsubsection{4 -- Escolha da arquitetura}

A escolha da arquitetura para algum aplicativo, ou até mesmo a estação de trabalho, dependerá dos seguintes fatores:

\begin{description}

	\item[a) a largura de banda da rede para os servidores e o que essa largura de banda terá que carregar. ] 
Se as estações de trabalho não forem ``pesadas'' a rede terá que integrar os controles de interface humana, os dados, ou o código de aplicativo executado, além do tráfego normal da rede (TCP, UDP, etc). Em algumas circunstâncias, o volume de dados, gerados por uma única estação de trabalho ou um conjunto delas, pode ser excessivo para a capacidade da rede. Neste caso, alternativas têm de ser avaliadas para que a rede não seja sobrecarregada.

	\item[b) a latência aceitável no uso do aplicativo. ] 
Quando alguém interage com o aplicativo, ou a estação de trabalho, apertando teclas ou movendo o \emph{mouse}, o tempo que o aplicativo leva para reagir e mostrar o resultado na tela é conhecido como latência. Para alguns aplicativos, pode-se tolerar latência maior; já para outros é necessário que os resultados ocorram em tempo real. A latência vai depender da largura de banda disponível entre a interface humana e o aplicativo, entre o cliente e o servidor, e da capacidade da máquina de executar o código do aplicativo. Normalmente, para menor latência, o aplicativo deve operar na mesma máquina da interface humana, e essa máquina deve ser poderosa o suficiente para executar o aplicativo.



	\item[c) a política de segurança da instituição. ] 
Se os dados residem nas estações de trabalho distribuídas por toda a instituição, existe risco que se qualquer máquina for furtada ou estiver acessível em um ambiente inseguro, os dados podem ser perdidos ou divulgados a terceiros ou a pessoal desautorizado. Por sua vez, se os dados estiverem centralizados em um servidor, é preciso checar a segurança e a privacidade da conexão dos clientes ao servidor. Se os dados estiverem trafegando de forma não criptografada, com falhas no controle ao acesso, é possível que alguma pessoa não autorizada os veja enquanto eles trafegam pela rede. Neste momento é preciso rever as normas de segurança da instituição e analisar qual a melhor forma de adequar as soluções a essas normas.

	\item[d) a política de \emph{backup} da instituição. ] 
Se os dados residem nas estações de trabalho distribuídas por toda a instituição, será necessário um mecanismo de \emph{backup} centralizado, ou a responsabilidade pelo \emph{backup} deve ser distribuída entre muitas pessoas, provavelmente entre os próprios usuários. Um esquema centralizado de \emph{backup} poderia vir a ser complexo e requerer alta largura de banda de rede e cooperação com os usuários das estações de trabalho (os quais, por exemplo, devem lembrar de não desligar suas máquinas nos períodos em que estiverem marcados os \emph{backups}). Já em um sistema de Cliente Leve como os dados estão centralizados no servidor ou em um conjunto de servidores o \emph{backup} se torna mais fácil operacionalmente.

	\item [e) a política de armazenamento de arquivos.]
A forma como o armazenamento de arquivos será organizado poderá influir
diretamente em questões como desempenho da rede, capacidade dos
servidores de arquivos, segurança, entre outras. É preciso definir onde
e como os usuários devem guardar arquivos corporativos e, se for
permitido, documentos pessoais.   

	\item[f) o desenho do aplicativo. ] 
Se for necessário interação humana com o aplicativo, ele precisará ter interface com o usuário que poderá estar na estação de trabalho ou em um servidor. Por exemplo, um terminal IBM 3270 ou DEC VT100 tem todo o código de exibição processado no servidor. Já um terminal baseado em navegador, \emph{metaframe}, \emph{Terminal Server}, \emph{X-window system}, terminal gráfico, VNC divide o código de exibição entre o servidor e o cliente.

	\item[g) a capacidade da estação de trabalho de executar o aplicativo. ] 
Na arquitetura de Cliente Pesado, quanto mais capacidade de processamento os aplicativos exigirem, mais poderosa (e, portanto, mais cara) a estação de trabalho deverá ser.

	\item[h) a capacidade da estação de trabalho de armazenar dados. ] 
Alguns aplicativos necessitam acessar grandes bases de dados, as quais só podem ser sustentados por servidores especializados.

	\item[i) o desempenho dos servidores disponíveis. ] 
Se um aplicativo é executado remotamente em um servidor, e não na estação de trabalho, o servidor deve ser suficientemente poderoso para executar todas as instâncias do aplicativo necessárias, no momento em que o número máximo de clientes estiver em uso.

	\item[j) o custo total de implementação. ] 
É importante destacarmos que, de forma semelhante a qualquer problema de engenharia, não há uma solução aplicável a todas as situações. Por exemplo, uma estação de trabalho pode operar de determinada forma para um aplicativo e de outra para um aplicativo diferente. Esses detalhes devem ser considerados como custos operacionais nos processos de migração.

\end{description}


\section{Arquitetura Básica de Referência}

A Arquitetura Básica de Referência (ABR) utilizada neste documento foi escolhida de maneira que possa ser aplicável na maioria das situações. Ela pode se tornar mais ``leve'' ou mais ``pesada'' para aplicativos ou perfis específicos, caso necessário. Muitas vezes a arquitetura utilizada em uma instituição tende a ser uma combinação de várias arquiteturas, cada uma escolhida para situações específicas.

A ABR é caracterizada como uma estação de trabalho sem condição específica, na qual:
\begin{itemize} 
	\item[a) ] todos os aplicativos são executados, sempre que possível, na estação de trabalho e são armazenados nela mesma;
	\item[b) ] nenhum dado persistente é guardado na estação de trabalho;  são armazenados em um servidor central;
	\item[c) ] toda a autenticação e a autorização são controladas por servidores centrais;
	\item[d) ] a gestão do sistema é centralizada;
	\item[e) ] o objetivo é que as estações de trabalho fiquem operacionais e não necessitem de suporte local.
\end{itemize} 


Os aplicativos funcionam localmente para reduzir quaisquer problemas de latência, e a ABR pressupõe a existência de banda larga suficiente para que os dados sejam mantidos centralmente. Além disso, pressupõe-se que todas as estações de trabalho sejam essencialmente idênticas, permitindo que qualquer pessoa se conecte a qualquer máquina que lhe seja permitido usar. Deve haver regime de gestão de sistemas eficiente para manter as instalações dos aplicativos das estações de trabalhos em harmonia.

A ABR concentra todos os dados importantes da organização nos servidores centrais, visando facilitar a gestão da informação e os processos de \emph{backup}, e disponibiliza estações de trabalho individuais, reduzindo o impacto na eventual avaria de uma máquina cliente.

A manutenção dos dados de forma local estabelece uma identificação da máquina com o usuário. Isso causa problemas quando o usuário muda de lugar ou deixa a organização. Também transforma o lugar da estação de trabalho em local específico de um usuário, dificultando a implementação da sistemática de mobilidade, na qual o usuário tem suas personalizações em qualquer estação que vier a utilizar (conceito \emph{hot-desking}).

A manutenção dos dados de forma central elimina essas dificuldades e flexibiliza a utilização da estação de trabalho. Também permite que se reduza a exigência de armazenamento local na estação de trabalho. Com isso, a estação transforma-se em um dispositivo do tipo ``ligar e funcionar'', facilitando a instalação. Dessa forma, a ABR é considerada boa escolha para diversas situações.

A ABR não é recomendada para \emph{laptops}, ou para estações de trabalho que não estejam permanentemente conectados à rede da instituição. Tais dispositivos, por muitas vezes executarem suas operações localmente, necessitariam de mais recursos para armazenar todos os dados. 


\chapter{Grupos Funcionais}


Este Capítulo visa apresentar os sistemas e os aplicativos no \emph{Software} Livre disponíveis segundo sua categoria. Para organização, os sistemas foram separados em três grandes grupos:

\begin{itemize} 
       \item Sistema Operacional -- uma vez que a maioria das considerações acerca do ambiente operacional é pertinente tanto a estações de trabalho como a servidores, elas serão tratadas à parte;
       \item Estação de trabalho -- considerações quanto a aplicações voltadas para utilização em estações de trabalho;
       \item Servidores -- abordagem dos módulos de servidores de diversos tipos.
\end{itemize} 

O segundo e o terceiro itens são organizados dentro de grupos funcionais, definindo os tipos característicos de atividade genérica de computador em uma Administração.
Eventuais atividades desconsideradas devem ser, em geral, as usadas por pequena proporção da população de usuários.
Entretanto, caso o leitor julgue que determinada 
solução deveria ser contemplada, por
favor, envie sugestão para o endereço eletrônico
<\www{guialivre@planejamento.gov.br}> para que a 
equipe de redação possa avaliá-la e incluí-la nas 
versões futuras deste documento. 


A grande quantidade de \emph{Software} Livre existente indica que, para muitas funções, há vários aplicativos diferentes disponíveis. A escolha do aplicativo a ser usado não é sempre evidente e deve ser pautada por diretrizes e especificações técnicas.

Outro ponto a ser considerado se refere a exigências específicas da Administração quanto aos formatos dos arquivos gerados e aos padrões de interoperabilidade. No caso do Governo Federal brasileiro essa regulamentação se encontra estabelecida na e-PING.

O modelo de referência usado nestas diretrizes deve, portanto, ser tratado como exemplo de um sistema que, reconhecidamente, funciona mais do que como uma recomendação de sistema para ser usado em todas as circunstâncias.

%As diretrizes discutem os assuntos que tomadores de decisões devem levar em conta; pode acontecer de essas pessoas chegarem a conclusões diferentes, mas igualmente válidas. Em qualquer caso, restrições locais ao Administrador podem tornar necessária a escolha de modelo diferente. 
%As escolhas possíveis para cada grupo são discutidas em detalhes no Capítulo 11, para os grupos Principais, e no Capítulo 12, para os Auxiliares.

Há alguns sítios de referência úteis, que contêm listas de aplicativos de \emph{Software} Livre, mostrando o que há disponível, e candidatos à substituição de aplicativos proprietários. O sítio <\www{http://linuxshop.ru/linuxbegin/win-lin-soft-en}> é exemplo disso.

O sítio <\www{http://www.osafoundation.org/desktop-linux-overview.pdf}> contém detalhes de muitos dos aplicativos discutidos a seguir. Torna-se, dessa forma, outro local em que os Administradores podem obter mais informações, especialmente sobre estação de trabalho.

Um dos pontos fortes do \emph{Software} Livre é o fato de ser modular e poder ser montado de várias formas diferentes, permitindo que os sistemas sejam talhados para satisfazer a necessidades específicas. Essa modularidade é possível porque o \emph{Software} Livre se adapta a interfaces abertas e disponíveis publicamente.

Essa flexibilidade pode, às vezes, traduzir-se como dificuldade, já que os Administradores podem ter dificuldades com a grande quantidade de opções disponíveis. Há muitas organizações que podem prover ajuda e suporte, da mesma forma como existe no mercado proprietário. 


\section{Sistema Operacional}

Há vários sistemas operacionais livres e várias distribuições (explicado adiante). Entretanto, muitas pessoas só têm ouvido falar do GNU/Linux e geralmente pelo nome Linux.

Um sistema operacional consiste de um \emph{kernel}, programa responsável pela alocação dos recursos da máquina que opera em modo supervisor, junto com programas de suporte que operam sob o controle do \emph{kernel} no modo usuário. O Linux é um \emph{kernel}, mas demanda carregadores de suporte, compiladores, drivers etc. A maior parte desses programas de suporte é fornecida pelo projeto GNU da Free \emph{Software} Foundation, sendo, portanto, chamados de programas GNU. A conjunção do \emph{software} GNU com o \emph{kernel} Linux forma o sistema GNU/Linux, termo correto a ser utilizado.

O \emph{kernel} do Linux é fornecido em pacote, junto com um conjunto de programas de suporte e aplicativos, formando uma distribuição.
Os componentes do conteúdo de uma distribuição devem interagir, e o \emph{kernel} pode ser compilado para possuir características específicas não disponíveis como padrão. Portanto, a escolha da distribuição deve ser considerada, já que cada uma possui suas próprias características nativas.

Algumas distribuições, como Conectiva, Mandriva\reg, Red Hat\reg e Novell/SuSE\reg, 
são mantidas por companhias que oferecem
suporte especializado dos seus produtos.
Outras distribuições, como o Kurumin, Debian, Slackware, Fedora e o Gentoo, não são preparados por uma organização comercial.
O suporte para essas distribuições vem de terceiros ou de acessos a listas de discussão e sítios na Internet. Essas ferramentas podem oferecer equivalentes níveis de cobertura às 
distribuições comerciais.


A distribuição Debian\footnote{
\wwn{http://www.debian.org}.} 
é reconhecida por sua estabilidade e sua robustez. As versões estáveis apresentam códigos cuidadosamente testados pela sua comunidade de desenvolvedores e raramente incluem aplicativos que não sejam distribuídos com licença de código aberto.

A distribuição Slackware\footnote{
\wwn{http://www.slackware.com}.}
é a distribuição Linux mais antiga em 
atividade. 
É uma distribuição de Linux para uso geral que 
se mantém mais próxima dos sistemas Unix.

O Gentoo\footnote{
\wwn{http://www.gentoo.org}.} 
é uma distribuição que contém apenas o código-fonte. 
Dessa forma, a Administração pode construir seus próprios binários facilmente, customizando a distribuição a seu ambiente e seus equipamentos. Construir uma distribuição do zero demanda tempo, porém, uma vez produzidos os binários, eles estarão disponíveis e poderão ser facilmente copiados. Esta é nova distribuição com características próprias que devem ser consideradas. Pelo fato de que a maior parte das distribuições fornece seu código de fonte completo, é possível customizar qualquer uma delas da mesma forma, porém o Gentoo deve ser mais receptivo a este tratamento.

O Kurumin\footnote{
\wwn{http://www.guiadohardware.net/kurumin}.} 
é uma distribuição enxuta que roda a partir do CD e facilita a migração de sistemas proprietários para GNU/Linux. Ele adota sistema de instalação e configuração simples, usando \emph{scripts} que facilitam muito a vida do usuário. É baseado em GNU/Debian e utiliza o sistema de detecção de \emph{hardware} e configuração automática do Knoppix.

As distribuições comerciais vêm em pacotes, com diferentes níveis de suporte. A distribuição disponível via Internet tem suporte geralmente por um ano; após esse período, os usuários têm que executar \emph{upgrade}. A maior parte das companhias oferece uma versão comercial, que tem garantia de suporte por cinco anos ou mais e é baseada em versões estáveis. Tais versões também possuem um contrato de suporte associado a elas que, às vezes, é chamado de licença, embora o código seja licenciado usando o GPL ou o LGPL e não de outra forma. O que muitos Administradores desejam é a disponibilidade de tais distribuições estáveis e o suporte para elas. Na verdade, uma razão que justifica a mudança para \emph{Software} Livre é a inexistência de pressão para \emph{upgrade} de forma constante e desnecessária. As companhias prometem conserto de defeitos de \emph{backport} independentemente de qualquer renovação contratual.

Entende-se que plataformas GNU/Linux são mais indicadas tanto para estações de trabalho quanto para servidores, uma vez que oferecem várias opções de ferramentas e pacotes de configuração, serviços nativos e apresentam alta robustez e estabilidade, comparativamente às plataformas proprietárias. Com relação a servidores, a Administração poderá optar também pela utilização de plataformas BSD\footnote{
\wwn{http://www.bsd.org}.}: 
FreeBSD\footnote{
\wwn{http://www.freebsd.org}.}, 
OpenBSD\footnote{
\wwn{http://www.openbsd.org}.} ou 
NetBSD\footnote{
\wwn{http://www.netbsd.org}.}.



\section{Estação de Trabalho}

Conforme destacado, GNU/Linux é o sistema operacional mais indicado para estações de trabalho. Os sistemas de arquivos contendo binários (tais como \txt{usr}) podem ser montados em formato ``somente para leitura'', para evitar que usuários alterem seu conteúdo, e os remanescentes montados em formato ``não executável'', para evitar que o código seja executado a partir deles. 
Caso seja determinado pela Administração, a 
interface do usuário poderá ser ajustada para 
permitir aos usuários executarem programas somente por meio de interfaces pré-definidas. Isso exprime que o acesso à linha de comando ou a habilidade de criar ou mudar itens de menu ou ícones devem ser removidos ou desabilitados.

Os sistemas de arquivos que contém dados voláteis baseados no usuário devem ser montados a partir de um servidor NFS central. A autenticação de usuário é realizada por um serviço de diretório LDAP.

Sugerimos ainda que servidores centrais forneçam endereço IP e configuração de rede por DHCP e resolução de nome por servidor DNS no momento em que o computador é ligado e se inicia a carga do sistema operacional. 


\subsection{Gerenciadores de Janelas}

Há várias opções de gerenciadores, que vão dos gestores leves de janelas muito simples, como o Icewm\footnote{
\wwn{http://www.icewm.org}.}, até gestores de sessão completos, como os incluídos no GNOME e no KDE. A escolha depende do uso pretendido.

Dos gerenciadores de janelas, o KDE e o GNOME são os mais maduros, mas existem outros em desenvolvimento se aproximando rapidamente. O GNOME tem o suporte da Sun Microsystems e de membros da GNOME Foundation. Existem opções de gerenciadores mais leves, a serem utilizados em equipamentos de menor capacidade. Dois exemplos são os ZAPPWM\footnote{
\wwn{http://www.zappwm.cjb.net}.}, que possuem características bastante interessantes e tamanho muito reduzido (apenas 2 Mb), e o Blanes 2000\footnote{
\wwn{http://labdid.if.usp.br/~blanes}.}, que tem a vantagem de interface gráfica muito parecida com algumas versões de \emph{software} proprietário.

A Ximian\reg lançou um ambiente de trabalho baseado no GNOME chamado XD2. Ele trabalha sobre várias distribuições de base diferentes, inclusive o Red Hat\reg e SuSE\reg. A Ximian\reg dedicou-se especialmente a integrar os vários diferentes aplicativos, para certificar-se de que trabalham de forma similar. Isso significa que eles incluíram suas próprias versões de alguns produtos como OpenOffice.org.

Outra opção para Gerenciadores de Janelas é o XFCE\footnote{
\wwn{http://www.xfce.org}.}, que consome menos recursos de \emph{hardware} que o GNOME ou KDE e facilita a migração usuários de outros sistemas Unix, como Solaris\reg, AIX\reg  etc.

A escolha do gerenciador de janelas será provavelmente definida pelo usuário, a menos que a Administração defina um ambiente por questões gerenciais ou de padronização. Na hipótese de limitação de \emph{hardware}, sugere-se que sejam utilizados aplicativos desenhados para a interface gráfica que está sendo utilizada. Aplicativos desenhados para trabalhar em um ambiente funcionarão em outro, porém haverá necessidade de se carregar bibliotecas específicas, o que poderá influenciar na performance do equipamento. 



\subsection{Escritório}

Abrange a criação, a modificação e a impressão de arquivos contendo dados do negócio em formato padrão, tais como cartas e relatórios. Também a criação, a modificação e a impressão de planilhas e apresentações. É preciso que haja utilitários para gerenciar esses arquivos. Deve ser possível ler e escrever formatos proprietários da melhor maneira possível, quando isso se tornar necessário. Quanto aos formatos abertos, obviamente, estes devem ser passíveis de leitura e escrita sem dificuldade. Deve ser disponibilizado o idioma Português brasileiro e, preferencialmente, outros possíveis idiomas a serem utilizados, como o Espanhol e o Inglês, além de configurações de moedas e alfabetos que sejam úteis para o trabalho cotidiano.


\subsubsection{Escritório -- Opções}


Um pacote de escritório muito utilizado  atualmente, sobretudo na Administração Pública, é o Microsoft Office\reg. Ele inclui os aplicativos proprietários de editor de texto, planilha, apresentação e correio eletrônico, junto com seus formatos também proprietários. Os formatos não são abertos e mudam de uma versão do MS-Office\reg para outra. Até mesmo os próprios produtos da Microsoft\reg não podem garantir a capacidade de ler e escrever um arquivo legado com total precisão, a não ser que os arquivos tenham sido criados na mesma versão do produto.

Os aplicativos \emph{Software} Livre, hoje, são capazes de ler formatos fechados com tal precisão que os problemas encontrados não são diferentes dos vistos com o uso das diferentes versões dos próprios produtos proprietários. Quanto mais antigo o formato, melhor os aplicativos do \emph{Software} Livre lidam com aquele. Os aplicativos \emph{Software} Livre tendem a ser mais eficientes na leitura de arquivos em formato proprietários do que na escrita deles. Em geral, os aplicativos \emph{Software} Livre podem ser usados com confiança para operações com proprietários similares.

A exceção ocorre quando é requerido algum tipo de trabalho colaborativo e, no mínimo, uma das partes insiste em usar um formato proprietário. A leitura, a alteração e a reescrita dos arquivos nesses formatos podem introduzir anomalias que o uso de um aplicativo proprietário único não faria. No entanto, deve-se ter em mente que esse tipo de erro também pode ocorrer caso sejam usadas diferentes versões do \emph{software} proprietário. Sugerimos nestes casos o uso do formato RTF (\emph{Rich Text Format}) ou mesmo o texto puro, até que formatações sejam requeridas e padronizadas. Para arquivos que só permitem leitura, sem atualização, o formato PDF ou o PS podem ser usados.

Podemos julgar também que a interface do usuário deve ser tão similar quanto possível ao \emph{software} proprietário, para minimizar custos de retreinamento. Alguns \emph{scripts} de configuração fazem isso automaticamente, por exemplo, na suíte OpenOffice.org, que possibilitem sua utilização para instalação em larga escala.

Modelos e Macros são comuns em muitas Administrações. Elas têm um formato proprietário fechado e terão que ser reescritas ou adaptadas.

Está disponível na Internet um estudo-piloto que compara a capacidade dos vários conjuntos de escritório em \emph{Software} Livre para lidar com os arquivos proprietários:\\
<\www{http://www.acmqueue.com/modules.php?name=Content&pa=showpage&pid=55}>.


Atualmente existem, três opções de pacotes de escritório em \emph{Software} Livre que podem ser considerados pela Administração são o OpenOffice.org, o KOffice e o GNOME Office.


\subsubsection{a. OpenOffice.org}

O OpenOffice.org\footnote{No Brasil por problemas de registro de marca o OpenOffice.org é chamado de BrOffice} é um conjunto de aplicações para escritórios baseado no StarOffice, produzido por uma empresa alemã chamada StarDivision. A Sun Microsystems comprou a StarDivision e franqueou o código à comunidade de \emph{Software} Livre. Continua a colocar no mercado uma versão do OpenOffice.org, ainda chamada StarOffice, que vende a  preço muito mais barato do que o dos pacotes proprietários correspondentes.

\figura{fig:oowriter}{openoffice_writer.png}{.4}{Editor de Texto do OpenOffice.org.}

O StarOffice e o OpenOffice.org são essencialmente idênticos, exceto porque:

\begin{itemize} 
       \item a Sun Microsystems fornece suporte comercial para o StarOffice;
       \item o StarOffice possui um sistema de banco de dados construído internamente (Adabas);
       \item o StarOffice tem alguns filtros extra para migração para/de outros pacotes de escritório (no entanto, o filtro do Wordperfect não é disponível em GNU/Linux em razão de licença);
       \item o StarOffice possui algumas fontes proprietárias;
       \item o StarOffice só é disponível em um conjunto de idiomas mais restrito (Alemão, Francês, Italiano, Inglês, Espanhol, Sueco e Português Brasileiro; além de algumas linguagens asiáticas);
       \item o OpenOffice.org é atualizado mais freqüentemente que o StarOffice;
	\item o OpenOffice.org é considerado \emph{Software} Livre em sua plenitude.
\end{itemize}
 
Ambos aplicativos são comparáveis às suítes de \emph{software} proprietário, porém alguns componentes destas suítes podem não estar contemplados, podendo ser obtidos à parte, também em \emph{Software} Livre. Ambos os pacotes lidam com a maior parte dos arquivos de formato proprietário, inclusive as versões mais recentes destes, embora a compatibilidade possa piorar com as versões mais novas. Não lidam com arquivos protegidos por senhas (exceto para proteção de planilhas página a página) e apresentam alguns problemas com objetos gráficos com \emph{link} com OLE. Ainda assim, possuem algumas das melhores integrações de formatos de arquivos de outras ferramentas de escritório. 

\figura{fig:ooimpres}{openoffice_impress.png}{.4}{Editor de apresentações do OpenOffice.org.}

Se a Administração está migrando de um ambiente proprietário, o OpenOffice.org possui uma versão para vários sistemas operacionais. Dessa forma, é possível realizar a instalação 
ainda no ambiente a que estão familiarizados os usuários, 
promovendo contato imediato com a solução.

A Sun Microsystems está estabelecendo ligações com companhias, para traduzir macros e modelos proprietários para uma forma compatível com o StarOffice.

Os dois aplicativos também oferecem uma interface Java, porém só reconhecem atualmente o JDK da Sun Microsystems. A Sun Microsystems anunciou um projeto para desenvolver um tradutor de \emph{Visual Basic for Applications} (VBA) para Java.

A versão disponível para cópia do OpenOffice.org.br contém o dicionário de Português brasileiro; além disso existem dicionários para diversos idiomas disponíveis. Já há versões pré-construídas em mais de 25 línguas diferentes.

Embora o OpenOffice.org não ofereça atualmente um pacote de banco de dados, ele contém interfaces ODBC e JDBC com muitos sistemas comuns de banco de dados, inclusive com os populares do \emph{Software} Livre. Além disso, não há filtros de conversão para Wordperfect, porém lançamento futuro está planejado. Ambos trabalham em uma faixa de sistemas operacionais que inclui ambientes proprietário e livre.

O OpenOffice.org possui uma versão em Português brasileiro sendo constantemente desenvolvida, disponível para cópia no endereço <\www{http://www.openoffice.org.br}>. Neste sítio do OpenOffice.org.br -- Projeto Brasil, há uma série de documentações sobre instalação, uso e funcionalidades avançadas do Produto. Veja mais nesse endereço, dentro da área de Ajuda -- Documentação. 


\subsubsection{b. Koffice}

Este é o componente office da estação de trabalho KDE. É um pacote integrado que oferece processador de textos, planilhas, mapas e gráficos, apresentações, ilustrações, geração de relatórios e ferramentas para fluxogramas, com \emph{desktop} opcional chamado Workspace.

\figura{fig:kword}{kword.png}{.37}{Editor de Texto Kword.}

Os filtros de arquivos proprietários não são tão bons quanto os oferecidos pelo OpenOffice.org. Ele não tem linguagem macro, mas existem \emph{scritps} disponíveis.


\subsubsection{c. GNOME Office}

O Gnome Office é uma coleção de programas escritos nos padrões GNOME; podem, portanto, integrar  uns aos outros, têm interface similar com o usuário e devem ser capazes de embutir  uns nos outros.

O OpenOffice.org é considerado agora parte do GNOME Office, muito embora não se prenda aos padrões do GNOME. A Ximian\reg, particularmente, está trabalhando para tornar o OpenOffice.org mais compatível com o GNOME; assim, incluiu sua  versão no mais recente produto para estações de trabalho, o XD2. Veja em <\www{http://www.gnome.org/projects}> para obter mais detalhes.

O GNOME Office conta com muitos componentes, incluindo o AbiWord (processador de texto), o Gnumeric (planilhas), o Sodipodi e o Sketch (desenho de gráficos vetoriais), o Gimp (edição de imagens), o Eye of GNOME (exibição de imagem), o Dia (gráficos de vetores, similar ao Visio), o MrProject (Gerência de Projetos) e o Agnubis (gráficos para apresentações), dentre outros. 

\figura{fig:abiword}{abiword.png}{.45}{Editor de Texto Abiword.}

Estes componentes apresentam graus variados de utilização. Por exemplo, o Abiword (Figura \ref{fig:abiword}) é solução eficiente para processamento de texto, mas apresenta limitações quanto à criação de tabelas; o Agnubis também exibe limitações; o Gnumeric mostra-se boa opção de planilha eletrônica.

\figura{fig:gnumeric}{gnumeric.png}{.4}{Gnumeric.}

O Gnumeric (Figura \ref{fig:gnumeric}), em particular, visa desenvolver uma planilha que pode fazer tudo que os equivalentes em \emph{software} proprietário fazem e ainda diversas funções adicionais. Os desenvolvedores 
são oriundos de formação na área de finanças
e incluíram várias características que tornam o Gnumeric especialmente útil para aplicações financeiras. É nessa área que eles acreditam que o Gnumeric seja superior ao \emph{software} proprietário.

O Gnumeric trabalha com diversos formatos de arquivos, inclusive compatíveis com \emph{software} proprietário e outros \emph{softwares} livres disponíveis no mercado.

A gama de produtos disponíveis é interessante e, junto com o OpenOffice.org, oferecem bom número de soluções diferentes. No entanto, caso seja necessário um conjunto integrado, o OpenOffice.org é a melhor solução atualmente. 


\subsection{Gerenciamento de Projetos}

A gerência sistematizada de projetos vem sendo adotada em muitas organizações, sejam elas públicas sejam particulares, de grande ou pequeno porte. Existe uma variedade de ferramentas livres destinadas a auxiliar os trabalhos de planejamento e acompanhamento de projetos. Algumas dessas aplicações são instaladas em servidor e acessadas via navegador \emph{web}, enquanto outras são instaladas nas próprias estações de trabalho, servindo a seus usuários. Em qualquer dos casos, a aplicação precisa ser utilizada a partir de um computador pessoal; portanto, aborda-se esta classe de aplicativo dentro do tópico ``Estação de Trabalho''.

Os recursos que cada aplicativo de auxílio à gerência de projeto disponibiliza variam bastante, havendo alguns mais completos e outros com funções para determinada atividade, como, por exemplo, o desenho de gráficos. São citados a seguir alguns exemplos dessas ferramentas. 


\subsubsection{GanttProject}

O GanttProject\footnote{
\wwn{http://sourceforge.net/projects/ganttproject}.} 
é uma alternativa para gerenciamento de projetos que não necessitem de elevado grau de sofisticação. Possui a vantagem de ser multiplataforma, o que facilita a migração posterior do sistema operacional. É executado localmente em estações de trabalho.


\subsubsection{DotProject}

O DotProject\footnote{
\wwn{http://www.dotproject.net}.} é acessado via navegador \emph{web}, devendo ser instalado em  equipamento com servidor \emph{web}, suporte a PHP e banco de dados MySQL. É um sistema de gerência de projetos bastante completo, contando com interface em Português, customizável. Possibilita o cadastro de usuários múltiplos, de modo que o acesso se torna personalizado e específico aos projetos em que se está atuando. Outras funcionalidades incluem:
\begin{itemize} 
       \item gerenciamento de clientes e instituições (empresas, departamentos etc.);
       \item listagem dos projetos;
       \item lista hierárquica de atividades;
       \item gráfico de Gantt;
       \item repositório de arquivos;
       \item lista de contatos;
       \item calendário;
       \item fórum de discussão.
\end{itemize}

\subsubsection{Planner}

O Planner\footnote{
\wwn{http://www.imendio.com/projects/planner}.}
é uma ferramenta para planejamento, agendamento e acompanhamento de projetos, voltado para o GNOME Desktop.

O Projeto é realizado pela Imendio, que desenvolve o \emph{software} em cooperação com a comunidade. 


\subsubsection{Netoffice}

O NetOffice\footnote{
\wwn{http://netoffice.sourceforge.net}.}
é um projeto de gerência on-line com colaboração da equipe, gerência de usuário, níveis de acesso simultâneo, tarefas, projetos, acompanhamento de tempo, histórico de mudança de tarefa, acompanhamento de arquivos aprovados, notas, sítios de projeto de cliente, CRM e gráfico de Gantt, dentre outros.


\subsection{Correios}
\label{est_correios}

Esta Seção contempla a criação, o recebimento e a apresentação de correio eletrônico, incluindo suporte para correio seguro.


\subsubsection{Cliente de \emph{e-mail} -- Opções}


Há grande número de clientes de \emph{e-mail} (MUA) com interfaces amigáveis disponíveis em \emph{Software} Livre.

Para os que estão acostumados a usar clientes em \emph{software} proprietário e desejam ter algo similar, o Evolution é forte opção. Ele não é somente um cliente de correio, mas também um Gestor de Informação Pessoal (\emph{Personal Information Manager} -- PIM).  Possui suporte à integração LDAP e pode, portanto, acessar dados de nomes e endereços eletrônicos da Administração.

Está sendo desenvolvido ativamente pela Novell\reg. A Novell\reg tem um produto chamado Evolution Connector, que permite ao Evolution conectar-se ao Exchange Server\reg 2000 e 2003. O Connector era proprietário, mas teve seu código aberto e disponibilizado sob a licença GPL recentemente, não mais necessitando de licença para ser utilizado. 

\figura{fig:evolution_mail}{evolution_mail.png}{.4}{Cliente de \emph{e-mail} Evolution.}

O Evolution tem interface com o usuário similar à de um \emph{software} proprietário muito comum, tornando-se fácil para as pessoas aprenderem. Também possui alguns aspectos úteis, como as Pastas Virtuais. Mais informações sobre ele podem ser encontradas em\\
<\www{http://www.novell.com/products/evolution}>.

O Kmail e o Sylpheed são alternativas para clientes de \emph{e-mail}. Ambos  se integram com os principais ambientes de estações de trabalho do \emph{Software} Livre. Se a estação de trabalho for KDE, usamos o Kmail, ao passo que, se a estação de trabalho for GNOME, usamos o Sylpheed.


\figura{fig:kmail}{kmail.png}{.4}{Cliente de \emph{e-mail} Kmail.}

Em termos de clientes com suporte a correio seguro, o Evolution dá suporte ao GPG, porém não ao S/MIME, embora esperemos que o faça em breve. O Mozilla Mail provém suporte ao S/MIME, mas não ao GPG ou ao PGP -- ele o fará em breve. O Kmail dá suporte ao S/MIME, ao GPG e ao PGP e foi desenvolvido recentemente para funcionar como cliente para o servidor \emph{groupware} Kontact.

Muitos pacotes de \emph{groupware} também incluem clientes compatíveis com IMAP e POP3. Em geral, eles não são tão bons quanto o Evolution, mas podem ser suficientes, caso se  integrem  bem com as outras funções do \emph{groupware}.

Em alguns casos, pode ser melhor migrar algumas categorias de usuários de correio para uma interface de usuário baseada na \emph{web}. Existem diversas opções disponíveis neste segmento, dentre elas o SquirrelMail\footnote{
\wwn{http://www.squirrelmail.org/}.},
 o IMP\footnote{
Parte do framework Horde, localizado em \wwn{http://www.horde.org/imp}.}
 e o NeoMail\footnote{
\wwn{http://neocodesolutions.com/software/neomail}.}.

A Open Systems Application Foundation tem um produto chamado Chandler, que está em fase inicial, mas que vale a pena monitorá-lo para o futuro. É um similar em potencial do Evolution. 


\subsection{Calendários e \emph{groupware}}

Esses abrangem a criação e a gestão de calendários, catálogos de endereços/contatos, correio, bate-papo, lista de tarefas. Os calendários também devem permitir funções como a organização de reuniões e a reserva de salas.


\figura{fig:evolution}{evolution.png}{.4}{Evolution.}

O Evolution é uma opção para calendário pessoal e gestão de contatos. No momento parece difícil encontrar um \emph{groupware} com \emph{Software} Livre. Somente soluções baseadas na \emph{web} estão realmente disponíveis, embora recentemente o projeto Kontact tenha produzido uma solução, usando o Kmail como cliente. Portanto, para verdadeira solução de \emph{Software} Livre, teria que ser utilizado um navegador para acessar o \emph{groupware}.


\figura{fig:kontact}{kontact.png}{.4}{Kontact.}


\subsection{Navegador}

É o programa responsável para acesso a conteúdos publicados na \emph{web}.
Também pode incluir funcionalidades de criação de documentos para
publicação. No início os navegadores eram meros visualizadores de
páginas html, mas foram evoluindo, incorporando novas funções e
recebendo \emph{plugins} que hoje permitem uma maior interação entre o \emph{Browser}
e o usuário. 



\subsubsection{Diversidades de Navegadores}

Os principais navegadores em \emph{Software} Livre são Mozilla, Galeon e Konqueror. Há outros, como Lynx, que é somente texto e freqüentemente usado como base para navegadores para pessoas com necessidades específicas, e o Mozilla Firefox (anteriormente conhecido como Phoenix e depois como Firebird), variante do Mozilla.

O Mozilla é um projeto de \emph{Software} Livre abrangente, inclusive sendo a base para o Netscape 7. Ele contém correio e componentes de notícias junto com catálogo de endereços e ferramenta de autoria de páginas de Internet. Grande parte do código do Mozilla é usada por outros projetos, inclusive pelo Galeon e pelo OpenOffice.org. 

\figura{fig:mozilla}{mozilla.png}{.4}{Navegador Mozilla.}

O Mozilla é uma alternativa no caso de se requerer um produto que inclua os recursos de leitor de correios e catálogo de endereços. Também seria opção no caso da Administração estar usando, no momento, estações de trabalho com ambiente proprietário; então seria necessário que o navegador trabalhasse no ambiente existente, para permitir aos usuários contato inicial com o novo \emph{software} em ambiente familiar.


\figura{fig:galeon}{galeon.png}{.45}{Navegador Galeon.}

O Galeon é um navegador projetado para ser leve e rápido. É baseado no Gecko, o motor de renderização no qual se baseia o projeto do Mozilla, junto com interface de usuário GNOME. Ambos, Galeon e Mozilla, dão suporte a todos os padrões de Internet aberta (W3C, por exemplo) e podem executar Java e Javascript escritos apropriadamente.

Alguns conteúdos requerem \emph{plugins} que só estão disponíveis para ambientes proprietários. O produto proprietário CodeWeavers CrossOver Plugin permite a \emph{plugins} que trabalham em ambiente proprietário trabalharem no GNU/Linux.

O Konqueror é o navegador escrito para estações de trabalho KDE e também usado como gerenciador de arquivos ``arraste e solte''. Baseia-se no motor de renderização KHTML, com Mozilla Gecko como opção, junto com interface de usuário KDE. O Konqueror permite o acesso a todos os protocolos suportados no KDE. Por exemplo, permite acessar compartilhamentos Windows\reg\
via protocolo SMB. Além disso, integra-se de maneira transparente com outros programas e permite acesso a todos os dispositivos e impressoras. 


\figura{fig:konqueror}{konqueror.png}{.4}{Navegador Konqueror.}

O Firefox se aproxima de sua versão final 1.0, estando atualmente como candidato a distribuição 0.9. Ele tem sido bem visto pelo mercado, sendo apontado como aplicativo que poderá revolucionar este segmento.


\subsection{Banco de Dados Pessoais ou Locais}

Esses são as ferramentas de gerência de informações estruturadas em banco de dados pessoais utilizados de forma local, ou seja, na própria estação de trabalho. Têm suporte por intermédio de alguns produtos que também são considerados SGBD's centrais e completos.

Para que tenham funcionalidades similares a um banco de dados \emph{ad hoc}, utilizam-se ferramentas externas de acesso a esses mecanismos. Tais ferramentas disponibilizam funcionalidades que incluem: manutenção (criar, alterar e remover) de tabelas e índices; consultas específicas (utilizando o SQL como linguagem de consulta); relatórios para impressão ou visualização; e ainda possibilidade de se construírem formulários para a automação do processamento dos dados armazenados, como uma tela amigável para inclusão de registros, ou uma grade (ou matriz) dos dados existentes para uma navegação interativa que facilite a escolha para alteração/exclusão.

Bancos de dados pessoais podem ser baseados no MySQL ou em um produto de \emph{groupware} baseado na \emph{web}, como phpGroupware. O Firebird, por possuir forma de instalação simplificada, pode também ser considerado para essa função.


\subsubsection{Conectividade de Bancos de Dados}
\label{conectividade_bancos_de_dados}

A maior parte dos produtos SGBDs dão suporte direto a APIs com ligações de linguagem C. Alguns também dão suporte naturalmente a C++. Costumam oferecer normalmente conectividade ODBC ou JDBC. Alguns também oferecem conectividade NET.

Há um produto chamado Unix-ODBC\footnote{
veja em \wwn{http://www.unixodbc.org}.} que provê conectividade do tipo ODBC aos programas Unix e GNU/Linux, incluindo suporte para KDE e GNOME. 


\section{Servidores}

O sistema operacional em \emph{Software} Livre sugerido para esse segmento é o GNU/Linux. Para máquinas altamente seguras, como \emph{firewalls}, os sistemas baseados em BSD, como o OpenBSD, podem ser boa escolha, pelas características de segurança atribuídas a esses sistemas.

As principais funções dos servidores são fornecidas pelos serviços descritos a seguir. 


\subsection{Serviço de Correio}
\label{servico_correio}

O serviço de correio é uma área complexa, que apresenta muitos componentes lógicos  e  riqueza de aplicativos baseados em \emph{Software} Livre, alguns dos quais sobrepõem funcionalidades comparativamente aos aplicativos proprietários. Também encontra-se estreitamente ligado a questões  relativas a controle de vírus e de \emph{spam}.

A escolha dos aplicativos apropriados é complexa, e está incluída no Apêndice \ref{apendice_correio}  discussão detalhada sobre essas questões, junto com a definição de todos os termos usados aqui.


\subsubsection{Opções de MTA -- Transferência de Correio}

Alguns dos principais MTAs do \emph{Software} Livre são Sendmail, Postfix, Qmail, Courier-MTA e Exim. Há muitos outros, mas estes são considerados os principais, por serem usados em larga escala.

Tradicionalmente, os sítios \emph{Unix-like} utilizavam o Sendmail\footnote{
\wwn{http://www.sendmail.org}.} como seu MTA. Infelizmente, ele apresentou registro de segurança insuficiente e também é notoriamente difícil de configurar. 
Existem outras opções disponíveis que poderão dificultar
a escolha, em função das funcionalidades apresentadas.
No entanto, há uma diferença significativa no padrão da documentação disponível em português.

A seguir, apresentamos as principais opções de MTA, além do Sendmail.

\begin{enumerate} 
   \item  O Courier-MTA\footnote{
\wwn{http://www.courier-mta.org}.} faz parte de uma família com MTA, MDA (Mail Delivery Agent), MAA e pacote webmail (SqWebMail) disponível. Cada parte pode ser usada por si, ou integrada com o resto da família.

   \item                  O Postfix\footnote{
\wwn{http://www.postfix.org}.} consiste em  alternativa compatível com o Sendmail, objetivando ser rápido, fácil de administrar e seguro. Possui arquitetura modular, diversas opções de configuração e extensões para atender a inúmeras demandas diferentes, tais como antivírus, anti-spam, armazenamento dos usuários em uma base LDAP etc.

   \item                  O Qmail\footnote{
\wwn{http://www.qmail.org}, -- 
\wwn{http://www.lifewithqmail.org}.}, é um MTA, rápido, moderno, que possui grande base de usuários, é um \emph{software} aberto, que possui algumas restrições quanto à redistribuição de alterações e binários. Exige um pouco mais de esforço para a configuração de servidores de \emph{e-mail} complexos.

   \item                  O Exim\footnote{
\wwn{http://www.exim.org}.}, apresenta capacidade similar ao Sendmail, facilidade de configuração e 
provavelmente maior nível de segurança.

\end{enumerate}

A escolha não é evidente, e os Administradores devem tomar suas decisões com base nas necessidades locais, nos conhecimentos técnicos de cada programa. 


\subsubsection{Opções de MAA e MDA -- Depósito e Entrega de Correio}

Muitos Administradores preferem que os clientes usem o armazenamento central de correio, em vez de descarregar as mensagens para armazenamento local na estação de trabalho do cliente. Para essa função, recomendamos o uso do IMAP.

Alguns dos servidores IMAP em \emph{Software} Livre bem conhecidos são o UW-IMAP (às vezes chamados somente de IMAP), o Courier-IMAP e o Cyrus. O UW-IMAP\footnote{
\wwn{http://www.washington.edu/imap}.} tem uma história de segurança insuficiente e não é muito recomendado. Dos outros dois, o Courier-IMAP\footnote{
\wwn{http://www.inter7.com/index.php?page=courierimap}.} é largamente conhecido por ser o mais fácil de configurar. Ele tem um tamanho pequeno e trabalha bem com o Postfix e o Courier-MTA. É a parte MAA da família Courier. Ele necessita do maildir como formato de armazenamento de correio.

O Cyrus\footnote{
\wwn{http://asg.web.cmu.edu/cyrus/}.}  usa o próprio formato de armazenamento de correio, que é similar ao maildir, e necessita do próprio MDA para completar o armazenamento de correio.

Ambos, Courier-IMAP e Cyrus, suportam o TLS (um protocolo padrão de autenticação e privacidade).

Há vários MDAs como, por exemplo, o procmail\footnote
{\wwn{http://www.procmail.org/}.}, o maildrop, que é parte da família do Courier e fornecimento da Cyrus. Os MDAs também possuem a habilidade de filtrar o correio de acordo com regras sofisticadas, o que é útil se o MUA usado não contiver dispositivos de filtro.

Uma escolha de referência é o Courier-IMAP sem MDA. Não é preciso um MDA, porque o Exim é capaz de escrever diretamente para as estruturas maildir e o Evolution tem os próprios filtros com muita capacidade. 


\subsubsection{Outras Ferramentas de Correio}

Existe grande número de filtros de \emph{e-mail} livres, ferramentas Anti-Spam, que evitam que anexos executáveis sejam baixados juntamente com os e-mails, e diversos outros tipos de opções. Atualmente há muitos projetos (cerca de 360) desse tipo cadastrados no Sourceforge.net. Obtenha mais informações em:\\
 \www{http://sourceforge.net/softwaremap/trove_list.php?form_cat=29}.

O \textbf{SpamAssassin}\footnote{
\wwn{http://useast.spamassassin.org/}.} é provavelmente o mais utilizado de todos os filtros anti-spam. Seu princípio de funcionamento é buscar por assinaturas heurísticas típicas de SPAMS no cabeçalho e no corpo das mensagens e atribuir a cada ocorrência encontrada uma pontuação. Após isso, a pontuação é checada; se exceder o limite do que é considerado normal, a mensagem é declarada como SPAM. Ele pode rodar diretamente no MTA ou no MUA. No sítio oficial podem ser encontradas diversas informações: como configurá-lo e utilizar em diversos MTA's diferentes e MUA's.



O \textbf{Anomy Sanitizer}\footnote{
\wwn{http://mailtools.anomy.net/}.} é um conjunto de filtros que permite que se procurem  vírus nas mensagens de \emph{e-mail}, desabilitem códigos HTML e Javascript potencialmente perigosos, bloqueiem ou removam anexos baseado em seus nomes de arquivo. Dessa forma, é possível bloquear \emph{Visual Basic scripts} eliminando o risco inerente à recepção deste tipo de arquivo. 

O \textbf{MailScanner}\footnote{
\wwn{http://www.mailscanner.info/}.} é um \emph{e-mail} vírus scanner, protetor de vulnerabilidades e marcador de spam. Ele utiliza o SpamAssassin para detecção dos spams e é desenhado para tratar com ataques do tipo Denial Of Service. Ele vai detectar arquivos \emph{zip} protegidos por senhas e aplicar checagem de nome de arquivos aos seus conteúdos. É muito fácil de instalar e suporta grande quantidade de servidores de \emph{e-mail}, Postfix, Sendmail, Exim, Qmail, Zmailler e diversos antivírus: Sophos, MacAfee, F-Prot, F-Secure, DrWeb, ClamAV, BitDefender, RAV, Panda e muitos outros antivírus. Ele pode ser integrado em qualquer sistema de \emph{e-mail}.



O \textbf{Fetchmail}\footnote{
\wwn{http://www.catb.org/~esr/fetchmail/}.} é um aplicativo completo, bem documentado e robusto para fazer cópia de \emph{e-mails} remotos e realizar encaminhamento entre servidores. Suporta quase todos os protocolos de acesso remoto a \emph{e-mail} em uso atualmente na Internet, tais como POP2, POP3, RPOP, APOP, KPOP, todos os tipos de IMAP, ETRN, e ODMR. Também permite IPv6 e IPSEC. Suporta diversos tipos de autenticação, tais como NTLM, IMAP RFC1731 \emph{encrypted method}. Como ele puxa o correio para uma máquina (a transferência é iniciada pela máquina receptora), é útil onde, por razões de segurança, os Administradores não querem abrir uma porta para a Internet em sua máquina, para permitir que o correio lhes seja imposto (onde o remetente inicia a transferência), como aconteceria com o modelo SMTP normal.

Estes são alguns das dezenas de aplicativos filtros de \emph{e-mail} Livres. Existem atualmente mais de 2.200 projetos de \emph{software}s livres relacionados a \emph{e-mail}, desde clientes a servidores, aplicativos \emph{web}, filtros anti-spam, webmail, antivírus, cadastrados no sourceforge.net. Esses projetos podem ser visualizados em\\
<\www{http://sourceforge.net/softwaremap/trove_list.php?form_cat=28}>.


\subsubsection{Dificuldades possíveis}

Para armazenar dados em um servidor LDAP, é preciso escolher um esquema. O esquema deve ser compatível com todos os clientes que possam requerer acesso aos dados. Felizmente, alguns pacotes vêm com um esquema que não somente dá suporte às suas necessidades, mas também às necessidades de vários outros pacotes em geral.

O Courier-IMAP vem com um esquema, mas o Exim, não. Descobrimos que o esquema do Courier dá suporte ao Exim também, mas é preciso verificar se este suporte abrange toda a capacidade do Exim. Detectamos alguns problemas com o arquivo de configuração do LDAP para o Courier, que já podem estar resolvidos.

Para usar o Courier com o Whoson\footnote{
\wwn{http://whoson.sourceforge.net/}.} são necessárias algumas correções no Courier. Algumas delas foram disponibilizadas no sítio do Whoson, porém estavam desatualizadas e necessitavam de atualizações significativas para trabalhar com a versão selecionada do Courier. 


\subsection{Serviço de \emph{webmail}}

Muitas vezes será conveniente a utilização de uma interface \emph{web} para acesso aos \emph{e-mails} em vez de utilizar um cliente de e-mail. Existem diversas ferramentas livres para Servidor de Webmail. Dentre elas, podemos destacar:

\begin{itemize}

	\item Horde\footnote{
\wwn{http://www.horde.org}.}, \emph{framework} de aplicações em PHP que possui uma suíte de aplicações \emph{web}, que abrangem Webmail (IMP\footnote{
\wwn{http://www.horde.org/imp/}.}), Gerenciador de Contatos (TURBA\footnote{
\wwn{http://www.horde.org/turba/}.}), Gerenciador de Calendários (Kronolith\footnote{
\wwn{http://www.horde.org/kronolith}.}).

       O IMP (\emph{Internet Messaging Program}) Webmail Client é um cliente de \emph{e-mail} escrito em PHP que permite acesso às contas via POP3 ou IMAP. Requer a instalação do PHP e do Horde no servidor. Em sua versão 3.2, permite opções avançadas, como a busca em múltiplas caixas de correio, identidades, e navegador de caixa de correio hierárquica, bem como interface de usuário enxuta.

	\item OpenWebmail\footnote{
\wwn{http://www.openwebmail.org}.} sistema de webmail baseado no Neomail, que possui as seguintes características:
	\begin{itemize}
		\item para os usuários: 

		auto login, suporte a múltiplas linguagens e Charsets, Strong MIME Message Capability, procura de conteúdo completa, pasta de rascunho, opção de confirmação de leitura, checagem de escrita, suporte a POP3, suporte a filtros de e-mail, suporte a Anti-Spam por meio do SpamAssassin, suporte a antivírus pelo ClamAV, calendário com suporte a lembrete e notificação, suporte a WebDisk, compressão HTTP;

		\item para o Sistema:
	
	acesso rápido às pastas, vários métodos de autenticação, suporte a PAM, suporte à utilização de um servidor SMTP de relay remoto, suporte a Virtual Host, suporte a alias de usuários, configuração por usuário de capacidade, dentre outros.

	\end{itemize}
		
	\item SquirrelMail\footnote{
\wwn{http://www.squirrelmail.org}.},  webmail baseado em padrões abertos escrito em PHP4. Inclui suporte para os protocolos IMAP e SMTP, todas as páginas são renderizadas em HTML 4.0 puro (sem JavaScript) para o máximo de compatibilidade entre os diversos \emph{browsers}. Possui poucos requerimentos e sua instalação/configuração é simples;

	Características/funcionalidades: suporte a caderno de endereços (privado e compartilhado); gerenciamento de pastas; pesquisa de conteúdo; filtros de mensagens; gerenciamento de segurança sobre anexos; suporte a anti-spam; verificação ortográfica; agenda (privada e compartilhada); gerenciamento de tarefas (pessoal ou de grupo); coleta de mensagens de outras contas pop3; trabalho com qualquer MTA via SMTP ou \emph{sendmail wrappers}; suporte a IMAP-SSL; criptografia de mensagens (suporte a S/MIME e GPG/OpenPGP), dentre outras;


	\item Uebimiau\footnote{
\wwn{http://www.uebimiau.org}.}, serviço de webmail multiplataforma, totalmente desenvolvido em PHP, com distribuição GPL. O produto foi desenvolvido no Brasil e possui as seguintes características: 


	\begin{itemize} 
		\item  Para usuários:

		suporte a SMTP, POP3, MIME, MultiTemas, procura de termos no conteúdo de mensagens, recebimento de arquivos anexados, envio de anexos, suporte ao gerenciamento do pastas (lixeira, caixa de entrada, itens enviados e pastas locais), catálogo de endereços, suporte a múltiplas linguagens, personalização de  ordem das mensagens, envio de \emph{e-mail} em formato HTML e limite de quotas;		

		\item  Para o Sistema:
		inexistência de banco de dados de armazenamento, pois as mensagens são armazenadas na pasta na qual o Uebimiau é instalado, dependências com JavaScript e PHP, pode ser implementado com Sendmail/Qmail para facilitar a gerência de mensagens.

	\end{itemize} 
\end{itemize}


\subsection{Serviço de Antivírus}

Se os sistemas de \emph{Software} Livre estiverem configurados corretamente, os vírus terão efeito até certo ponto limitado. No entanto, há o problema de passar vírus para os locais que executam outros sistemas operacionais. Assim, o controle de vírus é necessário principalmente para evitar a transmissão de vírus para outros ambientes que não sejam baseados em \emph{Software} Livre. Embora o correio eletrônico seja uma das principais formas de transmissão de vírus, não é a única; portanto, é necessário fazer uma varredura geral dos arquivos para evitar a transmissão por outros meios. Em termos de correio eletrônico, a melhor maneira de executar tais produtos é como parte do MTA. O Postfix e o Exim fornecem meios de incorporar tais filtros.

Um exemplo de \emph{Software} Livre que pode atuar como solução de antivírus para servidores de Correio Eletrônico é o Clamav Antivírus\footnote{
\wwn{http://clamav.sourceforge.net}}. Todavia, é possível garantir que os arquivos executáveis possam ser instalados apenas pelo sistema Administrador, por meio da configuração dos sistemas de arquivos, tanto nos servidores quanto nas estações de trabalho. Portanto, é importante que os Administradores de sistemas tenham certeza de que os arquivos que estão instalando são confiáveis, por exemplo, pela checagem da assinatura do vendedor da distribuição nos arquivos.

Existem antivírus proprietários que rodam em ambiente GNU/Linux, que, em casos especiais, podem ser considerados. 

\subsection{Serviços de Calendário e \emph{Groupware}}

O serviço de calendário é uma questão ainda não completamente definida. Tal fato ocorre devido à ausência de padrões abertos para comunicação entre os clientes e o servidor central. Conseqüentemente, os produtos desenvolvidos até agora usam a distribuição baseada na \emph{web}, e isso pode não proporcionar às pessoas a forma de trabalho exata às quais estão habituadas com o uso do \emph{software} proprietário.

%Podemos assumir que os produtos listados na tabela a seguir usam distribuição baseada na web, a não ser por afirmação em contrário. Todos eles são parte de conjuntos de \emph{groupware} que possuem grande variedade de outros aspectos. Executamos algumas integrações interessantes de recursos nesses produtos.

Podemos assumir que os produtos apresentados no detalhamento a seguir, utilizam distribuição baseada na \emph{web}, a não ser por afirmação em contrário. Todos eles são parte de conjuntos de \emph{groupware} que possuem grande variedade de outros aspectos. 
%Executamos algumas integrações interessantes de recursos nesses produtos.


A maior parte dos produtos de \emph{groupware} é escrita em PHP ou Perl e podem, portanto, ser customizadas. 


\subsubsection{Detalhes de Produtos \emph{Groupware}}


O e-groupware\footnote{
\wwn{http://www.egroupware.org}.}
abrange serviço de trabalho em grupo via \emph{web}, contando com correio eletrônico, agenda de contatos, agenda de compromissos, Wiki, fóruns e outras ferramentas de trabalho colaborativo. Foi desenvolvido em linguagem PHP e usa banco de dados PostgreSQL ou MySQL. Possui extrema compatibilidade com outros clientes de \emph{e-mail} para importar lista de contatos, é altamente configurável e o grande diferencial é importar dados da agenda do Exchange\reg/Outlook\reg.


O phpGroupware\footnote{
\wwn{http://phpgroupware.org}.} disponibiliza serviços de calendário, catálogo de endereços, e-mail, serviços de notícias, dentre outros.


Outra opção é o Horde\footnote{
\wwn{http://www.horde.org}.}, que consiste em uma estrutura para rodar outros aplicativos, como, por exemplo, o Imp, cliente de correio eletrônico via \emph{web}, o Turba, gestor de contatos, e o Kronolith, calendário.

        O NullLogic\footnote{
\wwn{http://nullgroupware.sourceforge.net/groupware}.} parece somente oferecer interfaces com o idioma inglês, porém o phProject, o Tutos, o Twiggi e Twiki, todos eles dão suporte a uma série de idiomas.

Um produto muito recente do \emph{Software} Livre é o OpenGroupware\footnote{
\wwn{http://www.opengroupware.org/}.}. Ele é o aplicativo SKYRiX, anteriormente proprietário, transformado por seus donos em \emph{Software} Livre. Ainda não houve tempo suficiente para o investigarmos, porém tudo indica que irá tornar-se muito influente.


Um outro produto recente é o Kolab\footnote{
\wwn{http://www.kolab.org/}.}. Esse produto tem um cliente com base no Kmail e vale a pena pesquisá-lo, particularmente se o KDE for escolhido como interface com o usuário, ou se o Kmail for escolhido como MUA para dar suporte a S/MIME.



\subsubsection{Calendários Pessoais e Agendas}

Todos os produtos podem manter calendários pessoais e listas de tarefas.

\subsubsection{Calendários de Grupo}

O Tutos, o Twiggi e o NullLogic todos dão suporte a calendários.

O Tutos permite controle em níveis de faixas, do individual ao grupo de trabalho e do grupo de projeto para todos.

No NullLogic, não se podem manter calendários privados em relação a outros membros do grupo, mas as tarefas, sim.


\subsubsection{Organização de Reuniões}

Muitos dos produtos incorporam itens de agendamento de recursos, que podem ser usados para planejar reuniões.

O Tutos permite a alocação automática de pessoas, junto com a notificação de correspondência automática para aqueles que não constam do calendário compartilhado (como os que estão em outras organizações). Ele mantém uma lista de aceitações e manda lembretes via correio, caso desejado. O phProject é similar e lida com notificações de texto SMS.

O NullLogic dá suporte a todos os recursos acima, exceto para alocação de salas. 


\subsubsection{Sincronização de PDA}


O phProject tem um recurso adicional que sincroniza com os PDAs baseados em PalmOS. A sincronização do PDA também recebe suporte como parte do GNOME e do Evolution. A maioria dos PDAs populares pode ser sincronizada.


\subsection{Serviços de \emph{Web}}


\subsubsection{Servidores \emph{Web}}
\label{servico_web}

O servidor de \emph{web} mais popular é o Apache, o qual, de acordo com pesquisas realizadas pela Netcraft\footnote{
\wwn{http://www.netcraft.com}.}, 
possui participação crescente no mercado. Uma combinação de produtos cada vez mais popular figura sob o nome LAMP: Linux, Apache, MySQL e PHP. Ela fornece estrutura para os sítios acessarem bancos de dados SQL pela linguagem PHP. Todos os componentes são \emph{Software} Livre.

O Apache conta com diversificada gama de módulos e extensões associados. Outros servidores poderiam ser utilizados para tarefas específicas, como, por exemplo, o Zope (veja no próximo item), o qual poderia ser usado para gestão de conteúdo.

O projeto Apache contém vários subprojetos, um dos quais é chamado de Jakarta e cobre o lado servidor do uso do Java. O Jakarta em si consiste de subprojetos, dois dos quais são o Tomcat e o Slide. O Tomcat oferece um produto para servlets Java, em conformidade com o padrão JSP. Outra opção de servidor de aplicativo baseada em Java é o Jboss\footnote{
\wwn{http://www.jboss.org}.}.
 O Slide é implementação baseada em Java da WebDAV, que permite gerenciamento de conteúdo. Veja em  <\www{http://www.apache.org}> para obter mais detalhes.

De todos esses, o Apache é, de longe, o mais popular. Ele trabalha atualmente na maioria dos sítios públicos e tem ganhado mercado de forma estável; portanto, há muita experiência a considerar ao planejar uma migração. O Apache é servidor modular, com um motor de protocolo nuclear e uma grande seleção de módulos para propósitos específicos. 


\subsubsection{Portal -- Gestão de Conteúdo}
\begin{enumerate}
	\item O Zope\footnote{
\wwn{http://www.zope.org}.} é desenhado para prover suporte dinâmico de conteúdo da \emph{web} e baseia-se em um modelo orientado para o objeto. É um pacote interessante, pois combina um sistema de gerenciamento de conteúdo com um servidor de \emph{web} e um sistema de modelos em um pacote. O Zope também dá suporte a \emph{add-ons} (chamados produtos) e baseia-se na linguagem Python orientada para objeto. É comum encontrar o Zope colocado ``atrás'' do Apache, em configuração multiservidor, na qual o Apache serve conteúdo estático e atua como acelerador baseado em cache para as partes do sítio geridas pelo Zope. Um projeto interessante baseado no Zope é o Plone\footnote{
\wwn{http://www.plone.org}.}.

	\item O PHP-Nuke\footnote{
\wwn{http://www.phpnuke.org.br}.} é um SGC (Sistema de Gerenciamento de Conteúdo), termo advindo do Inglês ``Content Managment System'',  reconhecido facilmente pela popular sigla CMS. O sistema recebe este nome porque integra todas as ferramentas necessárias para criar e gerenciar um portal, seja ele comercial seja institucional.

É caracterizado pela grande quantidade de funções presentes na instalação-padrão e/ou nos módulos adicionais. Já o nome PHP-Nuke vem do inglês \emph{nuke}, que possui vários significados, sendo o mais comum um dispositivo ou uma arma nuclear. Portanto, o PHP-Nuke pode significar ''Poder em PHP''. Ele é escrito 100\% EM PHP, o que significa portabilidade, podendo ser executado em quase todos os Sistemas Operacionais existentes, dentre eles os mais utilizados são *NIX, Microsoft\reg Windows\reg e Apple\reg Mac OS.

Para ter um portal construído em PHP-Nuke, é necessário

\begin{itemize}
             \item um servidor de páginas (preferencialmente Apache);
            \item o  PHP;
             \item um servidor de Banco de dados SQL (MySQL, mSQL, PostgreSQL, ODBC, ODBC\_Adabas\reg, Sybase\reg ou Interbase\reg).

\end{itemize}

	\item O Xoops\footnote{
	\wwn{http://www.xoops.org.br}.} é um sistema de portal que utiliza a tecnologia PHP integrada ao banco de dados MySQL. Seu código permite a construção de portais seguros e confiáveis tanto para uso pessoal quanto profissional.

	
	\item Drupal\footnote{
\wwn{http://www.drupal.org}.} é uma plataforma dinâmica de \emph{website} que permite publicar, manipular e organizar grande variedade de conteúdo, integra diversos recursos populares de CMS (\emph{content management systems}), \emph{weblogs}, ferramentas colaborativas e de discussão em um único pacote, fácil de ser usado.


	\item  JetSpeed-1\footnote{
\wwn{http://portals.apache.org/jetspeed-1}.}, integrante da seção de portais do projeto Apache, é implementação de um Portal de Informação Empresarial utilizando Java e XML. Atua como centro por meio do qual informações de múltiplas fontes podem ser disponibilizadas.

\end{enumerate}

Há atualmente muitos produtos de gerenciamento de conteúdo de \emph{Software} Livre, como mostra o sítio \www{http://www.oscom.org/matrix/index.html}.



\subsection{Serviço de Gestão do Documento}

\subsubsection{Registro e Recuperação}

A gestão do documento pode, e talvez deva, ser pensada como forma de gestão de conteúdo e fluxo do trabalho. Recomendamos que seja adotada uma solução com base nas de gestão de conteúdo e \emph{groupware} disponíveis. Em particular, os que usam a WebDAV podem prover as soluções mais úteis.

Alguns dos produtos de \emph{groupware} provêem suporte para gestão de documento:
\begin{itemize} 
       \item o Tutos inclui um sistema de gestão de documento que também possui gestão de versão;
       \item o NullLogic possui capacidade de armazenar, indexar e baixar arquivos simplesmente. Não parece oferecer um sistema de gestão de mudança. Possui mecanismo generalizado de query que pode ser instalado para oferecer indexação.
\end{itemize} 


\subsubsection{Trabalho colaborativo}

Esta função pode ser implementada \emph{ad-hoc} pela simples troca de documentos entre as pessoas.

Para que haja colaboração, as partes precisam acordar quanto ao formato do documento; atualmente, muitas pessoas usam formatos proprietários como padrão. Esse procedimento exige confiança entre as pessoas envolvidas, uma vez que esses formatos podem ser eficientes portadores de vírus. Além disso, os formatos proprietários não são ideais como padrão, porque mudam constantemente. Isso indica que as partes também precisam concordar quanto à versão do \emph{software} proprietário a ser usado.

Há pressão para que se adotem formatos de documentos baseados em padrões, particularmente os baseados no XML. O OpenOffice.org, que provê um padrão de documento baseado no XML, poderia ser usado como base para a colaboração.

Uma abordagem mais estruturada seria adotar uma solução de gestão de conteúdo/fluxo do trabalho apresentada na seção 
anterior.

O produto de \emph{groupware} do Tutos permite que os documentos sejam sujeitos ao controle de uma única pessoa ou por todos dentro de um grupo definido. O NullLogic e o Twiki também possuem controles sofisticados. 


\subsection{Serviço de Bancos de Dados}

Para sistemas que necessitam de um banco de dados rápido, como as aplicações com interface \emph{web}, podemos sugerir o MySQL; para sistemas que necessitam de maior robustez: o PostgreSQL e o Firebird são opções.

\subsubsection{Bancos de Dados Centrais --  baseados em aplicativos}

Os sistemas de banco de dados do \emph{Software} Livre disponíveis incluem MySQL, PostgreSQL e Firebird. Eles têm características e aplicabilidade significantemente diferentes.

O MySQL é um banco de dados SQL leve, interessante especialmente para aplicações \emph{web} e similares. É adequada a utilização das tabelas tipo ``MyISAM'' em situações em que a leitura predomina sobre a escrita. A empresa mantenedora do MySQL, que possui representação no Brasil, oferece outros produtos para necessidades específicas, como o MySQL Cluster e o MaxDB\reg. É utilizado o sistema de duplo licenciamento, em que a licença escolhida pode ser GNU/GPL ou comercial, dependendo da necessidade da Administração.

O PostgreSQL é outro SGBD bastante completo, comparável aos mais robustos do mercado, com os recursos necessários para se lidar com grande volume de dados. Apresenta-se como opção para substituir os SGBDs mais voltados às soluções corporativas. Inclui recursos e características necessários em aplicações corporativas de porte, como conformidade com SQL 92, integridade referencial, \emph{triggers}, \emph{stored procedures}, \emph{transaction commitment}, \emph{row level locking}, vários métodos alternativos de autenticação e direitos de usuários e grupos, bem como \emph{load balancing} e replicação de bancos de dados, dentre outros. Nas versões a partir da 7.x, o desempenho foi aprimorado e suporta grandes cargas transacionais de forma rápida, linear e previsível.

O Firebird é uma versão do banco de dados Interbase da Borland, liberado sob licença do \emph{Software} Livre. Grande parte do código é comum com o Interbase e, como tal, pode ser considerado maduro. Juntamente com o PostgreSQL, o Firebird também se apresenta como solução para aplicações corporativas.

O OpenOffice.org 1.1 suporta diretamente o MySQL ou qualquer outro SGBD por intermédio das ferramentas de conectividade ODBC e JDBC. 



\subsubsection{Desempenho}

O desempenho do banco de dados depende muito do tamanho das tabelas envolvidas e da complexidade das \emph{queries}, além dos ajustes finos e da configuração do equipamento em que estão sendo executados. Alguns SGDBs do \emph{Software} Livre já se mostraram robustos o bastante para as mais diversas aplicações. Dentre eles, podemos citar o PostgreSQL e o Firebird.

Diversos produtos proprietários estão disponíveis para rodar em GNU/Linux e podem ser considerados opções para aplicativos de bancos de dados pesados. 
 

\subsubsection{Conectividade (ODBC, JDBC, etc.)}

Veja o item \ref{conectividade_bancos_de_dados} 


\subsection{Serviços de Segurança}

Todos os grupos funcionais devem ser configurados tendo em vista a segurança. A segurança, em nível de \emph{software}, só pode trabalhar se também estiver presente na estrutura maior de gestão de segurança.

\subsubsection{Criptografia}

\begin{description}

	\item[Dados em trânsito: ] Dados confidenciais em LANs internas devem ser criptografados sempre que possível. Dados sensíveis enviados pela Internet ou outras redes compartilhadas devem estar sempre criptografados. Isso pode ser feito pela canalização de conexões em protocolos, como SSH, SSL/TLS e IPSEC, em que podem ser implementados produtos como openssh, stunnel e FreeSWAN, respectivamente.

	\item[Dados armazenados: ] Dados confidenciais mantidos em dispositivos móveis devem ser criptografados em disco. O ideal é que todos os dados sejam criptografados, porém isso imporia ônus significativos à performance e à Administração que nem sempre serão desejáveis ou aceitáveis. Há vários sistemas de arquivos que permitem isso, tais como no sítio <\www{http://www.tldp.org/HOWTO/Disk-Encryption-HOWTO}>, no qual há um procedimento que permite criar disco, partição ou arquivo criptografado com o algoritmo AES.

\end{description}

\subsubsection{Autenticação}

Métodos seguros podem identificar, de modo único, uma pessoa ou uma máquina que sejam parte de uma comunicação com outras pessoas ou outras máquinas. Isso inclui assinaturas digitais e infra-estrutura de chaves públicas (ICP). Nenhuma ICP foi avaliada na etapa atual deste Projeto. Todas as autenticações foram feitas em contraposição à senha padrão de um banco de dados LDAP.

\subsubsection{Autorização}

Determina o que uma pessoa ou máquina, após ser autenticada, podem fazer e em que circunstâncias. Isso normalmente é parte do sistema operacional (como no caso do controle de acesso a arquivos e diretórios) ou do código do aplicativo (como no caso de bancos de dados que controlam o que um usuário pode fazer em uma base de dados ou tabela). O \emph{Role Based Access Control}, ou RBAC, é forma mais sofisticada de realizar a autorização e o controle de acesso, foi definido pelo NIST \emph{National Institute of Standards and Technology} 
nos Estados Unidos e está disponível para GNU/Linux, Veja <\www{http://csrc.nist.gov/rbac}>.

Também é interessante pesquisar as funcionalidades do tipo ACL (Access Control List) disponibilizadas recentemente na versão 2.6 do \emph{kernel} do GNU/Linux.


\subsubsection{Servidor Proxy}

Há disponíveis diversos servidores \emph{proxy} em \emph{Software} Livre. Dentre os servidores \emph{proxy} para HTTP, o Squid\footnote{
\wwn{http://www.squid-cache.org/}.} é o mais popular, pois possui elementos refinados para controle de acesso, banda, hierarquias de caches, \emph{proxy} reverso etc. Ele possui um produto associado (squidguard), que evita o acesso a sítios indesejados, classificados por conteúdo.



\subsubsection{\emph{Firewalls}}

Todos os sistemas operacionais atuais em \emph{Software} Livre possuem \emph{firewalls} do tipo filtro de pacotes, dos quais a maioria é \emph{stateful}. Os \emph{firewalls} do tipo \emph{stateful} são aqueles que mantêm a informação sobre as conexões em curso e os seus fluxos de dados no \emph{firewall} e permitem a passagem de pacotes que são associados a essas conexões, enquanto eliminam pacotes que não o são. \emph{Firewalls} que não são \emph{stateful} examinam cada pacote, sem guardar qualquer registro de pacotes anteriores, sendo menos eficientes. Plugins especializados estão disponíveis para protocolos complexos como FTP e H.323 (Voz sobre IP).

O Iptables, atualmente incluído no GNU/Linux, o Ipfilter, incluído no FreeBSD, e o Packetfilter, incluído no OpenBSD, são boas soluções de \emph{firewall}. Essas três soluções são de forma geral equivalentes. Uma boa prática para \emph{firewall} externo (independentemente do produto utilizado) é ter dois modelos diferentes entre a conexão da rede pública e os servidores internos (o que pode incluir o roteador com filtro de pacote). 



\subsubsection{Redes Virtuais Privadas (VPN)}


\begin{description}

	\item[OpenVPN: ] Disponível para a maioria dos sistemas do tipo Unix, esta é uma ferramenta madura e poderosa, apesar de não seguir um padrão específico para VPNs. Os recursos incluem autenticação com chave pública, compressão dinâmica, gestão de largura de banda e  capacidade de trabalhar com NAT (\emph{Network Address Translation}). Veja em\\
<\www{http://openvpn.sourceforge.net}> para obter mais informações.

	\item[IPSEC: ] IPSEC é um conjunto de protocolos para a comunicação criptografada e/ou autenticada entre dois computadores. Existem algumas implementações livres como o FreeS/WAN\footnote{
\wwn{http://www.freeswan.org/}.} e os seus derivados;  para a versão do GNU/Linux 2.6, podemos  usar o IPSEC nativo do \emph{kernel}. Por seguirem o padrão definido, é possível fazermos a comunicação entre produtos, sistemas operacionais e dispositivos que sigam o mesmo padrão. Para mais informações de como implementar IPSEC,  veja em <\www{http://www.ipsec-howto.org/t1.html}>. 

	\item[CIPE: ] Este é menos maduro do que os outros dois, e o suporte de chave pública ainda é experimental. No entanto, pode funcionar com NAT e é desenhado para ser leve. Está disponível também para ambiente proprietário e é incluído com o Red Hat\reg Linux (você pode até configurá-lo com a ferramenta Controle de Dispositivo de Rede desse sistema). Mais informação está disponível em <\www{http://sites.inka.de/~W1011/devel/cipe.html}>. 

\end{description}

\subsection{Serviços de Gestão}


Apesar de não ser apenas um serviço do tipo provido por um servidor, a Gestão pode ser vista como uma questão estruturadora, assim como os demais serviços citados. Por esse motivo, ela está sendo tratada aqui.

O sítio <\www{http://www.infrastructures.org}> provê considerável detalhamento de como gerir uma rede de máquinas, servidores e estações de trabalho e dispõe de várias ferramentas de \emph{Software} Livre para uma série de tarefas de manutenção.

O sítio mostra que a gestão do Unix e, por extensão, do GNU/Linux tende a ser feita por ferramentas a serem agrupadas a partir de unidades de função única menores. Essa abordagem modular é extremamente poderosa e é o que permite aos Administradores do sistema Unix e GNU/Linux serem muito eficientes e efetivos. 


\subsubsection{Gestão do Usuário}

A manutenção de usuários e grupos de usuários, incluindo produtos de gestão de senhas como Directory Administrator e gq, permite que os bancos de dados LDAP sejam mantidos.


\subsubsection{Gestão de Configuração}

Embora um cliente bem projetado, gerido de forma central, deva ter um mínimo de instalação local, a atualização de sua configuração sem reinstalação do zero é ainda desejável para grandes redes, das quais se espera que fiquem ativas durante algum tempo. Por exemplo, se um serviço essencial central é mudado, os clientes podem precisar ser reconfigurados para usá-lo.


\begin{description}

	\item[Manutenção da Configuração Manual: ] 

Em redes pequenas, os Administradores podem manter atualizações de configuração manualmente, já que podem programar atualizações. No entanto, problemas similares de sincronização se aplicam. A modificação manual dos arquivos de configuração, geralmente armazenados em arquivos plain text, é particularmente sujeita a apresentar erros de digitação.

	\item[Cfengine: ] O GNU Configuration Engine\footnote{
        \wwn{http://www.cfengine.org}.}
automatiza a configuração remota de clientes de rede. Ele dá suporte a grande variedade de preferências Unix, e seu poderoso conceito de classe permite que diferentes grupos de clientes sejam geridos com um mínimo de configuração. Agentes autônomos nos clientes podem manter arquivos de texto, interfaces de rede, \emph{links} de arquivos e permissões, armazenamento temporário e sistemas de arquivos montados.

Algumas das primitivas que podem ser automatizados usando o cfengine são:
\begin{itemize} 
   \item    checar e configurar a interface da rede;
   \item    editar arquivos de texto;
   \item   fazer e manter \emph{links} simbólicos, inclusive múltiplos a partir de um único comando;
   \item   checar e estabelecer permissões de propriedade dos arquivos;
   \item   remover lixo de arquivos que confundem o Sistema;
   \item    montagem automatizada e sistematizada de sistemas de arquivos (em Unix);
   \item    checar a presença de arquivos importantes e sistemas de arquivos;
   \item    execução controlada de \emph{scripts} de usuários e comandos de embalagem.
\end{itemize} 

	\item[System Configurator: ] O System Configurator\footnote{
\wwn{http://sisuite.org/systemconfig}.} é parte do System Installation Suite, sendo utilizado pelo System Installer. Ele pode configurar e manter muitos componentes de uma instalação GNU/Linux por muitas distribuições, tais como redes, armazenamento, fuso horário e \emph{booting}.


	\item[Webmin: ]  O webmin\footnote{
\wwn{http://www.webmin.com}.} permite a Administração de sistemas Unix e GNU/Linux via \emph{browser} com opções para a Administração de diversos recursos de  servidores, usuários, gerenciamento de pacotes, sistemas de arquivos, quotas, além de servidores FTP, SMTP, www, DHCP, DNS etc.

\end{description}

\subsubsection{Gestão de \emph{Software}}

Esta Seção cobre a manutenção de sistemas de clientes, desde a configuração inicial do novo \emph{hardware} até as atualizações de \emph{software} em andamento e configuração e algumas tecnologias para facilitar sua gestão.

\subsubsection{Instalação do Sistema}

A instalação do sistema é a configuração inicial do \emph{software} e a configuração necessária para manter uma máquina. Máquinas construídas em fábricas podem não possuir qualquer sistema operacional, ou chegar pré-instaladas com \emph{software}. Máquinas antigas com \emph{software} indesejado também podem ser reutilizadas pela instalação de sistema novo em seu lugar.

A primeira tarefa de um instalador de sistema é carregar a máquina-alvo. O método mais antigo é carregar via disquete. Os disquetes estão sendo eliminados, pois são lentos, não confiáveis e oferecem espaço muito pequeno para o \emph{software} de instalação de sistema nos padrões modernos. Muitas máquinas construídas desde 1997 suportam inicialização a partir de CD-ROM pela emulação do setor de boot do disquete. Isso é mais rápido e oferece mais espaço para o \emph{software} de boot inicial e qualquer outro \emph{software} requerido. O modo mais sofisticado de carregar a máquina é pela rede. Nem todos os \emph{firmware} de BIOS ou placas de rede suportam esse novo recurso. O \emph{Pre Execution Environment} (PXE) é parte do padrão da indústria \emph{Wired for Management} (WIM) e habilita a maior parte das máquinas compradas desde 1998 a serem carregadas pela rede local.

O instalador deve acessar os meios de instalação apropriados contendo \emph{software} do mais alto nível para ser executado depois que a máquina tiver sido carregada. Caracteristicamente isso terá que ser armazenado em um CD-ROM local ou um servidor de arquivo de rede. Um único disco compacto pode ser usado para armazenar uma imagem de \emph{software}, e a capacidade de um CD-ROM deve ser suficiente para uma estação de trabalho de Administração básica, usando compressão de arquivo regular. Essa imagem pode ser apropriada se for pouco provável que o \emph{software} mude, ou se só for necessária uma base de instalação estável para a adição de \emph{software} adicional. Geralmente, uma instalação de rede é mais flexível, pode ser mais rápida, oferece maior capacidade, e escala melhor as instalações paralelas e múltiplas, do que compartilhar discos de instalação entre clientes.

O instalador de sistema transfere o \emph{software} da mídia selecionada para o disco rígido local da máquina-alvo e prepara-a para a inicialização. Isso vai envolver conhecimento do \emph{hardware}, checagem da capacidade do disco e configuração de detalhes de rede.

Alguns dos possíveis métodos de instalação são discutidos a seguir:


\begin{enumerate}
	\item \textbf{Instalação Manual}

A instalação mais básica se dá através de um Administrador de sistema. O \emph{software} vem em discos compactos, inclusive em um disco de instalação \emph{bootable}. Algumas indicações automáticas podem guiar o Administrador, mas, em última instância, toda a customização é manual. Já que a seleção do pacote, a divisão do disco rígido, a configuração do \emph{hardware} e os detalhes da rede devem todos ser inseridos manualmente, este processo é demorado e tende ao erro humano. A maior parte das distribuições tem o próprio programa de instalação.

	\item \textbf{Clonagem de Imagem}

Se a instalação de clones quase idênticos é adequada, uma origem pode ser manualmente instalada e depois replicada. Distribuições como Knoppix, Kurumin e outras podem ser usadas para copiar as imagens do sistema de arquivos da origem para outras máquinas. Configurações e customizações podem ser adicionadas por \emph{scripts} executados antes ou depois da instalação. Uma vez que sistemas de arquivos inteiros podem ser copiados para o disco em vez dos arquivos neles contidos, isso pode permitir menor tempo de instalação. No entanto, configurar  ``clones''  não idênticos é menos eficiente e requer habilidade maior do Sistema.

	\item \textbf{Instalação Totalmente Automática}

	A FAI\footnote{
	\wwn{http://www.informatik.uni-koeln.de/fai}.}
	instala a distribuição Debian automaticamente. Os pacotes de \emph{software} são acessados de um sítio Debian, que pode ser espelhado localmente para obter velocidade ou customização. O \emph{kernel} de instalação disponibilizado pode ser carregado a partir da rede ou do disquete, porém o carregamento por CD-ROM ainda está sendo aperfeiçoado. Embora o FAI tenha sido desenhado para replicação idêntica de máquinas em cluster, o \emph{Software} Cfengine, descrito anteriormente, é usado para configuração de sistema e permite extrema flexibilidade, se necessário.	


	\item \textbf{ System Imager}

	O System Imager\footnote{
	\wwn{http://www.systemimager.org}.}
faz instalação de sistema, configuração e manutenção para grandes redes de máquinas, de preferência com \emph{hardware} similar, por meio de várias distribuições. Ele pode carregar a partir do disquete, do CD-ROM ou dos servidores de rede PXE. Ambas as instalações, tanto Debian quanto Red Hat\reg, foram testadas, porém o \emph{software} \emph{System Configurator} usado ajuda a dar suporte a todos as distribuições GNU/Linux.

Uma origem é instalada e configurada manualmente. Então, seus sistemas de arquivos são espelhados para um servidor de imagem, no qual as máquinas-alvo são instaladas. Se a origem estiver atualizada, essas mudanças serão propagadas para clientes usando rsync. Embora rsync envie minimamente as diferenças de arquivos pela rede, ele pode requerer memória significativa para fazê-lo. Como as modificações são relativas à origem, o System Imager é mais apropriado para clientes-alvo com \emph{hardware} idêntico ou muito parecido.


	\item \textbf{Kickstart da Red Hat\reg}

	O Kickstart\footnote{
	\wwn{http://www.tldp.org/HOWTO/KickStart-HOWTO.html}.}
é o \emph{software} de instalação automatizada da Red Hat\reg. Ele instala distribuições da Red Hat\reg de CD-ROM, disco rígido ou rede, e carrega a partir de rede, CD ou disquete. O instalador Anaconda oferece texto ou interfaces gráficas e pode ser interativo ou totalmente automatizado por um arquivo de configuração. O \emph{software} de detecção de \emph{hardware} Kudzu fornece uma gama de dispositivos automaticamente. Opções de instalação generalizadas podem ser montadas no arquivo de configuração e extensões adicionadas com \emph{scripts} de instalação pré e pós.

Com seu \emph{software} inteligente de configuração e detecção, o Kickstart pode ser utilizado para automatizar instalações similares entre uma variedade de alvos de \emph{hardware}. A seleção de pacotes do Red Hat\reg distribuição padrão é direta, porém as atualizações ou as extensões também podem ser incluídas pela customização do processo kickstart.

\end{enumerate}

\subsubsection{Manutenção do \emph{Software}}

Instalações de \emph{software} não permanecem estáticas durante seu tempo de vida. Serão lançadas atualizações de \emph{software} como o de segurança ou o de conserto de problemas, após a instalação inicial. Além disso, será requisitada a remoção ou a adição do pacote para gerenciar o \emph{software} sem a reinstalação de um sistema inteiro.

As atualizações devem, sempre que possível, ser efetuadas por um processo controlado pelo equipamento que demanda a atualizaçãoaatualização, após realizadas comparações dos pacotes instalados com um servidor principal. Devemos -se evitar que os usuários realizem as atualizações. 


\begin{enumerate}
	\item  \textbf{Manutenção do \emph{Software} Manual}

Os Administradores do sistema podem manter o \emph{software} atualizado manualmente. Isso pode envolver acessar o cliente-alvo de forma remota, copiar pacotes de atualização e instalá-los com o gerenciador de pacote original da distribuição. No entanto, embora isso ofereça um rígido controle ao Administrador, tende a erros e dificulta a sincronização de grandes coletas de máquinas. Algumas distribuições oferecem ferramentas de atualização para manter seus pacotes-padrão, mas ainda requerem intervenção manual e podem não disponibilizar extensões à distribuição básica.

	\item \textbf{Debian APT}

O APT é um jogo de ferramentas-padrão fornecido com a distribuição Debian GNU/Linux, que permite atualizações automatizadas ado \emph{software} instalado em uma máquina. Ele pode checar dependências entre pacotes de \emph{software} instalados na máquina e disponíveis dos \emph{software}s depositários, os quais ele foi configurado para checar, e para recuperar e instalar atualizações relevantes disponíveis de um depositário.

As organizações podem montar seus próprios servidores depositários de \emph{software} a ser instalado em seus clientes, bem como CDROMs contendo os programas e as atualizações (O Debian inclui ferramentas para criar e manter tais depositários), podem usar depositários disponibilizados pelo Debian e outros, ou usar qualquer combinação dessas fontes de \emph{software} atualizado. Os CD-ROMs podem ser criados como reproduções dos depositários. A configuração de onde serão baixadas as atualizações (cdromcd-rom, iInternet, iIntranet) pode ser determinada e protegida para acesso apenas ao Administrador dos sistemas, viabilizando o controle total dos programas e das versões que podem ser instalados e atualizados. O APT foi transportado para trabalhar em sistemas operacionais baseados em RPM, tais como Conectiva, Red Hat\reg Linux e Mandrake, onde provê funcionalidade similar, e de algumas formas aperfeiçoadas por comparação ao Red Carpet. 

	\item \textbf{Novell\reg Ximian\reg Red Carpet}

		\underline{Novell\reg Ximian\reg Red Carpet Daemon\footnote{
		\wwn{http://www.ximian.com/products/redcarpet}.}\\} 

É uma ferramenta de atualização de \emph{software} disponibilizada gratuitamente pela Ximian\reg. Começou como um gerenciador de pacote gráfico para o Novell\reg Ximian\reg Desktop 2 (pacote de \emph{software} e interface da Ximian\reg), porém oferece agora acesso seguro à linha de comando remota e mais canais de \emph{software}, inclusive atualizações de distribuição. Mandrake, SuSE\reg e Red Hat\reg são suportados atualmente. Ele oferece Administração remota fácil e automação, possibilitando que um número bem grande de clientes possa ser mantido de forma central. Pode ser configurado para atualizar \emph{software} a partir de canais customizados.


		\underline{Novell\reg Ximian\reg Red Carpet Enterprise\reg\\}  

É um produto servidor proprietário, utilizado para facilitar a gestão de grandes coletas de \emph{software}. O Novell\reg Ximian\reg Red Carpet Enterprise\reg oferece a vantagem de controle centralizado de políticas de atualização de pacotes, permitindo o agendamento de tarefas e mantendo o tráfego de rede para busca de atualizações dentro da LAN. Sem o Novell\reg Ximian\reg \ Red Carpet Enterprise\reg, todas as estações de trabalho utilizam a diretamente o acesso a iInternet para buscar atualizações. Em ambientes corporativos, esse comportamento não é desejado. O Novell\reg Ximian\reg Red Carpet Enterprise\reg consolida no servidor corporativo todas as atualizações necessárias, reduzindo o consumo do \emph{link} de iInternet.

A interface gráfica não deve ser usada, pois permite aos usuários controlar as atualizações. A interface com a linha de comando deve ser incorporada aos \emph{scripts} que atualizam as máquinas automaticamente.


	\item \textbf{Red Hat\reg Enterprise Network}

	A Red Hat\reg oferece uma gama de serviços de atualização de \emph{software} como parte de seu  
	Enterprise Network\footnote{
	\wwn{http://www.redhat.com/software/rhen/software_delivery}.}. 
O mais poderoso é seu Satellite Server, que permite customização completa de atualizações e errata. Todos os servidores dão suporte aos seus clientes padrão clientes-padrão, os Update Agent, para distribuição. Os comentários contra a permissão de uso da interface gráfica podem ser aplicados aqui da mesma forma que os do Red Carpet anteriormente citados.

\end{enumerate}

\subsubsection{Gestão de \emph{hardware} e monitoramento de sistema}

O \emph{hardware} pode ser monitorado com relação a falhas e a falhas potenciais, por exemplo, utilizando o SMART -- discos rígidos habilitados e \emph{hardware} de checagem de saúde do Sistema. Sistemas de \emph{hardware} e \emph{software} também deveriam ser monitorados com relação às falhas, às falhas potenciais, à ausência de serviço e à falta de capacidade.

	
	\begin{description}
		\item[MRTG e Snmpd: ] O MRTG\footnote{
		Multi-RouterTraffic Grapher, 
		\wwn{http://people.ee.ethz.ch/~oetiker/webtools/mrtg}.}
é uma ferramenta de monitoramento de senha originalmente criada para rastrear e representar em gráfico o uso da capacidade dos \emph{links} de rede. No entanto, desenvolveu-se como ferramenta capaz de rastrear virtualmente qualquer mudança de quantidade e pode ser usada para monitorar variáveis, como processador, memória e uso do espaço do disco, uso dos serviços da rede incluindo estatísticas sobre volumes de correspondência processada, páginas da \emph{web} servidas, temperatura do sistema e velocidades da ventilação e outras variáveis.
		
O Snmpd\footnote{
		Simple Network Management Protocol Daemon, 
		\wwn{http://net-snmp.sourceforge.net}.}
é um servidor de gestão de sistema que pode operar em qualquer estação de trabalho de uma organização. Disponibiliza informação de gestão de sistema para clientes -- tipicamente para um cliente SNMP central, que agrega estatísticas a partir de algumas máquinas. O MRTG pode atuar como tal cliente e desempenhar essa função, fornecendo visão geral gráfica de grande número de máquinas de clientes.

		\item[Nagios: ] O Nagios\footnote{
		\wwn{http://www.nagios.org}.}		
(anteriormente conhecido como NetSaint) é um hospedeiro customizável, provê serviço e monitoramento de rede e sistema de gestão. É capaz de monitorar serviços de rede e desempenhar vários procedimentos de recuperação, caso descubra que um serviço não está disponível ou apresentando problemas, inclusive invocando \emph{scripts} de recuperação automática e alertando os Administradores do Sistema para o problema. O Nagios também pode fornecer relatórios e visões gerais dos \emph{status} presente e passado dos serviços que monitora.		

		\item[smartd: ] O conjunto de ferramentas SmartMon Tools\footnote{
		\wwn{http://smartmontools.sourceforge.net}.}
inclui um daemon chamado Smartd, que é desenhado para monitorar o SMART (\emph{Self-Monitoring, Analysis and Reporting Technology}), função dos modernos drives de disco rígido. Como esses dispositivos são um dos componentes que mais falham em um computador moderno, o SMART pretende monitorar parâmetros de drive e notificar um Administrador de sistema sobre falhas potenciais antes que elas aconteçam. O Smartd é desenhado para receber essas notificações e agir mediante alerta ao Administrador do Sistema.

	\end{description}

\subsubsection{Serviço de impressão}

	\begin{description}
		\item[LPRng: ] LPRng\footnote{
		\wwn{http://www.lprng.com}.}
é uma implementação desenvolvida do antigo sistema BSD padrão lpr/lpd. Contém alguns aprimoramentos que o fazem muito mais robusto e fácil de manusear do que os produtos originais. Até pouco tempo atrás, essa era provavelmente a escolha para gestão de impressora, porém recentemente o CUPS progrediu, e a escolha agora é menos evidente.


		\item[Sistema de Impressão Unix Common: ] O Common Unix Printing System ou CUPS\footnote{
		\wwn{http://www.cups.org}.}  
é desenhado para ser um sistema de impressão Unix  ``pronto para a empresa''. É baseado no padrão Internet Printing Protocol ou IPP e incorpora uma função navegação, que disponibiliza detalhes dos nomes e das características de impressoras, para serem distribuídos automaticamente pela rede. O CUPS também incorpora uma interface usuário baseada na \emph{web} para administrar e configurar as impressoras. Os drivers estão disponíveis para as impressoras mais comuns.


		\item[Kprint e GNOMEPrint: ] Tanto o KDE quanto o GNOME incorporam os próprios subsistemas de impressão, que podem ter interface com aplicativos do usuário e com a maior parte dos sistemas de impressão utilizados, incluindo LPRng e CUPS.
	\end{description}


\subsection{Serviço de \emph{backup} e recuperação}

Supomos que todos os dados do usuário e os da Administração estejam em um ou mais servidores. É necessário ser capaz de incluir arquivos de forma incremental, encontrar itens removidos com arquivos específicos e restaurar arquivos individuais ou sistemas inteiros de arquivo. Fazer o \emph{backup} dos dados do usuário tende a ser mais fácil em sistemas de \emph{Software} Livre do que em ambiente proprietário, porque os arquivos de dados do usuário, incluindo seus dados de configuração, estão normalmente contidos em um único diretório.


\subsubsection{Remoção e Recuperação}

Os dois programas apresentados são disponibilizados como parte da maioria das distribuições e são utilizados algumas vezes, junto com ``tar'' e ``cpio'', em \emph{scripts} customizados para \emph{backup} e recuperação de máquinas individuais.	

\subsubsection{Amanda}

Amanda\footnote{
\wwn{http://www.amanda.org}.}
 um produto cliente-servidor desenhado para \emph{backup} de múltiplas máquinas em dispositivo individual. Também é capaz de fazer \emph{backup} de ambientes proprietários por meio do Samba.


\subsubsection{Bacula}

O Bacula\footnote{
\wwn{http://www.bacula.org}.}
permite \emph{backup} gerenciado de várias máquinas da rede pela instalação de daemons disponíveis em várias plataformas, inclusive em win32. Torna-se opção para \emph{backup} com requisitos de complexidade para agendamento, com compactação de dados de várias máquinas em um servidor.


\subsection{Sistema de lista de discussão}

	Um dos sistemas de lista de discussão em \emph{Software} Livre mais utilizado é o Mailman.
\begin{itemize}
	\item O Mailman\footnote{
\wwn{http://www.list.org}.} é um \emph{Software} Livre para controlar listas de discussões eletrônicas e Newsletters. O MailMan é integrado com a \emph{web}, facilitando para os usuários controlar suas contas e, para os donos das listas, 
gerencia-las. Ele é um \emph{software} bastante maduro e completo e possui diversas características, dentre elas:


	\begin{itemize}


             \item criação e remoção de listas de discussão pela  \emph{web};
             \item suporte a diversas línguas;
             \item suporte a ``\emph{Real Name}'' para os usuários;
             \item moderação das mensagens;
             \item filtro de tópico baseado em expressões regulares;
             \item controle de privacidade;
             \item \emph{autoresponse};
             \item acesso de usuários a alteração de algumas de suas opções de entrega de mensagens globalmente para todas as listas no servidor, incluindo senha, \emph{status} de entrega, real name, dentre outras;
             \item processamento automático do bounce;
             \item filtro de conteúdo;
             \item \emph{digest delivery};
             \item filtros de \emph{spam}.

	\end{itemize}
\end{itemize}



\subsection{Sistemas de informações georeferenciadas}

Os Sistemas de Informações Georeferenciadas são importantes ferramentas de base digital para armazenamento, manuseio e visualização de informação vinculada às coordenadas geográficas de onde foi extraída.

Tais sistemas são requisito essencial para atividades de gestão e planejamento, para tomada de decisão e democratização da informação. Sua utilidade é ampliada, e sua adoção tornada mais atraente pela possibilidade de, com baixo investimento financeiro, acoplar essa ferramenta à Internet como meio de acesso remoto à informação. 

\figura{fig:GeoLivre01}{GeoLivre-01.png}{.5}{Geolivre -- Aplicação para o Programa GESAC do Ministério das Comunicações (2003).}

Para os gestores públicos, é imprescindível dispor de ferramentas ágeis, que referenciem as informações geograficamente, facilitando a gestão, prestem informações aos cidadãos de maneira fácil e possibilitem o diagnóstico preciso da situação, auxiliando o planejamento de ações futuras.


\subsubsection{Soluções}

Uma das ferramentas de Sistemas de Informações Georeferenciadas em \emph{Software} Livre das mais tradicionais e consolidadas, tanto em técnicas quanto em número de usuários, é a plataforma Mapserver. Ela foi inicialmente desenvolvida pela universidade de Minnesota no âmbito do projeto ``Missão Terra'' da NASA e está sendo mantida por uma comunidade internacional de \emph{Software} Livre exatamente como se passa com o próprio ambiente Linux.

\begin{description}

\item[Mapserver\footnote{
\wwn{http://mapserver.gis.umn.edu}.}
: ]
As oportunidades tecnológicas atuais fazem do Mapserver uma alternativa concreta. Em primeiro lugar, já existe versão da tecnologia de Sistemas de Informações Georeferenciadas desenvolvida em \emph{Software} Livre, tanto no exterior quanto no País, com sofisticadas funcionalidades e aplicações de sucesso nas mais diversas áreas.
Em segundo lugar, já existe capacitação nacional nessa ferramenta, em função de experiência estabelecida com divugação de 
resultados\footnote{ 
O estado do Rio Grande do Sul, o município de Campinas-SP, o Exército Brasileiro e o Ministério da Saúde têm experimentado a utilização dessa ferramenta e já disponibilizam seus resultados ao público. Detalhes podem ser obtidos 
nos sítios \wwn{http://www.ima.sp.gov.br/sig} e \wwn{http://www.geolivre.rs.gov.br}.}.


%já existe capacitação nacional nesta Ferramenta. O estado do Rio Grande do Sul, o município de Campinas-SP, o Exército Brasileiro e o Ministério da Saúde têm experimentado a utilização dessa Ferramenta e já disponibilizam seus resultados ao público. A experiência no Rio Grande do Sul, o GeoLivre, foi realizada pelo convênio entre a Companhia de Processamento de Dados do Estado do Rio Grande do Sul -- PROCERGS  e a Fundação de Apoio da Universidade do Rio Grande do Sul -- FAURGS  com subsídio da \emph{Deutsche Gesellschaft für Technische Zusammenarbeit GTZ} (Sociedade de Cooperação Técnica, Alemanha), conforme o acordo de cooperação técnica Brasil-Alemanha de 1996. No município de Campinas, a utilização da Tecnologia foi viabilizada por dois convênios, um entre a organização Informática de Municípios Associados S/A -- IMA e a Fundação de Apoio da Universidade Federal do Rio Grande do Sul -- FAURGS, e o outro, entre o Ministério da Saúde e a Organização Pan-Americana da Saúde -- OPAS (veja em <\www{http://www.ima.sp.gov.br/sig} e \www{http://www.geolivre.rs.gov.br}>). 


\figura{fig:GeoLivre02}{GeoLivre-02.png}{.6}{Geolivre -- Aplicação para o para o Estado Rio Grande do Sul (2000)}


\item[GeoLivre\footnote{
\wwn{http://www.geolivre.rs.gov.br}.}
: ] 
O GeoLivre permite interligar os dados do sistema de Informação e torná-los públicos, o que, atualmente, não se realiza por dificuldades técnicas e político-institucionais que urge superarmos. O GeoLivre permite que os dados existentes sejam transformados em informações úteis para análises e tomadas de decisão, bem como seja revelado ao usuário o conteúdo desejado sem que ele se perca nos meandros das complexas etapas do trato das informações que, em alguns casos, é tarefa praticamente impossível de realizar de forma rápida até mesmo por especialistas.

O GeoLivre propiciará a constituição de bom sistema de informações georeferenciadas, em que os dados serão coletados e atualizados de forma dinâmica. Sistemas de informação em que a coleta e a atualização dos dados são realizadas de forma demorada e estimulam o gestor público ou o privado e a população em geral a buscarem informações por meios alternativos, o que pode conduzir a erros e, principalmente, comprometer a credibilidade dos sistemas de informação e a das instituições que os mantêm. 

\end{description}


\figura{fig:GeoLivre03}{GeoLivre-03.png}{.6}{Geolivre -- Aplicação para a Prefeitura de Campinas e o Ministério da Saúde (2002).}


%\begin{comment}
Opcionalmente, existem aplicativos disponíveis 
para serem executados localmente nas estações 
de trabalho, como  o
GRASS\footnote{  
\wwn{http://grass.itc.it }.}, 
o GMT\footnote{
\wwn{http://gmt.soest.hawaii.edu}.},
o OpenDX\footnote{
\wwn{http://www.opendx.org}.} e 
o QGIS\footnote{
\wwn{http://qgis.org.}.}.
%\end{comment}


\subsection{Outros serviços}

\subsubsection{Serviço de tempo}

É essencial, em ambiente altamente interligado por rede, que todas as máquinas, tanto os servidores como as estações de trabalho, tenham a mesma noção do tempo corrente. Um ou mais servidores são designados como servidores mestres, e eles obtêm seu tempo de um relógio anexo ou de servidores de tempo externos na Internet. Todas as outras máquinas são escravas, sincronizadas a esses mestres.

A sincronização do tempo pode ser feita executando o ntp\footnote{
\wwn{http://www.ntp.org}.} nas máquinas. Ele pode manter, facilmente, uma rede de máquinas no intervalo de um segundo de uma para outra.

O Chrony\footnote{
\wwn{http://go.to/chrony}.}
é uma alternativa ao ntp. Possui alguns recursos que o fazem mais apropriado para cruzamentos NTP altamente estratificados do que o ntp, enquanto o ntp é melhor para cruzamentos de estratificação baixa, que podem ter que fazer interface diretamente com coisas tais como receptores GPS e relógios atômicos. Há também produtos de \emph{Software} Livre para ambiente proprietário, úteis em ambiente misto, como Automachron e Nettime. O sítio <\www{http://go.to/chrony}> fornece detalhes de ambos. 

\subsubsection{Serviços de infra-estrutura de rede}

Estes são os serviços necessários para operar uma rede baseada em um TCP/IP.

\begin{description}

	\item[Roteamento : ] Roteadores possibilitam a divisão de uma grande rede em redes menores interconectadas. Eles têm a função de direcionar os pacotes de uma sub-rede para outra, para habilitá-las a chegar a um destino. A construção de roteadores requer bom entendimento dos protocolos básicos.

Para os que desejam construir seu próprio roteador, existem dois produtos:
 Bird\footnote{
\wwn{http://bird.network.cz}.} 
 e GNU Zebra\footnote{
\wwn{http://www.zebra.org}.}

	\item[DNS : ] Uma rede TCP/IP necessita de alguns meios para traduzir endereços IP para nomes significativos do domínio humano e vice-versa. O DNS é um protocolo, junto com alguns servidores de intercomunicação, cada um com dados. O DNS é básico para o funcionamento da Internet. Há alguns programas para construção de servidores DNS, inclusive o
o BIND\footnote{
\wwn{http://www.isc.org/products/BIND}.},
o MyDNS\footnote{
\wwn{http://mydns.bboy.net}.}, 
e o  MaraDNS\footnote{
\wwn{http://www.maradns.org}.}. 
O BIND é, certamente, o mais utilizado.

	\item[DHCP: ] O DHCP (\emph{Dynamic Host Configuration Protocol}) 
permite que máquinas clientes dentro de determinada rede efetuem automaticamente suas configurações, obtendo de um servidor central informações sobre endereços e máscaras de rede, endereços de roteadores, servidores de nomes e \emph{proxy}. A grande maioria das distriuições GNU/Linux já contém os servidores e os clientes DHCP.

	\item[Integração do DHCP com o DNS:] Os serviços de DHCP e DNS podem ser configurados para trabalhar em conjunto. Nesse esquema, o servidor DHCP poderá realizar atualizações dinâmicas num Sistema de Nome de Domínios (DDNS). A integração do DHCP com o DNS amplia a funcionalidade do serviço DHCP que, além da distribuição automática de IPs e da configuração dos parâmetros de redes, executará o gerenciamento dos nomes de domínios para os IPs fornecidos pelo próprio DHCP.

A idéia básica é habilitar o servidor DHCP para efetuar solicitações de inclusão ou remoção dos FQDN (\emph{Full Qualified Domain Names}) de clientes DHCP na base de dados de um servidor DNS. Para evitar atualizações do DNS não-autorizadas, o Administrador poderá utilizar uma chave simétrica HMAC-MD5 compartilhada pelos serviços DHCP e DNS. Esta chave poderá ser gerada pelo utilitário dnssec-keygen do próprio BIND.

Atualmente o servidor DHCP v3 da ISC fornece suporte à DDNS e pode ser utilizado juntamente com o servidor de DNS BIND v8 ou 9, que suporta a RFC 2136 \emph{Dynamic Updates in the Domain Name System} (DNS UPDATE).
\end{description} 

\subsubsection{Servidores de Arquivos}  
Servidores de arquivos de rede permitem às máquinas anexas à rede acessar o armazenamento de arquivos em uma máquina remota, como se esta fosse local.

\begin{description}

	\item[NFS: ] Esse é o padrão de fato e está em uso há muitos anos. O subconjunto implementado comumente não oferece grande segurança, embora seja definida uma variante de segurança e implementada em algumas variantes comerciais Unix.

O NFS consiste de um serviço que compartilha arquivos de um servidor para clientes conectados à rede. Há autenticação mínima dos usuários anexos na versão Linux.

O NFS é parte padrão de muitas distribuições. 

	\item[Samba: ] O Samba é um produto que implementa o protocolo SMB, constituindo-se de uma ferramenta crucial para a integração do \emph{Software} Livre com sistemas baseados em ambiente proprietário. Os pacotes de instalação do 
Samba já vêm incluídos na maioria das distribuições 
GNU/Linux.
A Seção \ref{smb} apresenta descreve a utilização da 
ferramenta.

	\item[Netatalk: ] Para os que possuem máquinas Apple\reg Macintosh\reg, o netatalk oferece a implementação do  protocolo Apple\reg Talk\footnote{
\wwn{http://netatalk.sourceforge.net}.}.

	\item[OpenAFS, CODA e Intermezzo: ] Esses produtos implementam um sistema de arquivo distribuído em vários graus. Com tal sistema, o acesso aos arquivos pode continuar quando a rede falha, porque o caching local possibilita a aparência de estar conectado. Esse não é um problema trivial, e os produtos oferecem soluções de diversas formas. Esse tipo de sistema de arquivo é realmente necessário em \emph{laptops} ou máquinas anexas a uma conexão transitória. A outra forma de prover a mesma funcionalidade é possuindo armazenamento local sincronizado com um servidor central, periodicamente.

Veja em <\www{http://www.openafs.org}>, \\
<\www{http://www.coda.cs.cmu.edu}> e 
<\www{http://www.inter-mezzo.org}>  para obter mais 
detalhes de cada produto.
O sítio <\www{http://www.inter-mezzo.org/docs/bottlenecks.pdf}>  contém uma discussão detalhada das características desses produtos.

\end{description}


\subsubsection{Serviço de Diretório}

Este serviço propicia provisão de consulta rápida de nomes, endereços e dados associados.

O padrão mais popular de serviços de diretório é o LDAP. Esse é um protocolo aberto implementado em muitos produtos como, por exemplo, em Evolution e OpenOffice.org. O LDAP trabalha com definições de dados chamados esquemas e é possível às Administrações desenvolverem os próprios esquemas customizados. Infelizmente os esquemas usados pelos aplicativos não são sempre compatíveis uns com os outros, o que significa, por exemplo, que é difícil para o OpenOffice.org ler os dados do Evolution e vice-versa.

O serviço de diretório OpenLDAP adapta-se ao padrão LDAPv3 e à versão 2.1 e mais tarde poderá ser configurado com uma gama de bancos de dados (tais como \emph{flat file}, SQLs).

A maior parte dos conjuntos de \emph{groupware} fornece alguma forma de serviço de diretório, porém poucos estão atualmente compatíveis de fato com o LDAP. O Open LDAP ainda possui algumas peculiaridades, principalmente com relação a seu uso em grandes redes que possuem milhares de objetos em seus diretórios; estas existem devido ao fato de este Diretório ainda não possuir algumas facilidades e funções administrativas que atualmente se encontram disponíveis em diretórios proprietários. Porém, já estão em andamento projetos objetivando a implementação dessas funcionalidades, de forma que sua Administração seja mais amigável e facilitada para esses ambientes.

O OpenOffice.org, o Evolution e o Mozilla oferecem funções integrais de catálogos de endereços. No entanto, os formatos de armazenamento usados não são passíveis de trocas. É necessária alguma adaptação para possibilitar o trabalho interativo. 


\subsubsection{Serviço de Fax}

O serviço de fax é muito utilizado em diversas Administrações para centralizar e facilitar o envio de fax por seus usuários. Algumas ferramentas em \emph{Software} Livre podem ser alternativas para substituição de seu equivalente proprietário.

Uma destas opções é o Hylafax\reg Server\footnote{
\wwn{http://www.hylafax.org}.}, que se integra a um cliente para plataforma proprietária, chamado Hylafax Manager\footnote{
\wwn{http://codigolivre.org.br/projects/hylafaxmanager}.}, 
de modo a permitir o uso comum do servidor por ambas as plataformas -- para GNU/Linux existem diversos clientes disponíveis. Este Sistema permite inclusive juntar folhas de diferentes aplicativos.

A alternativa que vai além do serviço apenas de fax é o VOCP, sistema que transforma um computador em um sistema completo para correio de voz, mensagens e fax. Caixas postais ilimitadas podem ser criadas para correio de voz, pager e roteiros (\emph{scripts}), que permitem a navegação em um sistema de menus pelas teclas do telefone. Documentos de fax podem ser recebidos e enviados, pode-se ouvir \emph{e-mails} usando sintetização de voz, filtrar e redirecionar chamadas baseadas na identificação da chamada (deve-se checar como usar este recurso no sistema de telefonia do Brasil).

Para usar o VOCP, é preciso um computador com uma placa do tipo ``voice modem'' e uma máquina GNU/Linux, com módulos Perl e vgetty instalados. O VOCP inclui parte da central do sistema de mensagem, o Call Center (para usar stand-alone e monitorar a chegada de novas mensagens), o VOCPhax para visualização dos faxes recebidos, e o VOCPweb, para acesso às caixas postais pela \emph{web}, dentre outros pacotes. 


\subsubsection{Suporte a legados}

\begin{description}

	\item[Emulação terminal: ] O uso do xterm, com um jogo variável de ambiente TERM apropriado, pode emular a maior parte dos tipos terminais baseados em caracteres, como, por exemplo, VT220 e VT100. Há um emulador 3270 específico chamado x3270. Pode-se encontrar emulações baseadas em páginas em produtos proprietários.

	\item[Exibição remota: ] Há uma discussão a respeito na Seção \ref{exibe_remota}.

	\item[Emulação: ] Há uma discussão a respeito na Seção \ref{emulacao}. 
\end{description}

\chapter{Visão Geral da Migração de Aplicativo}

Uma vez redigida a lista de aplicativos, ela pode ser agrupada nas categorias a seguir:

\section{Aplicativos proprietários que possuem um \emph{Software} Livre equivalente}

Alguns aplicativos, tais como o Microsoft Office\reg, o Lotus\reg SmartSuite\reg, o WordPerfect\reg, o Framemaker\reg, o QuarkXPress\reg e o Photoshop\reg têm equivalentes que operam originalmente no \emph{Software} Livre, como o OpenOffice.org, o Gnumeric, o Evolution\reg e o GIMP. Nesse caso, é preciso testar o produto \emph{Software} Livre para garantir que forneça a funcionalidade necessária.


\section{Aplicativos proprietários que operam em um ambiente \emph{Software} Livre. }

Alguns aplicativos proprietários possuem versões que 
funcionam em ambientes livres\footnote{Por exemplo, 
o Acrobat\reg \  Reader\reg possui versão para GNU/Linux.}.
Caso não exista uma alternativa em \emph{Software} Livre 
é essencial que a versão para ambiente livre de 
tal aplicativo apresente todas as 
funcionalidades necessárias.

Na hipótese de existir alternativa \emph{Software} Livre para o aplicativo mas a migração parcial for aceitável, então deve-se considerar os recursos oferecidos pelo 
aplicativo proprietário e pela alternativa 
em \emph{Software} Livre para definição da solução a 
ser adotada. 


\section{\emph{Software} que pode ser acessado por exibição remota.}
\label{exibe_remota}

Outra abordagem é fazermos operarem os aplicativos em um servidor e transportar a tela para a estação de trabalho; essa é a abordagem Cliente Leve. Produtos como Windows Terminal Server, Citrix, Graphon e Tarantella permitem que os aplicativos funcionem em um servidor operando com \emph{software} proprietário em uma plataforma multiusuário. Isso significa que um aplicativo feito para operar em uma estação de trabalho no modo cliente individual poderá ter que ser alterado para funcionar nesses produtos. Isso não será possível sem o acesso ao código-fonte e poderá haver necessidade de negociação com 
os fornecedores.

O mais sofisticado desses produtos, o Metaframe da Citrix, tem sua própria linha de protocolo, ICA, que apresenta bom desempenho em conexões de banda estreita. Ele pode operar múltiplos servidores com carga balanceada e possui outros recursos. Existem clientes gratuitos do ICA que operam em GNU/Linux.

Todos esses produtos contam com \emph{software} proprietário de fonte fechada, e o custo do Citrix é particularmente elevado. Requer licença de servidor Windows, licença de Citrix e licença de Servidor de Terminal Windows, caso seja usado cliente não Windows. Adicionalmente, serão necessárias Licenças de Acesso ao Cliente para cada estação de trabalho que use o \emph{Software}. A licença do Citrix é baseada em usuários concorrentes, portanto essa abordagem pode reduzir custos, se houver muitos usuários que necessitem acesso a um aplicativo desde que o acesso do concorrente seja baixo.

Há estudos de casos documentados em <\www{http://www.citrix.com/press/news/profiles}>, que mostram que a economia realizada utilizando estações de trabalho em cliente leve é suficiente para justificar a mudança dos aplicativos para um servidor. O Citrix também possui produtos que permitem o transporte dos aplicativos Unix da mesma forma, usando o ICA e exibindo em uma tela de cliente leve.

O Windows Terminal Server oferece funcionalidade similar ao Citrix, exceto por usar seu próprio protocolo, RDP. O cliente GNU/Linux para RDP é uma solução, porém ainda é considerado por alguns como código beta. O RDP costumava ser ineficiente em comparação ao ICA, porém agora a diferença é pequena, se não insignificante.

O Citrix tem vários recursos, como equilíbrio de carga, o que faz dele a melhor opção para instalações de larga escala, em que o custo extra pode ser justificado. Tanto o Citrix quanto o Windows Terminal Server podem introduzir latência no aplicativo, se o tamanho dos servidores não estiver dimensionado corretamente e a rede não for suficientemente rápida. 


O Tarantella\footnote{
\wwn{http://www.tarantella.com}.}
funciona em Linux e Unix (Solaris), servindo de portal seguro (Apache e Tomcat) para aplicações Windows, Linux, Unix, Mainframe e AS/400. Ele usa sua própria linha de protocolo proprietário, AIP, capaz de disponibilizar aplicações Windows, Linux e UNIX, nativas, sem emuladores.

O CodeWeavers produz uma versão servidor de seu produto CrossOver Office. Ele trabalha com o cliente conectado com segurança ao servidor central e tem uma sessão X exibida de volta a ele. Isso significa que a comunicação com o servidor central é codificada e comprimida, porém também requer largura de banda suficiente para suportá-lo, já que é baseado em X. Não foram feitos testes no requisito largura de banda, porém é provável que seja maior do que para o ICA (Citrix) ou o AIP (Tarantella).

O VNC é um produto \emph{Software} Livre desenvolvido pela AT\&T, desenhado para exibir uma sessão, funcionando em outra máquina. Consiste de um servidor e um cliente, os quais são disponibilizados para ambiente proprietário -- Unix e GNU/Linux. O VNC permite que os aplicativos funcionem em um ambiente e a exibição, em outro. Usa o próprio protocolo aberto, RFB, sobre o TCP/IP, que não é tão eficiente quanto o ICA (Citrix) ou o AIP (Tarantella); portanto, necessita de alta banda larga de rede (como 100 Mb/s) para trabalhar bem. Infelizmente o servidor VNC para ambiente proprietário também não é tão eficiente quanto a versão Unix e pode necessitar de mais poder de processamento do que poderíamos esperar. O VNC pode ser muito útil para uso ocasional de Administrador de sistemas, permitindo que uma pessoa central controle uma estação de trabalho. Nessas circunstâncias, poderia ser aceita alta latência. 


\section{\emph{Software} que funcionará sob um emulador}
\label{emulacao}
Se nenhum caso acima oferecer qualquer meio de fazer operar o aplicativo ou o substituto, então pode ser possível fazê-lo operar na forma original, porém com seu ambiente operacional normal emulado em cima de um sistema operacional \emph{Software} Livre. Uma boa discussão dos assuntos relativos a esta abordagem pode ser encontrada em\\
<\www{http://www.linuxmednews.com.}>.

 
Todas essas técnicas têm implicações de licença porque podem envolver a operação de múltiplas cópias do aplicativo e/ou do sistema operacional proprietário. É provável que a maior parte desta Seção seja aplicável a ambientes Windows\reg, porém como as técnicas podem aplicar-se a outros Cenários, discutiremos  aqui, em vez de no Capítulo \ref{cenario_windows}.

Há dois tipos de emulação:

\subsection{Emulação de \emph{hardware}}

Produtos como Vmware e Win4lin fazem emulação de \emph{hardware}. Eles possibilitam que um sistema operacional de PC normal funcione como um aplicativo em nível usuário, imitando o \emph{hardware} Intel PC em interfaces de \emph{software} e provendo, portanto, uma máquina virtual. Isso permite que sistema operacional legado e seus aplicativos operem sobre de uma plataforma \emph{Software} Livre.

O Vmware não é rigorosamente um emulador. Ele permite que a maior parte das instruções passe pelo processador, o que significa que somente funcionará em uma máquina de arquitetura x86. É a opção mais completa, porém é proprietário e pode consumir muitos recursos da máquina.

O Win4lin é similar ao Vmware e também é um produto proprietário, mas é mais acessível. Pode ser boa solução em casos simples -- por exemplo, para operar aplicativos office somente. É componente do produto Lindows, que está sendo vendido em \emph{hardware} de baixo custo para usuários domésticos Pelo fato de aparentemente não usar contas de usuários não privilegiados para manter a segurança, o Lindows não deve ser recomendado para Administrações, sem a consideração cuidadosa das implicações de segurança.

Pelo fato da abordagem de emulação de \emph{hardware} requerer licenças completas para o sistema operacional e o aplicativo proprietários, junto com o custo do emulador, deveria ser visto como forma de operar um número pequeno de aplicativos legados que são difíceis de migrar. 

Há produtos de servidores Vmware e Win4lin que podem reduzir custos de licença, se o \emph{software} proprietário permitir licença de usuário \textbf{concorrente}, ao invés de \textbf{licença de usuário potencial}. 

Além disso, há aplicativos \emph{Software} Livre que emulam completamente um ambiente Intel: por exemplo, o Bochs. O Bochs é um emulador de PC x86 (pode emular um 386, um 486 ou um Pentium), \emph{Software} Livre, escrito em C++, multiplataforma, produzido para ser utilizado em máquinas x86, PPC ou Alpha. Pode ter como sistema operacional convidado, ou seja, rodando sobre ele o MS-DOS\reg, o Windows 95\reg, o Windows NT\reg\  4 ou o GNU/Linux. Ele possui boa documentação e está em pleno desenvolvimento, como podemos notar no sítio <\www{http://bochs.sourceforge.net}>.


\subsection{Emulação de \emph{software}}
\label{emulacao_soft}

A emulação de \emph{software} permite que programas escritos para um ambiente proprietário trabalhem diretamente em sistema operacional \emph{Software} Livre. Quaisquer chamadas ao sistema feitas por eles são mapeadas na interface do sistema de \emph{Software} Livre equivalente. Dessa forma não é mais necessária uma cópia do sistema operacional proprietário.


\subsubsection{Wine}


O Wine permite que aplicativos escritos para  Windows\reg funcionem em GNU/Linux por meio da emulação de \emph{software}. O principal  problema que o Wine precisa resolver é o grande número de chamadas ao sistema (inclusive \emph{bugs}) que precisa suportar. Seu código está disponível em <\www{http://www.winehq.org}>  ou em CodeWeavers em\\
<\www{http://www.codeweavers.com/technology/wine/download.php}>.


O Wine intercepta todas as chamadas aos sistemas Windows\reg e DOS, junto com as interrupções BIOS, e tenta mapeá-las no ambiente GNU/Linux e X Windows. São executadas instruções de processador original como se estivessem no ambiente Windows\reg; portanto, o Wine não é emulador propriamente dito, pois não são emuladas as instruções da arquitetura x86.

Nem todas as interfaces no ambiente Windows\reg podem ser mapeadas em uma interface nos ambientes GNU/Linux e X Windows: há interfaces Windows\reg que, simplesmente, não possuem equivalente. Isso mostra que, em alguns casos, é preciso escrever uma quantidade significativa de códigos para dar suporte ao mapeamento. Há problemas, por exemplo, com os cursores mais complexos usados por alguns programas Windows\reg: o X Window System não consegue lidar com mais de duas cores em um cursor, o que representa que o Wine precisa definir quais cores usar, ocasionalmente com resultados inúteis.

O Wine é atualmente composto por dois produtos: o Wine propriamente dito, que permite operar programas Windows\reg pré-compilados, e o Winelib, que pode ser usado para compilar um programa Windows\reg escrito nas linguagens ``C'' ou ``C++'' para produzir um programa GNU/Linux original (é o que o Corel usava para produzir a versão GNU/Linux do Wordperfect).

O Winelib pode ser usado para operar programas em outros \emph{hardwares} além do x86, caso o código-fonte esteja disponível, embora ainda possam permanecer alguns outros problemas específicos de arquitetura (por exemplo, questões de alinhamento de bits -- edian). 


\subsubsection{Situações em que o Wine é adequado}

Há suporte disponível para programas Windows\reg3.x/95/98/ME/NT (embora o suporte Windows\reg \ NT seja menos completo). Alguns programas dirigidos ao Windows\reg 2000 não vão operar, a não ser que usemos novas interfaces especializadas introduzidas com o Windows\reg 2000. Além disso, o trabalho no suporte específico a programas Windows\reg XP ainda é incipiente.

O Wine fornece suporte à maioria das interfaces Windows\reg documentadas publicamente; no entanto, o suporte não é sempre tão completo quanto gostaríamos. Acesse o endereço\\
<\www{http://www.winehq.com/?page=status}> para obter mais detalhes sobre a situação atual de suporte no Wine.

Programas que operam isoladamente, ou que usam apenas interfaces de comunicação externa, funcionarão normalmente. Cada programa deve ser verificado individualmente porque as interfaces precisas e os parâmetros usados podem interagir causando problemas. Há relatórios de pessoas que operaram compiladores e ambientes de desenvolvimento com muito sucesso.


\subsubsection{Situações em que o Wine não é adequado}

O trabalho em algumas áreas não está completo. Vejamos alguns exemplos de casos específicos:
\begin{itemize} 
       \item A \emph{Dynamic Data Exchange} (DDE) apresenta alguns problemas, mas como muitos programas fazem chamadas DDE sem usá-las de fato, eles deverão funcionar bem;
       \item O DirectX e as outras áreas gráficas especializadas de alta velocidade também apresentam problemas;
       \item Existe, em parte, a implementação de Access Control Lists (como no Windows\reg NT), mas ainda não foram integradas com ACLs na base O/S;
       \item O dispositivo VxD de tecnologia de driver, introduzido com o Windows\reg 98, é uma área difícil. Ele precisa de acesso ao interior do \emph{hardware} e do \emph{kernel} de forma que qualquer sistema multiuso sério não permite;

   \item         O desenho de algumas imagens gráficas ainda não é satisfatório, especialmente o retoque da fonte \emph{True Type} e a exibição de alguns objetos OLE. Contudo, trabalha-se ativamente com objetivo de melhorar isso, e pode-se utilizar as bibliotecas nativas do MS Windows\reg nesses casos;

   \item         Programas desenvolvidos pela própria Microsoft também constituem área problemática: trata-se de produtos que tendem a usar interfaces não documentadas. Embora seja possível descobrir o que acontece, os desenvolvedores devem ser cautelosos, já que as leis relativas à engenharia reversa são muito severas em alguns países. Nos Estados Unidos, por exemplo, é proibida a engenharia reversa para qualquer propósito, e a maior parte dos outros países ocidentais permite somente para o estabelecimento de compatibilidade. Portanto, o trabalho nessa área será sempre um pouco lento;

   \item         A operação de instaladores de aplicativos tem sido particularmente problemática, mas trabalhos recentes resolveram grande parte das dificuldades --  e esse trabalho continua. Algumas dessas dificuldades são causadas por desenvolvedores que não utilizam as técnicas recomendadas. O acesso ao registro é exemplo disso. O formato do Wine é diferente do do Windows\reg, para facilitar a recuperação. Enquanto as interfaces documentadas forem usadas para acessar o registro, não há problema; porém, às vezes, os desenvolvedores acessam o registro diretamente, sob o risco de corromperem um registro Windows\reg verdadeiro, e isso resulta em programas que não podem mais trabalhar no Wine;

   \item         O Wine é algumas vezes criticado por apresentar baixo desempenho, porém isso é freqüentemente devido a seu extenso código de \emph{debugging}. É possível compilarmos o Wine sem isso, porém devemos fazê-lo com cuidado, já que significa que os problemas não podem ser diagnosticados sem recompilação adicional. 

\end{itemize}

\subsubsection{Wine -- alternativas comerciais}

Como já mencionamos, versões prolongadas do Wine estão disponibilizadas como produtos comerciais para dar suporte à corrente principal do Wine. As duas companhias que estão fazendo isso são a Transgaming e a CodeWeavers.

A Transgaming trabalha principalmente no aperfeiçoamento de gráficos e interfaces de som, e seu produto visa ao mercado de jogos. Já a CodeWeavers trabalha em aplicativos office de tendência dominante e tem um produto, o CrossOffice, que dá suporte, por exemplo, ao Office\reg e ao Lotus Notes\reg. 


\subsubsection{Wine e Visual Basic\reg}

Relatamos  que os compiladores MS Visual Basic\reg (excluindo o .NET), funcionam corretamente no Wine com a utilização de alguns componentes nativos do MS Windows\reg. Os aplicativos escritos nessa linguagem exigem a utilização da versão nativa da máquina virtual do Microsoft Visual Basic (vbvmrunxx.dll).

\subsubsection{Migração de aplicativo para o Wine}

Esta é uma lista de diretrizes gerais para se gerir o processo de migração de aplicativos para GNU/Linux no Wine:
\begin{enumerate} 

   \item Cheque as condições da licença: Algumas companhias publicaram licenças que proíbem a execução de seu aplicativo, exceto no sistema operacional-alvo. Remova qualquer programa em tais condições da lista, teste e faça uma lista deles em separado.

   \item Obtenha cópias de todos os aplicativos para serem migrados. Licenças de programas obtidos pela Internet podem não permitir cópias para testes.

   \item Configure uma máquina com a última versão do Wine.

   \item Teste cada um dos programas da lista-teste. Anote todos os problemas encontrados e também se eles estão na fase de instalação, inicialização ou execução. Além disso, avalie se eles afetam o que os usuários precisam fazer por meio de testes, com uma seleção representativa de usuários finais. Anote também informações sobre o desempenho dos programas. O produto disso serão avisos indicando onde as chamadas do sistema ainda não foram implementadas ou estão implementadas de forma incompleta.

   \item Para cada programa da lista de problemas, verifique primeiro se já existe uma implementação GNU/Linux. Se houver, não deve haver problemas, mas teste até onde puder. Se não houver implementação GNU/Linux, será necessário contatar o fornecedor e sugerir a criação de uma pelo uso do Winelib. Novamente, podem estar faltando DLLs.

   \item Quando fornecedores se recusarem a cooperar, terão que ser encontrados aplicativos alternativos, ou o projeto deverá ser abandonado.

   \item Uma vez disponibilizadas as listas de DLLs extras e de chamadas de biblioteca requeridas, será possível obter um preço pela implementação.

   \item Cada programa precisará ser retestado com novos instantâneos de Wine/Winelib até que os todos problemas desapareçam. Remendos às vezes causam problemas com programas que anteriormente estavam operando corretamente, e isso precisa ser testado.

   \item O Wine é normalmente compilado com rastreamento \emph{debugging}, e isso prejudica o desempenho, especialmente em interações de telas. Quaisquer programas que operem corretamente, mas tenham problemas de desempenho, devem ser re-executados em contraposição a uma cópia do Wine compilado sem as macros de \emph{debug}. Se o desempenho ainda for insatisfatório, será necessário trabalho de desenvolvimento. 
\end{enumerate} 

\subsubsection{CrossOver}

A CodeWeavers produz dois produtos proprietários: o CrossOver Office\reg \ e o CrossOver Plugin\reg, baseados no Wine e desenhados para dar suporte a aplicativos Windows específicos. Embora os produtos sejam proprietários, periodicamente são enviadas modificações de código de volta à versão \emph{Software} Livre do Wine.

O CrossOver Office é desenhado para permitir que aplicativos como Office\reg \ e Lotus Notes\reg \ funcionem originalmente em GNU/Linux. Há alguns assuntos que ainda estão por se resolver, mas o produto está em ativo desenvolvimento. No entanto, essa abordagem pode ser apropriada para alguns usuários dependendo de suas necessidades. O CrossOver Office\reg \ está disponível agora como produto servidor, o que significa que não precisa ser totalmente instalado na estação de trabalho e que pode prover funcionalidade similar ao Citrix.

O CrossOver Plugin\reg \ é desenhado para permitir que plugins de navegador, que normalmente só trabalham em ambiente proprietário, funcionem em Netscape, Mozilla e Galeon em GNU/Linux. Este produto está disponível há mais tempo que o CrossOver Office\reg \ e apresenta bons resultados. 


\subsubsection{Cuidados}

Ao usarmos essas técnicas, removemos o custo da licença do sistema operacional proprietário, mas não o da licença do aplicativo. A licença do aplicativo precisa ser examinada minuciosamente para termos certeza de que não proíbe o funcionamento do aplicativo sem o ambiente proprietário. Essa restrição é usada em alguns aplicativos proprietários como tática para trancá-los, embora a imposição legal seja questionável.


\section{\emph{Software} que pode ser recompilado em \emph{Software} Livre }


Para aplicativos escritos em casa ou em nome da Administração para os quais haja código-fonte disponível, o \emph{software} pode ser transferido para funcionar em uma plataforma \emph{Software} Livre. Em geral, o problema de transferir código-fonte em qualquer linguagem não é a compilação, mas o uso pelo código de bibliotecas do sistema, incluindo o ambiente gráfico e o sistema operacional. Isso pode indicar muita intervenção manual para migrar o código. Adicionalmente, quaisquer suposições sobre o ambiente-base, tal como nomeação do arquivo, tornará necessária a mudança do código-fonte ou a replicação do ambiente, independentemente da linguagem usada.


\begin{enumerate}
	\item \textbf{Java.} 

Se o \emph{software} Java foi escrito de acordo com a especificação Java, o Programa deve funcionar sem quaisquer problemas. No entanto, caso quaisquer extensões proprietárias tenham sido utilizadas, o código terá que ser mudado e deve-se usar módulos-padrão.

	\item \textbf{Visual Basic.} 

Um produto proprietário chamado DeLux\footnote{
\wwn{http://www.deluxsoftware.com}.}
pode ser usado para converter o código Visual Basic para Kylix (veja item 4 abaixo) e trabalhar em GNU/Linux originalmente. As ferramentas de desenvolvimento da Microsoft\reg podem converter o código Visual Basic para .NET e produzir código CIL. O projeto \emph{Software} Livre Mono permite que esse código funcione em GNU/Linux. O Mono está sendo desenvolvido muito rapidamente no momento, e qualquer aplicativo poderá ou não funcionar, dependendo da forma como vai interagir com as bibliotecas, como o exibidor de tela.


	\item \textbf{C\#.} 

Este está recebendo suporte crescente GNU/Linux, e a Ximian\reg produziu um compilador como parte do projeto Mono, acrescentando as ligações C\# a componentes cruciais da estação de trabalho GNOME. O projeto Mono inclui um intérprete que permite que o código CIL produzido por ferramentas de desenvolvimento proprietárias trabalhe em GNU/Linux sem alterações. O projeto Mono e o uso da estrutura de desenvolvimento. NET são uma área muito viva do \emph{Software} Livre atualmente, e a posição muda rapidamente.

	\item \textbf{Pascal e Delphi.} 

 Pascal como linguagem livre, é menos usado atualmente, porém é o componente de codificação essencial da ferramenta de desenvolvimento rápido Borland Delphi. Borland tem um equivalente nativo GNU/Linux da Delphi chamado Kylix. O Kylix 2 e o Delphi 6 são feitos para usar sintaxe de código compatível e possuir ambientes de suporte idênticos.

	\item \textbf{C e C++.} 

Programas escritos para padrões ANSI devem ser recompilados e funcionar enquanto as bibliotecas do sistema-base usadas forem compatíveis. Por exemplo, sistemas escritos especialmente para ambiente proprietário, em geral, não irão recompilar e funcionar corretamente em GNU/Linux, por conta de jogos de chamadas muito diferentes dos do sistema operacional e das bibliotecas \emph{runtime}, como o sistema de janelas. Podemos resolver essa falta de combinação, freqüentemente, com a compilação do código com o Winelib, parte do projeto Wine.

\end{enumerate}


