As netenberg oor die algemeen nie geregverdig my verwagtinge fantastico 3 dryf ek het besluit om dit vry te stel heeltemal uit hulle dak. Hoewel korrespondensie wat bespreek lang en van die beginsels wat ek aan hulle gegee het vir die verbetering van hul produk in'n mededingende vlak, softaculous en installatron om te kry tot die punt waar jy veronderstel is om te verwyder word hul plugin Cpanel bedieners my. Aangesien daar is geen instruksies, hoe is dit'n misverstand, ek het'n kaartjie in die ondersteuning en hulle het my die volgende instruksies.

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

Изпълних си командите за чистиха се файловете им като осъзнах нещо важно пичовете изобщо не споменаха как се де регистрира плъгина им от контролният панел 🙄 😆 Мдаа педераски номер но се случва то и аз трябваше да гледам повече. Dit was ook, daar was een huis hul lêers, blykbaar met die hoop om terug te keer as hul kliënt, aangesien daar nie'n baie van skrifte vir die installasie soos gesê ondersteuning (moenie dink dit is die belangrikste ding reg) :lol: . O laat ons voortgaan met volle skorman:

Dit is die mees belangrike stap wat gedoen moet word voor setrate alles anders, so dan sal jy uiteindelik was die plugin, maar die ikoon in die beheer paneel, as alles anders was.

/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

Hier jy gemis het'n stap unregister_cpanelplugi om te speel nog'n ekstra stap:

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 reeds dek hierdie spel, en jy kan rustig slaap. Die redes as gevolg van wat dit is vervang met'n mededingende produk 3 en dit is baie eenvoudig

  • Jy hoef nie API wat ek kan bekostig komuniciram as ek wil om te maak toevoegings of enige ander uitspel
  • geen hake " tema in aksie te ek uitset en dopium funksionaliteit
  • dat damn ondersteuning is baie stadig en nie baie voldoende in hul antwoorde

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

Iemand programmeerders net nie leer om te skryf korrek volgens die RFC nooit. Ek het opgemerk'n paar errror_log lêers in wat hulle opgedoen het'n groot hoeveelheid maloni waarskuwing en kennisgewing vir versuim om te voldoen aan standaarde PHP. In die Algemeen, dit is moeilik om te verduidelik aan die gebruiker, die kode wat dit geïnstalleer is sleg en moet bevestiging. In die Algemene geval, ek het opgemerk dat die gebruikers nie omgee oor die fout log-s sodra hul kode werk. In beginsel, 'n radikale benadering te stop heeltemal error_log lêers, en wat wil om hul uitgawes, maar, as'n reël, sal veroorsaak ongemak vir baie gebruikers. Daarom dasilva op die pad 2 – geen super krag of 1 lyn bash. Soek vir lêers met die naam error_log groter as 5 MB (hier is die waarde van dit vir my, ek het in die groot al 1MB is meer as genoeg) en die verwydering van hulle weeklikse. Hierdie effek word bereik gemors met vind

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

Dit bly net om te crash in die kroon, wat hardloop een keer'n week, en ons het'n mooi hardnekkige oplossing. In my hier, ek dink OK 1 Elke sondag PM.

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

Enigiemand wat handel professioneel met web hosting weet wat die bedreiging verteenwoordig besmet gebruikers wat met hierdie malware, web skulpe ens. In obset hier gebruik maldet een slegte script. Dit verskil 3 dinge

  1. Vreeslik stadig
  2. Regtig stadig en as jy dit laat gaan in monitor af sal, shauri server wat jy
  3. Hou sy eie databasis met die md5/hex, definitiewe slegte kode.

Dit is die laasgenoemde funksie maak dit nuttig, want onder ander dinge, kan symitar lêers wat nog nie ontdek is so ver en op'n later stadium sal kry in die databasis. As gedeel in die punt 1 en 2 sy spoed is skokkend laag – by lae las op die motor 70K lêer geskandeer vir'n uur en'n half. Vir hierdie rede, het ek begin om te help om my goeie vriend, ShadowX met Malmö – alternatiewe maldet geskryf in python met'n bietjie van buigsaamheid. Ongelukkig, as gevolg van'n gebrek van die tyd (meestal, maar nie net) ons doen nie dovrsili projek, wat is tans nie baie nuttig – daar is nogal'n baie van die foute om skoon te maak. Oor die afgelope paar dae het ek het probleme gehad met kliënte besmet is met CryptoPHP wat'n groot public_html lêers ~60K+ inod-gebruiker. So in samewerking moes word nagegaan op 200k lêer wat groot rekeninge sal dit neem 5+ uur het ek besluit tuningova opset maldet, om te verminder die lêers wat sal nagegaan word in'n meer redelike plek en tyd. Terwyl die kies van konfa opgemerk die volgende lyne

# 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… Natuurlik, dit is moontlik om te gebruik ClamAV – wat is nie'n hoë spoed, maar nie hoekom nie om te probeer. Vinnig ek stel

/scripts/update_local_rpm_versions --edit target_settings.clamav installed

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

Vrylating maldet-'n klein gids – Ek sien geen verskil in spoed en gedrag – gebruik dit perl-ish skandeerder plaas vir clamav. Na'n kort grawe in die kode maldet ek het gevind dat die volgende lyne

 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, ek het een wat clamscan и за моя голяма изненада открих че clamav изобщо не е в PATH-a ами тъпият Cpanel го е оставил само в /usr/local/cpanel/3rdparty/bin/ от където той си използва бинарките. Един бърз ln реши проблема:

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

При повторно сканиране maldet вече горно съобщава

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

След като вече използва ClamAV maldet приключва сканирането си 3-4-5 пъти по бързо в сравнение с преди. Теста показа – 70к inod-а ги изтъркла за около 25 мин което си е около 3 пъти и половина по бързо в сравнение с преди.

By verstek wanneer jy installeer Munin Cpanel ontbreek'n paar goeie apache wat het hulle te doen met die hand. За мен един от тях е мониторинга на температурата на дисковете.

In die Algemeen, opset is triviale

1. Jy moet bepaal wat die tipe van ons dryf – dit kan een van die volgende : ata, scsi, sit[,auto][,N][+TIPE], usbcypress[,X], usbjmicron[,x][,N], usbsunplus, marvell, areca,N/E, 3ware,N, hpt,L/M/N, megaraid,N, cciss,N, auto, toets. Die maklikste manier is deur middel van die kontrolepunt op “/proc/ide” of “/proc/scsi”. Ek het:

# 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

 

 

Soos jy kan sien ek het 3 skyf tipe ATA.

2. In orde dat ons sal begin om te monitor die temperatuur, moet beskryf word in die munin knoop ons dryf. In die lêer /etc/munin/plugin-conf.d/hddtemp_smartctl te voeg inskrywings van die volgende tipe

# 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

 

Ons Kan trek ons toekoms toets config in die volgende manier

# 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

 

As jy waardes dan is alles OK. As jy'n fout wat jy moet kyk as alles is korrek beskryf. Jy moet herlaai munin knik-en jy iscache 10-15 min te popularat min data en begin om te trek grafiese. Можете да проверите /var/log/munin/munin-node.log за грешки и по лесното им отстраняване.

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

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

Vandag het ek besluit om te maak'n paar toetse op'n skoon Cpanel installasie, wat ek het'n behoefte vir verskeie gebruikers. As wou nie die gewig van die loop bedieners met die packers vir friends en lêer oordrag ek gebruik die argiewe laaste nag. Transferir al die lêers in /huis en gevind dat Cpanel nie herstel meer bied 1 rekening gelyktydig deur die GUI en deur CLI. In die GUI so kon nie die getalle nie, het ek besluit izhitsa met die cli restorepkg script. Dit is oneindig net

/scripts/restorepkg username.tar.gz

As die aksie herhaal word vir elke gebruiker afsonderlik. Wanneer jy probeer om te gebruik * in plaas van die gebruikersnaam van die script directno my sny, sodat jy nodig het om te loop'n bietjie meer elegant –

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

for archive in $archives

do

/scripts/restorepkg --force $archive

done

Nou is'n vinnige verduideliking. Ons maak'n lys van al die lêers en argiewe blyskal in'n veranderlike dan obchodne die lys item in die paragraaf, ons probeer om te onttrek van die volume beset elke argief afsonderlik. Нищо кой знае колко сложно интересно защо пичовете от Cpanel не са изплзвали подобно решение за множество файлове.