Boa tarde pessoal !

Como muitos sabem, ontem foi dia de lançamento da nova versão do OS X, sistema operacional da Apple para computadores Mac.
Esta versão, de codinome “Lion” foi bastante aguardada por suas novidades interessantes e integração/similaridade com o iOS, sistema para dispositivos móveis da empresa.

Não pretendo escrever um review sobre o Lion em si, porque já existem milhões espalhados pela internet. O objetivo do post é apenas apresentar as considerações deste que vos escreve, como as melhorias e problemas apresentados tanto no OS em si, quanto no processo de atualização.

Bom, comecemos pela primeira etapa, que é o download do arquivo. Vocês já devem saber que não existe forma de comprar o Lion em mídia física, restando como única opção a compra via App Store.
Tudo bem que hoje em dia é bastante comum termos conexões de banda larga, mas baixar quase 4Gb não é pra qualquer um. Eu, por exemplo, deixei meu Macbook Pro baixando durante toda a noite, e quando acordei o download havia sido concluído.

Eu havia decidido fazer uma instalação limpa, mas desisti. Não ando com tanto tempo disponível para formatar e reinstalar tudo o que tenho no meu laptop. Além disso, há menos de três meses atrás eu troquei de HD e reinstalei o sistema todo, obviamente. Resumo, estava com uma instalação relativamente limpa, e decidi fazer o upgrade de versão.

O processo todo levou praticamente uma hora. Eu imaginei que levaria menos, porque o contador de tempo restante acusou, num certo momento, que faltavam apenas 15 minutos para terminar. Uns dois minutos depois, ele deve ter pensado melhor e resolveu que faltava bem mais tempo – cerca de 30 minutos.

Instalação do OS X Lion

Após tudo devidamente atualizado, a surpresa foi encontrar mais de 700mb em atualizações no menu de atualizações do Mac. Coisa demais pra um sistema que estava completamente atualizado antes do upgrade – ou seja, muitos patches e versões mais novas de software já foram lançados, otimizados para o Lion. Claro que o download acabou levando mais algum tempo, mas exceto por este fato, é uma boa notícia ter recebido atualizações. Significa que temos desenvolvedores lançando programas melhores e mais compatíveis.

Logo no primeiro boot percebi a lerdeza no sistema – o culpado é o Spotlight, que estava reindexando o HD e abocanhou um percentual considerável da carga dos meus processadores.

Fui então testar os gestos novos de mouse, os recursos novos do trackpad e o que eu mais aguardava – o Mission Control. Todos os recursos me deixaram completamente satisfeito, como eu imaginava. Já havia assistido vídeos no Youtube e estes recursos acabaram sendo os fatores decisivos para que eu fizesse a atualização.

Os pontos negativos:

Bom, claro que nem tudo funcionaria de cara – este é o lado negativo de ser “early adopter”. Os itens que listarei aqui provavelmente terão conserto rápido, se é que já não existem updates ou remendos, e conforme eu for descobrindo, vou também atualizando o post.

- Problemas na montagem de dispositivos e partições NTFS
Logo após o término da instalação já notei que algo não tinha dado certo. Algumas mensagens de erro acerca do NTFS-3G foram exibidas na tela, e tanto minha partição com BootCamp, quanto meu HD externo não foram montados apropriadamente.

Mensagem de erro NTFS-3G

Atualização em 29/07/2011: As versões mais recentes do NTFS-3G e do Macfuse ainda não prestam suporte ao NTFS no Lion, porém um workaround foi criado por alguma boa alma.

Se você quiser apenas resolver o problema e fim de papo, instale este pacote aqui.
Por outro lado, se você mesmo quiser compilar o código-fonte, baixe-o clicando neste link e compile normalmente com:

./macfuse_buildtool.sh -t smalldist

- Incompatibilidade com o Visor e SIMBL (não sabe o que é isso?)
Este aqui resolvi rapidinho. O desenvolvedor do plugin Visor, que oferece um terminal no estilo “quake”, já lançou uma nova versão, que o torna compatível com o OS X recém lançado. Ele inclusive modificou o nome do programa, que agora atende por TotalTerminal. E ele continua opensource, ainda bem.

- Plugin de flash instável e pesado
Já bastante comentado na internet, ainda não teve solução. Dá pra viver muito bem sem ele durante alguns dias, porém (html5, favor dominar o mundo em breve, obrigado).

- Parallels Desktop, necessário atualização para funcionar
Portanto se você está usando aquela cópia do PirateBay, ou espera um pouco até lançarem uma versão que funcione, ou faz como eu e simplesmente atualize sua versão.

Atualização: Saiu a versão crackeada
Além disso, se você quiser manter sua versão atual, existe um workaround. Ele deixa sua VM sem a interface de rede, porém. Basta rodar no terminal do seu OSX a seguinte sequência de comandos:

sudo kextutil "/Library/Parallels/Parallels Service.app/Contents/Kexts/10.6/prl_hypervisor.kext"
sudo kextutil "/Library/Parallels/Parallels Service.app/Contents/Kexts/10.6/prl_hid_hook.kext"
sudo kextutil "/Library/Parallels/Parallels Service.app/Contents/Kexts/10.6/prl_usb_connect.kext"
sudo kextutil "/Library/Parallels/Parallels Service.app/Contents/Kexts/10.6/prl_netbridge.kext"
sudo kextutil "/Library/Parallels/Parallels Service.app/Contents/Kexts/10.6/prl_vnic.kext"

Programas que eu uso normalmente e que estão funcionando normalmente, até onde pude testar:

- Coda;
- Path Finder (dica do Augusto!);
- TextMate;
- Things;
- Toda a suíte de escritório da Microsoft;
- Toda a suíte de design e edição da Adobe (com ressalvas, mencionadas aqui);
- Evernote;
- Dropbox (vi relatos de pessoas com problemas, mas aqui funcionou);
- Skype, gTalk, Firefox, Chrome, Opera;

Resumo da ópera, por enquanto:

Vale a pena esperar uns dias ou semanas para atualizar. O update não trouxe nada maravilhosamente perfeito, apenas melhorias que, claro, foram completamente bem-vindas.
O ideal é aguardar que o pessoal da Apple e as empresas lancem versões de seus softwares já focando no Lion, para evitar dores de cabeça.

Para os aventureiros de plantão, porém, o update é bastante tranquilo. Vale a pena.

E não esqueçam: Fazer backups completos e atualizados de todo o conteúdo o seu HD é fundamental antes de atualizar a versão!

Espero atualizar em breve o post com saídas simples para os probleminhas que enfrentei. Quem resolver fazer a atualização e quiser contar suas experiências e problemas, por favor, compartilhe-as conosco !
Um abraço !
PS: Já se acostumaram com o scroll invertido do mouse ?

Característica número 2: Nós usamos vi, não emacs e definitivamente não pico ou nano
Todos sabemos que o emacs é muito querido por uma grande quantidade de administradores Unix, porém também sabemos que ele é o equivalente Unix ao Microsoft Word. O vi — e implicitamente o vim — é a verdadeira ferramenta para os geeks veteranos em Unix que precisam de agilidade nas suas tarefas, e não querem se preocupar com o monte de coisas estranhas que vêm junto com o Emacs. O Emacs possui um jogo de Tetris embutido, pelo amor de Deus.

Podemos admitir grunhindo que recursos do vim como “code folding” e destaque de sintaxe de várias linguagens pode ser considerado “fofo” por alguns, mas no final do dia, tarefas de verdade no Unix combinam muito bem com os conceitos de edição modal do vi. Além disso, seu pequeno tamanho e portabilidade universal o transformam na melhor escolha de editor de textos. Obrigado Bill, obrigado Bram.

Característica número 3: Nós empunhamos expressões regulares como armas
Para os leigos, mesmo o mais simples regex pode soar como digitação de bêbado. Para nós, porém, é a mais pura poesia. O poder representado na complexidade da pcre (Perl Compatible Regular Expressions) não pode ser vencido por outra ferramenta alguma.
Se você precisar substituir todos os terceiros caracteres num arquivo de 100.000 linhas, exceto quando ele é sucedido pelo número 4, as expressões regulares não são apenas uma forma de ter o trabalho feito – elas são a única forma de conseguir isto. Aqueles que se recusam a aprender regex fazem a si mesmos e seus colegas um desserviço diário.
Em todo grupo de usuários Unix de tamanho razoável você irá encontrar um ou dois “savants” em regex. Estes pobres coitados vivem recebendo sequencias de strings em seus emails, acompanhados por pedidos de regex para traduzí-las. Usualmente seguidos pela promessa de algumas cervejas, que nunca chegam a ser entregues.

Característica número 4: Somos inerentemente preguiçosos
Quando alguém nos apresenta um problema que envolve muito trabalho manual e repetitivo, nós Unix de antigamente sempre iremos optar por escrever algum trecho de código que dê conta do recado. Isto normalmente toma menos tempo do que a opção manual, mas nem sempre. Porém isto não importa, nós sempre preferimos gastar estes minutos e horas construindo algo que poderá ser utilizado depois, ao invés de simplesmente consertar o problema imediatamente. Normalmente, isto nos rende bons momentos quando nos deparamos com um problema semelhante ao anterior alguns anos depois, e então poderemos simplesmente arrancar algumas centenas de linhas de Perl do nosso home directory, resolver o problema em questão de minutos, e tornar a resolver algum outro código. Ou então podemos jogar Angry Birds por mais tempo.

Característica número 5: Nós preferimos soluções elegantes
Se existem diversas maneiras de consertar um problema ou alcançar uma meta, nós iremos optar por gastar mais tempo desenvolvendo uma solução que resolva o problema e previna que ele torne a acontecer, ao invés de simplesmente puxar o Band-Aid. Isto tem a ver com o fato de odiarmos voltar a um problema que já “marcamos como resolvido” em nossos cérebros. A moral da história é que, se podemos resolver um problema de uma vez por todas gastando um pouco mais de tempo hoje, o faremos, para que tenhamos menos dores de cabeça no futuro.

Característica número 6: Nós geralmente assumimos que o problema está com a pessoa que faz a pergunta
Atingir um certo nível de expertise em Unix é ser extremamente confiante nas suas habilidades e conhecimentos. Isto significa que nós nunca pensamos que um problema existe até que possamos vê-lo pessoalmente. Falar para um veterano em Unix que um arquivo “simplesmente sumiu” vai resultar em zombaria na certa. Prove para ele que aquilo realmente aconteceu, e você irá se deparar com alguém que irá mergulhar no problema incansávelmente, até que uma causa razoável e sua soluções sejam encontradas.
Muitos podem achar que isso é um sinal de arrogância ou prepotência. E é, mas nós temos este direito.

Característica número 7: Nós temos mais em comum com os médicos legistas do que com doutores
Quando lidamos com um problema muito grande, nós iremos gastar muito mais tempo no “pós-morte” do que com a solução do problema. A menos que a carga de trabalho absolutamente não nos permita gastar um tempinho com a investigação, nós precisamos saber a causa absoluta do problema. Não existe mágica no mundo do administrador hardcore de Unix; cada situação precisa partir de uma certa lógica e seguí-la nos moldes corretos. Ou seja, existe uma razão para tudo, e nós não vamos deixar pedra sobre pedra até a encontrarmos.

Para nós, é fácil estancar o sangramento mandando um HUP para um processo ou mudando permissões num arquivo ou diretório para 777, mas esta não é nem metade da história. Porque o processo precisou ser reiniciado ? Isto não deveria ser necessário normalmente, e nós precisamos saber o porque das coisas.

Característica número 8: Nós sabemos mais de Windows do que deixamos transparecer
Apesar de não rodarmos Windows nos nossos computadores pessoais, e parecer que não nos importamos nem um pouco com servidores Windows, nós somos geralmente bastante capazes de diagnosticar e consertar problemas neste sistema. Isto porque nós precisamos lidar com estes problemas quando eles ultrapassam os limites e caem no nosso território.
No entanto, nós geralmente não gostamos de demonstrar estas habilidades, porque o Windows não segue os mesmos fundamentos lógicos do Unix, e isto nos incomoda. Vide características 5 e 6 acima.

Característica número 9: Reinicializar o sistema quase nunca é a solução
Servidores Unix não precisam de reboot. A menos que não haja absolutamente nenhuma outra opção, nós preferimos gastar horas e horas consertando um problema com um sistema online e funcional, do que reinicializá-lo. A moral da história é que não existe razão para um reboot a menos que precisamos efetuar mudanças no hardware, ou existe alguma atualização para o kernel que estejamos rodando. Reinicializar o servidor é apenas uma saída temporária para o problema. Se ele aconteceu uma única vez e foi “consertado” por um reboot, pode apostar que irá acontecer novamente. Nós preferimos consertá-lo já do que simplesmente puxar a tomada e esperar pela próxima ocorrência.

Se algumas dessas características parecerem anti-sociais ou difíceis de serem entendidas a partir da perspectiva de um leigo, é porque elas são. Onde alguns enxergam métodos super complicados ou intratáveis, nós vemos o caminho certo, oriundo de anos de aprendizado, experiência e, acima de tudo, lógica.

####

Este texto não foi escrito por mim. O original, de autoria de Paul Venezia, em inglês, se encontra neste endereço, e honestamente, fica bem mais divertido no idioma original do que traduzido.

O que é ? Uma tabela enorme de comparação de comandos entre diferentes sistemas POSIX. Você inclusive pode filtrar quais deseja ver.

Se você, como eu, está super acostumado com Linux, Solaris e algum outro Unix, porém nunca viu um IRIX ou SCO na frente, este site é perfeito.
Olhem na screenshot um preview básico, com alguns diferentes UNIX selecionados por mim:

Fica aí a dica.

Abraços a todos.

Ontem foi dia de análise de alguns servidores da GM, especialmente os SOX, por estarmos próximos à outra auditoria.
Numa empresa grande como a HP, temos centenas de funcionários de suporte ao ambiente – Pessoas lidando com o sistema operacional, outros com banco de dados, alguns especialistas em ferramentas de monitoração, entre outros.

A menos que sua rede toda esteja rodando NIS ou LDAP (o que raramente acontece), você acaba tendo que criar todos estes ID’s nos servidores, e ao longo dos anos isso vira bagunça, se não for administrado corretamente.

Nessa revisão de ontem constatamos que possuíamos muita gente com acesso demais nos servidores. Isto é, com regras de sudo excessivas, pelo fato de serem membros de grupos desnecessários.

Tente administrar mais de 3.000 servidores e ir, de um por um, removendo os grupos de algumas dezenas de usuários. Complicado né ?
Foi com isso em vista que fiz um simples shell script, com a função de fazer algo que, na minha opinião, deveria ser um recurso nativo do Unix.As regras de sudo, num ambiente bem estruturado, são, em sua maioria, desenhadas para grupos – e então usuários adicionados aos grupos, dando-os permissões para a execução dos comandos como root.

Imaginemos então que o usuário torvalds é membro dos grupos admin, monitoracao e impressoras. E que nosso objetivo é retirá-lo do grupo admin, pois este grupo possui permissões para executar sudo su -.

Seria simples, não ?

usermod -g monitoracao -G impressoras torvalds

Porém agora considere o seguinte: O cara vai estar no grupo admin em todos os servidores, porém os grupos secundários dele são desconhecidos.
Além disso, você não pode conectar-se a cada servidor, grepando o /etc/group pelo ID dele, e montando um script para cada ocasião. Total perda de tempo, certo ?
Ah sim, mais um probleminha: Você vai rodar o script em Solaris, HP-UX, AIX e em alguns poucos servidores Linux. Portanto nada de comandos específicos.

Foi pensando nisso que eu criei um script simples, feio, mal-feito mas que funciona Usando apenas as ferramentas encontradas em todos os sabores de Unix, como sed, while-do, grep, cut, entre outros.
Ele automatiza a coisa, fantástico para uma ocasião como a minha, onde tenho em mãos uma ferramenta web que é capaz de rodar o script em todos os servidores ao mesmo tempo.

Enfim, sem mais delongas – Segue o script. Torço pro Google indexar isso logo e outros que passaram pelo mesmo problema que eu tenham uma solução mais prática:

# Entrar num diretório temporário:
mkdir –p /tmp/controlid && cd /tmp/controlid
# Pegar do /etc/group os grupos atuais do cara e jogar num arquivo temp:
grep torvalds /etc/group | cut -d: -f1 > currgroups
# Botar o output do comando anterior, todos na minha linha, separados por virgula:
while read line; do echo -n "$line,"; done < currgroups > currgroups2
# Tirar a porcaria da virgula que sobrou no final da string:
cat currgroups2 |sed 's/\(.*\)./\1/' > currgroups3
# Remover o grupo admin da lista acima. Troque a palavra admin abaixo pelo grupo que deseja remover.
cat currgroups3 | sed 's#,admin##g' > groups
# Atualizar os grupos do cara !
usermod -G `cat groups` torvalds

Sugestões de otimização para o script são sempre bem-vindas.

Um abraço a todos !