Din moment ce netenberg niciodată nu a trăit până la așteptările mele pentru Fantastico 3 așa că am decis să arunce în aer off totalka. Cu toate că corespondența pe care am avut mult timp în urmă și pe care le-a dat liniile directoare pentru îmbunătățirea produsului lor la un nivel competitiv Softaculous și Installatron a ajuns la momentul în care a trebuit să fie dezinstalat lor plug-in de la serverele Cpanel. Din moment ce nu există instrucțiuni cu privire la modul de a elimina această neînțelegere bilet ridicat de sprijin și mi-au dat aceste instrucțiuni.

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

Изпълних си командите за чистиха се файловете им като осъзнах нещо важно пичовете изобщо не споменаха как се де регистрира плъгина им от контролният панел 🙄 😆 Мдаа педераски номер но се случва то и аз трябваше да гледам повече. De asemenea, el a lăsat o grămadă de dosare lor, evident, sper să fie înapoi ca clientul lor, așa cum au avut instalarea multe script-uri după cum a spus act de sprijin (Nici un cuvânt nu este lucrul corect) :lol: . Așa că să continuăm cu eviscerare completă:

Acesta este cel mai important pas care trebuie făcut înainte de toate suprascriere altceva pentru că atunci se va termina, dar a fost plugin icon în Panoul de control, deoarece nu este încă înregistrat.

/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

În cazuri ați ratat pas unregister_cpanelplugi având să joace o etapă suplimentară:

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/

Fantastico voal deja este în afara jocului și poți dormi liniștit. Motivele pentru care sa schimbat cu produs competitiv sunt 3 și foarte simplu

  • Nr API pe care le pot comunica dacă doriți să faceți adăugiri sau orice alte vrăji
  • Nu există cârlige în anumite acte pot fi atașate la tipul și funcționalitatea
  • sprijin rău destul de lent și nu foarte adecvate în răspunsurile lor

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

Unii dezvoltatori pur și simplu nu vor învăța să scrie în mod competent în RFC niciodată. Am observat multe fișiere errror_log care s-au acumulat un număr mare de idioților și de avertizare și o notificare pentru nerespectarea standardelor PHP. În general, este dificil de explicat utilizatorului, acel cod care se pune este rău și trebuie reparate. În general, am observat că consumatorii nu excita eroare jurnal-s după codul lor de lucru. În principiu, abordare radicală este de a opri complet fișiere error_log și care vrea să le ruleze, ci ca un întreg va crea disconfort pentru utilizatori destul. Așa că strângeți să se apropie 2 – admin sau super-puteri 1 Ред bash. Căutarea fișierelor pe nume dimensiune error_log mai mult de 5MB (aici ma costat o las la mare, chiar dacă 1MB este mai mult decât suficient) și ștergerea lor săptămânal. Acest efect este realizat prin simpla găsi

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

Rămâne doar să se prăbușească în coroana care urmează să fie efectuată o dată pe săptămână și să aibă o decizie destul de persistentă. În cazurile mele pare a AC în 1 pm în fiecare duminică.

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

Oricine care este angajat în web hosting știe ce amenințare sunt utilizatori infectate cu malware, coji de web etc. În cazuri această utilizare generală h nu un script rău. acesta dispune de 3 lucruri

  1. Este teribil de lent
  2. Este teribil de lent și, dacă-l lăsa în modul de monitorizare va izgavri server de tine
  3. Își menține propria bază de date de definiție MD5 / hex de cod rău.

Ultima caracteristică doar o face utilă, pentru că în afară de orice altceva poate sabmitvash fișiere care nu au fost detectate până în prezent, iar într-o etapă ulterioară va intra în bazele de date. Așa cum am împărtășit la punctul 1 și 2 Viteza este foarte scăzută – la încărcare mică fișierul mașină 70K este scanat timp de aproximativ o oră și jumătate. Din acest motiv, am început să ajute bunul meu prieten cu ShadowX Malmo – maldet alternativă scrisă în Python cu puțină flexibilitate. Din păcate, lipsa de timp (în principal, dar nu numai) nu am terminat proiectul, care în acest moment nu este foarte ușor de utilizat – există mai multe bug-uri care trebuie să fie eliminate. In ultimele zile am avut probleme cu clienții infectați cu CryptoPHP care au avut fișiere de mari public_html ~ 60k + inod-și Utilizator. Din moment ce numărul total a trebuit să fie scanat peste 200k fișier care aproximativ ar lua 5+ ore am decis să tune configurația maldet, pentru a diminua fișierele care vor fi scanate într-un număr mai rezonabil și timp. In timp ce iau confit observat următoarele linii

# 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

Interesant… Se pare că există posibilitatea de a utiliza ClamAV – care oferă, de asemenea, viteza mare, dar de ce nu încercați. A instalat rapid

/scripts/update_local_rpm_versions --edit target_settings.clamav installed

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

Maldet-rula și într-un dosar mic – Nu văd nici o diferență în viteză și comportament – El folosește său de scanare sa-perl de schi în loc de cea a CLAMAV. După o scurtă cernerea prin sursa de maldet a constatat următoarele linii

 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

Da a făcut o care clamscan и за моя голяма изненада открих че clamav изобщо не е в PATH-a ами тъпият Cpanel го е оставил само в /usr/local/cpanel/3rdparty/bin/ от където той си използва бинарките. Един бърз ln реши проблема:

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

При повторно сканиране maldet вече горно съобщава

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

След като вече използва ClamAV maldet приключва сканирането си 3-4-5 пъти по бързо в сравнение с преди. Теста показа – 70к inod-а ги изтъркла за около 25 мин което си е около 3 пъти и половина по бързо в сравнение с преди.

În mod implicit atunci când instalați Munin Cpanel lipsesc într-un fel de configurare care trebuie să le facă cu mâna. За мен един от тях е мониторинга на температурата на дисковете.

În general, configurația este banală

1. Trebuie să identificăm tipul de drive-urile noastre – aceasta poate fi una dintre următoarele : ei, scsi, sat[,auto][,N][+TIP], usbcypress[,X], usbjmicron[,X][,N], usbsunplus, Marvell, Areca,N/E, 3articole,N, HPT,L / M / N, MegaRAID,N, cciss,N, auto, Test. Cel mai simplu mod este printr-o pisica “/proc / ide” sau “/proc / scsi”. mă:

# 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

 

 

Așa cum se vede au 3 Tip de disc ATA.

2. Pentru a începe să se monitorizeze temperatura ar trebui să descrie în nodul Munin ne conduce. În fișierul /etc/munin/plugin-conf.d/hddtemp_smartctl adăugați intrări de tipul următor

# 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

 

Ne putem lovi testul de configurare noastre viitoare în felul următor

# 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

 

Dacă obțineți valori înseamnă că totul este în regulă. Dacă obțineți o eroare ar trebui să verificați că totul s-a descris în mod corect. Ar trebui să reporniți Munin din cap și tu și așteptați 10-15 min la date mai puțin populate și să înceapă să atragă grafică. Можете да проверите /var/log/munin/munin-node.log за грешки и по лесното им отстраняване.

Ако искате да получавате email при критична температура на дисковете трябва да добавите описание за критична такава:

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

Astăzi am decis să fac niște teste pe o instalare curată pentru Cpanel că am nevoie de mai mulți utilizatori. Din moment ce eu nu am vrut să lucreze șa servere de ambalare de rezervă și transferul de fișiere înregistrări folosite de o noapte înainte. Se transferă toate fișierele din / acasă și a constatat că CPanel nu oferă restaurarea mai mult 1 se cont simultan în ambele GUI și CLI în. În GUI obține numere au decis putut să nascocit cu cli script-ul restorepkg. Utilizarea sa este extrem de simplu

/scripts/restorepkg username.tar.gz

Acțiunea se repetă pentru fiecare utilizator separat. Când încerc să folosesc * în schimb script-ul numele de utilizator derektno mi-a tăiat, prin urmare, ar trebui să fie abordată oarecum cu grație –

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

for archive in $archives

do

/scripts/restorepkg --force $archive

done

explicație rapidă acum. A face o listă a tuturor backup și arhivele bumping în variabile apoi parcurge lista de un element la un început despachetarea pentru fiecare înregistrare separat. Нищо кой знае колко сложно интересно защо пичовете от Cpanel не са изплзвали подобно решение за множество файлове.