כי נטנברג כלל לא עמד בציפיותי לפנטסטיות 3 אז החלטתי לאבד את זה לגמרי. למרות ההתכתבויות שהיו לנו לפני הרבה זמן וההנחיות שנתתי להם לשיפור המוצר שלהם לרמה תחרותית של מפגן והתקנה, זה הגיע למצב בו היה צורך להסיר את התוסף שלהם משרתי ה- 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

Изпълних си командите за чистиха се файловете им като осъзнах нещо важно пичовете изобщо не споменаха как се де регистрира плъгина им от контролният панел 🙄 😆 Мдаа педераски номер но се случва то и аз трябваше да гледам повече. היה שם גם חדר שהותיר את תיקיהם ככל הנראה בתקווה לחזור כלקוחם, כפי שהיו להם הכי הרבה סקריפטים להתקנה כפי שאמר התמיכה (אל תחשוב שזה הדבר החשוב ביותר) :מר ירוק: . אז בואו נמשיך עם הרזיה השלמה:

זהו הצעד החשוב ביותר שצריך לעשות לפני שמחיקת את כל השאר כפי שתמצא אז עצמך היה תוסף אבל עם אייקון בלוח הבקרה שכן הוא עדיין רשום.

/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/

הרעלה כעת נפלאה מהמשחק ותוכלו לישון בשקט. הסיבות שהחלפתי אותו במוצר מתחרה הן 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

יש מתכנתים שלעולם לא ילמדו לכתוב באופן שוטף על RFC. שמתי לב להרבה קבצי errror_log בהם הצטברו מספר עצום של אזהרות והודעות מטופשות על אי עמידה בתקני PHP.. באופן כללי, קשה להסביר לצרכן, שהקוד שהוא הכניס שובב וצריך לתקן אותו. באופן כללי שמתי לב שלמשתמשים לא אכפת מיומני שגיאות לאחר שהקוד שלהם עובד. בעיקרון, גישה רדיקלית היא עצירה מוחלטת של קבצי ה- error_log ומי רוצה לשחק אותם, אך באופן כללי זה יוצר אי נוחות עבור משתמשים רבים. זו הסיבה שאני מגישה גישה 2 – אדמיניסטרטיבי כוחות או 1 אדום אדום. חפש קבצים בשם 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

כל מי שעוסק באופן מקצועי באירוח אתרים מכיר את האיום הנשקף על ידי משתמשים נגועים בתוכנות זדוניות, פגזי רשת וכו '. במקרה הכללי משתמשים בו maldet תסריט לא רע. זה נבדל על ידי 3 דברים

  1. זה איטי להחריד
  2. זה איטי להפליא ואם תכניסו אותו למצב ניטור הוא יגע בשרת שלכם
  3. תומך בבסיס נתונים משלו עם הגדרות md5 / hex לקוד רע.

זו התכונה האחרונה שלה שהופכת אותה לשימושית, מכיוון שבין היתר תוכלו להגיש קבצים שלא התגלו עד כה ויכנסו למאגרי המידע בשלב מאוחר יותר.. כפי שחלקתי בפירוט 1 ו 2 המהירות שלה נמוכה באופן מזעזע – בעומס מכונה נמוך, סרקו 70K קבצים תוך כשעה וחצי. מסיבה זו התחלתי לעזור לחברתי הטובה ShadowX מאלמו – אלטרנטיבה למלדיט שנכתבה בפיתון עם קצת יותר גמישות. לרוע המזל מחוסר זמן (בעיקר אך לא רק) לא השלמנו את הפרויקט, וזה לא ממש שמיש כרגע – יש הרבה באגים שצריך לסלק אותם. בימים האחרונים היו לי בעיות עם לקוחות שנדבקו ב- CryptoPHP שהיו להם קבצי public_html ענקיים ~ 60k + משתמשים.. מכיוון שהיה צריך לסרוק יותר מ- 200,000 קבצים, מה שייקח בערך 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

אני מריץ את המלדיט על תיקיה קטנה – אני לא רואה הבדל במהירות ובהתנהגות – הוא השתמש בסורק הפרל שלו במקום הקלאמאב. לאחר חפירה קצרה במקור המלדיט מצאתי את השורות הבאות

 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

המממ, הכנתי אחת המסוקק ולהפתעתי הרבה גיליתי שקלאמב בכלל לא נמצא ב- PATH, אבל קפנל המטופש השאיר אותו רק ב / usr / local / cpanel / 3rd party / bin / משם הוא משתמש בבינריות שלו.. מהיר פתר את הבעיה:

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

בעת סריקה מחודשת, Maldet כבר מדווח על האמור לעיל

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

לאחר שכבר השתמש ב- Maldet ClamAV, הוא מסיים את הסריקה שלו 3-4-5 פעמים מהר מבעבר. הבדיקה הראתה – 70k inod - a שפשף אותם בערך 25 דקות שזה בערך 3 פעמים וחצי מהר מבעבר.

ברירת מחדל בעת ההתקנה מונין Cpanel חסרים כמה קונפיגים נחמדים שעלינו להכין בעבודת יד. За мен един от тях е мониторинга на температурата на дисковете.

באופן כללי, התצורה היא טריוויאלית

1. עלינו לקבוע את סוג הדיסקים שלנו – זה יכול להיות אחד מהבאים : הם, scsi, ישב[,אוטומטי][,נ][+סוג], usbcressress[,איקס], usbjmicron[,איקס][,נ], usbsunplus, פלא, ארקה,לא זה ולא זה, 3כלי,נ, hpt,L / M / N, megaraid,נ, cciss,נ, אוטומטי, test. Най лесният начин за това е чрез cat на “/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

 

Ако получите стойности значи всичко е ок. אם אתה מקבל שגיאה עליך לבדוק אם הכל מתואר כהלכה. אתה צריך להפעיל מחדש את המונין שלך מהנהן ולחכות 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 נקייה שעבורם אני זקוקה למספר משתמשים. מכיוון שלא רציתי להכביד על השרתים המריצים בארכיון אצווה והעברת קבצים, השתמשתי בארכיונים מהערב הקודם. העברתי את כל הארכיונים לבית / וגיליתי שקפנל כבר לא מציע התאוששות 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

עכשיו הסבר מהיר. אנו מכינים רשימה של כל הארכיונים ודוחפים אותה לארכיונים המשתנים ואז עוברים על פריט הרשימה אחר פריט על ידי התחלת הפריקה של כל ארכיון בנפרד.. איש אינו יודע כמה מסובך ומעניין מדוע החבר'ה מקפנל לא השתמשו בפתרון כזה עבור קבצים רבים.