Mars/NWE
Linux in Brazil
Documentação original
e de qualidade
em bom português
e de qualidade
em bom português
|
Mars/NWE
| Linux in Brazil Documentação original e de qualidade em bom português |
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.
6. Permissões dos usuários
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.
7. Diretório SYS:LOGIN
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.
8. Utilitários DOS
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.)
9. Performance do Mars-NWE
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.
10. Problemas com o Mars-NWE
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.
Boot remoto
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).