Som netenberg normalt ikke berettiget til mine forventninger fantastico 3 drev jeg besluttede at frigive totaly. Въпреки кореспонденцията която водихме преди много време и насоките които им дадох за подобряване на продукта им до конкурентно способно ниво на softaculous и installatron се стигна до момента в който трябваше да бъде деинсталиран техният плъгин от Cpanel сървърите ми. Da der ikke er nogen vejledning, hvor er det en misforståelse, tog jeg en billet i støtte, og at de gav mig følgende instruktioner.

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

Jeg fulgte hans befalinger chistiha Filer dem jeg indså noget vigtigt fyre aldrig nævnt, hvordan et sted registrere plugin fra kontrolpanelet 🙄 😆 Ja pederaski nummer, men det sker, og jeg måtte se mere. Det var også, der var et hus til deres filer, tilsyneladende i håb om at vende tilbage som kunde, da der ikke var en masse scripts til installation som sagde støtte (tror ikke det er det vigtigste lige) :lol: . Åh, lad os fortsætte med fuld skorman:

Dette er det vigtigste skridt, der skal gøres, før setrate alt andet, som så vil du ende op var plugin, men ikonet i kontrolpanelet, som alt andet var.

/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

I her du gik glip af et skridt unregister_cpanelplugi at skulle spille en anden ekstra skridt:

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 allerede dækker dette spil, og du kan sove roligt. De grunde, fordi, som det blev erstattet med et konkurrencedygtigt produkt 3 og det er meget simpelt

  • Du behøver ikke have API-at jeg kan tillade komuniciram hvis jeg ønsker at lave tilføjelser eller nogen andre besværgelser
  • ingen kroge " tema i aktion for at jeg output og dopium funktionalitet
  • det skide støtte er meget langsom og ikke særlig passende i deres svar

PS. paper_lantern x3 og var forblevet et ikon, der kører rundt med

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

Nogen programmører bare ikke lære at skrive korrekt i henhold til RFC aldrig. Jeg har bemærket et par errror_log filer, som de har opnået en enorm mængde maloni advarsel og varsel for manglende overholdelse af standarder PHP. Generelt, det er svært at forklare brugeren, den kode, der er installeret, det er slemt og behov fastsættelse. I det Generelle tilfælde, jeg har bemærket, at brugerne behøver ikke bekymre sig om fejl log-s, når deres kode virker. I princippet, er en radikal metode til at stoppe helt error_log filer, og hvem ønsker deres udgivelser, men, som en regel, vil medføre ubehag for ganske brugere. Derfor dasilva på vej 2 – ingen supermagt, eller 1 line bash. Søg efter filer med navnet error_log er større end 5 MB (her, værdien af det til mig, forlod jeg i det store og selvom 1 mb, der er mere end nok) og fjerne dem ugentligt. Denne effekt er opnået rode med finde

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

Det er fortsat kun at gå ned til den krone, der kører en gang om ugen, og vi har en temmelig vedvarende løsning. I min her, jeg tror, OK 1 PM hver søndag.

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

Alle, der beskæftiger sig professionelt med web-hosting ved, hvad truslen repræsenterer inficerede brugere med malware, web-skaller osv.. I obset anvendes her h en dårlig script. Det adskiller sig 3 ting

  1. Frygtelig langsom
  2. Virkelig langsomt, og hvis du lader det gå i monitor mode, shauri server, du
  3. Fastholder sin egen database med md5 - /hex, konkret dårlig kode.

Det er den sidstnævnte funktion gør det nyttigt, fordi der blandt andre ting, kan symitar filer, der ikke er blevet opdaget indtil nu, og på et senere tidspunkt, vil komme ind i databasen. Som delt i punkt 1 og 2 dens hastighed er chokerende lavt – ved lav belastning på bilen 70K-fil, der scannes til en time og en halv. Af denne grund, begyndte jeg at hjælpe min gode ven, ShadowX med Malmø – alternative maldet skrevet i python med en smule fleksibilitet. Desværre, på grund af manglende tid (for det meste, men ikke kun) vi har ikke dovrsili projekt, der er i øjeblikket ikke meget nyttige – der er en hel masse fejl for at rydde op. I løbet af de sidste par dage har jeg haft problemer med kunder, der er inficeret med CryptoPHP, der havde en enorm public_html filer ~60K+ inod-bruger. Så i forbindelse var nødt til at blive kontrolleret på 200k-fil, der stort konti, det vil tage 5+ timer besluttede jeg tuningova konfiguration maldet, for at reducere de filer, der vil blive tjekket i en mere rimelig tid og sted. Mens du vælger konfa bemærket følgende linjer

# 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

Interessant… Det er selvfølgelig muligt, at bruge ClamAV – der er ikke høj hastighed, men ikke hvorfor ikke prøve. Hurtigt satte jeg

/scripts/update_local_rpm_versions --edit target_settings.clamav installed

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

Udgivelse maldet-en lille folder – Jeg ser ingen forskel i hastighed og adfærd – der bruges it-perl-ish scanner i stedet for clamav. Efter en kort grave i koden maldet fandt jeg følgende linjer

 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

Mdaaa, jeg har lavet en som clamscan og til min store overraskelse opdagede jeg, at clamav ikke i VEJEN-en godt skrevet Cpanel venstre er det kun i /usr/local/cpanel/3rdparty/bin/, hvor han bruger det binarie. En hurtig ln løse problemet:

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

I Rescan maldet allerede rapporteret top

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

Når brugt ClamAV maldet færdig med at scanne din 3-4-5 gange hurtigere end før. tests viste – 70k-inod og gnid omkring 25 min, hvilket er ca. 3 og en halv gange hurtigere end den kendte.

Som standard, når du installerer Munin Cpanel mangler et par gode apache, der er nødt til at gøre dem manuelt. For mig er en af ​​dem at overvåge temperaturen af ​​diske.

Generelt, konfiguration, er trivielt

1. Du skal afgøre, hvilken type af vores drev – det kan være en af følgende : de, scsi, sat[,auto][,N][+TYPE], usbcypress[,X], usbjmicron[,x][,N], usbsunplus, Marvell, busk,N / E, 3ware,N, HPT,L / M / N, MegaRAID,N, cciss,N, auto, prøve. Den nemmeste måde er gennem checkpoint på “/proc / ide” eller “/proc / scsi”. Jeg har:

# 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

 

 

Som du kan se, har jeg 3 disk type ATA.

2. For at vi vil begynde at overvåge temperatur, skal være beskrevet i munin-node, der driver os. I filen /etc/munin/plugin-conf.d/hddtemp_smartctl at tilføje poster af følgende type

# 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

 

Vi Kan trække vores fremtidige test config på følgende måde

# 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

 

Hvis du får værdier, så alt er OK. Hvis du får en fejl, skal du kontrollere, om alt er korrekt beskrevet. Du skal genstarte munin nik-og du iscache 10-15 min popularat lidt data og begynde at tegne grafik. Du kan kontrollere /var/log/munin/munin-node.log fejl og deres let at fjerne.

Ако искате да получавате email при критична температура на дисковете трябва да добавите описание за критична такава:

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

I dag har jeg besluttet at lave nogle tests på en ren Cpanel-installation, som jeg havde behov for flere brugere. Som ikke ønsker, at vægten af kører serverne med de pakkerier for backup og filoverførsel jeg brugte arkiver sidste nat. Transferir alle filer i /home, og fandt, at Cpanel tilbyder ikke recovery mere 1 konto på samme tid via GUI og via CLI. I GUI, så kunne ikke få de tal, besluttede jeg izhitsa med cli restorepkg script. Det er bare uendeligt

/scripts/restorepkg username.tar.gz

Som den handling, der gentages for hver bruger separat. Når du forsøger at bruge * i stedet for det brugernavn scriptet directno mig klippe, så du er nødt til at gå lidt mere elegant –

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

for archive in $archives

do

/scripts/restorepkg --force $archive

done

Nu er der en hurtig forklaring. Vi gør dem en liste over alle de filer og arkiver blyskal i en variabel, så obchodne punkt på listen i afsnit forsøger vi at udtrække volumen besat hver separat arkiv. Intet meget interessant kompleks af Cpanel hvorfor fyrene ikke kan lide den medfølgende løsning til flere filer.