მას შემდეგ, რაც netenberg არასოდეს უცხოვრია მდე ჩემი მოლოდინი fantastico 3 ამიტომ მე გადავწყვიტე, რომ აფეთქება off totalka. მიუხედავად იმისა, რომ კორესპონდენცია, რომ ჩვენ გვქონდა დიდი ხნის წინ და რომ მისცა სახელმძღვანელო გაუმჯობესების მათი პროდუქტი კონკურენტუნარიანი დონეზე Softaculous და installatron მოვიდა მომენტში უნდა წაშლა მათი მოდული ჩემი cPanel სერვერები. მას შემდეგ, რაც არ არსებობს ინსტრუქციები, თუ როგორ უნდა ამოიღონ ეს გაუგებრობა ბილეთი მხარდაჭერა და მომცეს ეს ინსტრუქციები.

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

მე მოჰყვა მისი ბრძანებები chistiha ფაილები მათ მივხვდი, რაღაც მნიშვნელოვანი ბიჭები არასდროს აღნიშნა, თუ ადგილი რეგისტრაცია მოდული პანელი 🙄 😆 Yeah pederaski ნომერი, მაგრამ ეს ხდება და მე უნდა უყუროთ მეტი. გარდა ამისა მან დატოვა წყობის ფაილი აშკარად იმედი მაქვს, რომ უკან, როგორც მათი კლიენტი, როგორც მათ ჰქონდათ ბევრი სკრიპტები ინსტალაცია, განაცხადა მხარდაჭერის აქტი (სიტყვას არ ეს სწორი) :lol: . მოდით გავაგრძელოთ სრული gutting:

ეს არის ყველაზე მნიშვნელოვანი ნაბიჯი, რომელიც უნდა გაკეთდეს სანამ გადაწერა ყველაფერი იმიტომ, რომ მაშინ თქვენ დასრულდება მდე, მაგრამ მოდული ხატი პანელი როგორც ჯერ კიდევ არ არის რეგისტრირებული.

/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 veil უკვე თამაშგარე და შეგიძლიათ ძილის მშვიდობიანად. მიზეზი, რის გამოც ის შეიცვალა კონკურენტული პროდუქტი 3 და ძალიან მარტივი

  • არარის API რომელიც მე შეუძლია დაუკავშირდეს თუ გინდათ დამატებები ან ნებისმიერი სხვა შელოცვების
  • არ კაუჭები გარკვეული ქმედებები შეიძლება ერთვის შეიტანოთ და ფუნქციონალური
  • ცუდი მხარდაჭერა საკმაოდ ნელი და არ არის ძალიან ადეკვატური მათი პასუხი

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

ზოგიერთი დეველოპერები უბრალოდ ვერ ვისწავლოთ წერა კომპეტენტურად in RFC არასოდეს. მე დავინახე, ბევრი errror_log ფაილი, რომელიც დაგროვდა დიდი რაოდენობით morons და გაფრთხილება და გაფრთხილების მარცხი PHP სტანდარტების. ზოგადად, ძნელია ავუხსნათ მომხმარებელს, კოდი, რომელიც იდება არის ცუდი და უნდა გაკეთდეს. ზოგადად, მე არ შენიშნა, რომ მომხმარებელს არ აღელვებს შეცდომა-s შემდეგ მათი მუშაობა კოდი. ძირითადად რადიკალური მიდგომა, რათა შეწყდეს მთლიანად error_log ფაილი და რომელსაც სურს აწარმოებს მათ, მაგრამ, როგორც მთელი დისკომფორტს უქმნის საკმაოდ მომხმარებლები. ასე რომ გამკაცრდეს მიახლოება 2 – admin ან სუპერ ძალაუფლება 1 ред bash. ძიება ფაილი სახელად error_log ზომა უფრო მეტია, ვიდრე 5MB (აქ ღირს მე დატოვებს მას დიდი მიუხედავად იმისა, რომ 1MB საკმარისზე მეტია) და წაშლის მათ ყოველკვირეულად. ეს ეფექტი მიიღწევა მარტივი იპოვოს

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

ეს რჩება მხოლოდ ავარიული შევიდა გვირგვინი შესასრულებელი კვირაში ერთხელ და აქვს საკმაოდ მუდმივი გადაწყვეტილება. ჩემი შემთხვევები, როგორც ჩანს, ხარისხის უზრუნველყოფის 1 საათამდე ყოველ კვირას.

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

ყველას, ვინც ჩართული ვებ ჰოსტინგი იცის, რა საფრთხე ინფიცირებული მომხმარებლების malware, ვებ ჭურვი და ა.შ.. იმ შემთხვევაში, ეს ზოგადი h არ არის ცუდი script. იგი აღჭურვილია 3 რამ

  1. საშინლად ნელი
  2. ეს საშინლად ნელი და თუ მას ნება მონიტორინგის რეჟიმი izgavri სერვერზე
  3. ინარჩუნებს თავის მონაცემთა ბაზაში md5 / hex განმარტება ცუდი კოდი.

უბრალოდ ბოლო დამახასიათებელი ხდის სასარგებლოა, იმიტომ, რომ გარდა არაფერი შეგიძლიათ sabmitvash ფაილი, რომელიც არ იქნა ჯერჯერობით, და შემდგომ ეტაპზე მოვა მონაცემთა ბაზები. როგორც მე გაუზიარეს წერტილი 1 და 2 სიჩქარე shockingly დაბალი – დაბალი დატვირთვის მანქანა 70K ფაილი დასკანირებული დაახლოებით ერთი საათი და ნახევარი. ამ მიზეზის გამო დავიწყე, რათა დაეხმაროს ჩემი კარგი მეგობარი ერთად ShadowX Malmo – ალტერნატიული maldet დაწერილი Python პატარა მოქნილობა. სამწუხაროდ, დროის სიმცირის გამო, (ძირითადად, მაგრამ არა მხოლოდ) ჩვენ არ დასრულდება პროექტის, რომელიც იმ მომენტში არ არის ძალიან გამოსადეგი – არსებობს ბევრი შეცდომები, რომ უნდა იყოს გაწმენდილი. ბოლო დღეებში მქონდა პრობლემები კლიენტებს ინფიცირებული CryptoPHP რომელსაც ჰქონდა დიდი ფაილი public_html ~ 60k + inod და მომხმარებელი. მას შემდეგ, რაც სულ უნდა იყოს დასკანირებული მეტი 200k ფაილი, რომელიც დაახლოებით დასჭირდება 5+ საათი გადავწყვიტე სრულყოფილი კონფიგურაციის maldet, შეამციროს ფაილი რომ სკანირებული იქნება უფრო გონივრული რაოდენობა და დრო. მიუხედავად იმისა, რომ კრეფა confit შენიშნა შემდეგი ხაზები

# 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

Yep გააკეთა რომელიც clamscan და ჩემდა გასაკვირად აღმოვაჩინე, რომ ClamAV არ არის PATH მაგრამ dumb cPanel დატოვა იგი მხოლოდ / usr / local / cPanel / 3rdparty / bin /, სადაც იგი binarkite. სწრაფი ln პრობლემის მოგვარება:

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

In თავიდან სკანირება maldet უკვე ცნობით დაბრუნება

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

მას შემდეგ, რაც გამოიყენება ClamAV maldet სრულდება სკანირების თქვენი 3-4-5 ჯერ უფრო სწრაფად, ვიდრე ადრე. ანალიზმა აჩვენა, – 70k-inod და რუბლს გარშემო 25 min რომელიც დაახლოებით 3 და ნახევარი ჯერ უფრო სწრაფად, ვიდრე ადრე.

იყოს, როდესაც თქვენ დააყენოთ Munin CPanel აკლია რაღაც config, რომელიც უნდა მიიღოს მათ ხელით. ჩემთვის, ერთ-ერთი მათგანი მონიტორინგის ტემპერატურა დისკები.

ზოგადად, კონფიგურაცია არის ტრივიალური

1. ჩვენ უნდა იდენტიფიცირება ტიპის ჩვენი დისკები – ეს შეიძლება იყოს ერთ შემდეგ : ისინი, SCSI, sat[,განცხადება][,N][+TYPE], usbcypress[,X], usbjmicron[,x][,N], usbsunplus, marvell, areca,N / E, 3მოწყობილობები,N, hpt,L / M / N, megaraid,N, cciss,N, განცხადება, ტესტი. ყველაზე მარტივი გზა არის კატა “/proc / ide” ან “/proc / SCSI”. me:

# 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 კვანძის გვაიძულებს. ფაილი /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

 

ჩვენ შეგვიძლია მოხვდა ტესტი ჩვენი მომავალი config შემდეგ გზა

# 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

 

თუ თქვენ გაქვთ ღირებულებები ნიშნავს, ყველაფერი რიგზეა. თუ თქვენ გაქვთ შეცდომა თქვენ უნდა შეამოწმოს, რომ ყველაფერი სწორად უწოდა. უნდა გადატვირთეთ Munin nod და თქვენ და დაველოდოთ 10-15 წთ ნაკლებად დასახლებულ მონაცემები და დაიწყოს მიაპყროს გრაფიკა. თქვენ შეგიძლიათ შეამოწმოთ /var/log/munin/munin-node.log შეცდომები და მათი ადვილად მოხსნა.

თუ გსურთ მიიღოთ ელ კრიტიკული ტემპერატურა დისკები უნდა დაამატოთ აღწერა ასეთ კრიტიკულ:

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

დღეს მე გადავწყვიტე გავაკეთოთ ზოგიერთი ტესტები სუფთა მონტაჟი cPanel, რომ მე უნდა მრავალჯერადი მომხმარებლებს. მას შემდეგ, რაც მე არ მინდა ჩაუდგნენ სამუშაო სერვერები შეფუთვა სარეზერვო და გადაცემის ფაილი გამოიყენება ჩანაწერების ღამეს. გადაცემის ყველა ფაილი / home და აღმოჩნდა, რომ cPanel არ სთავაზობს აღდგენის მეტი 1 ანგარიშის ერთდროულად ორივე GUI და CLI in. In GUI როგორც couldnt მისაღებად ნომრები გადაწყვიტა ჩაიფიქრეს ერთად კლიმატის script restorepkg. მისი გამოყენება ძალიან მარტივია

/scripts/restorepkg username.tar.gz

მოქმედება მეორდება თითოეული მომხმარებლის ცალკე. როდესაც ვცდილობ გამოყენება * ნაცვლად მომხმარებლის სახელი script derektno დაჭრილი მე ამიტომ უნდა მიუახლოვდა გარკვეულწილად gracefully –

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

for archive in $archives

do

/scripts/restorepkg --force $archive

done

ახლა სწრაფი განმარტება. გააკეთეთ სია ყველა სარეზერვო და არქივები შეეჯახებით ცვლადი მაშინ გადახვევა მეშვეობით სიაში ერთი ნივთი დაწყების პაკეტების თითოეული ჩანაწერი ცალკე. ბევრი არაფერი საინტერესო კომპლექსი cPanel რატომ ბიჭები არ მომწონს მიეწოდება გადაწყვეტა რამოდენიმე ფაილი.