Qual a melhor opcao para rede somente com Linux?

Ola,

Tenho um laboratorio com 20 estacoes Linux e um servidor Linux.
Estou testando uso do Samba Server x NFS/NIS x "super-ultra-enrolado OpenLDAP Server". Alguem tem experiencia de uma rede "pura" dessas para dizer qual a melhor opcao? A mais facil realmente é usar o Samba e nas estacoes, apos o login automatico local com um usuario default, rodar um script para fazer mount do homedir do Samba Server. Contudo, tem gente que fala que o esquema NFS/NIS é o mais puro (o servidor NFS/NIS nao esta visivel na Net, portanto nao sofre de problemas externos de seguranca, apenas poderia sofrer de ataques internos), e o OpenLDAP é muito enrolado de configurar.

Ainda sobre isso, teria como eu fazer a estacao logar direto no servidor sem autenticacao local? Aquele utilitario authconfig do Fedora Core funcionaria pra isso? Tentei usa-lo mas nao deu certo a autenticacao direta remota.

bom cara redes NIS+NFS funcionam muito bem, vc cria os usuarios no servidor NIS e eles estarão disponibilizados em toda sua rede...

vc tb exporta a pasta /home do servidor NFS para que todas as maqunas enxerguem a pasta de usuario, montando ela automaticamente na inicialização..

ou seja, vc tem controle dos usuarios, seus arquivos centralizados.... roda belezinha....

usar SMB se tiver alguma maquina windows....se for so linux NFS+NIS roda melhor...

O que eu achei ruim no NFS/NIS é que eu tive que exportar o homedir de cada usuario separadamente, pois nao queria exportar a pasta pai /home.

E tambem achei ruim ter que ir em cada estacao e incluir no final do /etc/passwd uma linha "+usuario...".

Por nao ter muita experiencia com NFS/NIS, nao sei se eu fiz servico demais, e tem um jeito mais experto de configurar isso... pois eu tenho 200 estacoes. O que eu fiz foi sair copiando o passwd de uma maquina para outra, mas testei isso apenas em 10 maquinas, ate descobrir algo mais administravel para "encarar as 200".

o correto seira exportar o /home inteiro e montar no lugar do /home ans estacoes....

os usuarios teraoa acesso somente a sua propria pasta home...

200 máquinas vai ficar foda pra mandar todo o /home. Imagine todo mundo logando entre as 8 e 9h. sua rede vai ficar um dia soh baixando os /home dependendo do tamanho dos arquivos que os usuários guardarem lah (e usuário sempre guarda porcaria)

Ou seja,

1) se eu tiver mil usuarios, tenho que criar o compartilhamento na mao um por um? se sim, o Samba é mais esperto, pois o [homes] ja resolve o problema de X usuarios, qualquer que seja o valor de X!
2) e tambem tem que arrumar o passwd na mao um por um, nas duzentas maquinas? Pelo jeito o Samba "vence" novamente, porque eu crio o smbpasswd somente no servidor. Tudo bem que tenho que fazer logon automatico local na estacao pra depois entrar pelo smbmount na rede.

é isso? nao tem nenhum utilitario de gerenciamento que facilite isso?

Vc pode configurar o seu server para logar via nis, samba o passwd local.

Nao entendi a sua resposta... o meu server, que tem Samba e NFS/NIS instalados, ja faz autenticacao das estacoes.

Mas o que eu achei muito ruim do NFS/NIS em relacao ao Samba é que eu tenho que ir em todas as estacoes e mudar o passwd delas para o NIS e compartilhar o homedir de todos os usuarios no servidor.

Entao, se tenho 1000 usuarios, tenho que criar 1000 compartilhamentos no exports do NFS...

e se tenho 200 estacoes, tenho que alterar o passwd das 200 estacoes.

Gostaria de saber se tem um meio mais inteligente de gerenciar isso...

Usa Webmim mas dah uma idéia
http://www.conectiva.com/doc/livros/...03.html#N14B8C

Não gostei pq usa linuxconf (será que num vou achar algo na mão?)
http://www.inf.ufes.br/~proinfo/atividades/roteiro2.pdf

Esse tuto tah bem legal. Feito pra slack então eh na mão e dah pra ver tudo que tah acontecendo.
http://www.slacklife.com.br/article.php?sid=769

Acho que isso que vc quer.

Kra eh o seguinte para rede pura linux exprimente usar o Debian Sarge e o seu neto Kurumin....funfa muito bem....aki naum usamos NIS, usamos o LDAP mesmo com samba para máquinas ruindows e funciona legal...DEBIAN como serve LDAP e os demais estação...o melhor e que no diretório home do usuário vc pode usar o perfil mandatório...ai seu usário pode fazer o q quiser que no próximo logim fica igual como vc deixopu...MARAVILHA!!!

Se eu fosse montar uma rede com 20 PCs linux, eu faria 20 terminais burros, uma rede 100Mbps/gigabit e um servidor mais robustinho com um HD maior, e usando BOOTP. Assim tudo ficaria centralizado num lugar só. Home dirs, usuários, etc, tal, fulano e ciclano, mas não um compartilhamento NFS/samba como vocês estão levantando.

Não estou condenando, só estou falando o que eu acho que faria prá uma solução 100% linux num laboratório de informática.

Se o dono do tópico interessar, esse bootp é o seguinte: você coloca um sisteminha básico nos terminais burros (um disquete é o suficiente) para detectar a placa de rede na máquina e solicitar o bootp. Daí ele puxa o kernel e blahblah, em tempo real, do servidor, e monta as partições e tudo como se fosse local (só que via rede). Dá prá executar o X e tudo como se fosse no próprio servidor -- é como um Terminal Services do Windows.

cara, tenho uma rede com uns 30 pc's, uso NIS+NFS ( o nfs usa automouter, entaum so monta quando o usuário loga), a performance é muito boa, só dá problema quando o switch resolve pegar fogo :? , tudo em cima do slack 10.1 ( essa semana atualizo, eu acho). Facilita muito a administracao, e se as suas máquinas forem iguais ( ou mesmo um so um pouco parecidas), naum precisa instalar uma a uma. Use a clonagem (para fins terapeuticos...huahuahauhauah) com o G4U vc instala em uma máquina, configura como cliente de nis e nfs, testa, testa, testa.... e depois de ter certeza que tá tudo PERFEITO clona o hd para as outras.... muito mais fácil.... e também tem outros truques para administrar labortatórios....

Povu. Eu não sei se vcs leram o tópico todo mas o cara num tem um l;ab com 20 máquinas. Ele tem uma rede de 200 máquinas. Logo não deve ser máquinas iguais então num dah pra clonar. Outra coisa é que deve ter setores diferentes e logo sistemas diferentes rodando em cada setor.

Caímos num problema. Que server vc tem? Um servidor de arquivos pra guardar tantos homes e baixar os perfis vai ficar foda. Acredito que vc vá ter que fazer perfil local mesmo mas com autenticação via nis.

Vc deu uma olhada nos links que te passei? O que achou?

Ué, eu não tou conseguindo ler então, porque na primeira mensagem, tá assim ó:

Citação:

---

Postado originalmente por Edilmar

Tenho um laboratorio com 20 estacoes Linux e um servidor Linux.

---

Onde vi sobre 200 PCs primeiro, foi na mensagem

Citação:

---

Postado originalmente por Edilmar

e se tenho 200 estacoes, tenho que alterar o passwd das 200 estacoes.

---

E isso pareceu bastante com uma suposição. Repara na primeira: 'Tenho um laboratório...', e a segunda 'e se tenho 200 estacoes...'

:)
De qualquer forma acho que 200 disquetinhos nem ia ser tão complicado fazer assim... dava prá personalizar cada desktop compartilhado pelo sistema bootp... só ia ter que ser um puta HDzão, o que nem é mais tão difícil arrumar né... 2HDs de 250Gb já dava conta... 2,5Gb prá cada, só prá documentos e desktop. :) Sem contar os documentos compartilhados ou o banco de dados centralizado que ia ser um banquinho só...

Realmente daria pra fazer sim. Agora haja máquina pra rodar 200 clientes. HD eh o d-

O problema mesmo seria processamento e ainda teria o trafego na rede que aumentaria consideravelmente.

Ola pessoal,

Somente para esclarecer, no comeco da msg eu tinha 20 maquinas de um LAB mesmo. Mas o problema é maior, pois tenho tambem outras 180 maquinas de departamentos diferentes com sistemas diferentes. Portanto, clonagem nao seria muito bom.

Este mesmo ambiente eu ja tive ha alguns meses atras com Windows 2000 Server, e as estacoes Linux autenticavam neste servidor via Samba. Eu apenas troquei de Windows para Linux Server, por enqto.

Mas eu gostaria de conseguir com que o Linux na estacao tivesse o mesmo comportamento que teria com Windows na estacao. Ou seja, o cidadao logar somente na rede, sem necessidade de logon local. Tudo fica concentrado no servidor. O hardware do servidor ja funcionava bem com Windows 2000 atentendo os 200 clientes e cerca de 1000 usuarios, mas como decidimos migrar completamente para o Linux, entao gostaria de ter a mesma situacao de login que tinha antes.

Antes, bastava criar usuarios e pastar de usuarios no servidor, que as estacoes ao logar, com perfil mandatorio, pegavam o homedir em U:. Era tudo Windows... entao, imagine que agora estou fazendo um plano piloto com um laboratorio de 20 estacoes, mas depois vou ter que expandir para todas as estacoes. Por isso tenho esta preocupacao "de larga escala".

Quanto aos links:
1) NIS - Conectiva - Webmin: eu ja tenho instalado e configurado no servidor. Contudo, em cada estacao, tenho que colocar o +usuario, do jeito que esta explicado la. Portanto, se eu tiver um rodizio muito grande de usuarios (ahh, aqui é uma faculdade e tem alunos formando, outros calouros, etc) dar manutencao no passwd vai ser dureza... a nao ser que eu faca um programa que atualiza em todas as estacoes...
2) No 2o. link PDF achei estranho que ele usou o authconfig sem mexer no passwd da estacao. Eu tentei isso mas na hora que tento logar na estacao, ele da erro, dizendo que o usuario é invalido... e tambem na parte de NFS, ele montou o /home inteiro e nao o homedir especifico de cada usuario, como é o [homes] do SAMBA.
3) No 3o. link, nenhuma novidade em relacao ao 1o.

O principal é saber:
1) se tem como nao precisar manter o passwd das estacoes
2) se tem como exportar o homedir de cada usuario igual [homes] Samba

Agradeco desde ja a ajuda de todos!!!

Bom pessoal, pelo jeito, parece que a opcao de Samba Server + estacoes Linux é mais facil de configurar e mais concisa em larga escala mesmo, certo? Ja mexi de todo lado e ...

1) o NFS perde ponto para o [homes] unico do Samba
2) o NIS perde ponto para o smbpasswd centralizado do Samba

... entao parece que a solucao "pura" e "tradicional" do mundo UNIX/Linux NFS/NIS nao esta com a bola toda quando comparado com o Samba...

Dah uma olhada nesta solução.

http://www.unitednerds.org/thefallen...=LDAP-NSS_Ldap

Texto sobre openldap
http://geocities.yahoo.com.br/cesara...penldap-1.html

Eu ainda acho que a solução mais legal seria usar bootp. Mas daí todos os clientes teriam que ser linuxes também -- um disquetinho contendo o soft de bootp, reconhecimento da placa de rede + o endereço IP da máquina, que o resto ela pegaria tudo tudo do servidor.

Homedir, aplicativos, TUDO que o cara fizer vai estar dentro do servidor Linux principal. A máquina do cliente na verdade seria um 'terminal burro'. Mas o desktop dele poderia ser personalizado, de acordo com o nome de usuário e senha usado para logar quando o cliente tivesse inicializado.

Se os clientes têm que ser Windows, com word e tudo instalado no cliente mesmo... Aí acho que o que você procura é akele tal de Logon em domínio NT. Daí seria SAMBA com esses LDAPs da vida no servidor e o cliente configurado com domínio no servidor linux lá.

Mas re-reforçando: se puder ser TUDO linux, o lance é o boot remoto! :)
Só é bom que o servidor tenha um bom acesso a disco e que a rede seja pelo menos 100Mbps chaveada (hehe com switch) mesmo nos pontos de menor demanda. Possivelmente para ajudar, umas 4, 5 placas de rede no servidor para 'separar fisicamente' facetas da rede, distribuindo um pouco 100Mb (se for o caso) de acordo com a demanda (fazendo então um tráfego de 400, 500Mbps no servidor).

Citação:

---

Postado originalmente por Avenger

Eu ainda acho que a solução mais legal seria usar bootp. Mas daí todos os clientes teriam que ser linuxes também -- um disquetinho contendo o soft de bootp, reconhecimento da placa de rede + o endereço IP da máquina, que o resto ela pegaria tudo tudo do servidor.

Homedir, aplicativos, TUDO que o cara fizer vai estar dentro do servidor Linux principal. A máquina do cliente na verdade seria um 'terminal burro'. Mas o desktop dele poderia ser personalizado, de acordo com o nome de usuário e senha usado para logar quando o cliente tivesse inicializado.

Se os clientes têm que ser Windows, com word e tudo instalado no cliente mesmo... Aí acho que o que você procura é akele tal de Logon em domínio NT. Daí seria SAMBA com esses LDAPs da vida no servidor e o cliente configurado com domínio no servidor linux lá.

Mas re-reforçando: se puder ser TUDO linux, o lance é o boot remoto! :)
Só é bom que o servidor tenha um bom acesso a disco e que a rede seja pelo menos 100Mbps chaveada (hehe com switch) mesmo nos pontos de menor demanda. Possivelmente para ajudar, umas 4, 5 placas de rede no servidor para 'separar fisicamente' facetas da rede, distribuindo um pouco 100Mb (se for o caso) de acordo com a demanda (fazendo então um tráfego de 400, 500Mbps no servidor).

---

E que máquina vc aconselharia como server pra pendurar 200 clientes como terminais burros?

E ai eu acho que seria desperdicio das máquinas que ele já tem.

Bem... Ele já falou que tem um servidor lá que já 'abriga' esse pessoal com o windows. Como na verdade o overhead no servidor vai ser de transferência dos arquivos (o terminal burro vai ter que 'pensar' para carregar as janelas, processar o conteúdo das páginas bem como interpretar o próprio navegador e sistema X), então não creio que tenha que ser algo tão fora de lógica para aguentar. Só o tráfego de rede que pode ter um overhead maiorzinho. Nada que uma rede Gigabit não resolva.

No BootP, as coisas não vão fuincionar como o 'Terminal Services' ou um 'VNC', onde o servidor lá mostra a tela e só cospe o .bmp no outro terminal. O que vai acontecer é o 'terminal burro' montar a unidade remota em si. Então prá abrir o X, por exemplo, ele realmente 'baixa o binário' e 'executa localmente', não é como o terminal services, alocando, por exemplo, 64Mb para cada terminal. Tanto que, dependendo do vídeo que tiver no terminal burro, seja necessário ter a configuração e o modulo do vídeo corretamente configurado para aquele terminal. Um usuário para tal máquina, no servidor, com algo como '.xinitrc' no dir home seria a 'personalização a nível da estação cliente'.

Ia ser fundamental ter um usuário e um desktop (homedir, blahblah) prá cada um dos 200 clientes. Tudo só no servidor. Daí poderia ser feito 'esqueletos' para cada tipo de máquina que teria no meio dos 200 clientes... umas com sis620 outras com nvidia, só criar o usuário de acordo com os requisitos da máquina-cliente-terminal-burro... Acho realmente que ia ser uma idéia muito interessante o BootP.

O que achou agora que expliquei essas coisas? Ah! Até o cache do navegador fica separado a nível de usuário (pelo menos no netscape que já vi -- mas deve ter jeito de 'unificar' esse cache de navegador).

no NIS o sistema é centralizado assim como no samba, e vc so precisa exportar um diretório como home, o que torna uma EXCELENTE solucao para uma rede 100% unix ( o que inclui freeBSD, openBSD, netBSD, Tru64, SunOS, solaris.........) agora, como vc tem máquinas windows e naum vai migrar todas ao mesmo tempo ( pelo menos é o que eu entendi ) acho que seria realmente melhor para vc usar samba, colocando mais de uma máquina para controlar o domínio, de preferencia com sincronizacao entre elas, para manter uma copia de seguranca.

Citação:

---

Postado originalmente por Avenger

Bem... Ele já falou que tem um servidor lá que já 'abriga' esse pessoal com o windows. Como na verdade o overhead no servidor vai ser de transferência dos arquivos (o terminal burro vai ter que 'pensar' para carregar as janelas, processar o conteúdo das páginas bem como interpretar o próprio navegador e sistema X), então não creio que tenha que ser algo tão fora de lógica para aguentar. Só o tráfego de rede que pode ter um overhead maiorzinho. Nada que uma rede Gigabit não resolva.

No BootP, as coisas não vão fuincionar como o 'Terminal Services' ou um 'VNC', onde o servidor lá mostra a tela e só cospe o .bmp no outro terminal. O que vai acontecer é o 'terminal burro' montar a unidade remota em si. Então prá abrir o X, por exemplo, ele realmente 'baixa o binário' e 'executa localmente', não é como o terminal services, alocando, por exemplo, 64Mb para cada terminal. Tanto que, dependendo do vídeo que tiver no terminal burro, seja necessário ter a configuração e o modulo do vídeo corretamente configurado para aquele terminal. Um usuário para tal máquina, no servidor, com algo como '.xinitrc' no dir home seria a 'personalização a nível da estação cliente'.

Ia ser fundamental ter um usuário e um desktop (homedir, blahblah) prá cada um dos 200 clientes. Tudo só no servidor. Daí poderia ser feito 'esqueletos' para cada tipo de máquina que teria no meio dos 200 clientes... umas com sis620 outras com nvidia, só criar o usuário de acordo com os requisitos da máquina-cliente-terminal-burro... Acho realmente que ia ser uma idéia muito interessante o BootP.

O que achou agora que expliquei essas coisas? Ah! Até o cache do navegador fica separado a nível de usuário (pelo menos no netscape que já vi -- mas deve ter jeito de 'unificar' esse cache de navegador).

---

Entendi. Sendo assim só o chato seria mecher na extrutura da rede. Dependendo do tráfego que ele já tenha hoje se a rede num for giga realmente na hora que todo mundo ligar as máquinas vai demorar pra baixar tudu.

É, mas pelo que ele falou nunca vai todo mundo ao mesmo tempo (o que faz sentido: a probabilidade de 80% em uma amostra de 200 é bem menor do que a probabilidade de 90% em uma amostra de 10. Pelo menos é assim que funciona com clientes de provedor de internet. Quanto mais gente, menor a proporção de gente ligada por linha disponível.

Eu acredito que uma rede 100Mbps bem distribuidinha com switches legais vá dar conta do recado. Mas para a coisa ficar 'normal' mesmo durante os rushes, a gigabit, com fibra ótica de preferência, pelo menos entre os laboratórios e o servidor (não na estrutura interna dos laboratórios, onde sempre 100Mbps será suficiente para a méida de 20 máquinas por laboratório/seção), ia ser a solução para um possível congestionamento.

Continuando nossa "saga", ja que falou-se de BOOTP, o que voces acham do Linux Terminal Server para boot remoto, ou ate mesmo do FreeNX (que tem a mesma ideia do Windows Terminal Server). Sao boas alternativas tambem? Ou estas ferramentas continuam evoluindo a passos de tartaruga, e o unico estavel mesmo é o BOOTP?

Bem... Na verdade, eu defendo o bootp porque sei que ele vai ser uma solução pro seu problema.

Mas prá mim, idéia de terminal services, é a idéia de um programa que abre o desktop localmente, no servidor, alocando memória e tudo para isso, e cuspindo .bmp's na tela do computador remoto, fazendo o remoto ser um terminal mais 'burro' ainda. um leitor de .bmp. Hhe. Seguindo essa minha teoria do Terminal Services, o BootP seria melhor opção contra as equivalências Linux Terminal Services, pelo fato de por parte o processamento dos dados (abrir programas, etc) vai ser aplicado nos terminais remotos, deixando restar mais recursos para o servidor central, tendo claro, razoavel aumento na demanda de tráfego de rede ao custo de menor demanda de memória/processador no servidor.
Dessa forma, a meu ver, usando o BootP, o cliente vai ter uma demanda por banda do servidor para 'baixar' (ler) o aplicativo e as bibliotecas relacionadas, criar um cache na memória (que o linux faz normalmente), e só ler novamente mediante necessidade. Isso significa que quanto mais memória os clientes tiverem menor vai ser o uso de banda necessário. E por mais que não sejam dotadas de grande memória, no terminal services, para um desktop 'bonito', cada 'a' que você digitar tem que ter um tráfego de imagem, o que deixa 'constante' o tráfego do servidor->cliente. No caso do BootP, quando o programa 'carrega' o navegador, pode sair abrindo sites tanto quanto queira sem precisar ficar puxando dados de novo do servidor principal.

Bem, pelo menos eu não conheço sobre essas variantes terminal services em linux, não sei se essas funcionam exatamente como um 'vnc' ou como o terminal services do windows, onde cada desktop aloca '64Mb' de ram.
Se alguém que ler o Post aqui e vir que eu falei alguma besteira sobre o bootp ou terminal services, por favor corrija. Não tenho tanto embasamento, só um pouco de prática com os dois serviços. (um pouco MESMO)

No caso do Linux Terminal Service, acho que ele é bem parecido com o Bootp, pois ele foi projeto para boot remoto. So nao sei se a carga maior de processamento fica no cliente (como o bootp) ou no servidor.

Quanto ao Windows TS e FreeNX, atualmente eles sao MUITO melhores que VNC. Como voce disse, ao usar VNC, voce tem um processador de bmp. Mas no caso do WTS/FreeNX, eles nao mandam imagens para as estacoes, e sim uma chamada de funcao do SO para processar a operacao, algum muito mais "light". Com isso, ao teclar "a", ele nao manda o bmp novo com o "a" e sim uma chamada mais ou menos assim: "print(x,y,a)". Isso diminui muito o uso da banda de rede, e por isso esta sendo adotado largamente por empresas que usam links remotos de filiais lentos, com todo mundo acessando os sistemas online na matriz.

Então pelo que você me disse, o Terminal Services tem desvantagem quanto à latência da conexão (o ping alto). O 'lag' da rede é sentido 'na hora', enquanto no bootp, ele puxa os dados, mesmo com latência de 1000ms e na hora de você digitar 'a' no programa, você não vai conseguir notar o 'a' demorar a aparecer, o que aconteceria em qualquer instabilidade na rede do Terminal Services.
O que quero dizer com isso é que, ainda, o terminal services depende piamente de ficar a cada segundo mandando dados entre servidor e o cliente enquanto, no bootp, uma vez 'carregado' o programa, o cliente só vai fazer consulta de novo no servidor quando precisar abrir alguma janela em específico ou carregar algum 'PRUGIN do FRESH' por exemplo.
Ou seja:
- Por um lado, o Terminal services mantém sempre um tráfego de rede razoavelmente baixo, porém constante, entre servidor-cliente. Todo o processamento é centralizado no servidor (15 clientes abrindo o Netscape significam 15 netscapes abertos no servidor)
- Por outro lado, o cliente por BootP quando precisa carregar algo, dá um barrofo na rede para puxar logo o programa e, a partir de então ele -se vira- para fazer as tarefas do programa sem usar a rede, até que tenha que 'puxar' alguma parte do programa que não tenha sido usada ainda. Dependendo da memória do cliente, é possivel se fechar e abrir novamente o netscape com um uso mínimo de memória (ele só vai ter que ler os .conf por bootp). (15 clientes abrindo o Netscape significam 15 downloads dos binários/bibliotecas do netscape no servidor, uma vez só: 15 -usando- o netscape não significa -nada- para o servidor (hehehe).

Ainda acho que ia ser melhor 200 negos pendurados por bootp do que 200 negos pendurados por terminal services. :) Notem que estou procurando olhar o lado bom de um e do outro!.. Não é política do SIM ou do NÃO, não.
Mais lados BootP × TermSvs
Bootp: Afinal, 200 negos não iam ligar ao mesmo tempo o PC... ou iam? Bem... Ia ser um 'rush' das 08: às 08:30, uma lerdeza só. A partir de então, tudo devia ficar bem o resto do dia para todos... Ai! Tomara que a luz não vá embora! Mais meia-hora de instabilidade?.. Talvez.. Tem a gigabit prá isso, né!..
TermSVS: 200 Negos ligando o pc ao mesmo tempo... Hum... Não ia ser diferente isso às 08:00hs ou ao meio-dia... O dia inteiro seria do mesmo jeito. Se tiver ruim às 08hs da manhã, vai ficar mais ou menos assim às 3 da tarde.
Bem... Números: 64Mb para cada terminal (isso era no Windows Terminal Services), para 200 negos... tchung! 12Gb de RAM? tou certo? Acho que vai ter que atualizar placa-mãe do servidor prá aguentar tudo isso!..

Bootp: Caada máquina é bom que tenha seu próprio login/senha, ou então que o sistema seja tão amplo para suportar todo o tipo de hardware espalhado pela rede dos 200 PCs.. Acho que o jeito era fazer um login personalizado (só mechendo por exemplo nos drivers de vídeo do X e layout do teclado pros terminais). Ia tar tudo isso dentro do -servidor-.

TermSVS: Driver de vídeo? Não, o terminal services já manda tudo prá a interface que 'interpreta' nos clientes lá. O servidor terminal services só tem que 'abrir' os programas, 'alocar a memória' e mandar as coordenadas prá a tela dos PCs lá... Por outro lado... Se o cliente de lá der pau, tem que ir um técnico lá reinstalar o Windows... Nada diferente da situação que é agora. E aí? É um caos a rede cheia de Windowses? Muita instalação, aquela CPU que deu pau essa semana, tá difícil de achar o driver de vídeo?..

Me sinto por todos os lados defendendo o BootP a unhas e dentes. Mas eu realmente preferiria ter um trabalho para reunir as configurações dos terminais num lugar só... O que pode dar problema nos terminais(clientes) seria quebrar o disquete de bootp e ter que gerar outro, ou queimar uma placa de vídeo ou placa-mãe e ter que atualizar os módulos para aquele terminal. Atualizar os módulos lá no servidor mesmo e mandar o disquete com o bootp através de 'Moleco lá' prá alguém colocar no drive.

BootP daria um trabalhão implementar, mas uma vez funcionando seria uma beleza -- como tudo ia ficar num lugar só, não se esqueça de Fitas DAT ou DVD-RW prá fazer uns backups sérios do servidor!..

Espero que minhas abordagens dos dois lados tenha deixado margens a quem ler isso poder avaliar sobre o que prefere (terminal services ou bootp) sem que pareça o que eu mesmo tou convicto, de que tou defendendo a unhas e dentes o tal bootp.

Tá, grande vantagem do terminal services: vai rodar os programinhas do windows! (desde que seja servidor do windows terminal services, claro), mas não sei se no BootP algo impede do wine funcionar. Aqui na UFV tem uma rede, no BioAgro, de windows terminal services, são cerca de 5 computadores acessando um Windows TermSvs para poderem visualizar um programinha desenvolvido em VB. Funciona direitinho. Todos os clientes têm Windows 2000 Server instalado neles.