Porque Netenberg não atendeu às minhas expectativas em termos de fantastico 3 então eu decidi perdê-lo completamente. Apesar da correspondência que tivemos há muito tempo e das diretrizes que eu lhes dei para melhorar seu produto a um nível competitivo de instalação e softaculous, chegou ao ponto em que o plug-in precisou ser desinstalado dos servidores Cpanel.. Como não há instruções sobre como remover esse mal-entendido, peguei um tíquete de suporte, eles me deram as seguintes instruções.

rm -rf /var/netenberg/fantastico_de_luxe/
rm -rf /usr/local/cpanel/whostmgr/docroot/cgi/fantastico/
rm -rf /usr/local/cpanel/3rdparty/fantastico*
rm -rf /usr/local/cpanel/base/frontend/*/fantastico
rm -f /usr/local/cpanel/base/frontend/x/cells/fantastico.html
rm -f /usr/local/cpanel/whostmgr/docroot/cgi/addon_fantastico.cgi

Изпълних си командите за чистиха се файловете им като осъзнах нещо важно пичовете изобщо не споменаха как се де регистрира плъгина им от контролният панел 🙄 😆 Мдаа педераски номер но се случва то и аз трябваше да гледам повече. Também havia uma câmara deixando seus arquivos aparentemente esperando retornar como cliente, como eles tinham mais scripts de instalação, como o suporte dizia (não pense que isso é a coisa mais importante) :senhor Verde: . Então, vamos continuar com o estripamento completo:

Este é o passo mais importante a ser tomado antes de excluir todo o resto, porque você se encontrará como um plugin, mas com um ícone no painel de controle, pois ele ainda está registrado.

/usr/local/cpanel/bin/unregister_cpanelplugin /var/netenberg/fantastico_f3/fantastico_f3
rm -rf /usr/local/cpanel/3rdparty/fantastico_f3
rm -rf /usr/local/cpanel/base/frontend/*/fantastico_f3
rm -rf /usr/local/cpanel/bin/fantastico_f3.cpanelplugin
rm -rf /usr/local/cpanel/whostmgr/addonfeatures/fantastico_f3
rm -rf /usr/local/cpanel/whostmgr/addonsfeatures/fantastico_f3
rm -rf /usr/local/cpanel/whostmgr/docroot/addon_plugins/fantastico_f3.jpg
rm -rf /usr/local/cpanel/whostmgr/docroot/cgi/addon_fantastico_f3.php
rm -rf /usr/local/cpanel/whostmgr/docroot/cgi/fantastico_f3
rm -rf /var/cpanel/apps/fantastico_f3_cpanel.conf
rm -rf /var/cpanel/apps/fantastico_f3_whm.conf
rm -rf /var/netenberg/fantastico_f3

Caso você tenha perdido a etapa unregister_cpanelplugi, precisará executar outra etapa extra:

mkdir --parents /var/netenberg/fantastico_f3
cd /var/netenberg/fantastico_f3 && curl -O http://174.120.165.106/fantastico_f3/sources.tar.bz2
cd /var/netenberg/fantastico_f3 && tar --bzip2 --extract --file sources.tar.bz2
/usr/local/cpanel/bin/unregister_cpanelplugin  fantastico_f3
rm -rf /var/netenberg/

O véu agora está fantastico fora do jogo e você pode dormir em paz. Os motivos pelos quais o substituí por um produto concorrente são 3 e é muito simples

  • Eles não têm uma API com a qual eu possa me comunicar se eu quiser fazer adições ou outros feitiços
  • eles não têm ganchos para determinadas ações, para que eu possa desligar e adicionar funcionalidade
  • apoio impertinente bastante lento e pouco adequado nas respostas

ps. paper_lantern и x3 имаше останала икона която се разкарва с

rm  /usr/local/cpanel/base/frontend/paper_lantern/dynamicui/dynamicui_fantastico_f3.conf
rm /usr/local/cpanel/base/frontend/x3/dynamicui/dynamicui_fantastico_f3.conf

Alguns programadores simplesmente nunca aprendem a escrever fluentemente em RFC. Notei muitos arquivos errror_log nos quais um grande número de avisos e avisos estúpidos por não conformidade com os padrões PHP se acumularam.. Em geral, é difícil explicar ao consumidor, que o código que ele colocou é impertinente e precisa ser corrigido. Em geral, percebi que os usuários não se importam com os logs de erros após o código funcionar.. Basicamente, uma abordagem radical é parar completamente os arquivos error_log e quem deseja reproduzi-los, mas, em geral, criará desconforto para muitos usuários. É por isso que estou adotando uma abordagem 2 – super poderes de administração ou 1 festança vermelha. Procure arquivos com o nome error_log com mais de 5 MB (aqui deixo meu valor mais alto, mesmo que 1 MB seja mais que suficiente) e excluindo-os semanalmente. O efeito em questão é alcançado elementarmente com encontrar

find /home/ -name error_log -size +5M -type f -delete

Tudo o que resta é encontrar uma coroa para ser realizada uma vez por semana e temos uma solução muito persistente. No meu caso, parece ok em 1 horas todos os domingos.

0 1 * * 1 find /home/ -name error_log -size +5M -type f -delete >/dev/null 2>&1

Qualquer pessoa que lida profissionalmente com hospedagem na web conhece a ameaça representada por usuários infectados com malware, conchas da web etc. No caso geral, é usado maldet um roteiro nada mau. Distingue-se por 3 coisas

  1. É terrivelmente lento
  2. É terrivelmente lento e se você colocá-lo no modo de monitoramento, ele repreenderá seu servidor
  3. Suporta banco de dados próprio com definições md5 / hexadecimal para código incorreto.

É seu último recurso que o torna útil, porque, entre outras coisas, você pode enviar arquivos que não foram detectados até o momento e entrarão nos bancos de dados posteriormente.. Como eu compartilhei no ponto 1 e 2 sua velocidade é surpreendentemente baixa – com baixa carga da máquina, arquivos de 70k foram verificados em cerca de uma hora e meia. Por esse motivo, comecei a ajudar meu bom amigo ShadowX com malmon – uma alternativa para maldet escrito em python com um pouco mais de flexibilidade. Infelizmente por falta de tempo (principalmente mas não apenas) nós não completamos o projeto, o que não é muito utilizável no momento – existem muitos bugs que precisam ser limpos. Nos últimos dias, tive problemas com clientes infectados com CryptoPHP que tinham enormes arquivos public_html ~ 60k + inods de usuário. Como um total de mais de 200 mil arquivos teve que ser verificado, o que levaria aproximadamente 5+ horas eu decidi ajustar a configuração de maldet, para reduzir os arquivos que serão verificados para um número e tempo razoáveis. Quando peguei o conf, notei as seguintes linhas

# Attempt to detect the presence of ClamAV clamscan binary
# and use as default scanner engine; up to four times faster
# scan performance and superior hex analysis. This option
# only uses ClamAV as the scanner engine, LMD signatures
# are still the basis for detecting threats.
# [ 0 = disabled, 1 = enabled; enabled by default ]
clamav_scan=1

Interessante… Aparentemente, há uma oportunidade de usar ClamAV – que também não difere em sua alta velocidade, mas por que não tentar. Eu instalei rapidamente

/scripts/update_local_rpm_versions --edit target_settings.clamav installed

/scripts/check_cpanel_rpms --fix --targets=clamav

Eu corro o maldet em uma pequena pasta – Não vejo diferença de velocidade e comportamento – ele usou seu scanner perl em vez do clamav. Depois de uma breve pesquisa na fonte de maldet, encontrei as seguintes linhas

 clamscan=`which clamscan 2> /dev/null`
 if [ -f "$clamscan" ] && [ "$clamav_scan" == "1" ]; then
        eout "{scan} found ClamAV clamscan binary, using as scanner engine..." 1
    for hit in `$clamscan -d $inspath/sigs/rfxn.ndb -d $inspath/sigs/rfxn.hdb $clamav_db -r --infected --no-summary -f $find_results 2> /dev/null | tr -d ':' | sed 's/.UNOFFICIAL//' | awk '{print$2":"$1}'`; do

Hmmm, eu fiz um qual amêijoa e para minha grande surpresa, descobri que o clamav não está no CAMINHO, mas o estúpido Cpanel o deixou apenas em / usr / local / cpanel / 3rdparty / bin / de onde ele usa seus binários. Uma solução rápida resolveu o problema:

ln -s /usr/local/cpanel/3rdparty/bin/clamscan /usr/bin/clamscan

Ao digitalizar novamente, a maldet já informa o que foi mencionado acima

{scan} found ClamAV clamscan binary, using as scanner engine...

Depois de já usar o ClamAV maldet, ele termina sua verificação 3-4-5 vezes mais rápido do que antes. O teste mostrou – 70k inod-a esfregou-os por cerca de 25 min que é sobre 3 vezes e meia mais rápido do que antes.

Padrão quando você instala Munin O Cpanel carece de algumas configurações legais que temos que fazer manualmente. За мен един от тях е мониторинга на температурата на дисковете.

Em geral, a configuração é trivial

1. Precisamos determinar o tipo de nossos discos – pode ser um dos seguintes : eles, scsi, Sentou[,auto][,N][+TIPO], usbcypress[,X], usbjmicron[,x][,N], usbsunplus, maravilha, areca,NEM, 3porcelana,N, hpt,L / M / N, megaraid,N, cciss,N, auto, teste. A maneira mais fácil de fazer isso é através de “/proc / ide” ou “/proc / scsi”. Para mim:

# cat /proc/scsi/scsi
Attached devices:
Host: scsi0 Channel: 00 Id: 00 Lun: 00
  Vendor: ATA      Model: WDC WD1003FBYZ-0 Rev: 01.0
  Type:   Direct-Access                    ANSI  SCSI revision: 05
Host: scsi1 Channel: 00 Id: 00 Lun: 00
  Vendor: ATA      Model: WDC WD1003FBYX-0 Rev: 01.0
  Type:   Direct-Access                    ANSI  SCSI revision: 05
Host: scsi4 Channel: 00 Id: 00 Lun: 00
  Vendor: ATA      Model: TOSHIBA DT01ACA1 Rev: MS2O
  Type:   Direct-Access                    ANSI  SCSI revision: 05

 

 

Como você pode ver eu tenho 3 Tipo de disco ATA.

2. За да почнем да следим температурата трябва да опишем в munin node дисковете ни. В файла /etc/munin/plugin-conf.d/hddtemp_smartctl добавяте записи от следният тип

# cat /etc/munin/plugin-conf.d/hddtemp_smartctl
[hddtemp_smartctl]
user root
env.drives sda sdb
env.args_sda -d ata
env.args_sdb -d ata

 

Podemos fazer um teste de nossa futura configuração da seguinte maneira

# env drives="sda sdb sdc" args_sda="-d ata" args_sdb="-d ata" args_sdc="-d ata"  /etc/munin/plugins/hddtemp_smartctl
sda.value 32
sdb.value 33
sdc.value 33

 

Se você receber valores, tudo está bem. Se você receber um erro, verifique se tudo está descrito corretamente. Você deve reiniciar seu munin e esperar 10-15 min para preencher alguns dados e começar a desenhar um gráfico. Você pode verificar /var/log/munin/munin-node.log quanto a erros e solução fácil de problemas.

Se você deseja receber um email em uma temperatura crítica do disco, adicione uma descrição para a temperatura crítica:

[example.com]
    address 127.0.0.1
    use_node_name yes
    hddtemp_smartctl.sda.critical 55
    hddtemp_smartctl.sdb.critical 55

Hoje decidi fazer alguns testes em uma instalação limpa do Cpanel para a qual eu precisava de vários usuários. Como não queria sobrecarregar os servidores em execução com arquivamento em lote e transferência de arquivos, usei os arquivos da noite anterior. Transferi todos os arquivos para / home e descobri que o Cpanel não oferece mais recuperação 1 conta por meio da GUI e da CLI. Através da GUI, como não havia como receber o número, decidi enganar com cli um script restorepkg. Seu uso é infinitamente simples

/scripts/restorepkg username.tar.gz

Como a ação é repetida para cada usuário separadamente. Ao tentar usar * em vez do nome de usuário, o script me interrompeu diretamente, por isso deve ser abordado um pouco mais elegante –

archives=$(ls /home/ | grep tar.gz)

for archive in $archives

do

/scripts/restorepkg --force $archive

done

Agora uma explicação rápida. Fazemos uma lista de todos os arquivos e os enviamos para os arquivos variáveis. Depois, examinamos o item da lista por item, iniciando a descompactação de cada arquivo separadamente.. Ninguém sabe o quão complicado e interessante é por que os caras da Cpanel não usaram essa solução para muitos arquivos.