Mivel netenberg soha nem élt-ig az elvárásokat fantastico 3 ezért úgy döntöttem, hogy kifújja totalka. Bár a levelezés, hogy mi volt régen, és hogy nekik iránymutatást javítva termék versenyképes szintre softaculous és installatron eljött a pillanat, hogy lehet eltávolítani a bővítményt én Cpanel szerver. Mivel nincsenek utasításokat, hogyan kell eltávolítani a félreértést emelte jegy támogatásának-, és adtak nekem ezeket az utasításokat.

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

Én ellenőrzött a parancsokat, fájlok, mint volt, megtisztítják, rájöttem, hogy valami fontos srácok soha nem említette, hogyan kell regisztrálni a de plug-inek Vezérlőpult 🙄 😆 igen pederaski, de ez történt, és volt, hogy nézel ki. Szintén távozott egy halom a fájlokat nyilvánvalóan remélem, hogy vissza az ügyfél, ki, hogy a sok script telepítést mondta előzenekara (Nincs szó, hogy ez a helyes) :lol: . Úgyhogy továbbra is a teljes zsigerelésre:

Ez a legfontosabb lépés, amelyet meg kell tenni, mielőtt felülírás minden mást, mert akkor a végén de bővítmény ikonra a Control Panel, mivel még regisztrált.

/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

Azokban az esetekben, kimaradt lépés unregister_cpanelplugi kelljen játszani egy további lépés:

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 fátyol már ki a játék, és akkor aludhat nyugodtan. Az ok, amiért ez megváltoztatta a versenyképes termék 3 és nagyon egyszerű

  • Nem API ami tudok kommunikálni, ha azt szeretné, hogy kiegészítsék, vagy bármely más varázslatokat
  • nincs horog bizonyos cselekmények lehet csatolni, hogy írja és funkcionalitás
  • Rossz támogatás meglehetősen lassú és nem túl megfelelő válaszaikban

PS. paper_lantern és x3 hagyott egy ikon, melyik van futás-val

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

Egyes fejlesztők egyszerűen nem tanulni írni hozzáértő RFC soha. Észrevettem sok errror_log fájlok halmozott rengeteg hülyék és figyelmeztető-és értesítés elmulasztása PHP szabványok. Általában nehéz megmagyarázni, hogy a felhasználó, ezt a kódot, hogy kerül rossz, és meg kell javítani. Általában azt vettem észre, hogy a fogyasztók nem gerjeszti error log-ok után működő kód. Alapvetően radikális megközelítés teljesen leáll error_log fájlokat és aki akar futtatni őket, de egészében véve kényelmetlenséget okozhat elég felhasználóknak. Így húzza megközelíteni 2 – admin vagy szuper erőkre 1 bash sort. Fájlok keresése elemzi error_log mérete nagyobb mint 5 MB (Itt nekem kerülni otthagyni a nagy noha 1MB több mint elég) és törli a héten. Ez a hatás úgy érhető el, egyszerű megtalálja

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

Továbbra is csak összeomlik a koronát kell végezni hetente egyszer, és van egy nagyon kitartó döntés. Az én esetekben úgy tűnik, QA 1 pm minden vasárnap.

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

Bárki, aki részt vesz tárhely tudja, milyen veszélyt jelent a fertőzött felhasználók malware, web kagyló stb. Azokban az esetekben jelen általános használatra h Nem rossz script. Jellemzője 3 a dolgok

  1. Szörnyen lassú
  2. Ez szörnyen lassú, és ha hagyja, hogy a monitoring módban izgavri szerver
  3. Megtartja saját adatbázisa md5 / hex meghatározása rossz kód.

Csak a múlt tulajdonság teszi hasznos, mert eltekintve bármi mást sabmitvash fájlokat, amelyeket nem mutattak ki eddig, és egy későbbi szakaszban lépnek adatbázisok. Amint azt a közös pont 1 és 2 sebesség megdöbbentően alacsony – kis terhelés a gép 70K fájl beolvasása körülbelül egy és fél óra. Emiatt kezdtem, hogy segítsen a jó barát ShadowX Malmö – alternatív maldet írt python kevés rugalmasságot. Sajnos, az idő rövidsége (elsősorban, de nem kizárólag) mi nem fejezte be a projekt, amely abban a pillanatban nem nagyon használható – sok hibát, hogy tisztázni kell. Az elmúlt napokban nem volt probléma az ügyfelek fertőzött CryptoPHP aki nagy fájlok public_html ~ 60k + inod-és felhasználói. Mivel összesen kellett szkennelni alatt 200K fájl, amely nagyjából tartana 5+ órát úgy döntöttem, hogy beállítsa a konfiguráció maldet, hogy csökkentse a fájlok lesznek vizsgálva, hogy egy ésszerű számban és időben. Míg szedés confit észrevette a következő sorokat

# 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

érdekes módon… Úgy látszik, van egy lehetőség, hogy használni ClamAV – amely szintén tartalmaz nagy sebességgel, de miért nem próbálja. A gyorsan telepíthető

/scripts/update_local_rpm_versions --edit target_settings.clamav installed

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

Maldet-futás és egy kis mappa – Nem látok különbséget a sebesség és a viselkedés – Ő használja az ő perl-ski szkenner helyett, hogy a clamav. Egy rövid szitálás forrása maldet talált a következő sorokat

 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

Ja tett amely clamscan és nagy meglepetésemre rájöttem, hogy clamav nem található elérési út, mi egy hülye Cpanel elhagyta őt csak a/usr/helyi/cpanel/3rdparty/bin/a házmester binarkite ahol. Egy gyors erősít a probléma ln:

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

Scan most maldet felső jelentések bíró

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

Után már használ ClamAV maldet véget ér a beolvasás 3-4-5 szer gyorsabb, mint korábban. A vizsgálat azt mutatta – 70k-izt″rkla inod őket a 25 min, ami körülbelül 3 és fél-szer gyorsabb, mint korábban.

Alapértelmezés szerint telepíti munin Cpanel hiányzik valamilyen config, aki köteles azokat kézzel. Számomra ezek közül az egyik, a hőmérséklet a lemezek ellenőrzése.

Általánosságban, a konfigurációs triviális

1. Meg kell adnia a típusát mi meghajtók – ez lehet a következők valamelyike : ők, SCSI, ült[,kocsi][,N][+TÍPUS], usbcypress[,x], usbjmicron[,x][,N], usbsunplus, Marvell, aréka,N / E, 3áru,N, HPT,L / M / N, MegaRAID,N, cciss,N, kocsi, teszt. A legkönnyebb módja egy macska “/proc / ide” vagy “/proc / scsi”. nekem:

# 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

 

 

Amint van 3 lemez típusát ATA.

2. Ahhoz, hogy kövessék nyomon a hőmérséklet le kell írnia a munin csomópont hajt minket. A fájl /etc/munin/plugin-conf.d/hddtemp_smartctl adja a következő típusú

# 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

 

Mi lehet hit próbáját jövőnk config a következő módon

# 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

 

Ha kapsz értékek azt jelentik, minden rendben van. Ha hibaüzenetet kap ellenőriznie kell, hogy mindent helyesen leírt. Kell indítani munin nod-és, és várja 10-15 min kisebb népsűrűségű adatok és elkezd rajzolni grafika. Ellenőrizheti az errors/var/log/munin/munin-node.log és a könnyű eltávolítás.

Ha ön akar-hoz kap elektronikus levél, amikor a kritikus hőmérséklet lemez kell adnia egy leírást, mint kritikus:

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

Ma úgy döntöttem, hogy néhány tesztet egy tiszta telepítés Cpanel, hogy szükségem van több felhasználó. Mivel nem akartam, hogy nyereg dolgozó szerverek csomagolás mentés és átadása használt fájlokat rekordok az este. Átvitele az összes fájlt a / home és megállapította, hogy Cpanel nem nyújt helyreállítása több 1 fiók egyszerre GUI és CLI. Ebben GUI tudott kap számokat úgy döntött, hogy kiagyalt CLI script restorepkg. A használata rendkívül egyszerű

/scripts/restorepkg username.tar.gz

Ismétlődik az akció minden felhasználó külön-külön. Amikor megpróbálom használni * helyett a felhasználó nevét script derektno megvágott ezért kell megközelíteni némileg elegánsan –

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

for archive in $archives

do

/scripts/restorepkg --force $archive

done

Most gyors magyarázat. Készítsen egy listát az összes mentést és archívumok nekimegy változó majd a listán görgetve egy tétel egy kezdő kicsomagolás minden rekordot külön. Semmi sok érdekes bonyolult, miért a srácok a Cpanel, nem izplzvali egy hasonló megoldás a több fájl.