Ponieważ netenberg w ogóle nie spełnił moich oczekiwań dotyczących fantastico 3 więc postanowiłem to całkowicie stracić. Pomimo korespondencji, którą mieliśmy dawno temu i wytycznych, które im dałem, aby ulepszyć swój produkt do konkurencyjnego poziomu softaculous i installatron, doszło do tego, że ich wtyczka musiała zostać odinstalowana z moich serwerów Cpanel.. Ponieważ nie ma instrukcji, jak usunąć to nieporozumienie, wziąłem bilet na wsparcie, dali mi następujące instrukcje.

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

Изпълних си командите за чистиха се файловете им като осъзнах нещо важно пичовете изобщо не споменаха как се де регистрира плъгина им от контролният панел 🙄 😆 Мдаа педераски номер но се случва то и аз трябваше да гледам повече. Była też komora, która pozostawiła ich akta, mając nadzieję, że wrócą jako ich klient, ponieważ mieli najwięcej skryptów instalacyjnych, jak wsparło wsparcie (nie sądzę, że jest to najważniejsza rzecz prosto) :Pan Zielony: . Kontynuujmy więc pełne patroszenie:

Jest to najważniejszy krok, który należy wykonać przed usunięciem wszystkiego innego, ponieważ będziesz wtedy podłączony, ale z ikoną na panelu sterowania, ponieważ jest nadal zarejestrowany.

/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

Jeśli przegapiłeś krok unregister_cpanelplugi, musisz zagrać jeszcze jeden krok:

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/

Zasłona jest teraz fantastyczna z gry i możesz spać spokojnie. Powody, dla których zastąpiłem go produktem konkurencyjnym, są 3 i to jest bardzo proste

  • Nie mają interfejsu API, z którym mogę się komunikować, jeśli chcę dodawać nowe zaklęcia
  • nie mają haczyków do niektórych działań, więc mogę się rozłączyć i dodać funkcjonalność
  • niegrzeczne wsparcie dość powolne i niezbyt odpowiednie w odpowiedziach

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

Niektórzy programiści nigdy nie nauczą się płynnie pisać na RFC. Zauważyłem wiele plików dziennika błędów, w których zgromadzono ogromną liczbę głupich ostrzeżeń i uwag dotyczących niezgodności ze standardami PHP.. Zasadniczo trudno jest wyjaśnić konsumentowi, że kod, który wprowadził, jest niegrzeczny i musi zostać naprawiony. Ogólnie zauważyłem, że użytkownicy nie dbają o dzienniki błędów po zadziałaniu kodu. Zasadniczo radykalnym podejściem jest całkowite zatrzymanie plików error_log i kto chce je odtwarzać, ale ogólnie spowoduje dyskomfort dla wielu użytkowników. Właśnie dlatego wybieram podejście 2 – super uprawnienia administracyjne lub 1 czerwona uderzenie. Wyszukaj pliki o nazwie dziennik błędów większy niż 5 MB (tutaj zostawiam moją wartość wyższą, chociaż 1 MB to więcej niż wystarcza) i usuwając je co tydzień. Omawiany efekt osiąga się elementarnie za pomocą odnaleźć

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

Pozostaje tylko wbiegać w koronę, która będzie wykonywana raz w tygodniu, a my mamy bardzo trwałe rozwiązanie. W moim przypadku wydaje się to w porządku 1 godziny w każdą niedzielę.

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

Każdy, kto profesjonalnie zajmuje się hostingiem, zna zagrożenie ze strony zainfekowanych użytkowników złośliwym oprogramowaniem, powłoki internetowe itp. W ogólnym przypadku jest używany maldet niezły skrypt. Wyróżnia się 3 rzeczy

  1. Jest strasznie powolny
  2. Jest strasznie powolny, a jeśli przełączysz go w tryb monitorowania, zadziała na twoim serwerze
  3. Obsługuje własną bazę danych z definicjami md5 / hex dla złego kodu.

Jest to jego ostatnia funkcja, która czyni ją użyteczną, ponieważ między innymi możesz przesyłać pliki, które nie zostały dotychczas wykryte i wejdą do baz danych na późniejszym etapie.. Jak już wspominałem 1 i 2 jego prędkość jest szokująco niska – przy niskim obciążeniu komputera, zeskanowano 70 000 plików w około półtorej godziny. Z tego powodu zacząłem pomagać mojemu przyjacielowi ShadowX malmon ( malmon ) – alternatywa dla maldeta napisanego w pythonie z nieco większą elastycznością. Niestety z braku czasu (głównie ale nie tylko) nie ukończyliśmy projektu, co obecnie nie jest zbyt użyteczne – istnieje wiele błędów, które należy usunąć. W ciągu ostatnich kilku dni miałem problemy z klientami zainfekowanymi CryptoPHP, którzy mieli ogromne pliki public_html ~ 60k + inod na użytkownika. Ponieważ w sumie trzeba było przeskanować ponad 200 000 plików, co z grubsza zabrałoby 5+ godziny postanowiłem dostroić konfigurację maldet, aby zredukować pliki, które będą skanowane do rozsądnej liczby i czasu. Gdy podniosłem conf, zauważyłem następujące wiersze

# 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

Ciekawy… Najwyraźniej istnieje możliwość korzystania ClamAV – co również nie różni się dużą prędkością, ale dlaczego nie spróbować. Szybko to zainstalowałem

/scripts/update_local_rpm_versions --edit target_settings.clamav installed

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

Maldet uruchamiam na małym folderze – Nie widzę różnicy w szybkości i zachowaniu – użył skanera perla zamiast clamav. Po krótkim przejrzeniu źródła maldetu znalazłem następujące wiersze

 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, zrobiłem jeden który clamscan i ku mojemu wielkiemu zdziwieniu odkryłem, że clamav wcale nie jest w ŚCIEŻCE, ale głupi Cpanel zostawił go tylko w / usr / local / cpanel / 3rdparty / bin /, z którego używa swoich plików binarnych. Szybkie rozwiązanie problemu:

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

Podczas ponownego skanowania Maldet już zgłasza powyższe

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

Po użyciu maldetu ClamAV kończy skanowanie 3-4-5 razy szybciej niż wcześniej. Test wykazał – 70k inod-a przetarł je przez około 25 min, co jest około 3 półtora razy szybciej niż wcześniej.

Domyślnie podczas instalacji Munin Cpanelowi brakuje kilku fajnych konfiguracji, które musimy wykonać ręcznie. За мен един от тях е мониторинга на температурата на дисковете.

Ogólnie rzecz biorąc, konfiguracja jest banalna

1. Musimy określić typ naszych dysków – może to być jeden z poniższych : one, scsi, sob[,automatyczny][,N.][+RODZAJ], usbcypress[,X], usbjmicron[,x][,N.], usbsunplus, marvell, areca,ANI, 3towar,N., hpt,L / M / N, megaraid,N., cciss,N., automatyczny, test. Najłatwiej to zrobić przez kota “/proc / ide” Lub “/proc / scsi”. Dla mnie:

# 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

 

 

Jak widać mam 3 Typ dysku 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

 

Możemy przetestować naszą przyszłą konfigurację w następujący sposób

# 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

 

Jeśli otrzymasz wartości, wszystko jest w porządku. Jeśli pojawi się błąd, musisz sprawdzić, czy wszystko jest poprawnie opisane. Powinieneś ponownie uruchomić skinienie głową Munina i czekać 10-15 min, aby wypełnić niektóre dane i rozpocząć rysowanie wykresu. Możesz sprawdzić /var/log/munin/munin-node.log pod kątem błędów i łatwego rozwiązywania problemów.

Jeśli chcesz otrzymać wiadomość e-mail o krytycznej temperaturze dysku, musisz dodać opis temperatury krytycznej:

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

Dzisiaj postanowiłem zrobić kilka testów na czystej instalacji Cpanel, do której potrzebowałem kilku użytkowników. Ponieważ nie chciałem obciążać działających serwerów archiwizacją wsadową i przesyłaniem plików, skorzystałem z archiwów z poprzedniego wieczoru. Przesłałem wszystkie archiwa do / home i odkryłem, że Cpanel nie oferuje już odzyskiwania 1 konto zarówno przez GUI, jak i przez CLI. Przez GUI, ponieważ nie było sposobu na otrzymanie numeru, postanowiłem przechytrzyć za pomocą cli skryptu restorepkg. Jego użycie jest nieskończenie proste

/scripts/restorepkg username.tar.gz

Ponieważ akcja jest powtarzana dla każdego użytkownika osobno. Podczas próby użycia * zamiast nazwy użytkownika skrypt bezpośrednio mnie odciął, więc należy podejść do niego bardziej elegancko –

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

for archive in $archives

do

/scripts/restorepkg --force $archive

done

Teraz krótkie wyjaśnienie. Tworzymy listę wszystkich archiwów i pchamy ją do archiwów zmiennych, a następnie przeglądamy pozycję listy po pozycji, rozpoczynając rozpakowywanie dla każdego archiwum osobno. Nikt nie wie, jak skomplikowane i ciekawe jest, dlaczego faceci z Cpanel nie używali takiego rozwiązania dla wielu plików.