lyra

Tive a mesma demanda há alguns meses e acabei optando por um Macbook Pro M1. Não me adaptei com a forma que o IpadOS trata o monitor externo... A imagem fica com bordas pretas, não aproveita 100% da tela. Eu pretendia utilizar um único equipamento para tudo (ipad no escritório, em casa, na rua etc.) Mas para quem não precisa de um monitor, é perfeito.

Já vi gente caindo dentro de um buraco que tinha em uma das salas de colocation, no datacenter Data Corpore, centro do Rio de Janeiro.

Ao prestar serviços de hosting como MEI, o CNAE não terá relevância quando a cobra fumar. A nossa categoria depende do CNAE 63.11-9-00. Esteja preparado para multa, juros e correção. Ainda pode sobrar pro cliente por não ter validado o tributo corretamente.

Sugiro rbldnsd. Informações relevantes: http://www.blue-quartz.com/rbl/ Eu usava um DNSBL próprio em todos os meus servidores, mas acabei desativando (assim como SpamAssassin) depois que implementei o serviço (não DNSBL) SPFBL.

Se o VestaCP também utiliza Dovecot, não deveria ter problemas. Apague os arquivos com o nome dovecot.index para que um novo índice seja gerado. Caso o problema persista, migre com imapsync: http://imapsync.lamiral.info O script sync_loop_unix.sh disponibilizado pelo próprio imapsync facilita bastante quando são muitas contas.

Esse comando executa algum script php? Qual o comando? Tente atingir o objetivo de outras formas. Por exemplo, se está usando wget, teste curl ou lynx. Enviado de meu ONEPLUS A5000 usando Tapatalk

1. Confirme se o crond está em execução. service crond status / systemctl status crond.service (se CentOS 7) 2. Confirme se a sua tarefa esta sendo executada: tail -f /var/log/cron 3. Direcione o output do comando para algum arquivo e valide o que está sendo armazenado: Um exemplo: */1 * * * * /SEU_COMANDO > /home/login_cpanel/public_html/cron_output 2>&1 Caso ainda assim não consiga identificar e solucionar o problema, habilite acesso shell nessa conta cPanel, acesse por SSH com usuário/senha e dispare exatamente o mesmo comando.

Muitos também pecam no MX. O CloudFlare publica um MX 'dc-xxx.cloudflare.com'. Mas basta disparar 'host dc-xxx.cloudflare.com' para obter o IP do MX, que na grande maioria dos casos é o mesmo do servidor web. Enviado de meu ONEPLUS A5000 usando Tapatalk

Os repositórios oficiais inclusos na distribuição foram desligados. Se realmente depende do CentOS 5, utilize o repositório Vault: http://vault.centos.org

Visualizou toda a linha ou somente "Mozilla"? Acesse um dos seus ambientes de revenda e busque por esse user-agent. Ouso afirmar que você não vai encontrar nenhum registro. Sugeri o bloqueio de somente uma compilação específica, não todas as versões. [] 's Enviado de meu ONEPLUS A5000 usando Tapatalk

Excepcionalmente neste caso, é um simples flood de get. Provavelmente estão utilizando um script bunda desenvolvido em perl. O autor do tópico é root no servidor, correto? Aplique: iptables -A INPUT -p tcp --dport 80 -m string --algo bm --string "Mozilla/5.0 (X11; U; Linux x86_64; de; rv:1.9.2.8)" -j DROP Enviado de meu ONEPLUS A5000 usando Tapatalk

O único problema que está tendo é sobrecarga de CPU e RAM, correto? Imagino que aquela proteção captcha do CloudFlare seja suficiente para barrar esse flood de get. Caso não seja, bloqueie esse HTTP_USER_AGENT no seu .htaccess (será retornado 403 forbidden, o consumo de recurso é mínimo). Também é possível bloquear em nível de rede, no próprio iptables, mas é mais complexo e muito importante que saiba o que está fazendo, para não acabar bloqueando o que não deve.

Como administrador de dois /21, eu digo: Não adianta vocês quebrarem a cabeça, na maioria dos casos o problema não é você, é o seu vizinho. O culpado? O responsável pela rede que faz vista grossa. A Microsoft não tem pena. Quando o responsável não faz o acompanhamento no SNDS e mesmo que somente um único IP atinja vários spamtraps, ela bloqueia aleatoriamente IPs do mesmo range, para gerar problemas e chamar a atenção dos responsáveis. Falo por experiência própria, pois quando assumi esse gerenciamento, vi que eles haviam bloqueado IPs que nunca foram utilizados publicamente, sempre foram usados em equipamentos internos (nunca tiveram tráfego na porta 25). Após três meses notificando, suspendendo e até mesmo expulsando clientes (não tenho interesse nesse tipo de cliente, o meu foco é corporativo), a situação foi normalizada.

Você está executando o PHP em modo CGI. O EA3 também faz isso quando executado em modo CGI. Altere o modo de execução para suPHP. Obs: Atualmente tenho utilizado PHP-FPM em todos os meus servidores, o ganho de performance é bastante perceptível. Ele também não exibe o caminho do script que está sendo executado, mas quando necessário, valido no log de acessos do domínio (/etc/httpd/domlogs/login_cpanel).

Eso no es posible. Eu sempre mantenho uma licença sem uso para não ter dor de cabeça em casos como este. Quando surge um cliente querendo testar o cPanel em um IP que já teve licença, abro um ticket na buycpanel e solicito realocação da licença no IP. Também tenho costumo de utilizar essa licença em ambiente de testes.

Vai de imapsync que é sucesso: http://imapsync.lamiral.info/#DOC_BASIC

Se ainda está iniciando, inicie da forma correta. Arranque esse Windows que tudo vai ficar muito mais fácil. Quando li o título do tópico vim com o intuito de ajudar, mas Windows não é comigo :(.

Não vi nada suspeito. Quando obter retorno do suporte WHMCS, compartilhe a solução conosco :)

Depura a execução do processo PHP referente ao seu acesso com lsof. lsof -p ID_DO_PROCESSO Em 90% dos casos como este (não estou afirmando que é o seu caso), me deparo com o sistema do cliente estabelecendo conexão com algum servidor remoto.

É bem simples. Faz o download do freetds-stable.tar.gz, extrai, compila e habilita o módulo mssql no PHP utilizando aquele esquema "raw opts" do cPanel. Já vi alguns casos em que a conexão só foi estabeleida após definir "tds version = 8.0" no freetds.conf. No entanto, cada caso é um caso e nem sempre é necessário. Tenta aí seguindo as instruções que passei, se não conseguir me envia uma MP.

É difícil fornecermos qualquer sugestão sem avaliarmos o ambiente, mas eu solucionaria da seguinte forma: 1. Inicie o MySQL em modo de recuperação O modo de recuperação não permite gravação, apenas leitura e deve ser utilizado exclusivamente para gerar dumps. 2. Reinstale o MySQL (ou simplesmente mova o /var/lib/mysql para /var/lib/bk.mysql e crie um novo /var/lib/mysql com os devidos chmod e chown) 3. Restaure o dump full (mysqldump --all-databases ..) Caso não tenha conhecimento para seguir as orientações acima, procure um técnico.

O cenário ficou um pouco confuso. O problema ocorre com o destinatário root @ hostname_do_seu_servidor? Se sim, lembre-se que root @ hostname_do_servidor não existe, pois o domínio utilizado como hostname não pode receber e-mails :) Acesse WHM -> Edit System Mail Preferences e cadastre o seu e-mail em "Forward mail for “root” to", para que o seu e-mail seja o destinatário dessas mensagens.

Ta explicado :)

01.03.06 - Hospedagem para a internet 01.03.07 - Serviços de datacenter, parque tecnológico ou congêneres não seriam válidos? Seguindo as orientações do contador, nós declaramos os serviços prestados dessa forma (01.03.06) e nunca tivemos problemas.

Após visualizar o erro em seu navegador, busque pelos logs que foram gerados pelo seu IP no Apache: cat /usr/local/apache/logs/error_log | grep "IP" Substitua IP pelo seu endereço IPv4 público.