|
| Tenho varrido a Internet a procura de tutoriais de todo o tipo e tenho encontrado muita coisa boa! Várias vezes fui "salvo" por algum blog, site ou ftp, torrent, etc...
Mas, outro dia, tendo estado várias horas acompanhado de meu ex-coordenador na tarefa de solucionar um problema, discutindo com ele sobre a falta de método de muitos profissionais "atuais" (nós somos filhos do Netware+DOS, depois inseridos no *nix - e Macintosh, no meu caso) ocorreu-me que não lembro de ter encontrado um manual de "como resolver problemas de informática", mas somente tutoriais de "o quê" fazer.
Então resolvi narrar nosso dia de trabalho, como uma espécie de guia para muitos que têm zigue-zagueado diante de problemas até encontrar a solução.
Pensei em escrever um manual genérico, mas isso demandaria muitas horas de expressão literária, então resolvi fazer um esboço, narrando específicamente o caso com o qual nos deparamos e como o resolvemos. A análise dos procedimentos indicará um método, a saber:
O problema: Permitir que usuários Uindous(XP) navegassem na Internet através de proxy autenticado (squid) sem precisar informar usuário e senha e tendo um AD/Uindous-2003 como autenticador.
O recurso a ser usado: Há diversas formas de fazer isto, mas o cliente exigia que fosse usado o winbind, porque era assim que funcionava, antes;
Requisitos: Kerberos (padrão do AD), Samba/server como membro do domínio, Winbind para fazer a ligação.
Sistemas operacionais: Uindous 2003 contendo o AD; OpenSuse 10.3 contendo o Squid/winbind/samba/kerberos; Estações de trabalho UindousXP ou outras acessando a Internet via meta-frame;
Tudo pra ajudar! hehehe....
Começamos o trabalho procurando documentação sobre o assunto: Verificamos a documentação existente do próprio cliente, de outros clientes com soluções semelhantes, "guugou", sites: samba.org, squid-cache.org e support.novell.com [excelente hábito do meu ex-coordenador], aliás, foi neste último que encontramos o melhor passo-a-passo (em inglês, fique claro).
Montamos o laboratório: Utilizamos máquinas virtuais, pela facilidade e versatilidade (já tínhamos as imagens prontas, bastava copiar e sair alterando conforme a necessidade); Levantamos um AD, preparamos um XP cliente e começamos a instalar as coisas no OpenSuSE;
Até aqui, nada demais, mas é sempre bom reforçar a idéia de que JAMAIS se deve testar soluções no ambiente de produção!!! Sempre utilize máquinas virtuais ou estações isoladas da rede principal.
A diferença corre por conta dos recurso que os sistemas GNU/Linux proporcionam:
Como o *SuSE é um sistema meio temperamental, algumas coisas são mais fáceis de realizar através do Yast e foi por onde fomos, a diverença foi a seguinte:
Abrimos vários terminais virtuais no servidor; Num deles executamos o Yast, e em cada um dos outros, os seguintes comandos:
#tail -f /var/log/messages
#tail -f /var/log/squid/access.log
#tail -f /var/log/squid/log.cache.log
#tail -f /var/log/rcsquid.log
Ao mesmo tempo que íamos seguindo o passo-a-passo, íamos analisando as saídas de log. Isso nos permitiu encontrar várias mensagens de erro as quais iam sendo analisadas, submetidas ao "guugou" e pesquisadas nas páginas de manual do sistema;
Descobrimos que precisávamos mudar as permissões de acesso em determinados diretórios; que precisávamos levantar os serviços em determinada ordem;
Que era preciso inserir linhas específicas no arquivo smb.conf, squid.conf, krb5.conf, nsswich.conf, bem como outros arquivos correlatos.
Bem na real, não fomos tão metódicos, no início... mas preferi colocar nesta ordem para incutir em vossas mentes a linha correta de trabalho! :D
Não tínhamos aberto tantos terminais para monitorar os logs... monitorávamos alguns deles alternadamente... mas uma mania que tenho (demência de escovador de bits) deu o sinal: No meio dos processos do Yast, eu pressionava CTRL+Z para paralisar os processos e então listá-los com o "ps ax"... e algumas vezes eu ainda chamava o "bg" e continuava acompanhando os processos, depois voltava para o Yast digitando "%" na linha de comando.
Estas saídas aleatórias (motivadas, unicamente, pela inquietação de saber QUE PORRA ESSA MERDA(Yast) TÁ FAZENDO???) permitiram-me descobrir uma mensagem de erro que não aparecia quando se estava na interface do Yast! No caso, para ingressar no domínio do AD, é necessário que os relógios do candidato a membro do domínio (aqui, o SuSE) e do AD estejam sincronizados, o Yast tem uma opção para testar isso e ao executá-la, recebia-se mensagem de "tudo ok", porém, fora do Yast, percebi que antes das mensagens de OK, aparecia uma mensagem de falha na sincronização.
Foi preciso reconfigurar o serviço de NTP do SuSE e modificar alguma linha no smb.conf, bem como no krb5.conf para que tudo isso funcionasse perfeitamente. Só depois desta etapa é que conseguimos receber as novas mensagens de erro.
Cada decoberta e vitória era comemorada e ao mesmo tempo chocada com o fato de que já havíamos conseguido fazer cada uma delas no dia anterior, porém não havia funcionado no cliente! Era uma felicidade efêmera, porém nos motivava a seguir pelo desafio e pelo compromisso com o cliente!
É difícil dizer se um dois dois motivos é maior que o outro! Sou tentado a dizer que o desafio é o maior motivo - e o mais prazeroso -, mas em respeito aos clientes, não direi isso!
A grande questão é que nos dias anteriores eu e outros técnicos abordamos esta questão de forma meio conturbada por "n" motivos e situações o que nos permitiu obter sucesso em alguns aspéctos e insucesso em outros e, o pior de tudo, os insucessos foram encontrados no cliente!!! Nos laboratórios tudo funcionava!
A diferença foi, realmente, o método!!! Enquanto inúmeras ações anteriores não deixavam claro onde estávamos errando, o método passo-a-passo documentado, nos permitia ter certeza de onde estávamos acertando!!!!!!!! E a certeza do acerto, elimina o re-trabalho, elimina a dúvida, em última instância.
Assim, fomos dando um passo após o outro, sempre em frente, de forma decidida, séria e certeira.
Outro dia, se eu tiver tempo, reescreverei a idéia deste texto em formato de tutorial... uma espécie de algorítmo da solução de problemas [de informática].
Abraços!
| | |
| Há alguns anos venho defendendo a tese de que a Maicro$ofiti vai lançar um "linux";
Argumentei que a precariedade e o altíssimo custo da plataforma vêm empurrando as empresas para o mundo "GNU/Linux" e que muitas empresas, ainda hoje, estão presas à Maicro$ofiti por contratos bilionários, parques instalados gigantescos, aplicativos proprietários que só rodam naquela plataforma e porque os gerentes de tecnologia precisam ter alguém pra processar quando tudo falhar.
Assim, se fosse lançado um MS-Linux, muitas empresas o adotariam, mesmo que custasse a mesma coisa que hoje custam os Uindous, pelo simples fato de poder processar alguém caso hajam falhas.... ou porque as empresas "confiam" na Maicro$ofiti ou, simplesmente, porque esta versão de "linux" seria compatível com os aplicativos desenvolvidos para Uindous - ou, ainda, porque os contratos vigentes poderiam permitir a aquisição destes "linux" direto da Maicro$ofiti.
O outro fato é que o Wine se vale de força bruta para fazer aplicativos uindous rodarem no linux, já que a Maicro$ofiti não libera as especificações de bibliotecas para o pessoal trabalhar, mas a própria M$, conhecendo perfeitamente o funcionamento dos aplicativos, pode adaptar o Wine pra rodar todos os aplicativos do mundo M$ com perfeição.
Além disso, há diversos indícios de que eles estão tentando fazer o inverso (portar o *nix pra dentro do Uindous):
Primeiro, eles portaram o Cygwin pra dentro do Server2003 e posteriores, chamando de powershell ou sei-lá que nome deram.... (pelo menos é o que tudo indica, já que tu precisa recompilar os programas unix para rodarem ali dentro, tal e qual se faz com o cygwin);
Paralelo a isto, vemos coisas unixosas no UindousEneTe, como caminhos de arquivos assim: "winnt/system32/etc/hosts"...
Várias mensagens de erro das versões mais recentes de Uindous, trazem termos do mundo unix, agora não lembro de nenhuma, mas isso não faz diferença porque quem viu estas mensagens, percebeu, quem não viu, teria que acreditar em mim (ou não).....
E mais: A cada dia o desktop Uindous se parece mais com o KDE! O que pode ser uma estratégia da M$ para acostumar o seu usuário com a nova interface, gradualmente, minimizando os traumas da mudança.
A outra forte aposta é a M$ copiar a Apple, como sempre!!! Afinal, a Apple se rendeu ao mundo *nix, abandonou seu MacOS de sempre, adotou o Darwin e, apenas, colocou a interface Acqua em cima. O resultado é o sucesso do MacOS X (cujo X trata da versão 10, mas alude diretamente ao gerenciador gráfico X); A M$ vai fazer a mesma coisa.... vai adotar o GNU/Linux, ou mesmo o Darwin, vai colocar um KDE modificado mais parecido com o Uindous (e com o Explorer portado) e vai oferecer compatibilidade total com todos os aplicativos que existem para o mundo Uindous (e quem sabe, até para MacOS!).
O esquisito vai ser ver gente comprando um Maicro$ofiti GNU/Linux!
| | |
|
Anteriormente, eu coloquei um post aqui, ensinando como particionar um pendrive e gravar o GRUB nele, mas esqueci de mostrar como instalar um sistema operacional no mesmo.
Bem, há várias maneiras de fazer isso! Vou citar algumas, todas partindo do princípio que o pendrive está particionado como sugeri antes [veja o link para detalhes]:
1) Instalando o DSL no pendrive com duas partições -
Primeiro, baixe o Damm Small Linux aqui:
Depois, monte a imagem ISO com o seguinte comando:
#mount -t iso9660 -o loop dsl-4.2.5.iso /mnt/custom
depois copie todo o conteúdo do "cd" para a segunda partição do pendrive (que já vai conter uma pasta boot com o grub), que vou supor que está na unidade /dev/sdb:
#cp -Rv /mnt/custom/* /mnt/sdb2
em seguida edite o arquivo menu.lst:
#vim /mnt/sdb2/boot/grub/menu.lst
e adicione as seguintes linhas (copiei do próprio DSL, então não me responsabilizo pelas cores apresentadas:
color light-gray/blue black/light-gray
title *=*=*=*=*=*=*=*=*=*=*=*=* Pendrive *=*=*=*=*=*=*=*=*=*=*=*=*
root (hd0,1)
title Boot DSL 2.3!
kernel /boot/linux24 APPEND ramdisk_size=100000 init=/etc/init lang=us apm=power-off vga=791 nomce noapic quiet BOOT_IMAGE=knoppix
initrd=/boot/minirt24.gz
title Boot memtest86 memory tester!
kernel /boot/memtest86
Salve o arquivo com ":wq" e então reinicie o computador configurando a BIOS para iniciar pelo pendrive.
...Agora, preciso sair :D outro dia eu volto pra colocar outros métodos. Divirtam-se!
| | |
| Uma das coisas que dão um certo trabalho é descobrir qual placa é a eth0, eth1, eth....
Várias vezes a gente vai no método da tentativa e erro, plugando e desplugando o cabo... mas e se o cabo está inascessível, por exemplo, numa máquina remota?
Bem, depois de muito penar, acabei pedindo ao meu filho para resolver o problema pra mim... então o Vítor fez um script pra mim que descobre a placa.
Copie o texto, cole num arquivo e depois execute com:
#bash nethwinfo
Ou torne-o executável:
#chmod +x netwinfo
E depois execute-o:
#./netwinfo
Segue o script:
#!/bin/bash
# nethwinfo - Prints which card corresponds to which network interface.
# Written by Vítor De Araújo <huangho@ymail.com>.
# No copyright -- this program is in public domain.
# Version 0.0.1, 2008/09/18.
# Usage: nethwinfo <iface>...
error() { local quit=0; [[ $1 = -q ]] && { shift;quit=1;}; echo "$*" >&2; ((quit))&&exit 1; }
[[ $# -eq 0 ]] && error -q "Usage: nethwinfo <iface>..."
[[ -d /sys/class ]] || error -q "/sys/class not found. Try 'mount -t sysfs sysfs /sys'."
IFS=$' \n'
for iface; do
[[ -d /sys/class/net/$iface ]] || { error "$iface: No such interface."; continue; }
cd /sys/class/net/$iface/device/ 2>/dev/null || { error "$iface: Could not cd to device directory."; continue; }
vendor="$(<vendor)"; vendor="${vendor#0x}"
device="$(<device)"; device="${device#0x}"
svendor="$(<subsystem_vendor)"; svendor="${svendor#0x}"
sdevice="$(<subsystem_device)"; sdevice="${sdevice#0x}"
sed -n -e "
/^$vendor/,/^[0-9]/{
/^$vendor/p
/^\t$device/,/^\t[0-9]/{
/^\t$device/p
/^\t\t$svendor[[:space:]]*$sdevice/p
}
}
" </usr/share/misc/pci.ids
done
| | |
| Muito bem, depois de loooonga discussão com a Dell, por e-mails e telefone - e note que repassei o e-mail para quase dez pessoas diferentes, lá dentro -, finalmente, chegaram a um consenso e resolveram enviar-me a placa do bluetooth.
Realizei a compra no dia 19/07/2008 e em 29/08/2008 recebi a informação de que a placa estava sendo enviada, recebi poucos dias depois e precisei, eu mesmo, instalá-la no note (não foi difícil, graças a instruções que encontrei no site do fabricante).
Tentaram convencer-me de que não se tratava de venda-casada, mas que não entregavam o bluetooth porque não podiam dar garantia de funcionamento sem o sistema operacional.
Mas e eles dão garantia para os demais itens, como a placa wireless bcm4310 (Broadcom) que não tem drive para linux???
Blá,blá,blá... pois eles têm que dar garantia de que o hardware funciona, simplesmente, se eu não conseguir configurá-lo no meu sistema, problema é meu.
E se eu quisesse o note pra usar DOS? Ou, ainda, já que a máquina vem com o FreeDOS, eles garantem que o wireless e outros dispositivos vão funcionar no FreeDOS?
Acho que outras pessoas deveriam pressioná-los para mudarem a página e passarem a permitir a compra de qualquer hardware com ou sem sistema operacional.
Ando atarefado demais, mas vou me informar melhor sobre esse caso... | | |
|
