chuvadenovembro

Maravilha pessoal, Era exatamente o problema do arquivo "/includes/hooks/cancel_paghiper_slip.php" Fiz a edição do arquivo, mas apresentava erro. Então baixei o arquivo conforme a orientação da ultima postagem. O que achei curioso é que baixei esse modulo hoje e esse arquivo veio com esse problema... O arquivo que eles criaram para sincronizar os pagamentos caiu como uma luva kkkkkkkk "paghiper_force_sync.php" Estávamos nos preparando para fazer um plantão aqui de conferencia de pagamentos em pleno sabadão kkk Como aqui só usamos paypal como pagamento alternativo e ele vira e mexe não faz a confirmação de pagamento, então nem vai dar pra saber se realmente afetou ele hehehe Tudo ok por aqui pessoal

Pessoal, Ontem eu atualizei o modulo do paghiper para mais recente até essa data "2.0.3", mas hoje eu recebi os emails de pagamento do paghiper, o whmcs registrou os pagamentos em transações, no entanto o whmcs não confirmou o pagamento dessas faturas... Ou seja, o paghiper enviou para o whmcs as informações de pagamento, mas não entendi por qual razão não confirmou o pagamento (Consequentemente as faturas estão em aberto). Caso alguém tenha passado por um problema similar e puder dar alguma dica ficarei grato, não estou querendo voltar o modulo antigo... Brigadão

Eu tive um problema estranho com um servidor faz muitos meses, o serviço de dns estava praticamente bloqueado no directadmin. Veja se esse link ajuda a resolver o problema: https://forum.directadmin.com/threads/howto-setup-your-nameservers-real-beginners-guide.26937/

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?

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...