Sampayu

Essas informações do seu navegador significam que o único plugin Java instalado no seu navegador é o libnpjp2.so versão 1.7.0_21. Ocorre que, uma vez detectado pelo navegador, o plugin Sun Java informa ao navegador quais são os tipos e versões MIME que ele é capaz de manipular. No caso do plugin Sun Java, os tipos e versões MIME incluem versões antigas da Sun JVM (Máquina Virtual Java da Sun), como é o caso dos applets Java escritos para Sun JVM versões 1.1 e 1.2 (entre outras) e das classes JavaBeans escritas para Sun JVM versões 1.1 e 1.2 (entre outras). Se você não entendeu direito o que eu escrevi aí em cima, relaxa: o importante é entender que a mensagem acima refere-se a apenas um plugin Sun Java que está informando qual é a versão dele e quais tipos de conteúdo ele é capaz de executar, dentro do navegador. __________ Adendo: se quiser entender melhor o que o seu navegador quis dizer, vai ser necessário você estudar alguns conceitos. Caso tenha interesse, os conceitos a serem estudados são estes: Tipos MIME. O que é um plugin. NPAPI - uma arquitetura de software que permite que você instale plugins dentro de um navegador (em qualquer sistema operacional) e então execute esses plugins ou dentro da janela do navegador ou dentro da página que está carregada dentro da janela do navegador. Os principais navegadores modernos (como o Firefox, o Chrome e o Chromium) são navegadores NPAPI, e é por isto que neles você consegue instalar plugins, extensões e complementos. Extensões e complementos geralmente são instalados na janela do navegador e modificam o menu, instalam uma barra de ferramentas ou realizam alguma outra alteração na interface do navegador. Já os plugins geralmente são executados dentro de páginas: é o caso do teclado virtual do banco, que é carregado pelo plugin dentro da página do banco, e é também o caso dos vídeos do YouTube, que são carregados pelo plugin AdoBe Flash dentro de uma página do YouTube aberta no navegador. Se os navegadores contemporâneos não fossem NPAPI, eles não conseguiriam executar os plugins, os complementos e as extensões que nós instalamos. Um Applet é um aplicativo em miniatura. Aplicativos são programas capazes de "conversar" diretamente com o sistema operacional, por isto são independentes: você executa o aplicativo e ele já carrega tudo o que ele precisa para funcionar e agir como um intermediário entre você e o sistema operacional do seu PC. Os navegadores web são aplicativos, por exemplo. Mas applets não são independentes: eles precisam ser executados dentro de um aplicativo "maior", que por isto recebe o nome de container ("aquele que contém ou hospeda o applet"). O plugin Sun Java é um container para applets Java. O teclado virtual do banco é um applet Java (um applet escrito em linguagem Java). Para funcionar, o applet Java precisa ser executado dentro de um container, que no caso é o plugin Java. Como a maioria dos bancos escreve o applet do teclado virtual para ser executado especificamente dentro do plugin Java da Sun/Oracle, a gente costuma ter problemas quando tenta carregar o applet Java do teclado virtual dentro de outro container, como é o caso do plugin IcedTea. O conceito computacional de objeto é abstrato, mas, grosso modo, pode-se dizer que objetos são os botões e outros objetos que você vê na interface gráfica dos programas, e também cada uma das funções que cada objeto executa. Uma classe é, grosso modo, uma coleção de objetos. Um Java Bean é um tipo especial de classe que contém somente objetos escritos em linguagem Java. Depois que você entender os conceitos acima, vai compreender que aquela lista que você viu no seu navegador está mostrando que o plugin Sun Java está instalado no seu navegador NPAPI, e que por isto o seu navegador NPAPI está lhe informando que o plugin Sun Java é um container capaz de executar diversos applets escritos em linguagem Java, e também é capaz de utilizar diversas classes de JavaBeans durante a execução dos tais applets. Aquelas versões que aparecem no lado direito significam que o plugin é capaz de executar applets e classes JavaBeans que tenham sido escritos para diferentes versões da Sun JVM (Máquina Virtual Java da Sun), inclusive versões 1.1, 1.2 e 1.5 (entre outras). Repare, por exemplo, que no final o navegador informa: application/x-java-applet;version=1.7 Java™ Plug-in application/x-java-bean;version=1.7 Java™ Plug-in Isto significa que o plugin Sun Java libnpjp2.so, versão 1.7.0_21, é capaz de executar applets que tenham sido escritos para uma Sun JVM da versão 1.7 (que é a que está instalada no seu sistema, dentro de /opt/java/jre). As classes JavaBeans escritas para uma Sun JVM da versão 1.7 também poderão ser carregadas, nesse plugin. Enfim: o navegador informa que o plugin é versátil, então mesmo que você entre num website antigo, contendo um applet que tenha sido criado na época em que o Java da Sun ainda estava na versão 1.1, o plugin será capaz de executar o tal applet, porque isto consta na linha application/x-java-applet;version=1.1 Java™ Plug-in Cada uma daquelas linhas é identificada pelo navegador como sendo um tipo MIME diferente. Mas todos eles apontam para o mesmo lugar: o plugin Sun Java 1.7.0_21 (arquivo libnpjp2.so armazenado em /opt/java/jre/lib/amd64, no caso do seu sistema de 64 bits). Se você teve paciência para ler tudo até aqui, acredito que agora tudo esteja mais claro (ou não, rs ).

Então... "Qual Java usar" é uma questão de foro íntimo, gosto pessoal. No meu caso, prefiro o Java da Sun mesmo, porque em muitos websites (inclusive de bancos) só o Java da Sun funciona (ou funciona direito). A minha escolha é o Java da Sun porque não gosto de ter estresse com outros JRE, como é o caso do OpenJDK e do GIJ/GCJ, que, pelas mensagens que você postou, são os dois JRE que você tem aí no seu sistema, e esses JRE são bons mas não são tão compatíveis quanto o da Sun. Então, na minha opinião, o melhor mesmo seria deixar o Java da Sun instalado e definido como o padrão do sistema. Eu não sei se é uma boa ideia você excluir todos os JRE, talvez alguns componentes da sua distribuição usem esses JRE que são instalados (estou só especulando). O que sei é que não é necessário excluí-los para que o Sun Java funcione. Mas, se você quiser mesmo deixar só o JRE da Sun instalado e excluir os demais, no parágrafo a seguir vou começar a explicar como fazer isso. Infelizmente, não tenho como fazer simulações e testes com o Linux de 64 bits, porque meu PC só tem Linux de 32 bits e o hardware dele é muito "velhão", não aguenta Linux de 64 bits (nem por VirtualBox nem por LiveCD). Mas espero que as dicas a seguir funcionem. O primeiro passo é entrar no Synaptic e procurar aqueles pacotes que você viu no terminal. Caso ainda não tenha o Synaptic instalado, execute o comando sudo apt-get install synaptic e então execute o Synaptic a partir do menu (está em Sistema / Gerenciador de pacotes Synaptic). Para executar o Synaptic pelo terminal, basta executar o comando sudo synaptic & Na interface do Synaptic, você vai clicar naquele campo "Filtro rápido" e começar a digitar os nomes dos JRE que quer excluir. Primeiro digite openjdk. Repare que aparecerão vários pacotes contendo a palavra openjdk. Os que estiverem com a caixa de verificação marcada à esquerda são os pacotes que atualmente estão instalados. Clique no cabeçalho da primeira coluna da esquerda (aquela que exibe as caixas que estão marcadas e as que não estão marcadas), para que a coluna reclassifique os pacotes exibindo no topo os que estão instalados (caixa marcada). Agora clique com o botão direito do mouse sobre cada um dos pacotes que possua a palavra openjdk ou a palavra icedtea e selecione a opção Marcar para remoção completa. Retorne ao campo "Filtro rápido" e substitua a palavra openjdk pela palavra icedtea. Marque para remoção completa os pacotes remanescentes do IcedTea. Ainda no campo "Filtro rápido", repita o procedimento com as palavras netx, gcj e gij, para marcar para remoção completa todos os pacotes do GCJ/GIJ e do NetX. Todos esses pacotes são JRE "alternativos", de código livre. Agora que você marcou todos os pacotes para remoção completa, clique no botão Aplicar. Todos aqueles pacotes serão removidos. Não se preocupe: se futuramente você quiser reinstalar algum ou alguns daqueles pacotes, retorne ao Synaptic, vá em Arquivo/Histórico e clique na data em que você removeu os pacotes. Os nomes deles serão mostrados. Agora que você removeu todos os pacotes JRE de código livre, precisamos nos certificar de que você removeu manualmente o Sun Java. Para isto, é só executar o comando sudo rm -rf /opt/java que consta no passo 2.1 do tutorial. Por fim, mas não menos importante, é preciso informar ao update-alternatives que você removeu todos os JRE do seu sistema. Para fazer isto, basta executar o comando sudo update-alternatives --remove-all java Pronto! Agora o seu sistema está limpo! Agora que a faxina está concluída, basta seguir os passos da seção 1 do tutorial para instalar manualmente o Java da Sun. Se após executar os passos da seção 1 o seu navegador continuar não detectando o Java da Sun, execute os comandos sudo mkdir -p /etc/.java/.systemPrefs e sudo chmod 755 -R /etc/.java que são melhor explicados na seção 4 do tutorial. Após isto, o Java deverá estar funcionando no seu sistema. Caso algum problema persista, será provavelmente com o navegador Chrome. Neste caso, vá em chrome://plugins e marque aquela caixa "Sempre permitido". Além disto, experimente executar o Chrome/Chromium em modo de compatibilidade com plugins antigos (vide a dica sobre o --allow-outdated-plugins, na seção 4 do tutorial). Se os caminhos realmente existirem, então o Java tem que funcionar aí. Se o seu navegador exibir uma mensagem informando que o Java está desatualizado, ignore: é o bug que eu relato na seção 4 do tutorial. Se aparecer alguma janela informando que não é seguro executar o Java, ou que existem riscos envolvidos blá blá blá e a janela estiver com botões de autorização (tipo bloquear/desbloquear ou permitir/não permitir, por exemplo), sempre autorize/permita/desbloqueie, senão o Sun Java evidentemente não vai ser executado, no seu navegador. Ufa! Eu sempre escrevo muito, putz... Espero que este monte de texto tenha servido para resolver o problema. Aguardo um retorno seu informando se deu certo ou se o problema continua.

Devido a uma falha de conexão enquanto eu estava salvando algumas alterações que havia feito no tutorial, perdi praticamente todo o texto. Mas recuperei o conteúdo e aproveitei para incluir os comandos para Linux de 64 bits. Agora está normalizado.

Oi, André. Só me tira uma dúvida: seu sistema é de 32 ou de 64 bits? O ideal seria você instalar um JRE da mesma arquitetura do seu sistema. Vamos por partes: O primeiro passo é o usuário saber se ele está em um Linux de 32 ou de 64 bits. A maioria sabe, mas, em caso de dúvida, basta executar o comando uname -a e ver se a palavra i386 ou a palavra amd64 aparece no resultado do comando. Se aparecer a palavra i386 (também pode ser i486, i586, i686 etc.), então o sistema é de 32 bits. Se aparecer amd64, o sistema é de 64 bits (ou seja, foi escrito para um hardware da arquitetura AMD64, também conhecida como X64 ou x86-64). Se o sistema for de 32 bits, é só seguir os passos do tutorial. Se o sistema for de 64 bits, deverá ser feito o download do Java para 64 bits, e neste caso os passos 1.1 e 1.2 do tutorial farão o plugin ser instalado em /opt/java/jre/lib/amd64/libnpjp2.so (isto afeta os passos 1.6, 1.7 e 1.10 do tutorial, pois o usuário terá que substituir o i386 por amd64). Também será necessário verificar a localização dos navegadores, que em um sistema de 64 bits pode ser diferente (estou só especulando). Eu infelizmente não disponho de equipamento para poder realizar testes em distribuições GNU/Linux de 64 bits. Quanto à libc6, existem duas versões que nos interessam: o pacote libc6, que é para sistemas de 32 bits (a biblioteca libc6-i386 deixou de existir, foi substituída pela libc6, por isto o comando apt-get install libc6-i386 atualmente redireciona para a instalação do pacote libc6), e o pacote libc6-amd64, que é para sistemas de 64 bits. Por padrão, os sistemas GNU/Linux de 32 bits já vêm com a biblioteca libc6 pré-instalada e os de 64 bits já vêm com a libc6-amd64 pré-instalada, porque a libc6 é utilizada em uma infinidade de situações. É de se esperar que o apt-get retorne um erro, caso o usuário tente instalar uma libc6 da mesma arquitetura do sistema, porque a priori a libc6 já estará instalada. Mas se o usuário tentar instalar a libc6-amd64 num sistema de 32 bits (ou caso tente instalar a libc6 num sistema de 64 bits), o sistema instalará, embora na prática isto não terá utilidade nenhuma, apenas ocupará espaço físico no HD. De acordo com o seu texto, o que eu entendi foi que você está num sistema de 64 bits, mas instalou um JRE de 32 bits e, para fazê-lo funcionar, instalou a biblioteca libc6, que é de 32 bits. Se foi mesmo isto que aconteceu, a minha sugestão é que você: Desinstale esse JRE de 32 bits (seção 2 do tutorial). Em seguida, use o comando sudo apt-get remove libc6 libc6-i386 para remover o pacote libc6 e o metapacote libc6-i386. Em seguida, instale o pacote libc6-amd64 com o comando sudo apt-get install libc6-amd64 Caso o sistema informe que o pacote libc6-amd64 já existe, reinstale aquela biblioteca executando o comando sudo apt-get install libc6-amd64 --reinstall Agora faça download do Sun/Oracle JRE para 64 bits e instale-o com o supercomando sudo mkdir /opt/java && sudo mv ~/Downloads/jre-7u21-linux-x64.tar.gz /opt/java && cd /opt/java && sudo chmod a+x jre-7u21-linux-x64.tar.gz && sudo tar -xvf jre-7u21-linux-x64.tar.gz && sudo mv ./jre1* ./jre && sudo rm -f ./jre-*.tar.gz Execute os passos 1.3 e 1.4. Execute o passo 1.5 antes verificando se as pastas dos seus navegadores são mesmo aquelas que constam no passo 1.5. Execute o passo 1.6, exceto que o plugin deverá ser procurado no caminho /opt/java/jre/lib/amd64/libnpjp2.so Execute o passo 1.7 substituindo o i386 por amd64 Execute os passos 1.8 e 1.9. Execute o passo 1.10, mas repare que, se ocorrer algum problema e você precisar usar aqueles comandos que estão no final do passo 1.10, primeiro substitua o i386 por amd64 e substitua também os caminhos dos navegadores pelos caminhos corretos. Era isso (ufa!).

Oi de novo. Nos últimos 12 meses (aproximadamente), vários artigos especializados em T.I. têm apontado falhas de segurança encontradas no JRE da Sun/Oracle. Algumas dessas falhas afetam também as implementações livres (tais como o JRE OpenJDK e o JRE GIJ), outras afetam apenas o JRE da Sun/Oracle. Por conta disto, os desenvolvedores dos navegadores web têm inserido mecanismos que alertam o usuário a respeito dos riscos de se utilizar o Java. Os navegadores não chegam a impedir a utilização do Java, mas avisam que há riscos envolvidos. Só que a gente precisa do Sun/Oracle, porque (por exemplo) os nossos bancos utilizam applets Java que em muitos casos só funcionam com o JRE da Sun/Oracle. Então o negócio é instalar o Java, mas ser cauteloso: só autorizar a execução do Java plugin quando o applet que estiver solicitando isto for de um website confiável (como é o caso do website do seu banco, por exemplo). Junte-se a isso aquele bug de compatibilidade do Sun Java com os navegadores, e o resultado é que você vai ver 2 tipos de mensagens aparecerem em seus navegadores: Avisos de plugin desatualizado (por conta do "bug da falta de diálogo" entre o Java e os navegadores); e Avisos de segurança (que iriam aparecer mesmo que o bug acima não existisse, porque os navegadores estão mesmo alertando os usuários a respeito dos riscos de se usar o Java). Em outras palavras: você não cometeu nenhum erro na instalação, pois se tivesse cometido o Java não estaria funcionando. Se você seguiu todos os passos da seção 1 do tutorial (e inclusive verificou a versão do Java com o comando java -version e acessando a página de testes da Sun e, nos dois casos, a resposta obtida foi que seu Java está instalado e é o 7u21), então com certeza o problema está é naquele bug de versão e nos inevitáveis alertas de segurança que os navegadores estão emitindo. A solução para esse problema é, na verdade, um paliativo (que você aliás já vem executando): se você estiver em um website no qual você confia, então sempre clique em Executar esta vez e jamais bloqueie a execução do applet Java, quando o navegador perguntar se você deseja bloquear ou não o applet que está sendo carregado pelo website. No caso tanto do Chrome quanto do Chromium, você poderá executar o navegador a partir do terminal do shell, para poder incluir a opção --allow-outdated-plugins e com isto não ter que ficar toda hora clicando em Executar esta vez. Já o Firefox não possui este tipo de recurso, portanto o jeito é ficar clicando no botão Executar esta vez... Daqui a pouco a equipe do Google atualiza o Chrome e o Chromium (ou a equipe da Sun/Oracle lança uma nova atualização para o Java) e daí o bug some! Isso já aconteceu antes, rs. Quanto aos alertas de segurança, a tendência é eles continuarem sendo exibidos pelos navegadores, até que a Sun/Oracle reconquiste a confiabilidade perdida e daí os desenvolvedores dos navegadores sintam-se suficientemente seguros para remover os alertas de segurança, nas próximas versões dos navegadores deles.

Oi, baisse. Resumidamente: sim, pode executar tranquilamente o passo 1.3. O comando de remoção que você executou é (mais do que) suficiente para você poder executar o passo 1.3 sem ter estresse. Agora vou lhe dar a explicação que eu gostaria que alguém tivesse me dado quando eu entrei em contato pela primeira vez com o comando update-alternatives e não fazia ideia do que diabos era isso (e tive que me virar para entender o que é e como funciona, porque não encontrei explicações suficientemente didáticas, na internet e nos fóruns): o comando update-alternatives serve para que você possa instalar, em seu sistema, várias versões (ou implementações) diferentes de um mesmo programa, mantidas ou não pelo mesmo desenvolvedor, e então alternar entre essas versões e/ou implementações. As diferentes versões e implementações são instaladas em diversas pastas diferentes, mas daí você usa o update-alternatives para criar uma "lista" dessas versões e implementações que você possui e então definir qual delas será a "padrão" que o seu sistema vai usar. Daí, sempre que você quiser usar uma outra versão ou implementação, basta executar o update-alternatives e informar qual versão ou implementação você deseja que passe a ser a "padrão" do sistema. Você pode fazer isso ou de forma interativa, usando o comando update-alternatives --config apelido, ou então de forma não-interativa, usando o comando update-alternatives --set apelido caminho. No caso, apelido é o apelido que você atribuiu a esse "grupo de versões e implementações de um mesmo programa" e caminho é o local em que está a versão ou implementação que você deseja que passe a ser o novo padrão do seu sistema. No caso dos JRE, o update-alternatives permite, por exemplo, alternar entre diferentes versões do Oracle JRE (6u20, 7u10, 7u21 etc.) que estejam presentes no seu sistema, ou ainda alternar entre diferentes implementações do JRE, como por exemplo o OpenJDK (uma implementação livre do Java) e o GIJ (outra implementação livre do Java). Repare que, no caso dos JRE do seu sistema, esse grupo de JRE recebeu o apelido java. Exemplo: o comando interativo update-alternatives --config java exibirá a lista de JRE cadastrados no grupo java e pedirá para você escolher na lista qual deles você quer que se torne o JRE padrão. Já o comando não-interativo update-alternatives --set java /opt/java/jre/bin/java faz com que o JRE padrão do seu sistema passe a ser aquele que se encontra em /opt/java/jre/bin/java. O update-alternatives faz isso basicamente modificando o link que aponta para o JRE padrão. O arquivo /usr/bin/java é apenas um link simbólico: você instala "um monte de JRE", em várias pastas diferentes, mas o update-alternatives faz com que o seu Linux sempre considere que o Java está instalado em /usr/bin/java, daí o /usr/bin/java redireciona o seu sistema para a pasta que você definiu como padrão (que pode ser a pasta do Oracle JRE 7, pode ser a do OpenJDK ou alguma outra). Além do JRE 7 da Sun/Oracle, você provavelmente tem aí no seu sistema o OpenJDK, e talvez também tenha o GIJ (GNU Interpreter for Java), que recentemente passou a ser instalado junto com as últimas atualizações de algumas distribuições Linux (como é o caso da Ubuntu). Exemplo: aqui no meu XUbuntu 12.04 de 32 bits, há cerca de 1 mês o GIJ versão 4.6 foi instalado em /usr/bin/gij-4.6. Ocorre que aquele comando sudo update-alternatives --remove-all java que você executou remove todos os vínculos para todos os JRE do seu sistema, portanto é um comando bem radical. Veja bem: ele não remove os JRE, mas remove as ligações para eles. É como se eles tivessem sido descadastrados da "lista de JRE", embora esses JRE continuem presentes no seu sistema. Por isto, seu sistema Linux "deixou de saber" que aqueles JRE estão presentes e qual é a localização deles. Se (por exemplo) você tiver aí o OpenJDK e o GIJ (além do Oracle que você instalou), então você possui aí três JRE instalados, mas o seu Linux já não "sabe" mais isso. Você poderia ter simplesmente executado este comando, no terminal: sudo update-alternatives --remove java /usr/lib/jvm/java-7-oracle/bin/java O comando acima significa "remova do grupo java o JRE que se encontra em /usr/lib/jvm/java-7-oracle/bin/java", ou seja, ele removeria apenas o vínculo para o JRE que você possui em /usr/lib/jvm/java-7-oracle/bin/java: os demais vínculos (para o OpenJDK e o GIJ, por exemplo) seriam preservados. Mas tudo bem, você fez uma limpeza geral nos vínculos e excluiu o grupo java. Isto não chega a ser um problema, caso a sua intenção seja usar apenas o JRE da Sun/Oracle. O comando do item 1.3 do tutorial irá recriar o grupo java e incluir na lista o Sun/Oracle java que você puser em /opt/java/jre. Mas não se esqueça de que você excluiu apenas os vínculos. Ficou faltando excluir a pasta do Oracle Java que você havia instalado em /usr/lib/jvm/java-7-oracle. Para excluí-la, execute este comando, no terminal: sudo rm -rf /usr/lib/jvm/java-7-oracle Após excluir a pasta java-7-oracle, execute normalmente os passos da seção 1 do tutorial. Após instalar o Sun Java, você pode querer tentar recuperar seus JRE "alternativos". Caso esteja em um Ubuntu de 32 bits, procure seus JRE nestes locais: OpenJDK: /usr/lib/jvm/java-6-openjdk-i386/jre/bin/java GIJ: /usr/bin/gij-4.6 Para adicioná-los à "lista dos JRE", os comandos são estes: Adicionar o OpenJDK com prioridade 11 (número maior que o da prioridade 10 usada no item 1.3 do tutorial): sudo update-alternatives --install /usr/bin/java java /usr/lib/jvm/java-6-openjdk-i386/jre/bin/java 11 Adicionar o GIJ com prioridade 12 (número maior que o das prioridades 10 e 11, assinaladas respectivamente para o Sun Java e para o OpenJDK): sudo update-alternatives --install /usr/bin/java java /usr/bin/gij-4.6 12 Como no item 1.3 do tutorial você executou o comando update-alternatives --set java /opt/java/jre/bin/java, o JRE padrão continuará sendo o que se encontra em /opt/java/jre/bin/java (daí a "sacada" de sempre instalar o Sun Java naquela pasta "jre": quando você instala numa pasta que tem o nome da versão, como por exemplo "jre-7u21", você fica limitado, porque teria que ficar executando o update-alternatives para atualizar a lista do grupo java, sempre que você instalasse um novo JRE, em uma pasta com nome diferente, como por exemplo "jre-7u22", "jre-7u23" etc.). Por fim, mas não menos importante: aqui em casa o Google Chrome voltou a dar pane de versão com o Java (estou executando o Sun Java versão 7, atualização 21). Se isto acontecer com você, ignore: é um bug antigo, que inclusive já foi solucionado pelo time do Google, mas que de tempos em tempos retorna (veja a seção 4 do tutorial), provavelmente porque o pessoal da Sun/Oracle desenvolve uma nova versão do Java mas não a testa em todos os navegadores (ou a equipe do Google desenvolve uma nova versão do navegador Chrome mas não a testa com todos os plugins, como por exemplo o Sun Java). Por isto, o navegador Chrome talvez lhe diga que o plugin Java está desatualizado, mesmo após você instalar a última (a mais recente) versão do Sun Java. Simplesmente clique em "Executar esta vez" e prossiga. Se o botão aparecer de novo, clique de novo em "Executar esta vez". Se perder a paciência, execute o --allow-outdated-plugins que eu explico lá na seção 4. Era isso. Agora vou dormir, rs.

jalomfarias, por nada, é sempre um prazer saber que o tutorial está ajudando outras pessoas a resolverem esse problema chato que ocorre com o Java no Linux. Abraço.

Oi, André. Filosoficamente falando, nada é 100% seguro. Mas, com base no que já li sobre essa questão dos bugs (defeitos internos) e exploits (falhas de segurança que podem ser exploradas por terceiros) do plugin Java, é "seguro dizer" que o plugin Java pode ser suficientemente seguro, desde que: Você continue usando sempre (e somente) a última (a mais atual) versão do Sun/Oracle Java. O exploit mais famoso (que é o que está gerando todo esse receio) é conhecido por afetar até a atualização 10 da versão 7 (7u10), mas nas últimas semanas a Sun/Oracle, em um esforço para corrigir este e outros problemas, tem liberado várias atualizações para o Java, tanto que em poucas semanas chegamos rapidamente à atualização 17 da versão 7 (7u17), que é a atualmente em vigor. Evite acessar websites que podem estar hospedando conteúdos maliciosos (websites de torrents, warez, conteúdos pornográficos etc.). Evite também acessar websites de empresas desconhecidas, pois nelas geralmente a política de segurança não é muito boa e por isto os servidores são alvos mais vulneráveis e frequentes de ataques. Um website infectado pode solicitar que seu navegador execute o plugin Java e em seguida passar a infecção para o seu sistema operacional. Já os websites de bancos costumam ter uma política de segurança melhor, por isto eu não tenho receio nenhum de usar Java para internet banking. O máximo que pode acontecer é o seu PC já estar infectado por algum outro malware que tenha modificado o arquivo de hosts do seu PC e com isto você seja levado a acessar uma página falsa (clonada) do seu banco, hospedada em outro domínio, achando que está acessando o website do seu banco. Mas isto já é outro problema, não tem relação direta com o Java. Caso queira acessar websites perigosos e/ou vulneráveis, como os mencionados anteriormente, utilize um navegador no qual o Java esteja desabilitado. Você pode, por exemplo, abrir o about:plugins ou o chrome://plugins que eu mostro no tutorial e desabilitar o Java do seu Firefox, ou o do seu Chrome, ou o do seu Chromium, para então poder acessar websites maliciosos ou vulneráveis a partir deste navegador em que o Java se encontra desabilitado. Particularmente, adotei o Firefox como navegador que utilizo quando estou querendo navegar em modo paranoico: no Firefox, instalei o complemento No-Script, que por padrão bloqueia todos os componentes das páginas que você acessa. O ruim do No-Script é que ele requer que você fique autorizando, um por um, tudo o que você quer que seja executado/carregado, nas páginas do website. Por outro lado, o No-Script tem a vantagem de bloquear tudo o que não foi explicitamente autorizado por você, inclusive o plugin Java (seja Sun Java, seja IcedTea ou o que for). Usando o No-Script, você pode adicionar permissões temporárias (para executar o conteúdo da página somente durante aquela sessão, aquele acesso que você está fazendo: uma vez que você saia da página, ela volta a ficar bloqueada), ou então adicionar permissões permanentes. No caso do internet banking, você pode adicionar permissões permanentes para o website do seu banco, mas continuar rejeitando as tentativas dos outros websites de executar o plugin Java e outros recursos porventura indesejáveis ou mal-intencionados. Devido a os bancos terem optado por usar o Java para estruturar o ambiente de internet banking deles, você terá que usar Java, seja Sun/Oracle Java, seja OpenJDK/IcedTea Java, para conseguir acessar seu banco via internet. Por isto, o negócio é usar o Java, mas mantê-lo atualizado e adotar uma conduta precavida.

Agora que me dei conta: meu tutorial foi escrito para sistemas de 32 bits, por isto os comandos que postei são todos para Ubuntu 32 bits. Como você está num Ubuntu de 64 bits, alguns comandos mudam um pouco: 1. Remova novamente tudo, conforme explica a seção 2 do tutorial. 2. Execute novamente os procedimentos de instalação da seção 1 do tutorial, com as seguintes diferenças: 2.1. O arquivo que você tem que baixar não é o do tutorial, mas sim o Linux x64 (atualmente: jre-7u10-linux-x64.tar.gz). 2.2. Consequentemente, no supercomando você tem que substituir o nome do arquivo por este de 64 bits, que você obteve. Vai ficar assim: sudo mkdir /opt/java && sudo mv ~/Downloads/jre-7u10-linux-x64.tar.gz /opt/java && cd /opt/java && sudo chmod a+x jre-7u10-linux-x64.tar.gz && sudo tar -xvf jre-7u10-linux-x64.tar.gz && sudo mv ./jre1* ./jre && sudo rm -f ./jre-7u10-linux-x64.tar.gz 2.3. Os atalhos também mudam, porque no Java de 32 bits o plugin fica na pasta i386, mas no Java de 64 bits o plugin fica na pasta amd64: Google Chrome: sudo ln -sf /opt/java/jre/lib/[B]amd64[/B]/libnpjp2.so /opt/google/chrome/plugins/sunjava Mozilla Firefox: sudo ln -sf /opt/java/jre/lib/[B]amd64[/B]/libnpjp2.so /usr/lib/firefox/plugins/sunjava Google Chromium: sudo ln -sf /opt/java/jre/lib/[B]amd64[/B]/libnpjp2.so /usr/lib/chromium-browser/plugins/sunjava Vê se agora funciona. PS: se não funcionar, experimente as dicas que constam na seção 4 do tutorial. PPS: o openjdk não precisa ser desinstalado.

Oi de novo, Wagner. Agora que você me disse que o seu sistema é de 64 bits, a minha suspeita é que seu sistema esteja com o bug que eu menciono no item 4.1 do tutorial. Vamos ver se minha suspeita se confirma. Execute estes dois comandos: sudo mkdir -p /etc/.java/.systemPrefs sudo chmod 755 -R /etc/.java Depois reinicie o computador e tente novamente usar o Sun Java no Banco do Brasil. Acho que agora vai funcionar.

Oi, Wagner. Identifiquei o problema. O seu comando sudo update-alternatives --list java retornou /opt/java/jre1.7.0_10/bin/java ao invés de /opt/java/jre/bin/java, o que significa que você não executou literalmente o supercomando que consta no item 1.2 da seção 1 do tutorial. Como você disse para o seu sistema operacional que seu JRE padrão está instalado em /opt/java/jre1.7.0_10/bin/java (ao invés de em /opt/java/jre/bin/java), os atalhos do item 1.7 da seção 1 do tutorial não funcionaram, já que eles apontam para o caminho /opt/java/jre/lib/i386/libnpjp2.so, mas ele não existe: no lugar dele quem existe é /opt/java/jre1.7.0_10/lib/i386/libnpjp2.so Por causa disto, seus navegadores não vão encontrar o plugin, já que eles estão procurando o plugin em um local que não existe, rs. Para corrigir o problema, siga estes passos: i) Execute os comandos dos itens 2.1 e 2.2 do tutorial. ii) Execute o comando abaixo: sudo update-alternatives --remove java /opt/java/jre1.7.0_10/bin/java iii) Execute os comandos de todos os itens da seção 1 do tutorial, inclusive o supercomando que consta no item 1.2. Mesmo os comandos que você já tenha executado no passado, execute-os novamente. Isto é muito importante para poder corrigir algumas coisas, como por exemplo a localização do seu JRE padrão e os links que apontam para o plugin dos seus navegadores. Caso o problema persista, responda este post informando qual distribuição GNU/Linux que você está usando (Ubuntu, Debian, Mint etc.), a versão dela (12.04, 11.10, 12.10 etc.), a arquitetura da sua distribuição (32 bits ou 64 bits), e também os resultados apresentados por estes comandos: java -version sudo update-alternatives --list java Caso o problema tenha sido resolvido, não deixe de informar para eu saber que nada ficou pendente.

Olá, pbkblaum. Que bom que o tutorial resolveu seu problema. Já o fiz mesmo bem completo para reduzir as chances de algo dar errado com alguém. É, às vezes a gente precisa temporariamente desligar a nossa máquina (com umas boas horas de sono) antes de continuar mexendo na máquina (PC), rs. Ao reiniciar o PC e perceber que o Java passou a funcionar, você acabou indiretamente descobrindo o porquê de, no final da seção 1, eu dizer que após instalar e configurar o Sun Java deve-se esvaziar o cache do navegador, fechá-lo e abri-lo novamente. Esvaziar o cache costuma ser melhor do que reiniciar a máquina, porque força o navegador a carregar tudo novamente: tanto os dados da página do seu banco quanto os dados do novo plugin que você instalou. Mas se você esvaziar o cache e mesmo assim o plugin não funcionar (o que seria estranho, mas nem por isto impossível), não custa nada reiniciar a máquina e ver se de repente o sistema limpa, renova ou atualiza algo que se encontrava pendente. Pelo menos no Debian e nas distribuições baseadas em Debian, o sistema pode ser reinicializado também por intermédio deste comando, no Terminal: sudo telinit 6

Ouquêi! A propósito, eu inadvertidamente escrevi invertido, quando falei para usar /opt/java/jre/lib/amd64 no lugar de /opt/java/jre/lib/i386: o correto é o inverso. Enfim: é só seguir à risca o passo-a-passo da seção 1 que a instalação da versão de 32 bits será feita corretamente, criando a pasta /opt/java/jre/lib/i386 ao invés de /opt/java/jre/lib/amd64. Acabei de corrigir o texto da minha mensagem anterior. Agora está correto. Vou aguardar o seu próximo post. Tomara que alguma daquelas dicas consiga resolver o problema!

Mmm... Estranho mesmo... A maioria dos problemas que vejo acontece no GNU/Linux de 64 bits, e quase sempre com o Google Chrome ou Chromium. Não sei o porquê, mas é quase sempre assim. Como você está num sistema de 64 bits e realizou a instalação tal como descrito no tutorial (apenas fez download do instalador de 64 bits e mudou as pastas para os caminhos que são os corretos do sistema de 64 bits), é possível que o problema persista devido a algum dos bugs que ocorrem (quase que) exclusivamente em sistemas de 64 bits, por isto pergunto: você chegou a seguir os passos da seção 4 do tutorial? Eu não uso GNU/Linux de 64 bits e meu PC é velho demais (Intel Pentium D 3.4GHz com 2GB de RAM 667MHz e um BUS de 800MHz) para aguentar rodar um sistema de 64bits dentro de uma VirtualBox, razão por que elaborei o tutorial voltado para sistemas de 32 bits. Meu hardware infelizmente me deixa limitado para realizar testes e troubleshootings em sistemas de 64 bits. Mas a maioria dos problemas que tenho visto serem reportados, em fóruns especializados estrangeiros, a respeito do funcionamento do Java em sistemas e navegadores de 64 bits, está relacionado ou à dificuldade de o navegador identificar a versão do Java instalado, ou então está relacionado a problemas de permissão ou acesso à pasta /etc/.java ou à subpasta /etc/.java/.systemPrefs Consequentemente, no momento as minhas sugestões para você tentar resolver o problema são estas: 1. Experimente fechar o Google Chrome e então executar os passos descritos na seção 4 do tutorial. Primeiro, tente acessar o BB via Google Chrome com a opção --allow-outdated-plugins ativada. Se der certo, o seu navegador ou está desatualizado, ou então é uma versão "unstable" (ao invés de ser a versão "stable"). Se o procedimento funcionou, informe a versão do navegador que você usou, pra eu poder investigar o que está havendo com o navegador. Se o --allow-outdated-plugins não deu certo, continue seguindo os passos daquela seção 4: execute os comandos do item 1 da seção 4 (criar a pasta .systemPrefs e rodar chmod em /etc/.java). Daí tente novamente acessar o BB com o navegador. Se funcionar, daqui pra frente você não terá mais problemas com o Java. Mas, se não funcionar... ...então feche o navegador e siga para o item 2 da seção 4: delete a pasta /etc/.java (com o comando rm) e tente novamente acessar o website do BB. Se funcionar, você não terá mais problemas com o Java, daqui pra frente. Mas, se não funcionar... 2. Deixe o restante da seção 4 pra lá e faça o seguinte: desinstale o Java de 64 bits (ou seja: exclua a pasta /opt/java que você criou na instalação do Java de 64 bits) e em seguida faça download do Java de 32 bits e instale-o (seguindo os passos da seção 1), ao invés de instalar o java de 64 bits. Refaça os links usando o comando ln -sf, mas utilize /opt/java/jre/lib/i386 no lugar de /opt/java/jre/lib/amd64, como consta na seção 1. A intenção desta última dica é ver se a versão de 32 bits roda no ambiente de 64 bits. Se ela rodar, o problema provavelmente será resolvido. Veja se alguma dessas dicas funciona para você.

Olá, nakanoalex! Obrigado pela parabenização. Explica melhor o problema que você está tendo: ao acessar o website do BB, aparece alguma mensagem de Java desatualizado? O que acontece? Se puder postar aqui no fórum a mensagem que o Terminal retorna para você, quando você executa o comando java -version, e se você também puder postar aqui a mensagem que a página de testes da Sun apresenta para você, será possível eu levantar algumas hipóteses. Ah, e eu preciso saber também qual é a distribuição GNU/Linux que você usa (se é Ubuntu ou outra, e se ela é de 32 ou 64 bits). Já fazia um tempo que eu não atualizava o tutorial, por isto ele ainda estava se referindo ao Sun Java 7u7. Atualmente, o Java "mais novo" é o 7u9. Será que você não obteve e tentou instalar o 7u9 mas, ao copiar os comandos do tutorial para o seu terminal de comandos, acabou se esquecendo de mudar o texto dos comandos de 7u7 para 7u9? Se você ao menos suspeitar que isto possa ter acontecido, experimente usar as dicas da seção 2 do tutorial para desinstalar o seu Java. Em seguida, utilize as dicas da seção 3 para novamente instalar o Java 7u9. Outra coisa: a extensão do arquivo de instalação do Sun Java tem que ser .tar.gz (ou seja: o arquivo tem que ser um tarball). Ontem mesmo fiz um teste: baixei o Sun java 7u9 usando o meu Macbook Pro (sistema operacional OS X 10.6 "Snow Leopard"), ao invés de fazer o download pelo Linux. Sabe o que veio? Um arquivo com extensão .gz (GZIP). Portanto, caso você tenha feito o download via Windows e depois acessado o Linux para instalar o arquivo, pode ser que o arquivo que veio no download tenha sido uma versão para Windows, ou então uma versão para Linux com uma extensão diferente de .tar.gz, e daí os comandos do tutorial realmente não vão funcionar. Para evitar esses problemas, faça o download do instalador do Java pelo Linux mesmo. Vou supor que você está usando alguma versão do Ubuntu de 32 bits. Neste caso, para baixar o instalador de 32 bits, clique aqui. Outro modo é acessar a página de download do Sun Java para Linux e então clicar na segunda opção da lista. De cima para baixo, é a opção onde se lê "Linux tamanho do arquivo: 45.7 MB". Aproveite para também verificar se os seus navegadores não estão desatualizados. Se você estiver no Ubuntu ou em alguma outra distribuição GNU/Linux que utilize o sistema de pacotes .deb (por meio de aplicativos tais como apt, dselect, dpkg, aptitude, synaptic etc.), então uma forma de atualizar seus navegadores (e demais pacotes do seu sistema) é executar, no Terminal, os comandos abaixo, na exata sequência em que eles aparecem, de cima para baixo: sudo mv /var/lib/apt/lists /var/lib/apt/lists.old sudo apt-get clean sudo apt-get update sudo apt-get build-dep sudo apt-get check sudo apt-get purge sudo apt-get autoclean sudo apt-get autoremove sudo apt-get upgrade Espero que o seu problema seja resolvido com as dicas acima. Se não foi resolvido, envie outro post informando a distribuição e a versão do seu GNU/Linux, a versão do seu navegador, a mensagem que surge na página de testes da Sun, idem a que surge após você executar o comando java -version, e informe junto uma descrição mais detalhada do problema que está ocorrendo, para eu ver se consigo ajudá-lo a desvendar esse problema, ok?

Caramba, que esquisito... Digo: ok, há apenas um plugin detectado pelo Chromium. Mas, justamente porque há apenas um plugin instalado e ele foi detectado pelo Chromium, esse plugin deveria funcionar sem problemas. Estou ficando sem opções. No momento, só consigo pensar que o seu Chromium está apresentando exatamente o mesmo problema que o Chrome, ou seja, que o Chromium está detectando o plugin mais recente como se fosse um plugin desatualizado. Isto é bastante provável, já que os projetos de desenvolvimento de ambos os navegadores são mantidos pelo Google. Se for mesmo isto, o mais provável é que esse problema só será resolvido após ser lançada uma nova versão do Sun Java ou do seu navegador. A minha sugestão é que, enquanto não surge uma nova versão do Sun Java, tampouco do navegador, você entre no terminal (em modo usuário normal, não superusuário) e execute o Chromium em modo de compatibilidade com plugins desatualizados. O comando é este (os mesmos comandos de terminal do Chrome servem para o Chromium): chromium-browser --allow-outdated-plugins Como o Chromium está detectando o plugin (apenas diz que a versão mais recente do plugin está desatualizada), deverá ser suficiente informar ao navegador para ignorar o fato de que o referido plugin está "desatualizado" (já que nós sabemos que não está desatualizado coisa nenhuma, só é preciso ignorar esse falso erro). Assim tem que dar certo. É um paliativo, infelizmente. Mas acho que vai funcionar. Se funcionar, a minha sugestão é que você fique utilizando o paliativo até que esse bug seja sanado pelos desenvolvedores do navegador (acredito que o problema esteja no navegador, não na JVM). Se não funcionar, vou torcer para você conseguir descobrir a resposta para esse problema sem a minha ajuda, porque no momento estou sem outras ideias. Em casa eu pelo menos ainda tenho o meu PC com Linux (embora seja XUbuntu de 32 bits e eu não use o Chromium). Mas estando de férias, longe de casa e de qualquer computador com Linux, não tenho sequer como instalar o Chromium e testar uns comandos no terminal.

Você possui duas JVM em seu sistema, mas a primeira da lista (jre1.7.0_06) é a padrão do seu sistema. Experimente definir também o plugin padrão, por meio dos dois comandos abaixo. update-alternatives --install /usr/lib/chromium-browser/plugins/libnpjp2.so javaplugin /opt/java/jre1.7.0_06/lib/amd64/libnpjp2.so 3 O comando acima associa o número 3 ao plugin libnpjp2.so que se encontra em /opt/java/jre1.7.0_06/lib/amd64/ e que foi vinculado ao Chromium por meio de uma ligação inserida em /usr/lib/chromium-browser/plugins/libnpjp2.so Agora execute este segundo comando, no terminal. Ele informará ao sistema que o plugin associado ao número 3 é o plugin padrão: update-alternatives --config javaplugin Digite 3, tecle ENTER para confirmar, reinicie o navegador e faça o teste.

Olá. Eu ainda estou de férias, longe de um PC com Linux, por isto não estou tendo como testar algumas coisas (instalar o Chromium, por exemplo). De qualquer modo, no momento estou suspeitando do seguinte: você instalou o Sun Java versão 1.7.0_06 (não 1.7.0_05) em /opt/java/jre1.7.0_06/ (não /opt/java/jre1.7.0_05/) e ligou o plugin corretamente ao seu navegador Chromium, por isto o Chromium detectou corretamente a presença do plugin Sun Java versão 1.7.0_06... ...porém, o seu sistema operacional não detectou o executável da JVM (que fica dentro de /opt/java/jre1.7.0_06/bin/). Daí, quando o Chromium solicita ao plugin Java que carregue algum componente da JVM, o plugin retransmite a solicitação para o sistema operacional, mas o sistema operacional procura a JVM e não a encontra, o que causa o problema. * Se a minha suspeita estiver correta, creio que o problema será resolvido tão logo você informe ao sistema operacional a localização da sua JVM padrão. Execute este comando, no terminal, para verificar qual é a JVM padrão do seu sistema operacional: java -version Se o comando acima não retornar uma referência ao Java da Sun, versão 1.7.0_06, então há uma outra JVM (outra versão de JVM da Sun, ou uma JVM de outro desenvolvedor) instalada em seu sistema operacional e definida como "padrão". Se o seu sistema operacional de fato não sabe qual é a sua JVM padrão, ou se ele está tentando utilizar, por padrão, uma JVM alternativa (tipo OpenJDK), que não é aquela Sun Java 1.7.0_06 que você instalou manualmente, execute este comando, no terminal: sudo update-alternatives --config java Deverá aparecer uma lista contendo pelo menos uma JVM. Cada JVM deverá ter um número inteiro associado a ela, na lista, e deverá aparecer um asterisco ao lado da JVM definida como padrão. Pressiona ENTER para sair da lista. Agora execute este comando, ainda no terminal: sudo update-alternatives --install /usr/bin/java java /opt/java/jre1.7.0_06/bin/java 3 NOTA: aquele 3 no final do comando é o número inteiro que será vinculado à sua JVM (cada JVM é vinculada a um, e somente um, número inteiro. E vice-versa: cada número inteiro é vinculado a uma, e somente uma, JVM). Caso naquela lista tenha aparecido alguma JVM associada ao número 3, escolha outro número inteiro que não tenha aparecido na lista. Aquele comando update-alternatives --install incluirá a JVM Sun Java 1.7.0_06 na "lista de JVM" do seu sistema operacional. Agora retorne à lista de JVM: sudo update-alternatives --config java Digite o número que você atribuiu à sua JVM (Sun Java versão 1.7.0_06) e tecle ENTER. Exemplo: se você de fato atribuiu o número 3 à sua JVM, tecle 3 e depois ENTER. Isto fará com que você selecione e defina a JVM número 3 para ser a JVM padrão do seu sistema operacional. Reinicie e computador e tente novamente acessar o website do BB com o Chromium. Se continuar dando problema, cole aqui no fórum as mensagens de erro que estão surgindo, e também o resultado deste comando: sudo update-alternatives --list java

Oi! Mas tchê... Que esquisito esse problema, hein? Algumas possibilidades que (talvez) expliquem o problema que ocorreu com você: 1. O website do Banco do Brasil pode estar passando por algum problema técnico temporário. Experimente tentar novamente daqui a 1 ou 2 dias. 2. Você pode ter se esquecido de executar o passo 1.7 do tutorial. Ele serve para eliminar a possibilidade de alguma JVM antiga ou incompatível ainda estar sendo executada por padrão, a partir do cache do seu navegador. Limpe o cache do seu navegador, feche o navegador e execute-o novamente, para se certificar de que o problema não está relacionado com o cache. 3. Você pode ter se esquecido de executar o passo 1.10 do tutorial. Ele serve para corrigir eventuais problemas relacionados à permissão de arquivo do plugin Sun Java que foi instalado. Execute aquele passo 1.10. 4. Você pode ter se esquecido de que é necessário clicar sempre no botão [Executar esta vez], que aparece no topo da página do Banco do Brasil. 5. Você pode não ter tentado executar o "comando alternativo", que faz o Google Chrome executar em um modo especial de compatibilidade. Experimente abrir uma janela do terminal e executar este comando (execute o terminal em modo "usuário comum", não root): google-chrome --allow-outdated-plugins & 6. O seu navegador Google Chrome pode estar desatualizado. Se (e somente se) nenhum dos procedimentos anteriores foi capaz de resolver o problema, experimente desinstalar o seu navegador Google Chrome e em seguida instalar a versão mais recente dele. O passo-a-passo consta nas linhas a seguir. 6.1. Desinstale o Google Chrome e limpe o cache dos pacotes. Você pode fazer isto via Synaptic. Caso não tenha o Synaptic, as linhas de comando de terminal são estas: Desinstalar o Google Chrome: sudo apt-get remove google-chrome Limpar o cache dos pacotes: sudo apt-get purge sudo apt-get autoremove sudo apt-get clean Caso o APT pergunte algo, sempre responda com um "sim" (S), para confirmar que deseja limpar o cache, desinstalar pacotes não utilizados etc. Nota: você pode querer instalar o Synaptic. Ele facilita bastante as coisas. Caso queira instalá-lo, use este comando de terminal: sudo apt-get install synaptic ...daí execute o Synaptic e marque o pacote google-chrome para desinstalação e clique no botão "Aplicar". Mas não deixe de executar os comandos de terminal purge, clean e autoremove, após ter removido o Google Chrome! Isto garantirá que o cache dos pacotes ficará limpo, após o Chrome ter sido removido! 6.2. Abra o Gerenciador de Atualizações do Ubuntu (ou o Synaptic) e remova o repositório do Google Chrome e a chave de acesso ao repositório do Google Chrome. 6.3. Agora que você desinstalou o Google Chrome e removeu tanto o repositório antigo de instalação do Google Chrome quanto a chave de acesso daquele repositório antigo, faça download do pacote DEB do Google Chrome mais atual para o Ubuntu (abra o link e clique no botão "Fazer Download do Google Chrome"). Se o seu Ubuntu for 32 bits, faça download do arquivo 32 bit .deb (Para o Debian/Ubuntu). Se o seu Ubuntu for 64 bits, selecione a opção 64 bit .deb (Para o Debian/Ubuntu). 6.4. Instale o pacote DEB: Digamos que o arquivo que você pegou esteja na sua pasta "Downloads" (atalho no terminal: ~/Downloads) e que o arquivo DEB que você pegou tenha este nome: google-chrome-stable_current_i386.deb Neste caso, execute este comando, no terminal: sudo dpkg -i ~/Downloads/google-chrome-stable_current_i386.deb O comando dpkg -i instala o pacote DEB que você informa à direita daquele comando. No caso, o pacote do Google Chrome será instalado e, durante o processo, automaticamente adicionará o repositório de atualização do Chrome, assim como também automaticamente adicionará a chave de acesso ao repositório oficial do Google Chrome. Isto fará com que você seja notificado (pelo Gerenciador de Atualizações do Ubuntu) sempre que os desenvolvedores do Google Chrome liberarem uma nova versão do navegador. Se durante a instalação do pacote DEB ocorrer algum problema de dependência de arquivo, execute também este comando, no terminal: sudo apt-get -f install Notas: N1. Ao atualizar o navegador, não será necessário reinstalar o Sun Java. N2. Apesar de residir na cidade de São Paulo (SP) e possuir (em casa) um PC com XUbuntu Linux 12.04 de 32 bits, atualmente estou passando férias em Porto Alegre (RS) e portando comigo apenas o meu Macbook, que está apenas com o sistema operacional OS X 10.6 de 64 bits. Por isto, atualmente estou limitado para tentar reproduzir o seu contexto e tentar desvendar o que pode estar ocorrendo. Informei algumas alternativas e uns comandos que sei "de cabeça". De qualquer modo, creio que executando os procedimentos deste post você conseguirá acessar o website do BB sem problemas, via Google Chrome. Caso o problema persista, experimente fazer a instalação do Mozilla Firefox (para neste ínterim não ficar sem acesso ao seu banco) e então coloque aqui um novo post, informando: A distribuição Linux que você está usando (exemplo: XUbuntu 12.04, versão 32 bits). A versão do Google Chrome que você está utilizando. Uma descrição detalhada do problema. Um "print screen" da tela de erro que aparece no seu navegador. N3. Caso o problema tenha sido resolvido ou parado de ocorrer, por gentileza avise-me por aqui ou por mensagem privada do fórum.

Oi, Mota! Que bom que deu tudo certo! Foi um prazer ter colaborado para o solucionamento do seu problema.

Se você seguiu todos os passos do tutorial (removeu todas as versões anteriores do Java, instalou o Java mais recente e esvaziou o cache do navegador antes de começar a usá-lo) e, ainda assim, ao tentar acessar o internet banking do Banco do Brasil com o Google Chrome, você viu esta mensagem: O Java foi bloqueado porque está desatualizado. [Executar esta vez] [Atualizar plugin...] Volte lá em chrome://plugins e procure por "1.7.0_05" (sem as aspas) Se você encontrar um texto com esta aparência: Java - Versão: 1.7.0_05 Faça download da atualização crítica de segurança Ignore-o. Em outras palavras: clique sempre no botão [Executar esta vez] Atualmente (01/08/2012), a versão mais recente do Sun Java é a 1.7.0_05. Se você instalou a versão mais recente e mesmo assim o navegador está apresentando uma mensagem de erro (como se o seu Java estivesse desatualizado), ignore: é um falso erro. Prova disto é que se você for à página de teste da Sun e testar o seu Java, o próprio website da Sun exibirá uma mensagem assim: Parabéns! Você tem o Java recomendado instalado (Version 7 Update 5). Ou então assim: Seu Java está funcionando Java mais recente instalado De qualquer modo, caso você esteja se sentindo muito incomodado com os alertas do navegador Google Chrome, ou caso esteja tendo problemas para acessar algum website, há basicamente duas opções: 1. Usar o Firefox (caso ele também esteja instalado em seu sistema); ou 2. Abrir uma janela do Terminal (não use o modo superusuário/root!) e digitar este comando: google-chrome --allow-outdated-plugins & O comando acima informado é um modo especial (personalizado) de executar o navegador Google Chrome. Porém, ao ser fechado, o Google Chrome perde aquelas configurações especiais. Por isto, será necessário executar novamente aquele comando especial, sempre que se quiser abrir o Google Chrome sem ver as mensagens chatas de falso erro.

É uma satisfação saber que o tutorial está ajudando também pessoas que vivenciavam problemas similares com outros bancos.

Bacana! Fico feliz em saber que o tutorial está ajudando outras pessoas. Espero que ainda ajude muitas outras que também estejam vivenciando a mesma dificuldade que eu vivenciei na primeira vez em que fui acessar o website do BB com o Google Chrome.

O tutorial que aqui constava foi definitivamente movido para o fórum do Ubuntu, que é mais apropriado para este tema, e portanto será doravante mantido atualizado somente naquele fórum. Consequentemente, considero este tópico fechado, no fórum do Clube do Hardware.

Já faz algum tempo que os usuários Mac passam por alguns estresses com o plugin de segurança do home banking do Banco do Brasil. Um caso recente que me incomodou bastante foi o fato de que atualmente o plugin de segurança está criando uns arquivos de biblioteca dinâmica dentro da minha pasta home (veja a figura abaixo). O pior é que não adianta você excluir aqueles arquivos gbas.dylib, porque tão logo você volte a acessar sua conta corrente via internet banking, o website do Banco do Brasil novamente criará aqueles arquivos. * dylib é abreviação de dynamic library. Eu já reportei o problema ao Banco do Brasil e ainda não obtive uma resposta. Porém, estou usando um paliativo e abaixo descrevo como implementá-lo, caso alguém mais tenha interesse em se ver livre dos arquivos. 1º passo) Abra o Editor de Texto, clique no menu Formato e selecione a opção Converter para Texto Normal (veja a figura abaixo). 2º passo) Coloque estas três linhas de comando na janela do Editor de Texto: cd ~ rm -f *gbas* kill `ps -A | grep -w Terminal.app | grep -v grep | awk '{print $1}'` A primeira linha de comando vai fazer o script acessar sua pasta pessoal (onde estão os arquivos gbas.dylib). A segunda linha vai fazer uma exclusão forçada dos arquivos gbas.dylib. A terceira linha vai forçar o Terminal a se encerrar, após a exclusão daqueles arquivos. 3º passo) Salve o arquivo na pasta que quiser e com o nome que quiser dar a ele. No meu caso, fui à pasta Documentos, criei uma subpasta chamada Scripts, e lá dentro salvei o arquivo com o nome startup (não adicione extensão nenhuma ao arquivo). 4º passo) Abra uma janela do Terminal (Aplicativos -> Utilitários -> Terminal) e use o comando cd para acessar a pasta em que você salvou o seu script. Por exemplo, no meu caso, como eu salvei o script dentro da pasta Scripts, que por sua vez está dentro da pasta Documentos (Documents), que por sua vez está no meu diretório local (que é representado pelo símbolo ~), eu vou digitar o seguinte, dentro do Terminal: cd ~/Documents/Scripts ...e pressionar a tecla return (enter), para que o comando seja executado. 5º passo) Agora que estou na pasta em que o script se encontra, vou digitar o comando abaixo (substitua a palavra startup pelo nome que você deu para o seu arquivo de script, caso tenha escolhido um nome diferente): chmod +x startup Isto fará com que o arquivo startup possa ser executado pelo Terminal. 6º passo) Clique sobre a maçã que aparece no canto superior esquerdo do seu Mac e selecione a opção Preferências do Sistema... (veja a figura abaixo). A janela de preferências do sistema será aberta. Clique sobre o ícone Contas. 7º passo) Na janela Contas, clique sobre a sua conta e em seguida clique sobre o botão Itens de In. de Sessão (veja a figura abaixo). 8º passo) Em seguida, clique no símbolo +, selecione seu script e clique no botão Adicionar (veja a figura abaixo). 9º passo) Marque a caixa de verificação da coluna Ocultar, para que o seu script seja executado de forma discreta (veja a figura abaixo). 10º passo) Reinicie o seu Mac e faça login novamente. Se tudo deu certo, os arquivos gbas.dylib terão desaparecido da sua pasta pessoal, e somente voltarão a aparecer quando você voltar a acessar sua conta corrente no website do Banco do Brasil. Conclusão: sempre que você fizer login no Mac, o script será executado e excluirá os arquivos gbas.dylib. Caso queira excluí-los sem precisar fazer novo login, clique sobre o seu script (como você configurou ele para ser executável, ele irá executar a si mesmo, dentro da janela do Terminal). O script então excluirá os arquivos para você. No meu caso, como o script se chama startup e está na pasta /Documents/Scripts, eu simplesmente clico no ícone Documentos (que fica na Mesa), coloco o ponteiro sobre a pasta Scripts e então clico sobre o arquivo startup.