Esta postagem nasce como reflexão sobre um cenário muito comum dentro das empresas de nossos clientes (e acredito que seja comum também na grande maioria dos provedores de hospedagem web que ainda estão engatinhando), trata-se da condição de suportar ou não scripts hospedados pelos usuários.

Se fossemos analisar pelo ponto de vista técnico, cada usuário deveria ser o único responsável pela manutenção de seus scripts hospedados, e ele deveria ter a competência atenção de, antes de se tornar cliente de um provedor, verificar se as configurações do servidor web que o provedor apresenta são compatíveis com seus scripts, exemplo: Há provedores que não admitem o uso de variáveis globais, outros não permitem CGI FormMail, e por aí vai.

As vezes, alguns de nossos clientes (que utilizam nossos serviços para gerenciamento de seus servidores dedicados) nos colocam em situações adversas por justamente haver, no meio do caminho, um problema que é de competência do programador web e não do sysadmin ou tampouco do provedor de hospedagem de sites. Porém, as vezes isso é difícil de ser compreendido por ambos os lados e é justamente nesta questão que se concentra a razão de nossa postagem.

Em nosso ponto de vista, o provedor não deve – mesmo – prestar suporte de qualquer nível aos scripts dos utilizadores de serviços hosting, porém constitui-se uma oportunidade para o provedor, quando ele consegue fazer o “algo mais” por seu cliente. Quando falo do “algo mais”, me refiro a micro intervenções no código do script do cliente, intervenções esta do tipo: remover um espaço no final da linha; ajustar um “ponto e vírgula” que esta fora do lugar e por aí vai.

No entanto, afirmo: O provedor deve ter o maior cuidado ao se dispor a esta ação! Bastará um único equívoco do provedor para tornar o script do seu usuário ainda pior do que estava antes da intervenção, portanto, seja tardio nesta escolha.

Em nossa micro análise percebemos que, mesmo sem a obrigação de se prestar o suporte direto ou indireto aos scripts de seus usuários, é necessário e de suma importância que o provedor possua um programador web interno para, sempre que possível, dispensar análise sobre casos onde o usuário declare que o script deveria estar funcionando corretamente.

Logo, ter um programador web em seu provedor é uma ação estratégica além de uma garantia contra acusações ao seu provedor, no que tange a configuração e padronização de ambiente. Esta é nossa dica a todos os provedores (sejam micros ou pequeno) que desejam crescer sem depender da sorte ou de incertezas: Contratem um programador web (sem que por vias do outsourcing).

]]> http://blog.sierti.com.br/o-provedor-host-e-responsavel-pelo-suporte-aos-scripts-hospedados-por-seus-clientes/feed/ 0 http://blog.sierti.com.br/avast-identificando-sites-como-infectados-htmlscript-inf/ http://blog.sierti.com.br/avast-identificando-sites-como-infectados-htmlscript-inf/#comments Mon, 18 Apr 2011 11:39:14 +0000 Eltern http://blog.sierti.com.br/?p=451 Alguns internautas, que utilizam o avast! Free Antivirus, andam recebendo alertas de segurança ao acessar algumas páginas eletrônicas (websites). Pesquisando no Google localizamos que esse alerta HTML:Script-inf por ser um falso positivo em razão de uma atualização recente do Avast, conforme relatado nos endereços abaixo:

- http://forum.avast.com/index.php?topic=41771.45 (site oficial do Avast)

- http://www.travou.com.br/site/2011/04/atualizacao-do-avast-detecta-virus-falso-script-inf/

- http://www.bleepingcomputer.com/forums/topic390569.html

As referências vieram do pessoal do provedor de MINAS.

A Microsoft começou a liberar endereços de email terminados com @hotmail.com.BR – vimos isso agora a pouco.
Mas você não conseguirá assegurar seu nome só por que usa um endereço @hotmail.com, ou seja, se você usa fulano @ hotmail.com, outra pessoa poderá registrar fulano @ hotmail.com.BR sem qualquer restrição.

Quer aproveitar? Corrra, quem sabe você ainda não consegue sem email idêntico na terminação .BR!

Todos nós que utilizamos a carteira de cobrança 175 (sem registro) nos boletos bancários Itaú, sofremos com a demora para que o pagamento fique visível no Extrato de Movimentação (Francesa) no Internet Bank, mas há uma forma de antecipar esta consulta.

Na verdade, o valor (a compensação do crédito em nossa conta corrente) só ocorrerá mesmo após 3 dias úteis do cliente ter pago o título (fora da rede de agências Itaú). O que a dica nos mostrará é como ao menos saber que o cliente pagou o título (boleto) com maior agilidade, dispensando assim a imposição de desgaste do comerciante e do cliente, em relação a espera para a efetivação da prestação de serviços ou da entrega da mercadoria.

Mas vamos logo não é mesmo? Você agora saberá como confirmar com apenas um dia útil (contra dois dias úteis do padrão) o titulo pago. Siga os passos abaixo:

1) Após estar devidamente autenticado no Internet Banking do Itaú, clique no menu Cobrança:

2) Agora localize na seção Títulos o link  Baixados e liquidados:

3) Faça agora a inserção da data do último dia útil para obter a listagem dos boletos pagos:

4) Agora, veja a lista das pessoas que pagaram no dia útil anterior:

No caso da nossa empresa, o valor do campo “Nosso Número” é gerado automáticamente por nosso sistema de gestão on-line (referente ao número da fatura ou invoice), e com ele identificamos quem pagou e realizamos a confirmação do pagamento nos sistemas.

Lembrando que pessoa física também pode gerar boleto bancário no Itaú.

Imagine a praticidade e a eficácia desta informação chegando à você com apenas um dia útil? Nós estamos vendo pessoas que estão deixando de usar gateways de pagamentos terceiros (o boleto bancário) em função desta informação. Boleto Itaú compensado (demostrativo) em um dia útil sem pagar comissões a ninguém.

A história toda começa quando você percebe que por algum motivo desconhecido ou sem lógica, seus sites começam a perder visitação, ficam posicionados de forma insatisfatória nos mecanismos de buscas e consequentemente, registra-se um prejuízo por causa disso tudo. O que poucos sabem (ou ignoram) é que para se ter uma intenção de alcançar bons posicionamentos em sites de pesquisa como o Google, ou ainda para aumentar o número de visitantes através de técnicas SEO, é preciso ter seu site hospedado em um provedor que promova algumas adequações, e neste post vamos dar ênfase à RFC2182.

Não adianta nada ter sua página em sites de compartilhamento de links, alcançar muitas referências, ter um planejamento de SEO se na hora H seu site não estiver disponível, mesmo quando você pensa que ele está. Acontece que quando seu site está hospedado em servidores onde o servidor de DNS está na mesma máquina, ou seja, todos os serviços rodam dentro do mesmo servidor, ocorrem diversas falhas que fazem com que diversos internautas (e motores de busca que indexam suas páginas)  não localizem seu site, tendo-o como inexistente e não como, indisponível (se este fosse o caso).

De acordo com a RFC2182, posso transcrever o seguinte:

Leia a RFC para obter todo conteúdo técnico a respeito do porque você nunca deve ter dois servidores de nomes no mesmo servidor. Se você não entender as implicações técnicas e as razões da investigação, sugerimos ler mais. Se você não está preocupado com a potencial perda de e-mail, redução de seu posicionamento no ranking dos motores de busca, ou perda de visitas devido à domínios hospedados sendo relatados como inexistente, em vez de simplesmente temporariamente inacessível (para citar apenas alguns exemplos), durante um tempo de inatividade prolongada, simplesmente ignorar o fato de não ter um servidor DNS secundário externo.

O correto então é possuir dois servidores DNS, geográficamente separados (ou pelo menos em classe de IPs diferentes em máquinas diferentes) para abrigar todas as zonas dns de servidores cpanel, sejam revendas ou não. Um servidor externo já resolve muitos problemas, ou seja, mantenho o servidor DNS padrão de seu embiente e um externo.

Logo podemos compreender que, se você não está seguindo esta recomendação, está colocando em risco os acessos aos sites de seus usuários.

É fácil resolver esta questão, implementando num VPS Linux (servidor dedicado virtual) o cPanel DNS ONLY e realizando os ajustes de interligação desta função. A SIERTI oferece um pacote de 2 (um no Brasil e outro nos EUA) servidores dedicados virtuais gerenciados com o cPanel DNS ONLY instalado e configurado junto ao seu servidor (ou servidores) com cPanel. Fale conosco para obter um orçamento e ter uma atitude técnica que favorecerá seus negócios.

]]> http://blog.sierti.com.br/o-que-e-o-cpanel-dns-only-e-qual-sua-finalidade/feed/ 1