Eu ainda estava usando a versão 3.1. Espero que não quebre nada, mas o carregamento da página inicial está estranhamente lento aqui.
|
|
|||||||||||||||||||||||||||
|
Eu ainda estava usando a versão 3.1. Espero que não quebre nada, mas o carregamento da página inicial está estranhamente lento aqui. 6 comentáriosClique para comentar(Prefira clicar em "Responder" se estiver comentando um comentário)Deixe um comentárioConfigurar a execução automática de um script powershell no Agendador de Tarefas do Windows deveria ser fácil. Afinal é uma tecnologia Microsoft em um SO da Microsoft, configurada em uma GUI. 10 segundos no máximo, certo? Grande engano. Eu não vou explicar aqui como se agenda uma tarefa, porque envolve um monte de passos e detalhes que só vão distrair. O “segredo” está todo na definição da ação:
Leva até menos que 10 segundos, mas quando você já sabe como fazer. Dependendo da sua instalação do Windows, “-executionpolicy bypass” pode não ser necessário porque a diretiva de execução pode ter sido mudada. Testado no Windows 8.1 x64. 1 comentárioClique para comentar(Prefira clicar em "Responder" se estiver comentando um comentário)Deixe um comentárioO problema começou há algumas semanas, com o Yahoo rejeitando o recebimento de mensagens.
Ontem o gmail começou a jogar até mesmo as mensagens que recebo, das mesmas contas de email, na minha caixa de SPAM, alegando algo como:
Isso significa que provavelmente todos vocês que comentam aqui e usam o gmail vão ter os avisos do meu servidor jogados na caixa de SPAM. É importante notar que minha conta é compartilhada e um número indefinido de outros usuários estão no mesmo servidor gator3299.hostgator.com. Fiz uma busca em ferramentas de verificação de blacklists como esta e o servidor não está com a ficha tão suja assim. Constando hoje em apenas 2 listas de um total de 102. Abri um ticket para o suporte Hostgator perguntando o que posso fazer e aguardo resposta.
4 comentáriosClique para comentar(Prefira clicar em "Responder" se estiver comentando um comentário)Deixe um comentárioHá mais de três anos eu vinha usando o Syntax Highlighter Evolved, mas apesar do nome o danado do complemento não é tão “evoluído” assim e de vez em quando suas limitações me incomodavam, entre elas definir o tamanho da janela de código, para que uma listagem imensa não vire um post imenso. Aí eu esbarrei na semana passada em um blog que usava um highlighter bem mais atraente. Dei uma olhada no código-fonte e acabei descobrindo o Crayon Syntax Highlighter, que já comecei a testar na minha série de textos sobre DDNS. E um post que já deixei bem mais organizado graças a isso é minha análise do mini-NVR chinês. Eu não removi o Syntax Highlighter Evolved porque ele não parece ter entrado em conflito com o Crayon e pode ser usado nos comentários facilmente. Clique para comentar(Prefira clicar em "Responder" se estiver comentando um comentário)Deixe um comentárioGraças à modificação feita por Ethanpil no script cPanel original (parte 2 deste texto), os métodos que vou explicar a seguir são compatíveis com a atualização de serviços como dyndns e no-ip. Ou seja: você pode usá-los também, com pequenas modificações, para atualizar seu IP dinâmico oferecido por esses serviços. É interessante consultar também: DNS Dinâmico: Como ter no seu site a funcionalidade de whatismyip, check.dyndns ou icanhazip Windows – arquivo batch híbrido com javascript
Uso Edite as variáveis na zona javascript
E faça uma edição correspondente na zona batch
Salve o script com a extensão .cmd em uma máquina Windows qualquer que esteja na mesma rede cujo IP externo você quer atribuir ao host. Crie uma tarefa agendada que o execute a cada x minutos. Se não for detectada nenhuma mudança no IP, o script que se conecta ao cPanel nem será chamado. Testado apenas no Windows 8.1 x64. Não requer permissão de administrador para rodar. Esse script não tem nenhuma checagem contra problemas de conectividade.
Windows – Powershell
Uso
Testado apenas no Windows 8.1 x64. Não requer permissão de administrador para rodar. Esse script não tem nenhuma checagem contra problemas de conectividade. O arquivo batch intermediário é necessário porque, como o Windows é alvo de abusos e o Powershell é poderoso, a MS decidiu bloquear a execução de scripts Powershell por default. Aparentemente é possível agendar uma tarefa para rodar o script diretamente, mas ainda preciso confirmar isso.
Outro dia eu expandirei este texto com exemplos de:
4 comentários
Clique para comentar(Prefira clicar em "Responder" se estiver comentando um comentário)Deixe um comentárioEu coloquei “whatismyip” no título mais para fins de compreensão imediata da finalidade. Eu não pretendo duplicar a funcionalidade desse serviço específico porque ela cresceu além das necessidades do DNS dinâmico. O script a seguir duplica exatamente a funcionalidade e resposta de icanhazip.com e pode facilmente duplicar a resposta de check.dyndns.com com o mero acréscimo de algumas palavras. A finalidade é não depender de terceiros. Se você tem um site, por que não usá-lo? Com o bônus de não ter nenhuma surpresa futura com o dono do domínio avacalhando tudo (direito dele) e obrigando você a mudar seus scripts, como aconteceu com whatismyip.com. O script é decepcionante simples:
Basta salvar isso como, por exemplo, “meuip.php” no seu site e rodá-lo de qualquer lugar. O resultado é idêntico ao de icanhazip.com. Há quem acredite que o conteúdo da variável REMOTE_ADDR pode ser falsificado pelo usuário e induzir uma vulnerabilidade no script, e que por isso você deveria ao menos checar se o valor recebido é mesmo um valor IP, como neste exemplo:
Mas segundo o que é explicado aqui e pelo usuário Achernar aqui, essa preocupação não se justifica, porque REMOTE_ADDR é preenchida pelo servidor www (apache, por exemplo) com o valor na camada de rede, que só pode ser um IP mesmo. Ao contrário de outras variáveis como aquela que identifica o seu browser (HTTP_USER_AGENT) e que podem ter na realidade qualquer texto que o usuário remoto queira. Então você pode usar o primeiro script sem medo.
Clique para comentar(Prefira clicar em "Responder" se estiver comentando um comentário)Deixe um comentárioEste texto é auxiliar da série de textos sobre DNS dinâmico. O seu modem é sempre o primeiro a saber qual o seu IP externo e seria perfeito se existisse um mecanismo padronizado para que ele avisasse quando obtivesse um IP. Infelizmente esse mecanismo não existe e o meio mais “simples” de saber qual o seu IP externo acaba sendo, contra-intuitivamente, perguntar a terceiros! Você pode nem saber o que é um IP externo mas cada site que você acessa sabe qual é o seu, porque essa informação é indispensável e faz parte do protocolo de conexão. Sendo assim, como a maioria dos meus leitores deve saber, há muito tempo sites vem oferecendo uma gambiarra para contornar essa deficiência dos protocolos de conexão à internet: basta abrir a página deles que eles respondem com o seu endereço IP. Entre eles estão:
Mas o que danado é IP externo? Como este texto foi criado primariamente para dar suporte aos meus textos sobre DNS dinâmico eu imagino que a maioria dos leitores não precise ser lembrado do que é isso. Porém muita gente pode cair aqui via Google, então aí vai uma explicação sucinta, que eu posso ou não expandir depois (não tenho tempo agora): Uma das primeiras coisas a confundir os novatos é que cada dispositivo conectado à internet através de um roteador (que pode ser o modem) tem dois endereços IP:
Como explicado acima, o IP externo não é uma informação “óbvia”, depende de você estar conectado ou não à internet e geralmente muda com freqüência. Não é algo que possa simplesmente ser memorizado. Se alguém pergunta a você “qual o seu IP externo?” geralmente está esperando que você verifique ou tenha verificado isso recentemente pelos meios indicados acima ou similares.
2 comentários
Clique para comentar(Prefira clicar em "Responder" se estiver comentando um comentário)Deixe um comentárioNa parte 1 deste texto eu expliquei como criar um “A RECORD” no seu domínio usando o cPanel que aponta para um IP qualquer na internet, imitando o funcionamento de um serviço de DNS dinâmico como o no-ip ou dyndns. Nesta segunda parte eu começo a explicar como automatizar a atualização desse registro. A automação do processo é dividida em duas partes para facilitar a implementação em dispositivos mais simples, como roteadores. E também facilita a implementação e o diagnóstico. AVISO: O script que apresentarei a seguir tem problemas de segurança que você deve conhecer. Preste atenção a tudo o que é explicado antes de usá-lo. Origem A automação do processo de atualização da zona DNS no cPanel foi elaborada por Mitchel Haan e publicada em seu site [link morto] em abril de 2013. O site de Mitchel foi apagado em algum momento entre 5 e 23 de fevereiro de 2015 mas por sorte ainda existe uma cópia na Wayback Machine. De qualquer forma a versão que apresento a seguir é uma adaptação feita por Ethanpil.
UsoA primeira coisa a fazer é preencher toda a seção de variáveis. As duas primeiras podem ser o que você quiser porque servem apenas para identificar você ao executar o script, evitando que terceiros possam remotamente executar o seu script indicando um IP sob controle deles.
As outras variáveis são relacionadas ao seu domínio e sua conta cPanel:
Note o “.” inicial na última variável. Não é erro de digitação. Sem ele o script não funciona. Parâmetros do script
Parâmetros são separados pelo caractere “&”. Cada valor é separado do respectivo parâmetro pelo caractere “=”. Estas são convenções universais e não do script. Salve o script no servidor www. Digamos que tenha sido na raiz do domínio exemplo.com.br e o nome do arquivo seja atualiza.php. Rode o script colocando em qualquer browser, exceto Internet Explorer: http://nome_de_usuario:senha@exemplo.com.br/atualiza.php?hostname=teste&myip=189.70.37.12 Isso atualizará o host teste.exemplo.com.br para apontar para o IP 189.70.37.12 Se tudo estiver OK a resposta do script, no browser, será algo assim:
Na terceira parte desta série de textos eu vou abordar as maneiras de você enviar esse comando para o script automaticamente. Mas é importante que o que expliquei até aqui já esteja funcionando corretamente. Se não está, não adianta procurar a solução na Parte 3.
Problemas de segurança1 – Isso não é jeito de tratar credenciais cPanel O script foi criado com a intenção de rodar no mesmo servidor onde roda o domínio a atualizar. Entretanto isso é preocupante porque como você pode ver, as credenciais cPanel são escancaradas no script:
Qualquer invasor que tenha acesso meramente de leitura ao seu diretório www (e existem infindáveis meios de se conseguir isso) poderá eventualmente esbarrar nesse script e aí… “perdeu playboy”. Com as credenciais cPanel o invasor tem o controle de toda a conta, com todos os seus domínios, www, email, bancos de dados… No meu caso isso seria uma catástrofe. Uma forma de minimizar esse problema é rodar esse script fora do domínio que ele atualiza. Por exemplo, se você já tem um servidor local rodando 24h, que não oferece nenhum serviço para a internet (menos vulnerável), você pode rodar o script nele. Uma “gambiarra” para conseguir isso em uma máquina Windows sem precisar fazer qualquer modificação no script é instalar o XAMPP. Eu simulei isso no meu desktop e funcionou. Mas tenha o cuidado de manter o uso de https na variável $dyndnsCpanel. Dessa forma será bem mais difícil capturar as suas credenciais do cPanel interceptando a conexão entre seu servidor local e o seu domínio:
Se você usar http (nem estou certo de que o cPanel permita) as credenciais cPanel poderão ser interceptadas. Outra forma de tentar minimizar o problema é obfuscar o código PHP. Obfuscação não vai impedir um invasor determinado a descobrir do que se trata, mas dificulta bastante. Se você der um nome ao script que não denuncie seu propósito e obfuscar o suficiente o conteúdo, aumenta muito as chances de que o invasor ache que não vale a pena perder tempo com isso. Deixando escancarado qualquer script kiddie vai ter um orgasmo. Como fazer essa obfuscação precisará ser tema para outro texto. 2 – A conexão com o script pode ser interceptada Estando o script em uma máquina remota, as credenciais de acesso ao mesmo podem ser interceptadas com relativa facilidade, porque são transmitidas claramente no URL: http://nome_de_usuario:senha@exemplo.com.br/atualiza.php?hostname=teste&myip=189.70.37.12 Isso não é problema se no lugar de HTTP o seu domínio usa HTTPS, porque nesse caso até o URL é criptografado. Mas se você não usa HTTPS qualquer pessoa observando o seu tráfego, como o operador do seu provedor de acesso via rádio, poderá assumir o controle de para onde aponta esse hostname. Dependendo do quanto ele seja esperto ele pode conseguir induzir você a fornecer senhas de acesso extras simulando em máquina controlada por ele o dispositivo que você quer acessar, entre outras coisas. Se você rodar o script fora do seu domínio como explicado no item anterior pode minimizar esse problema também. Nota: na primeira revisão deste texto eu afirmei que os serviços de DDNS gratuitos como o no-ip e dyndns também são vulneráveis a interceptação. Isso está parcialmente correto. O no-ip, por exemplo, suporta http e https, mas o simples fato de suportar os dois já é motivo para preocupação porque só Deus sabe que protocolo está usando o danado do roteador, modem ou dvr onde nós colocamos nossas credenciais. Somente interceptando nós mesmos a atualização para termos certeza. 7 comentários
Clique para comentar(Prefira clicar em "Responder" se estiver comentando um comentário)Deixe um comentárioO processo que explico aqui, é inteiramente manual e pouco prático, mas funciona. Entre no cPanel Em Domains, escolha Advanced DNS Zone Editor
Digamos que você queira adicionar o host “teste” no domínio “ryan.com.br”:
Imediatamente após adicionar você já pode testar. Um ping para teste.ryan.com.br deve retornar o IP que você colocou em Address.
Este processo não é prático porque toda vez que o IP mudar você tem que manualmente atualizar o Address no cPanel. Na segunda parte deste texto eu explico como automatizar isso. 5 comentários
Clique para comentar(Prefira clicar em "Responder" se estiver comentando um comentário)Deixe um comentárioEste texto foi escrito para dar suporte a outros textos que postarei mais tarde. Eu não estou ainda satisfeito com a minha explicação por isso o texto pode mudar bastante, mas a teoria que tento explicar até onde sei está correta. Primeiro, vamos fazer uma breve resumo do que constitui um “domínio”…
…E do que é DNS e como funciona:
TTL, do inglês Time To Live (tempo de vida) é o parâmetro que determina a “validade” da resposta do servidor DNS e é parte integrante de todo registro DNS. Se o dispositivo recebe uma resposta do servidor DNS dizendo que o TTL é de x segundos, ele só vai consultar o servidor DNS novamente para aquele host se alguém acessá-lo novamente depois de passados x segundos. Esse parâmetro é praticamente irrelevante no dia a dia, mas você precisa estar atento a ele quando usa qualquer serviço de DDNS. Serviços de DNS dinâmico como o no-ip costumam ter um TTL de 60 segundos. O valor padrão em um serviço de hospedagem como o Hostgator costuma ser 14400 (4 horas). Não é recomendado baixar para menos que 300 (5 minutos) porque o seu provedor pode não gostar do stress desnecessário no servidor DNS dele. E francamente ele tem razão. Tenha em mente que entre você e o host que você quer acessar existem diversos servidores DNS ou “caches” secundários, inclusive em cada um dos seus roteadores. Quando você configura manualmente no seu PC ou dispositivo um servidor DNS você passa por cima de vários, mas no mínimo você deve contar com o cache no seu dispositivo, o do servidor DNS que você configurou e qualquer um depois dele. Para um número “n” de caches TTL >= x <= n * TTL Então, por exemplo, se existirem 3 caches e o TTL for de 4h, o tempo de propagação (o tempo que leva para o dispositivo que fez a consulta receber uma resposta atualizada) será qualquer coisa entre 4h e 12h. Se por acaso você fizer seu primeiro teste de DDNS com TTL de 14400 e mudar o IP, mesmo que você baixe o TTL para 300 pode ter que esperar 4 horas ou mais até poder “ver” essa mudança ter efeito. Confuso? Vamos tentar com um exemplo simples: Servidor DNS configurado na sua máquina: Google (8.8.8.8) Na primeiríssima vez que você acessar teste.ryan.com.br, o Windows não sabe qual é o IP, mesmo que ele saiba o IP default de “ryan.com.br”, porque se trata de outro “host” e vai perguntar ao servidos DNS configurado (o da Google). O servidor da Google também não faz idéia de quem seja (o hostname acaba de ser criado), por isso vai consultar o servidor DNS que tem autoridade sobre o domínio ryan.com.br. A resposta dirá que o TTL é de 14400, assim o servidor da Google só vai perguntar quem é teste.ryan.com.br novamente em 4 horas. Ele repassa a informação para o Windows, que também vai ver esse TTL de 14400 e só vai perguntar novamente ao servidor da Google em 4 horas. Você pode esvaziar o cache DNS do Windows, forçando-o a perguntar mais cedo, mas o servidor da Google ainda acha que o TTL é de 4 horas e não adianta reduzir o TTL de teste.ryan.com.br para 300 nesse meio tempo, porque o servidor da Google só vai tomar conhecimento da redução do TTL quando o prazo expirar e ele fizer uma nova consulta a pedido de alguém. Escolher qualquer outro servidor DNS nesse meio tempo, como o do OpenDNS (208.67.222.222 ou 208.67.220.220) ou um serviço de ping remoto (vai depender de que servidor DNS esse serviço usa) pode acelerar o processo de teste.
1 comentário
Clique para comentar(Prefira clicar em "Responder" se estiver comentando um comentário)Deixe um comentário |
|||||||||||||||||||||||||||
|
Copyright © 2026 Quick Talk - All Rights Reserved |
|||||||||||||||||||||||||||
Aqui foi normal…
Aqui voltou ao normal. É possível que tenha sido o cache do WordPress.
Sim, o cache dá umas enroscadinhas quando atualiza. Eu atualizei (backup feito antes eheh) o meu parao 4.3.1 a uns dias e não deu nenhuma quebra.
Eu ia comentar que você provavelmente não deu um salto tão grande quanto o meu, de 3.1 para 4.3.1. Mas fui fazer uma checagem e descobri que minha ultima atualização foi para a versão 3.6, em outubro de 2013. Eu ainda estou tentando entender como eu podia estar ainda com a versão 3.1. Eu sou meio distraído para certas coisas, mas o Media Manager do QuickTalk certamente não era o da versão 3.1. Essa versão nem suportava drag and drop de imagens ainda.
Bom… o meu salto foi da 4.2.5 para 4.3.1
Realmente da 3.6 pra 4.3.1 teve muitas atualizações ehehe.
Eu não atualizo religiosamente a cada nova versão, eu dou uma lidinha no pontos das atualizações, se for coisa que eu vejo que não me afeta diretamente ou não é bug escandaloso, eu deixo pra lá espero a próxima.
Como eu já te disse no outro post, eu tenho todas as atualizações salvas em backup que fiz, desde a 2.9.2 que foi quando eu migrei do bloger.com.br para o WordPress. E nisso já se vão 15 atualizações feitas.
Mais mudanças:
Atualizei WP-DBManager Versão 2.63 para 2.78
Deletei Watermark RELOADED e Watermark My Image, que nunca funcionaram mesmo.