Քանի որ netenberg ընդհանրապես արդարացված չեն իմ սպասելիքները fantastico 3 հեծ ես որոշել է նրան ազատ արձակել тоталка. Չնայած նամակագրության, որը երկար քննարկել վաղուց եւ սկզբունքների, որոնք ես տվել եմ նրանց բարելավել իրենց արտադրանքը մրցունակ որը կարող է մակարդակով softaculous եւ installatron է հասնել մինչեւ այն պահը, որ պետք է հանել նրանց plugin 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

Изпълних си командите за чистиха се файловете им като осъзнах нещо важно пичовете изобщо не споменаха как се де регистрира плъгина им от контролният панел 🙄 😆 Мдаа педераски номер но се случва то и аз трябваше да гледам повече. Էր նաեւ, միայնակ պալատը իրենց ֆայլերը, ըստ երեւույթին, վերադառնալու հույս ունեն, քանի որ իրենց հաճախորդը, քանի որ եղել է շատ սցենարներ տեղադրելու համար: ինչպես ասել է աջակցության (չեմ կարծում, դա ամենակարևորն է հենց) :lol: . Րդ եկեք շարունակենք ամբողջական изкормване:

Դա առավել կարեւոր քայլ է, որը պետք է անել, նախքան затриете մնացածը, քանի որ, ապա դուք պետք է, ի վերջո, եղել է plugin բայց պատկերակը վահանակի, քանի որ դեռ գրանցվել.

/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

Այստեղ է, որ դուք կարոտել քայլ unregister_cpanelplugi, որպեսզի խաղալ ևս մեկ լրացուցիչ քայլ:

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 դա խաղ է եւ դուք կարող եք հանգիստ քնել. Պատճառները, որոնց պատճառով նրան փոխարինեց մրցակցային արդյունք է 3 եւ սա շատ պարզ

  • Չունեն API, որ ես կարող եմ պատկերացնել комуникирам եթե ես ցանկանում եմ կատարել լրացումներ կամ ինչ-որ այլ spells
  • ոչ hooks " թեմաներով որոշակի գործողություններ, որպեսզի ես եզրակացություն և дописвам ֆունկցիոնալությունը
  • ահա բլիթ support բավականին դանդաղ եւ ոչ շատ համարժեք իրենց պատասխաններում

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

Ինչ-որ ծրագրավորողները պարզապես սովորել գրել գրագետ ըստ RFC երբեք. Ես նկատեցի մի քանի errror_log ֆայլերը որը նրանք կուտակել են հսկայական քանակությամբ малоумни նախազգուշացում եւ notice չկատարման դեպքում ստանդարտների PHP. Ընդհանուր առմամբ, դժվար է բացատրել, թե օգտագործողը, որ կոդ, որը ստեղծվել էր դա վատ է և պետք է ուղղել. Ընդհանուր դեպքում, ես նկատել եմ, որ օգտվողները նրանց չի հուզում error log-ներ այն բանից հետո, երբ նրանց կոդ աշխատում. Սկզբունքորեն արմատական մոտեցումը, այն է ' կանգնեցնել ամբողջությամբ error_log ֆայլերը, եւ ով ուզում է, որպեսզի նրանց թողարկում, բայց, որպես կանոն, պետք է ստեղծել անհանգստություն համար բավականին օգտագործողների համար. Ուստի засилвам մոտեցման 2 – ոչ super ուժի կամ 1 տող bash. Որոնել ֆայլեր անունով error_log չափի ավելի քան 5 ՄԲ (այստեղ նշանակություն ունի ինձ, ես թողնում եմ մի մեծ, չնայած որ 1մբ-ի համար ավելի, քան բավարար է) եւ հեռացնել նրանց շաբաթական. Այդ ազդեցությունը ձեռք խառնաշփոթ լուսանկարներ

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

Մնում է միայն զարկել մեջ kroon է, որը կատարվում է մեկ անգամ, եւ մենք ունենք բավականին персистентно որոշումը. Իմ այստեղ, ինձ թվում է ok 1 ժամ թեմա ամեն կիրակի.

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

Յուրաքանչյուր ոք, ով զբաղվում է պրոֆեսիոնալ հետ web hosting գիտի, թե ինչ վտանգ է ներկայացնում վարակված օգտվողները հետ չարամիտ, web shells etc. "Обшият այստեղ օգտագործվում է maldet մեկը ոչ մի վատ սցենար. Նա տարբերվում է 3 բաներ

  1. Ահավոր դանդաղ
  2. Ահավոր դանդաղ են ընթանում, եւ եթե նրան ազատ արձակել ռեժիմով մոնիտորինգի չի изгаври սերվերի վրա դուք
  3. Աջակցում է սեփական բազայի հետ, md5/hex дефиници վատ կոդ.

Հենց վերջին առանձնահատկությունն է, այն օգտակար, քանի որ, ամեն ինչից զատ, կարող է събмитваш ֆայլերը, որոնք հայտնաբերվել էին մինչ այժմ եւ ավելի ուշ փուլում պետք է հասնել բազայի. Ինչպես կիսվել կետ 1 ու 2 նրա արագությունը սարսափելի ցածր է – ցածր ծանրաբեռնվածության մեքենայի վրա 70к ֆայլի отсканировали մեկ-մեկուկես ժամ. Այդ պատճառով ես սկսեցի օգնել իմ լավ ընկեր, ShadowX հետ malmon – այլընտրանք maldet գրված է python մի քիչ ճկունություն. Ցավոք, ժամանակի սղության պատճառով (հիմնականում, բայց ոչ միայն) մենք չենք довършили նախագծի, որը տվյալ պահին շատ օգտակար է – բավականին սխալներ կան որոնք պետք է մաքրել. Անցած օրերին ինձ հաճախորդների հետ, վարակված CryptoPHP որոնք ունեին հսկայական public_html ֆայլերը ~60к+ inod-օգտագործողի. Քանի որ միասին պետք է ստուգվել 200к ֆայլ որ խոշոր հաշիվների այն տեւում 5+ ժամ ես որոշեցի тунинговам կազմաձեւման maldet, նվազեցնել ֆայլերը, որոնք պետք է ստուգվի ինչ-որ բան ավելի խելամիտ տեղը եւ ժամանակը. Մինչեւ ընտրության конфа նկատել է հետեւյալ տողերը

# 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

Հետաքրքիր է… Ակնհայտ է, որ կա հնարավորություն օգտագործել ClamAV – ով նույնպես աչքի չի ընկնում մեծ արագությամբ, բայց, ինչու չէ, փորձեք այն. Արագ ես տեղադրել

/scripts/update_local_rpm_versions --edit target_settings.clamav installed

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

Թողարկել maldet-իսկ փոքրիկ թղթապանակ – չեմ տեսնում տարբերություն արագությամբ եւ վարքի – օգտագործել է իր perl-ски սկաների փոխարենը clamav. Հետո կարճատեւ փորում, ըստ կոդ maldet ես գտել հետեւյալ տողերը

 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

Мдааа, ես մի ստուգելու 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 пъти и половина по бързо в сравнение с преди.

Նախնականը, երբ տեղադրել Munin Cpanel բացակայում են մի քանի բարի apache որոնք պետք է իրենց ձեռքով անել. За мен един от тях е мониторинга на температурата на дисковете.

Ընդհանուր գծերով կոնֆիգուրացիան չնչին

1. Դուք պետք է բացահայտել տեսակը մեր սկավառակներ – նա կարող է լինել մեկը, հետեւյալ : ata, scsi, sat[,ավտոմեքենաներ][,N][+ՔԱՆԱԿ], usbcypress[,X], usbjmicron[,x][,N], usbsunplus, marvell, areca,N/E, 3ware,N, hpt,L/M/N, megaraid,N, cciss,N, ավտոմեքենաներ, test. The ամենադյուրին ճանապարհը դա անցակետով է “/պաշտպանության proc/ide” կամ “/պաշտպանության proc/scsi”. Ես:

# 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

 

 

Ինչպես երեւում է, ինձ 3 սկավառակի տեսակը 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

 

Մենք Կարող ենք ձգել փորձություն է մեր ապագա конфиг հաջորդ միջոց

# 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

 

Եթե ստանալ արժեքները նշանակում է ՝ ամեն ինչ ok է. Եթե դուք ստանում եք, որ սխալը դուք պետք է ստուգեք, եթե ամեն ինչ ճիշտ է նկարագրված:. Պետք է վերսկսել munin nod-իսկ ձեզ եւ изчакте 10-15 րոպե, որպեսզի популират քիչ տվյալներ, եւ սկսել նկարել գրաֆիկայի. Можете да проверите /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

Այսօր ես որոշեցի անել մի քանի թեստերի մաքուր Cpanel է տեղադրել, որը ինձ անհրաժեշտ էր մի քանի օգտագործողների համար. Քանի որ չի ցանկացել, որպեսզի քաշը աշխատող սերվերների հետ packers եւ կրկնօրինակում ֆայլեր փոխանցել էի արխիվները երեկվա թեմա.. Трансферирах բոլոր արխիվները /home, եւ պարզվել է, որ Cpanel առաջարկում է վերականգնել ավելի 1 հաշիվ միաժամանակ որպես GUI, այնպես էլ մի CLI. GUI քանի որ չի կարող ստանալ համարներ, ես որոշեցի изхитря հետ cli սցենար restorepkg. Այն օգտագործում է անվերջ պարզապես

/scripts/restorepkg username.tar.gz

Ինչպես գործողությունը կրկնվում է յուրաքանչյուր օգտագործողի համար առանձին-առանձին. Երբ փորձում է օգտագործել * անվան փոխարեն օգտագործողի սցենար деректно ինձ թլփատեց, ուստի պետք է մոտենալ մի քիչ ավելի էլեգանտ –

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

for archive in $archives

do

/scripts/restorepkg --force $archive

done

Այժմ արագ բացատրություն. Մենք անում ենք նրանց ցուցակը բոլոր արխիվները եւ նրա блъскаме է փոփոխական archives ապա обхождаме ցուցակում կետը կետը, քանի որ մենք վազում համար unpacking ծավալը զբաղված յուրաքանչյուր առանձին արխիվ. Нищо кой знае колко сложно интересно защо пичовете от Cpanel не са изплзвали подобно решение за множество файлове.