Ĉar netenberg tute ne konformis al miaj atendoj pri fantastico 3 do mi decidis perdi ĝin tute. Въпреки кореспонденцията която водихме преди много време и насоките които им дадох за подобряване на продукта им до конкурентно способно ниво на softaculous и installatron се стигна до момента в който трябваше да бъде деинсталиран техният плъгин от Cpanel сървърите ми. Тъй като няма инструкции как се премахва това недоразумения вдигнах тикет на support-а те ми дадоха следните инструкции.

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

Изпълних си командите за чистиха се файловете им като осъзнах нещо важно пичовете изобщо не споменаха как се де регистрира плъгина им от контролният панел 🙄 😆 Мдаа педераски номер но се случва то и аз трябваше да гледам повече. Ankaŭ ĉambro lasis siajn dosierojn ŝajne esperante reveni kiel ilia kliento, ĉar ili havis la plej multajn instalajn skriptojn kiel subteno diris (Ne pensu, ke ĉi tio estas la plej grava afero) :mrgreen: . Do ni daŭrigu kun la kompleta truado:

Ĉi tio estas la plej grava paŝo, kiu devas fari antaŭ ol forigi ĉion alian, ĉar vi tiam trovos ke vi estis kromaĵo sed kun ikono en la kontrolpanelo ĉar ĝi ankoraŭ estas registrita.

/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

En la okazo ke vi maltrafis la unregister_cpanelplugi-paŝon, vi devas ludi ankoraŭ unu paŝon:

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/

La vualo nun estas fantastika el la ludo kaj vi povas dormi pace. La kialoj mi anstataŭigis ĝin per konkurenciva produkto estas 3 kaj ĝi estas tre simpla

  • Ili ne havas API kun kiu mi povas komuniki se mi volas fari aldonojn aŭ iujn aliajn sorĉojn
  • ili ne havas hokojn por iuj agoj, por ke mi pendigu kaj aldonu funkciojn
  • naŭza subteno sufiĉe malrapida kaj ne tre adekvata en iliaj respondoj

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

Iuj programistoj simple neniam lernos verki flue sur RFC. Mi rimarkis multajn dosierojn errror_log en kiuj amasiĝis multe da stultaj avertoj kaj avizoj pri nekonformeco kun PHP-normoj.. Ĝenerale malfacilas klarigi al la konsumanto, ke la kodo li enigis estas naŭza kaj bezonas esti riparita. Ĝenerale mi rimarkis, ke uzantoj ne zorgas pri eraraj ŝtipoj post kiam ilia kodo funkcias. Esence, radikala alproksimiĝo estas ĉesi tute la erarojn_logajn dosierojn kaj kiu volas ludi ilin, sed ĝenerale ĝi kreos malkomforton por multaj uzantoj. Tial mi paŝas al alproksimiĝo 2 – administraj superpotencoj aŭ 1 ruĝa baso. Serĉi dosierojn nomitajn eraro_logoj pli grandaj ol 5MB (ĉi tie mi lasas mian valoron pli alta kvankam 1MB estas pli ol sufiĉa) kaj forigante ilin ĉiusemajne. La efikon en demando atingas elementa kun trovi

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

Lin sola kiu restas en krono por esti realigita unufoje semajne kaj ni havas tre konstantan solvon. En mia kazo ŝajnas bone eniri 1 horoj ĉiun dimanĉon.

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

Ĉiu, kiu traktas profesie kun reteja gastigado, konas la minacon prezentitan de infektitaj uzantoj kun malware, retaj ŝeloj ktp. En la ĝenerala kazo ĝi estas uzata maldeto ne malbona skripto. Ĝi distingiĝas per 3 aferoj

  1. Ĝi estas terure malrapida
  2. Ĝi estas terure malrapida kaj se vi metas ĝin en monitoradon, ĝi skoldos vian servilon
  3. Elportas propran datumbazon kun md5 / heksaj difinoj por malbona kodo.

Ĝi estas ĝia lasta trajto, kiu faras ĝin utila, ĉar, interalie, vi povas sendi dosierojn, kiuj ĝis nun ne estis detektitaj kaj eniros la datumbazojn en posta stadio.. Kiel mi dividis en punkto 1 kaj 2 ĝia rapideco estas ŝoke malalta – ĉe malalta maŝina ŝarĝo, 70k dosieroj estis skanitaj en ĉirkaŭ unu horo kaj duono. Por tio mi komencis helpi mian bonan amikon ShadowX Malmo – alternativo al maldet skribita en pitono kun iom pli da fleksebleco. Bedaŭrinde pro manko de tempo (ĉefe sed ne nur) ni ne kompletigis la projekton, kio ne tre uzeblas nuntempe – estas multaj eraroj, kiuj devas esti forigitaj. En la pasintaj tagoj mi havis problemojn kun klientoj infektitaj per CryptoPHP, kiuj havis grandegajn publik_html-dosierojn ~ 60k + uzantajn inodojn. Ĉar entute pli ol 200k dosieroj devis esti skanitaj, kio daŭras proksimume 5+ horojn mi decidis agordi la agordon de maldeto, redukti la dosierojn skanitajn al akceptebla nombro kaj tempo. Dum mi reprenis la konfiton, mi rimarkis la jenajn liniojn

# 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

Interesaj… Ŝajne estas ebleco uzi ClamAV – kiu ankaŭ ne diferencas pro sia alta rapideco sed kial ne provu ĝin. Mi rapide instalis ĝin

/scripts/update_local_rpm_versions --edit target_settings.clamav installed

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

Mi kuras la maldetekton sur malgranda dosierujo – Mi ne vidas diferencon en rapideco kaj konduto – li uzis sian perlan skanilon anstataŭ la klamon. Post mallonga fosado tra la fonto de maldeto, mi trovis la jenajn liniojn

 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, mi faris unu kiu clamscan kaj al mia granda surprizo mi trovis, ke clamav tute ne estas en la PATRO, sed la stulta Cpanel lasis ĝin nur en / usr / local / cpanel / 3rdparty / bin / de kie li uzas siajn binarojn.. Rapida ln solvis la problemon:

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

Kiam re-skanado, maldeto jam raportas ĉi-supre

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

Post jam uzado de ClamAV-maldeto, ĝi finas sian skanadon 3-4-5 fojojn pli rapide ol antaŭe. La testo montris – 70k inod-a frotis ilin por ĉ 25 min kiu temas 3 fojojn kaj duonon pli rapide ol antaŭe.

Defaŭlta kiam vi instalas Munin Al Cpanel mankas kelkaj belaj agordoj, kiujn ni devas fari mane. За мен един от тях е мониторинга на температурата на дисковете.

Ĝenerale, la agordo estas bagatela

1. Ni bezonas determini la tipon de niaj diskoj – ĝi povas esti unu el la jenaj : ili, scsi, sidis[,aŭtomobilo][,N][+TIPO], usbcypress[,X], usbjmicron[,x][,N], usbsunplus, marvell, areca,NENIU, 3vazoj,N, hpt,L / M / N, megaraido,N, cciss,N, aŭtomobilo, testo. La plej facila maniero fari tion estas per katoj “/proc / ide” aŭ “/proc / scsi”. Al mi:

# 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

 

 

Kiel vi povas vidi, mi havas 3 ATA-disko-tipo.

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

 

Можем да ударим тест на нашият бъдещ конфиг по следният начин

# 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 vi ricevas eraron, vi devas kontroli, ĉu ĉio estas priskribita ĝuste. Vi devas rekomenci vian muninan kapon kaj atendi 10-15 min por populigi iujn datumojn kaj komenci desegni grafikaĵon. Vi povas kontroli /var/log/munin/munin-node.log pri eraroj kaj facilaj problemoj.

Se vi volas ricevi retpoŝton je kritika disko-temperaturo, vi devas aldoni priskribon por la kritika temperaturo:

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

Hodiaŭ mi decidis fari iujn provojn pri pura Cpanel-instalaĵo, por kiu mi bezonis plurajn uzantojn. Ĉar mi ne volis ŝarĝi la kurantajn servilojn per batch-arkivado kaj dosiera translokigo, mi uzis la arkivojn de la antaŭa vespero. Mi trapasis ĉiujn arkivojn al / hejmen kaj trovis, ke Cpanel ne plu ofertas resaniĝon 1 konto ambaŭ per GUI kaj per CLI. Per GUI ĉar ne estis maniero ricevi numeron, mi decidis forigi per cli la restaŭkkriptan skripton. Ĝia uzo estas ege simpla

/scripts/restorepkg username.tar.gz

Kiel la ago ripetas por ĉiu uzanto aparte. Kiam vi provas uzi * anstataŭ la uzantonomo la skripto rekte fortranĉis min, do ĝi devas esti alproksimigita iom pli elegante –

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

for archive in $archives

do

/scripts/restorepkg --force $archive

done

Nun rapida klarigo. Ni fabrikas liston de ĉiuj arkivoj kaj puŝas ĝin en la ŝanĝiĝantajn arkivojn, poste ni trairas la liston per ero komencante la malplenigon por ĉiu arkivo aparte. Neniu scias kiel komplika kaj interesa kial la uloj de Cpanel ne uzis tian solvon por multaj dosieroj.