Linux in Brazil tem o orgulho de apresentar mais um artigo do Elvis Pfützenreuter, que além de ser consultor de informática (com ênfase no uso do Linux), também já prestou muitos serviços à comunidade brasileira, com algumas traduções e também alguns ótimos artigos originais.
Desta vez o artigo é sobre o Mars/NWE, o pacote de software capaz de fazer o Linux emular um servidor Novell Netware. Vamos ao texto do Elvis:
versão 1.0 - 09/10/1999
Elvis Pfützenreuter - info@rootshell.com.br
O objetivo deste documento é familiarizar o leitor com as possibilidades e limitações do Mars-NWE. Este software é uma opção bastante viável em instalações que ainda usam Netware 3, ou que estejam em processo avançado de migração para Linux mas ainda precisam suportar o protocolo NCP/IPX por algum tempo além do "dia do julgamento" (01/01/2000).
Ainda existem inúneras empresas que usam e dependem de servidores Netware 3.12. Como a maioria de nós já sabe, mas algumas pessoas ainda não, os servidores Netware 3.12 falharão fragorosamente a partir do dia 01/01/2000. Quero dizer que eles realmente travarão a cada 10 minutos. Hoje é dia 29 de setembro - há pouco tempo para evitar a tragédia...
Existem algumas opções:
- Obter os patches do site da Novell. Considero esta opção um tanto imperfeita e insegura, pois são inúmeros patches que devem ser aplicados numa ordem crítica. A chance de se terminar com um Netware mal remendado (e ainda sensível ao bug do milênio) é muito grande. Além disso, a Novell vai deixar de suportar o Netware 3.12, se não me falha a memória, no dia 01/02/2000. Portanto, problemas futuros NÃO terão mais patches que os remendem;
- Comprar o upgrade para Netware 3.2, que continuará sendo suportado; ou ainda o Netware 4.1, ou 5.x. Pode ser uma opção para quem pretende usar Netware até o final dos tempos. Mas para quem está em processo de migração para uma arquitetura de rede diferente (v.g. saindo de um sistema Clipper e partindo para um sistema cliente/servidor), e já sabe que ao final do processo os servidores Netware serão deixados de lado em favor de outra arquitetura, seria um investimento sem muito retorno;
- E, finalmente, usar o Mars-NWE, um emulador gratuito de Netware que roda sob Linux e alguns outros Unixes.
O Mars-NWE oferece um subconjunto do protocolo NCP, suficiente para que as estações e demais servidores enxerguem-no como servidor Netware. Já quanto a administração do servidor (contas de usuários, permissões etc.), muita coisa tem de ser feita pelo Linux, pois as ferramentas de administração do Netware (SYSCON, FCONSOLE...) não são eficazes com o Mars. Afinal, é um emulador, não um sistema operacional.
O Mars é indicado para instalações onde haja pelo menos uma pessoa com conhecimento razoável de Linux, e ainda mais indicado a sites em processo avançado de migração para Linux, que por qualquer motivo (e.g. estações DOS) ainda precisam manter um ou mais servidores Netware.
E o melhor de tudo: o Mars funciona após o ano 2000 (eu testei ;)
O protocolo IPX é análogo ao IP, ao que farei diversas analogias entre um e outro, o que pressupõe um entendimento mínimo de como o TCP/IP funciona.
O IPX é um protocolo de transporte, que encarrega-se de transportar UM pacote de rede da origem ao destino. O controle da sessão é feito por outros protocolos empilhados sobre dele. No caso dos serviços Netware, o protocolo de sessão é o NCP. Também existe o protocolo SPX, embora muito menos usado (e não suportado pelo Mars). O NCP em conjunção com o IPX cria uma pilha com poderes semelhantes ao NetBIOS encapsulado em IP. Já o SPX em conjunção com o IPX cria uma pilha muito semelhante ao TCP/IP.
Em máquinas que usam TCP/IP, há necessidade de especificar o número IP de cada uma delas. Já no IPX, isso não precisa ser feito. O "número IPX" de cada máquina é o próprio número Ethernet de 48 bits da placa de rede. (O número Ethernet é atribuído às placas de rede na fábrica, e garantidamente não conflitam.). Nesse aspecto, configurar uma rede IPX é mais fácil pois não é preciso atribuir e controlar números e faixas de endereçamento.
Também não é suportado, no IPX, o conceito de netmask. O número de rede é um campo separado, de 32 bits, do cabeçalho do pacote IPX. Cada rede local deve ter um número unívoco. Desta forma, o protocolo IPX é roteável, tal como o TCP/IP.
Adicionalmente, servidores Netware nativos e também o Mars desempenham automaticamente a função de roteadores, se estiverem ligados a mais de uma rede local. Uma vez por minuto, os servidores "anunciam-se" com pacotes de broadcast, e isso permite que os servidores montem rapidamente uma tabela de roteamento dinâmica. Também é possível especificar rotas estáticas para IPX, mas dificilmente isso é necessário (um possível uso de rota estática é a interligação de redes via WAN). O protocolo de auto-descoberta de rotas é denominado RIP, e, como alguns devem ter notado, seu modus operandi é análogo ao protocolo homônimo RIP para TCP/IP.
Essa troca freqüente de pacotes torna o IPX um tanto inadequado para redes WAN realmente grandes com links de baixa velocidade. Por esse motivo, a própria Novell mudou o protocolo "default" de IPX para TCP/IP na versão 5 do Netware. O NCP, tal como o NetBIOS, pode ser e é encapsulado em TCP/IP na versão 5.
As máquinas TCP/IP têm todas uma "rede interna", 127.0.0.0/8, também chamada de interface de loopback. No mundo IPX, apenas os servidores precisam ter uma rede interna. Por outro lado, os números das redes internas dos diversos servidores NÃO podem coincidir uns com os outros, nem com números de redes "reais" - eles têm de ser únívocos.
Computadores IPX com mais de uma interface de rede tem de eleger uma das interfaces como primária. Como dificilmente uma estação terá mais de uma interface de rede, essa escolha tem sentido apenas nos servidores. No caso do Mars, é obrigatório que a interface primária seja a rede interna.
Nos Unixes em geral, e também no Linux, o protocolo IPX é suportado pelo kernel de uma forma um pouco mais confusa que num servidor Netware:
- O kernel do Linux permite criar uma rede interna no próprio kernel. Se você for usar o Mars-NWE, não use esse recurso. O próprio Mars encarrega-se de criar a rede interna e não vai funcionar se o kernel já o tiver feito;
- Os utilitários ipx_configure e ipx_interface configuram interfaces de rede para funcionarem com IPX. Eles são úteis quando você precisa montar volumes Netware remotos (com ncpmount) e não estiver usando o Mars no computador-cliente. Ainda, o ipx_interface permitirá que você atribua a interface primária a uma placa de rede (como já foi dito, uma das interfaces tem de ser a primária). Alias, você será obrigado a configurar a primeira interface de rede como primária se utilizar o ipx_interface;
- Como o Mars cria sua própria rede interna e atribui a rede primária a ela, está claro que ele não funcionará se as interfaces IPX tiverem sido previamente configuradas com o ipx_interface. Assim, NÃO MISTURE o Mars com comandos ipx_interface e ipx_configure. Nem mesmo ative IPX no LinuxConf se for usar o Mars;
- O Mars-NWE permite que as interfaces de rede "reais" sejam especificadas em seu arquivo de configuração, o que elimina qualquer necessidade residual de utilizar o ipx_interface.
Por último, saiba que é possível encapsular pacotes IPX em TCP/IP, e criar "túneis" para trafegar IPX sobre redes TCP/IP, inclusive pela Internet pública. Nunca encontrei uma aplicação prática para esse recurso; mas não custa saber que ele existe.
Você poderá consultar aqui um exemplo de arquivo de configuração, totalmente comentado. Não é a leitura mais agradável do mundo; mesmo assim, é aconselhável ao menos passar os olhos nele ,logo após a leitura dos demais tópicos do texto.
Se desejar, você pode transplantar o arquivo como está para sua máquina e customizá-lo, baseando-se nas orientações dos comentários.
Como foi visto no arquivo de configuração, a cada usuário Netware corresponde um usuário Unix, que deve estar cadastrado no arquivo /etc/passwd.
Porém, a autenticação da senha não é feita com base na senha do /etc/passwd ou /etc/shadow. A primeira senha do usuário pode ser colocada no próprio arquivo /etc/nwserv.conf. Quando o Mars lê o arquivo de configuração e detecta que há novos usuários no arquivo (ou seja, que ainda não estão cadastrados no bindery) ele cadastra-os como objetos de bindery, com as senhas especificadas.
A especificação de senhas para usuários no arquivo /etc/nwserv.conf não é obrigatória nem recomendada. O ideal é cadastrar o usuário sem senha, atribuir uma senha qualquer com o passwd (DOS) ou nwpasswd (utilitários Netware para Linux), e deixar o próprio usuário redefinir sua senha a gosto.
Adiantando um pouco o assunto do tópico 6, os usuários UNIX devem ser cadastrados em grupos condizentes com os grupos de trabalho. Por exemplo, se você tem usuários do setor de recursos humanos, contas a receber e chão de fábrica, e cada um desses grupos deve ter acesso restrito aos arquivos concernentes ao trabalho, devem ser criados três grupos UNIX (o script groupadd pode ser útil), e os usuários devem ser membros desses grupos.
Se determinados usuários pertencem a mais de um grupo de trabalho, isso não constitui problema. No Unix, cada usuário pertence a um único grupo primário, mas é fácil atribuir grupos secundários ao usuário, através de intervenção manual do arquivo /etc/group.
Desde a versão 0.99pl9, o Mars-NWE é capaz de armazenar objetos de bindery. Programas que dependam dessa capacidade funcionarão todos.
Porém, o Mars não honra objetos de configuração do próprio servidor, tais como trustees e limitações de horário. Você pode até criar trustess com o SYSCON, eles ficarão corretamente armazenados, mas não terão o efeito prático. As permissões de usuários devem ser controladas pelo arquivo de configuração e pelo próprio Linux, conforme será visto no tópico 6.
Os únicos objetos de bindery que o Mars honra são as senhas dos usuários, que podem então ser configuradas pelo SYSCON. Assim, cada usuário pode configurar sua senha sem intervenção do administrador do sistema.
Os objetos de bindery, por padrão, ficam armazenados no diretório /var/mars_nwe/*, portanto é importante fazer cópia de segurança desses diretórios, além dos diretórios dos volumes.
Os login scripts ficam armazenados no diretório SYS:MAIL\
Às vezes o SYSCON não consegue gravar o login script; ele grava um
arquivo LOGIN.BAK no diretório do usuário e não consegue renomeá-lo
para LOGIN. Geralmente isso é problema de permissão em diretórios ou
arquivos velhos. Renomeie manualmente no Linux e atribua as permissões
do usuário. É certo que isso não acontecerá uma segunda vez.
Se você estiver migrando do Netware para o Mars, certamente vai montar
o volume Netware com ncpmount e copiar os dados para um diretório como
/home/netware/sys ou coisa parecida. Muito bem, é interessante que,
uma vez feita a cópia, você apague os subdiretórios do diretório
SYS:MAIL.
Se você não o fizer, ali ficarão os diretórios antigos, criados pelo
servidor Netware. E é certo que os números de usuário atribuídos pelo
Netware (que são justamente os nomes dos diretórios) não vão bater com
os números criados pelo Mars; e você terá de ficar descobrindo '"quem
é quem" e atribuir as permissões corretas com chown e chmod etc...
Apague tudo; assim que você iniciar o Mars, todos os diretórios serão
criados automaticamente. Só então preencha os login scripts dos
usuários.
Veja a seção 6 para maiores informações sobre permissões de diretórios
e arquivos.
Como os trustees não são honrados pelo Mars, é necessário estabelecer
as permissões no próprio Linux através dos comandos chmod, chgrp e
chown.
Já vimos que o arquivo de configuração do Mars estabelece uma relação
entre usuários Netware e usuários UNIX. Os comandos citados acima
trabalham apenas com usuários UNIX, portanto as permissões tem de ser
"pensadas" em termos de usuários UNIX. (É certo que se os usuários
UNIX tiverem os mesmos nomes dos usuários Netware, fica tudo mais
fácil ...)
O usuário Unix associado ao "supervisor" pode ser o root, ou um
usuário comum. Se for um usuário comum, ele deve ter um grupo primário
só seu, e também deve participar de todos os grupos onde haja usuários
Unix associados com usuários Netware. Isso garante que o supervisor
possa de fato ler e gravar qualquer arquivo dos volumes exportados.
Pessoalmente, acho que associar o root ao supervisor economiza
bastante tempo. No entanto, se o servidor estiver num ambiente
inseguro (exposto à Internet, ou com usuários desconhecidos etc. etc.)
é melhor associar o supervisor a um usuário Unix comum.
Basicamente, os seguintes pontos tem de ser observados:
- Os diretórios e arquivos SYS:SYSTEM, SYS:PUBLIC e SYS:LOGIN devem
ser possuídos por root:root (*), e com permissões de leitura para todo
mundo;
- O diretório SYS:MAIL deve ser possuído por root:root mas com
permissão de leitura a todo mundo;
- Os demais diretórios e arquivos devem ser possuídos pelos
respectivos usuários:grupos;
- As permissões de todos os diretórios devem ser: 2775 se legíveis a
todos os usuários; e 2770 se legíveis apenas aos usuários do grupo. O
dígito "2" aciona o bit SGID do diretório; assim quaisquer arquivos e
diretórios novos criados dentro do diretório serão possuídos pelo
usuários que os criaram, mas o grupo será sempre o mesmo do
diretório-mãe. Assim, os demais usuários do grupo também terão acesso
garantido aos novos arquivos e diretórios. Note que isso complementa a
configuração das máscaras de permissão do arquivo /etc/nwserv.conf;
- O diretório-raiz de cada volume (como no arquivo-exemplo, o
diretório /home/netware/sys) deve ter permissões 775 e ser possuído
por root:root (*), salvo se os usuários tenham permissão de criar
arquivos/diretórios no diretório-raiz do volume, caso em que as
permissões devem ser 777;
- Os diretórios MAIL/
- Ainda com referência aos subdiretórios de SYS:MAIL, se você deixou o
Mars criá-los sozinho, as permissões já estarão todas corretas, sem
necessidade qualquer intervenção ulterior;
- Diretórios que determinado usuário não tenha permissão de leitura
lhe aparecerão como vazios;
- Se por exemplo, um usuário precisa ter acesso ao arquivo
VOLUME:DIR1\DIR2\DIR3\DIR4\DIR5\ARQUIVO, ele precisará ter, pelo
menos, acesso de leitura ao diretório-raiz de VOLUME, bem como a todos
os diretórios do caminho. Se não puder ler o diretório, o usuário não
enxergará subdiretórios e arquivos.
(*) se o usuário Unix associado ao "supervisor" for o root. Do
contrário, use o usuário:grupo associado ao supervisor.
Uma maneira ainda mais "limpa" de configurar permissões aos grupos é
separar os dados em diversos volumes. Cada usuário tem acesso restrito
ao(s) volume(s) do(s) grupo(s) a que pertence.
Esse diretório é acessível para leitura à toda e qualquer conexão,
identificada ou anônima. O fim dessa permissão é permitir o boot
remoto e o processo de login.
Muitas operações (cadastro de usuários, senhas etc.) podem ser feitas
através do próprio Linux com os utilitários /usr/bin/nw*. Mas é certo
que você precisará de um ou outro utilitário da Novell (IPX20, SYSCON,
LOGIN, SLIST etc.) Existem umas poucas versões gratuitas de alguns
desses utilitários (LOGIN e SLIST, pelo que me lembro), o que é
insuficiente para uma rede com estações DOS. Será difícil constituir
uma rede Novell-like totalmente livre de software comercial.
Se você tem um Netware licenciado, simplesmente copie os diretórios
SYS:PUBLIC e SYS:SYSTEM para o servidor Mars e desative o servidor
Netware. Como você não está usando o mesmo produto em dois servidores
simultaneamente, não vejo problema legal em se fazer isso. Agora, se
você não tiver Netware licenciado...
Como existe uma tendência forte de as estações DOS desaparecerem em
favor das estações Windows 95/98, e estas últimas incluem um cliente
para redes Netware que não depende de nenhum utilitário DOS, você será
capaz de constituir uma rede totalmente livre de software comercial
Netware se todas as suas estações forem Windows.
Se suas estações forem todas Linux, também não haverá necessidade dos
utilitários DOS. (Se bem que o próprio Mars-NWE não tem muita razão de
ser numa rede assim, pois os Linuxes podem comunicar-se nativamente
usando NFS, NetBIOS e lpd.)
Segundo o autor, "a performance do Mars-NWE é ligeiramente inferior ao
Netware 3.12, no mesmo hardware, mas é superior ao Netware 4". Minha
experiência particular mostrou que o Mars-NWE é mais rápido (10-15%)
que o Netware 3.12 para operações comuns em arquivos (leitura e
gravação de pequenos trechos etc.).
Porém, o Mars é 50% mais lento em operações de leitura/escrita de
grandes trechos, como por exemplo um COPY do DOS. Após fazer inúmeros
testes (troca de hardware, kernel, placa de rede etc. etc.) finalmente
desconfiei que o problema poderia ser o "packet burst".
O protocolo NCP original prevê que todo e qualquer pacote transmitido
é confirmado por um pacote de retorno. Isso limita velocidade de
transmissão de dados a 30-35% da largura de banda, pois para cada
pacote útil é gerado mais um, "inútil", fora o tempo de processamento.
Então, a partir do Netware 3.12, o NCP foi estendido com o "packet
burst", que permite a confirmação por bloco, ou seja, vários pacotes
NCP são confirmados por um único pacote de retorno. Assim, a
velocidade de transferência de dados do IPX/NCP chega a 70% da largura
de banda.
O Mars-NWE não habilita o packet burst por padrão. Esse é o motivo da
performace pobre na transferência de grandes trechos de dados. Se você
analisar a documentação do Mars, descobrirá como habilitar esse
recurso, porém também descobrirá que ele está em fase de testes, e
poderá trazer problemas, se houver bugs no Mars.
Não gosto de correr riscos, e não habilitei o "packet burst" do Mars
em nenhum ambiente de produção. Se alguém mais corajoso usar esse
recurso e verificar que não há problema, gostaria de ser avisado...
Em resumo: se você usa Netware de modo "normal", com programas
"normais", vai ficar feliz com o Mars. Se for usar para cópias
massivas de dados, considere testar o Packet Burst ou usar outro
produto que não o Mars.
Além do fato de que alguns procedimentos são truquescos demais para
quem está acostumado com Netware, o Mars-NWE tem uma característica
indesejável. Se um usuário abrir um arquivo em modo exclusivo, e
depois tentar abrir novamente o mesmo arquivo, terá sucesso, enquanto
o comportamento de um servidor Netware seria denegar quaisquer
tentativas de reabertura. (Obviamente, o comportamento do Netware é o
correto.)
Note que isso acontece apenas se o arquivo é aberto múltiplas vezes
através da mesma conexão. Se um usuário logar-se com o mesmo nome em
diferentes estações, e tentar abrir um mesmo arquivo em modo exclusivo
em todas elas, não terá sucesso a partir da segunda estação. (Ainda
bem!) O impacto desse bug do Mars varia em função dos programas
utilizados.
Se os usuários costumam abrir múltiplas instâncias de um mesmo
aplicativo, e esse aplicativo usa abertura de arquivos em modo
exclusivo para garantir integridade de certas operações (os
programadores em Clipper usam muito esse recurso - pelo menos EU
usava), pode haver problemas. O que eu fiz foi proibir os usuários com
estações Windows de abrir múltiplas instâncias do mesmo aplicativo ;)
Um exemplo prático de como a migração pode trazer problemas
inesperados. Havia um programa em Clipper com um bug oculto: ele abria
o mesmo arquivo duas vezes (a primeira em modo compartilhado e a
segunda em modo exclusivo). Enquanto estava rodando no servidor
Netware, tudo bem - a segunda tentativa de abertura falhava
silenciosamente. Quando o programa foi migrado para o Mars, a segunda
tentativa de abertura começou a ser bem-sucedida, por força do
problema descrito mais acima. Como sabem os Clippeiros, não se pode
ter dois arquivos abertos com o mesmo "alias", sob pena de abortamento
do programa, e de fato o programa começou a abortar logo na abertura.
Como eu tinha os fontes à mão e conhecia o programa de trás para
diante, a resolução do problema tomou 30 segundos, descontada a meia
hora que eu gastei para recolocar o disco rígido antigo e atestar que
de fato o tal programa só falhava com o Mars-NWE.
Um outro possível problema é que o Mars não vai carregar/executar suas
NLMs preferidas. Uma extensão eventualmente encontrada em servidores
Netware 3 é o BTrieve. Já existe BTrieve para Linux, porém é um
produto comercial, e, principalmente, o processo de substituição deixa
de ser algo trivial.
Este texto não estava incluído no artigo original, mas como recebi muitas
mensagens perguntando sobre o assunto, pedi ao Elvis (autor de todo o texto
sobre o Mars/NWE) que escrevesse este pequeno complemento:
O boot remoto nada mais é que um arquivo no diretório SYS:LOGIN - a imagem de
um disquete hábil a dar boot na rede. O boot remoto "default" é o NET$DOS.SYS.
Nesse sentido, basta copiar esse arquivo para o diretório SYS:LOGIN que as
máquinas de boot remoto vão achá-lo. (pois o Mars responde corretamente às
requisições GET NEAREST SERVER e também, como já mencionei no documento,
permite acesso irrestrito de leitura a SYS:LOGIN.
Eu não saberia dizer como a coisa funciona se há mais de um boot remoto (e.g.
boots remotos diferentes para diversos típos de maquina e/ou placa de rede). Eu
realmente não sei se o processo de escolha é feito pelo cliente ou pelo
servidor. Testes., testes...
Agora, o Mars não tem ferramentas para FABRICAR o arquivo de boot remoto, até
porque são ferramentas do lado cliente. Caso em que devem ser usadas as
ferramentas da Novell (não me recordo o nome do primeiro e mais importante
executável; o segundo é o RPLFIX, para redes com frames 802.3).
O Arquivo Histórico do BR-Linux.org mantém no ar (sem alteração, exceto quanto à formatação) notícias, artigos e outros textos publicados originalmente no site na segunda metade da década de 1990 e na primeira década do século XXI, que contam parte considerável a história do Linux e do Open Source no Brasil. Exceto quando indicado em contrário, a autoria dos textos é de Augusto Campos, e os termos de uso podem ser consultados na capa do BR-Linux.org. Considerando seu caráter histórico, é provável que boa parte dos links estejam quebrados, e que as informações deste texto estejam desatualizadas.
6. Permissões dos usuários
7. Diretório SYS:LOGIN
8. Utilitários DOS
9. Performance do Mars-NWE
10. Problemas com o Mars-NWE
Boot remoto