chuvadenovembro

Por aqui também já atualizei e sem nenhuma surpresa.

Na madrugada eu fiz alguns testes e se fizesse a atualização do cpanel (nesses servidores que apresentaram erro), o problema voltava a ocorrer...neste caso, pra não correr o risco, vou deixar pra sexta esse update hehehe

Pessoal, Hoje tivemos este problema em alguns servidores aqui, após a atualização do cpanel, o serviço mysql caiu e não voltava mais (servidores com mariadb)... Notei que vários arquivos foram modificados: /usr/bin/aria_chk: FAILED /usr/bin/aria_dump_log: FAILED /usr/bin/aria_ftdump: FAILED /usr/bin/aria_pack: FAILED /usr/bin/aria_read_log: FAILED /usr/bin/innochecksum: FAILED /usr/bin/mariadb_config: FAILED /usr/bin/myisamchk: FAILED /usr/bin/myisam_ftdump: FAILED /usr/bin/myisamlog: FAILED /usr/bin/myisampack: FAILED /usr/bin/my_print_defaults: FAILED /usr/bin/mysql: FAILED /usr/bin/mysqlaccess: FAILED /usr/bin/mysqladmin: FAILED /usr/bin/mysqlbinlog: FAILED /usr/bin/mysqlcheck: FAILED /usr/bin/mysql_config: FAILED /usr/bin/mysqld_multi: FAILED /usr/bin/mysqld_safe: FAILED /usr/bin/mysqld_safe_helper: FAILED /usr/bin/mysqldump: FAILED /usr/bin/mysql_embedded: FAILED /usr/bin/mysqlimport: FAILED /usr/bin/mysql_plugin: FAILED /usr/bin/mysqlshow: FAILED /usr/bin/mysqlslap: FAILED /usr/bin/mysql_tzinfo_to_sql: FAILED /usr/bin/mysql_upgrade: FAILED /usr/bin/mysql_waitpid: FAILED /usr/bin/perror: FAILED /usr/bin/replace: FAILED /usr/bin/resolveip: FAILED /usr/bin/resolve_stack_dump: FAILED /usr/sbin/mysqld: FAILED Pesquisei e rapidamente encontrei um tópico no cpanel com informações uteis para resolver o problema: Mas esse tópico simplesmente sumiu alguns minutos depois... https://forums.cpanel.net/threads/mariadb-failing-to-start.662601/ Aqui eu fiz o procedimento e realmente resolveu o problema, no entanto, ao atualizar o cpanel, o problema volta a acontecer... Acredito que vamos precisar verificar junto ao suporte do cpanel como resolver de forma definitiva. Alguém mais com esse problema?

Show de bola, quando o pagamento está reservado ele exibe no wmcs também? é necessário exec ativo no php para rodar esse report?

Os dois servidores que tenho de backup lá está com uptime de 12 horas.

Para instalar e ativar o spamassassin é necessário fazer esse procedimento: https://help.directadmin.com/item.php?id=36

Eu tive um problema semelhante, mas no directadmin, o arquivo desaparecia depois de concluir o upload via ftp, olhando logs não encontrava nada e solução foi exatamente a mesma, alterar de pureftp p/ proftp...

Eu fico pensando o trabalho que daria pra trabalhar com esse site. Uma vez achado o novo servidor, quanto tempo demoraria para migrar todos os dados para o novo servidor... O servidor de backup precisa ficar em outro data center, mas o ideal seria próximo, pois em caso de desastre deve ser bem tenso precisar aguardar o envio desses dados... Se um dos discos apresentar falha também deve ser maior transtorno... Dependendo do tamanho do banco de dados, acho que eu transformaria o servidor de backup em um espelho para ter redundância em caso de necessidade...seria possível isso? (tudo via rsync) Por curiosidade, um site com essa quantidade de dados que deve exigir enormes desafios, também tem necessidade de uptime de 99.9% por exemplo?

Fiquei curioso, são 30tb mesmo ou você diz 30gb?

Aqui usávamos o moip para pagamento via cartão de crédito, fizemos uma mudança do cpanel para directadmin em nosso servidor então tivemos problemas com os modulos do moip (versão do ioncube). Fiz uma reflexão e aqui, notamos que a maioria dos clientes que pagavam via CC faziam o pagamento IMEDIATAMENTE após suspensão do serviço, para o retorno automático reativar novamente... Ou seja, tínhamos que ter um modulo pago, com criptografia que no final das contas atendia clientes que tem a cultura de pagar bem atrasado. Então decidimos remover o pagamento via CC, ainda temos paypal, que na maioria das vezes não funciona o retorno e depende de verificação manual na maioria das vezes.

Supondo que fez a instalação do directadmin, o usuário padrão criado é admin...é esse usuário e a senha dele que deverá configurar no whmcs. Com esse usuário, você será capaz de criar revendas de hospedagens no directadmin.

Experimente revisar, principalmente se a pasta cron estiver fora da pasta public_html (incluindo arquivo de configuração dentro dessa pasta),

Já aconteceu comigo de ter configurado o whmcs com o usuário root, na verdade os dados de acesso precisam ser do usuário criado no directadmin. Quem sabe é uma situação semelhante...

Achei interessante, mas não é tenso deixar exec ativo nos servidores compartilhados para manter esse monitoramento? Pergunto porque vi que é requisito para ele funcionar...

Isso ai me lembrou a época que o pessoal utilizava xbox desbloqueado na live kkk Pela descrição do produto no site é declarado que tem pegadinha do malandro nessa licença ai... Resta saber o que acontece com o servidor com esse tipo de licença.