Um pouco atrasado em relação à mídia em geral, que ansiosamente lança esse tipo de reflexão logo na última semana do ano, ou no máximo nos primeiros dias do ano que recém chega, aqui estou eu falando do ano que se foi, 2011. E no dia 11 de janeiro! Não tenho mesmo aquele "timing" jornalístico.
Deixando de lado a discussão sobre certo ou errado em relação a tais publicações, estou escrevendo aqui como foi o ano de 2011 aqui nesse site. Com a ajuda do JoomlaStats ficou bem fácil de ver a quantidade de acessos, páginas mais acessadas, sistemas operacionais, navegadores, etc. Então vamos lá!
Com uma média de aproximadamente 1000 visitas por mês, não tenho do que reclamar em relação à quantidade. Foram mais ou menos 33 visitantes por dia. Uma boa média para quem não tem um grande acervo de material, nem marketing direcionado. Achava que eu só atraia os spammers, mas vejo que tenho algo a mais que um endereço de e-mail valioso (pros spammers).
Não sou grande fã de padrinhos mágicos. Não que o seriado seja ruim, mas não tenho assistido muito televisão. Mas esse vídeo foi apresentado durante a aula de Marketing do MBA, com o professor Peruzzo, que por si só já é um show à parte.
É um vídeo interessantes pois mostra o Flappy Bob, um cara de uma família de palhaços, que se perdeu dos pais e foi criado pelos duendes, verdadeiros burocratas.
Notem como o vídeo é a própria realidade de nossas vidas, onde se não escolhemos o que queremos, as escolhas são feitas por nós. E nós as engolimos sem nem mesmo contestar. Vídeo forte.
A letra:
Timmy: Ei, Flappy Bob olha que situação
Você foi usado apenas como peão
As suas roupas de palhaço
Eles tiraram sem razão
Cai na real isso não é diversão
Desde pequeno manipularam você
Escolhiam seu carro e o que devia comer
Sei que é difícil enxergar
Que é tudo um plano pra te enganar
É hora de parar antes de se arrepender
DC e Sanderson:Ei Flappy Bob, o que é que tá havendo?
Você tá escutando mentiras sem sentido
Pra encher o teu ouvido
Te botando contra nós
Abafando a nossa voz
É, mas vê se não esquece
Foi você, Flappy Bob!
É, foi só você!
Que protegemos, respeitamos!
Como um filho especial.
E agora o que é que temos?
Seja grato pelo menos!
Assinando esse contrato
Tudo vai ficar legal!
Timmy: Cadê a diversão?
Flappy Bob: Em quem acredito?
Duendes: Cadê a diversão?
Flappy Bob: Estou em conflito!
Timmy: Quem vai dizer o que na verdade é diversão?
Timmy: Cadê a diversão?
Flappy Bob: Faz uma pausa!
Duendes: Ele é o vilão!
Flappy Bob: Por sua causa
Quase perdi tudo que eu sempre achei diversão.
Timmy: Ei, Flappy Bob! Ouça o seu coração!
Não é nada disso a sua verdadeira missão!
Eu sei que agora eu tô numa fria
Mas os seus pais, o que diriam
Sobre o caminho que você escolheu sem razão?
Timmy: Cadê a diversão?
Flappy Bob: Em quem acredito?
Duendes: Cadê a diversão?
Flappy Bob: Estou em conflito!
Timmy: Quem vai dizer o que na verdade é diversão?
Timmy: Cadê a diversão?
Flappy Bob: Eu tô confuso!
Duendes: Mas ele é o vilão!
Flappy Bob: É só um intruso!
Duendes: Não merece atenção!
Flappy Bob: Vou agora assinar é minha decisão!
Timmy: Não!
Flappy Bob: Pode até ser um erro que cometi
Duendes: Ha! Ha! Ha! Ha!
Flappy Bob: Mas tudo mudar é muito arriscado pra mim
As coisas que eu usei são do passado eu já deixei!
Eu quero meu mundo como eu me acostumei!
Com toda proteção
Duendes: O perdedor vai pro chão!
Timmy: Ah!
Flappy Bob: Valeu pela caneta!
Não dá mais pra ignorar os dispositivos móveis. Não é somente na televisão, Internet e no dia à dia que vemos os smartphones e tables. Na estatística de acesso ao site eles também estão aparecendo, e de forma crescente.
Eu mesmo tenho usado bastante meu celular Nexus S para navegar na web (principalmente quando estou na cama) e nada me irrita mais que acessar um site não preparado para ele, que fica mais de 1 minuto para carregar as páginas. Mas não adianta nada reclamar dos outros se nem mesmo eu tava prestando a devida atenção a isso.
Então instalei o módulo Mobilebot do Joomla para modificara formatação do site para dispositivos móveis.
Como ainda está em fase de testes, não prometo uma grande melhoria o resolução imediata dos problemas, mas já é um começo.
Finalmente cheguei à conclusão do motivo das falhas de SSH. Eu não tinha me dado conta, mas o problema surgiu depois do upgrade do Ubuntu que estou usando no laptop, para a versão 11.10 (Oneiric).
Como fui conectar em um outro servidor e tive o mesmo erro, vi que não era problema do Solaris, mas sim do cliente ssh. Então tentei uma conexão em modo de debug:
helio@shibboleet:~$ ssh -C -v slowlaris
OpenSSH_4.2p1 Debian-4.sesarge.2, OpenSSL 0.9.7m 23 Feb 2007
debug1: Reading configuration data /home/helio/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to slowlaris [1.2.3.103] port 22.
debug1: Connection established.
debug1: identity file /home/helio/.ssh/identity type 0
debug1: identity file /home/helio/.ssh/id_rsa type 1
debug1: identity file /home/helio/.ssh/id_dsa type 2
debug1: Remote protocol version 2.0, remote software version Sun_SSH_1.1.3
debug1: no match: Sun_SSH_1.1.3
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.2p1 Debian-4.sesarge.2
debug1: Unspecified GSS failure. Minor code may provide more information
Credentials cache file '/tmp/krb5cc_1000' not found
debug1: Unspecified GSS failure. Minor code may provide more information
Credentials cache file '/tmp/krb5cc_1000' not found
debug1: Unspecified GSS failure. Minor code may provide more information
debug1: Unspecified GSS failure. Minor code may provide more information
debug1: Unspecified GSS failure. Minor code may provide more information
SPNEGO cannot find mechanisms to negotiate
debug1: Offering GSSAPI proposal: (null)
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 zlib
debug1: kex: client->server aes128-cbc hmac-md5 zlib
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'slowlaris' is known and matches the RSA host key.
debug1: Found key in /home/helio/.ssh/known_hosts:4
debug1: ssh_rsa_verify: signature correct
debug1: Enabling compression at level 6.
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: gssapi-keyex,gssapi-with-mic,publickey,password,keyboard-interactive
debug1: Next authentication method: gssapi-with-mic
debug1: Unspecified GSS failure. Minor code may provide more information
Credentials cache file '/tmp/krb5cc_1000' not found
debug1: Trying to start again
debug1: Authentications that can continue: gssapi-keyex,gssapi-with-mic,publickey,password,keyboard-interactive
debug1: Authentications that can continue: gssapi-keyex,gssapi-with-mic,publickey,password,keyboard-interactive
debug1: Authentications that can continue: gssapi-keyex,gssapi-with-mic,publickey,password,keyboard-interactive
debug1: Authentications that can continue: gssapi-keyex,gssapi-with-mic,publickey,password,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Offering public key: /home/helio/.ssh/id_rsa
debug1: Authentications that can continue: gssapi-keyex,gssapi-with-mic,publickey,password,keyboard-interactive
debug1: Offering public key: /home/helio/.ssh/id_dsa
Received disconnect from 1.2.3.103: 2: Too many authentication failures for minsat
Dessa vez olhei com mais atenção a saída do comando. Notei vários erros com a mensagem "Unspecified GSS failure. Minor code may provide more information" e uma referência aos tipos de autenticação "gssapi-keyex,gssapi-with-mic,publickey,password,keyboard-interactive". Então busquei pelos erros de ssh com gssapi na Internet e... BINGO! Achei uma opção simples para desativar o mesmo, que deve ter mudado com o upgrade do openssl. Basta passar o parâmetro "-o GSSAPIAuthentication=no".
helio@shibboleet:~$ ssh -C -v -o GSSAPIAuthentication=no slowlaris
OpenSSH_4.2p1 Debian-4.sesarge.2, OpenSSL 0.9.7m 23 Feb 2007
debug1: Reading configuration data /home/helio/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to slowlaris [1.2.3.103] port 22.
debug1: Connection established.
debug1: identity file /home/helio/.ssh/identity type 0
debug1: identity file /home/helio/.ssh/id_rsa type 1
debug1: identity file /home/helio/.ssh/id_dsa type 2
debug1: Remote protocol version 2.0, remote software version Sun_SSH_1.1.3
debug1: no match: Sun_SSH_1.1.3
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.2p1 Debian-4.sesarge.2
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 zlib
debug1: kex: client->server aes128-cbc hmac-md5 zlib
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'slowlaris' is known and matches the RSA host key.
debug1: Found key in /home/helio/.ssh/known_hosts:4
debug1: ssh_rsa_verify: signature correct
debug1: Enabling compression at level 6.
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: gssapi-keyex,gssapi-with-mic,publickey,password,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Offering public key: /home/helio/.ssh/id_rsa
debug1: Authentications that can continue: gssapi-keyex,gssapi-with-mic,publickey,password,keyboard-interactive
debug1: Offering public key: /home/helio/.ssh/id_dsa
debug1: Authentications that can continue: gssapi-keyex,gssapi-with-mic,publickey,password,keyboard-interactive
debug1: Next authentication method: keyboard-interactive
Password:
debug1: Authentication succeeded (keyboard-interactive).
debug1: channel 0: new [client-session]
debug1: Entering interactive session.
debug1: Sending environment.
debug1: Sending env LANG = en_US.UTF-8
debug1: Remote: Channel 0 set: LANG=en_US.UTF-8
Last login: Tue Dec 6 11:30:56 2011 from 1.2.3.7
Oracle Corporation SunOS 5.10 Generic Patch January 2005
You have new mail.
[helio@slowlaris ~]>
Para evitar digitar essa opção em todas as conexões, simplesmente adicionei o parâmetro em ".ssh/config". E fim dos problemas.
Fonte: http://www.walkernews.net/2009/04/06/how-to-fix-scp-and-ssh-login-prompt-is-very-slow-in-linux/
Hoje fui brindado com essa mensagem ao tentar acessar por ssh uma workstation Sun Ultra 10 que tenho por aqui. Simplesmente não conseguia conectar por ssh.
helio@shibboleet:~$ ssh ultra10
Received disconnect from 1.2.3.241: 2: Too many authentication failures for helio
Felizmente o acesso por telnet estava disponível. Não encontrei nada relacionado à ssh que pudesse estar bloqueando meu acesso. Mas como estava rodando um programa que testava acesso via ssh para outra máquina, que abria várias threads, imaginei que isso tivesse matado todo os meus max_files_open disponíveis.
Mas mesmo matando todos os processos ssh, continuei com esse problema.
ultra10{root} #: ps -ef | grep -i ssh | awk '{print $2}' | xargs kill -9
Tentei parar o serviço e abrir o ssh em modo de debug:
ultra10{root} #: svcadm disable ssh
ultra10{root} #: /usr/lib/ssh/sshd -f -dd
Mas também sem nenhuma ajuda claro. Olhando na Internet achei que era possível arrumar isso alterando o parâmetro " MaxAuthTries". Editei então o arquivo "/etc/ssh/sshd_config" e deixei as entrada da seguinte forma:
MaxAuthTries 60
MaxAuthTriesLog 30
O ssh voltou a funcionar. Resta agora descobrir como meu programa com expect e threads causou isso.
Recentemente foi liberado o Joomla 1.5.25 em http://www.joomla.org com várias correções sérias de exploração de falha por XSS.
A série 1.5.x refere-se à versão estável. Para as versões de desenvolvimento, atualização para 1.7.3 corrige essa falha.
Se você é usuário de Joomla, não perca tempo e atualize logo seu CMS.
Patch do Joomla 1.7.3 a partir do 1.7.2
Patch do Joomla 1.5.24 a partir do 1.5.25
Faz um pouco mais de uma ano desde a aquisição do netbook Dexnet N280 através da loja online da Saraiva. Na época em que escrevi sobre o mesmo por aqui, algumas pessoas me alertaram sobre o problema com as dobradiças da tela. Após pouco mais de 1 ano utilizando o netbook, e esses problemas começaram a dar as caras.
Não resta muito o que fazer uma vez que o problema parece ser por desgaste do material (não pelo uso contínuo, mas pela baixa qualidade), então estou procurando a nota fiscal para notificar o fabricante e solicitar reparo do equipamento. Eu só não lembro se a garantia era de mais de 1 ano. Se não for, só me resta chorar...
Tudo tem um início. Para fazer o restante dos artigos inteligíveis, é preciso explicar um pouco de telefonia, mais precisamente da transmissão da telefonia em forma de dados. Ou na verdade como a voz vira dados.
Na figura abaixo é mostrado um exemplo, bem simplificado e limitado, de chamadas telefônicas em sistemas que chamamos de "rede fixa". Antes da chegada dos celulares, era o que conheciamos como telefonia.
O telefones se comunicam com as "centrais telefônicas", ou "centrais de comutação", que pegam o conteúdo de voz do assinante e enviam para o destino. As centrais telefônicas fazem também o roteamento para o telefone de destino.
Não entrando muito sobre os detalhes do antigo sistema de telefonia, mas comentando da parte que realmente interessa, basta saber que a comunicação entre os telefones e a central telefônica se faz de forma analógica. Uma vez a voz chegando na mesma, essa é digitalizada e trocada entre as outras centrais totalmente digital. Ao chegar na central do telefone destino, essa voz digitalizada é convertida em formato analógico novamente.
Os primeiros celulares usavam algo muito parecido, inclusive enviado o conteúdo da chamada (voz) em forma analógica, o que permitia a "escuta" da mesma. Apesar da tecnlogia CDMA naquela época já permitir chamadas digitais, no Brasil adotou-se o formato analógico provavelmente pelo alto custo dos aparelhos celulares digitais. Já no GSM, a comunicação é completamente digital. Qualquer tecnologia a partir do GSM tem-se a chamada telefônica completamente digital. O responsável pela digitalização é o próprio celular.
Não importando muito para explicar a rede de telefonia pré-paga, mas como curiosidade, existem dois modos de digitalização de voz: a lei-A e a lei-µ (lei-mi). Nos EUA é usada a lei-A e aqui no Brasil, a lei-µ.
Ambas as leis designam com quantos bits será digitalizada a voz. Não em relação à quantidade, mas em relação à inclinação da curva de frequência da voz. Falando de forma mais simplificada, quando a voz é mais grave, usa-se menos bits, quando é mais aguda, mais bits. Onde e quando usar esses bits é o que é mapeado pelas tais leis. Em geral ao se trocar os codecs de voz e misturar as leis, de um lado se ouve a tal "voz de pato", e do outro, a voz do Darth Vader.
Como o nosso espectro de voz, ou faixa de frequência da voz, varia entre 300 Hz e 4KHz, usa-se uma amostragem de 8 KHz para ser digitalizada. Essa digitalização é feita por meio de pulsos, os chamados PCM, Pulse Coded Modulation, que "medem" a intensidade da voz e a digitalizam.
Essa voz digitalizada é transmitida entre as centrais telefônicas dentro de um link de 2 Mbps no Brasil (os chamados links E1) e 1.5 Mbps nos EUA (links T1). Vários links E1 são agregados em links maiores, como links STM-1 (155 Mbps) ou até como STM-4 ( 622 Mbps). Apesar do mundo IP já adotar redes de maior velocidade, com links de 10 Gbps, as redes de telefonia em geral ficam dentro do 622 Mbps.
Essa comunicação entre centrais com esses links é o que veremos nos próximos artigos.
Já faz algum tempo tenho pensado em falar um pouco mais sobre telecomunicações por aqui. Não que eu entenda muito de telefonia, mas boa parte dos sistemas em que trabalho, em geral redes de pré-pago, são na verdade máquinas Unix rodando ou Linux ou Solaris e com bancos de dados MySQL ou Oracle. Algo bem mais simples que muita gente imagina.
Quando comecei a trabalhar nessa área, também tinha uma idéia de que centrais e serviços telefônicos rodavam em sistemas complexos e dedicados, com algum tipo de linguagem alienígena e que não seriam inteligíveis pelos outros seres humanos. Em parte eu estava certo. Existem as centrais de comutação, ou centrais telefônicas, que realmente são algo nesse nível. Mas existem sim sistemas mais simples (pra nós, humanos) que rodam o bom e velho Linux. Claro que isso não significa que eles estão somente lá pra fazer backup usando o comando "tar". Existem também aplicativos sobre os mesmos que suportem aplicações de telefonia, dentro dos requisitos definidos para tal (como tempo de resposta menor de 10 ms por exemplo).
Então espero de agora em diante colocar aqui um pouco de conhecimento sobre essa parte do sistema de telefonia, esclarecendo tanto a parte Unix quanto a parte de telefonia em si.
Terror da Internet, os ataques de DDoS ficaram em evidência ultimamente por causa dos grupos AnonOps e LuzSec, que atacaram vários sites usando essa técnica.
DDoS nada mais é que um ataque do tipo "estouro de boiada". Utilizando máquinas contaminadas, usa-se um programa "administrador" que envia o agendamento do ataque, com data e horário, para uma máquina de destino. No caso esse destino foi num dos servidores que administro. Por acaso onde está o serviço do http://eri.cx entre outros.
O ataque não foi dirigido diretamente à mim, mas um dos sites hospedados lá (não, não foi pro eri.cx). Durante um ataque DDoS, isso não importa muito pois tudo que está hospedado no servidor é afetado juntamente. Ou os serviços tornam-se indisponíveis ou a máquina pode travar, o que não deveria acontecer. Mas um ataque DDoS não abre brechas pra invasão ou algo do gênero.
Site atualizado para última versão estável, 1.5.23.
Estava pensando em migrar para 1.7, mas acabei descobrindo pelo FAQ que a versão 1.5.x é uma LTS, Long Term Supported, ou suporte de long prazo.
Então vou continuar na geração 1.5.x por enquanto.
No sistema de agendamento de tarefas, o cron, existe a possibilidade de controle de acesso pelos arquivos /etc/cron.allow e /etc/cron.deny. Existindo somente o /etc/cron.allow no sistema, o usuário deverá ter seu login incluso nesse arquivo para fazer uso do cron. Do contrário será brindando com uma mensagem semelhante a essa:
You (helio) are not allowed to use this program (crontab)
See crontab(1) for more information
Nos ambientes de telecomunicações, onde muitos dos sistemas operacionais em uso são Solaris, ex-Sun e agora da Oracle, esses vêm com essa forma de controle do cron habilitada por padrão.
Isso aumenta a segurança do sistema, mas também torna alguns trabalhos simples mais difíceis, principalmente quando é necessário ter agendamento de trabalho. Claro que isso poderia ser resolvido com ajuda de um bom administrador de sistemas, o sysadmin, e conhecimento em Unix, mas isso parece estar se tornando cada vez mais raro nesses dias.
Então criei o mycrond, um daemon escrito em perl, para rodar periodicamente como o crond do sistema. A sintaxe não é perfeita e tem alguns furos, como não aceitar "*/5" para tarefas a cada 5 intervalos, mas utiliza uma sintaxe que somente Solaris aceita como, por exemplo para tarefas agendadas para cada 5 minutos, utilizar "0,5,10,15,20,25,30,35,40,45,50,55". O restante é parecido com o uso normal da crontab.
Não é 100% perfeito, pois acabei deixando a análise de sintaxe incompleta para todos os valores de data, mas funciona perfeitamente como daemon, não morrendo ao sair do sistema, e é capaz de analisar e rodar formas mais simples da crontab.
Não tem nada mais chato que sistema lento. Atualmente não dá pra aguentar um sistema que fica cortando a música que se está ouvindo só porque o Firefox consumiu 2 GB de memória, a máquina virtual no VirtualBox tá com mais 2 GB alocados e ainda tá compilando um kernel.
Pois é exatamente o que tem acontecido e muito em Linux. Não sei de outras distribuições, mas especificamente em Ubuntu.
Como os patches de tempo real foram incluídos na árvore principal do kernel já faz algum tempo, isso deveria estar bem mais amenizado. Fui em busca de informação sobre como ativar tal função e encontrei o comando "chrt" (change realtime talvez).
Lendo o manual do chrt, é possível ver uma gama de opções sem muitas explicações, nem comparativos de resultados. Isso não ajuda muito na ampla adoção do mesmo. Eu acabei fazendo alguns experimentos tanto em Intel 32 bits quanto em 64 e consegui um resultado supreendemente bom e bem fácil. Apenas adicionei prioridade de tempo real ao processo init.
chrt -r -p 1 1
Esse comando adiciona a política de escalonamento SCHED_RR ao processo ID 1 (init) com prioridade 1.
A política default do init é SCHED_OTHER, que de acordo com manual - SCHED_SETSCHEDULER(2) - significa:
SCHED_OTHER política padrão de round-robin baseado em compartilhamento de tempo
SCHED_RR política round-robin
Olhando mais a fundo o manual do escalonador, é possível ver que somente o SCHED_RR ativa a funcionalidade de tempo real.
Então basta adicionar esse comando no "/etc/rc.local" do Ubuntu/Debian para ter um sistema sem problemas de "travadinhas" quando sobrecarregado. Eu fiquei mesmo surpreso em como foi fácil melhorar o desempenho do sistema e como isso não é incluído por padrão nos sistemas.
Page 19 of 31
