Sinds netenberg nooit voldeed aan mijn verwachtingen voor Fantastico 3 dus ik besloot om af te blazen totalka. Hoewel de correspondentie dat we een lange tijd geleden had en dat gaf hen richtlijnen voor het verbeteren van hun product aan een concurrerend niveau Softaculous en installatron het kwam tot het moment dat moest worden verwijderd hun plugin uit mijn Cpanel servers. Aangezien er geen instructies over hoe dit misverstand verhoogde ticket of te verwijderen support-en ze gaven me deze instructies.

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

Изпълних си командите за чистиха се файловете им като осъзнах нещо важно пичовете изобщо не споменаха как се де регистрира плъгина им от контролният панел 🙄 😆 Мдаа педераски номер но се случва то и аз трябваше да гледам повече. Ook had hij een stapel van hun dossiers gelaten uiteraard hopen terug als hun cliënt, want ze hadden de vele scripts installatie zoals gezegd voorprogramma (Geen woord het is het juiste ding) :lol: . Dus laten we doorgaan met de volledige strippen:

Dit is de belangrijkste stap die moet worden gedaan voordat het overschrijven alles anders, want dan zal je uiteindelijk maar werd plugin pictogram in het Configuratiescherm, omdat er nog steeds is ingeschreven.

/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

In gevallen gemist stap unregister_cpanelplugi hebben om een ​​extra stap te spelen:

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 sluier al is uit het spel en je kunt rustig slapen. De redenen waarom het veranderde met concurrerende product 3 en zeer eenvoudig

  • Geen API die ik kan communiceren als u wilt toevoegingen of enige andere spells te maken
  • geen haken in bepaalde handelingen kan worden bevestigd aan het type en functionaliteit
  • slechte ondersteuning nogal traag en niet erg adequaat in hun antwoorden

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

Sommige ontwikkelaars gewoon niet leren om competent schrijf nooit in RFC. Ik heb gemerkt dat veel errror_log bestanden die enorm aantal idioten en waarschuwings-en merk had opgelopen wegens niet-PHP-normen. In het algemeen is het moeilijk te leggen aan de gebruiker, die code dat wordt overgebracht slecht is en moet worden gerepareerd. In het algemeen heb ik gemerkt dat de consument niet op error log-s na hun werkende code. In principe radicale aanpak is om volledig error_log bestanden te stoppen en die wil om ze te draaien, maar als een geheel zal ongemak voor vrij gebruikers maken. Dus draai te benaderen 2 – admin of superkrachten 1 ред bash. Zoeken naar bestanden met de naam error_log omvang meer dan 5MB (hier kostte me laat haar in haar geheel, hoewel 1MB is meer dan genoeg) en wekelijkse ze te verwijderen. Dat effect wordt bereikt door eenvoudige vind

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

Het blijft alleen om te crashen in de kroon moet worden uitgevoerd een keer per week en hebben een vrij hardnekkige beslissing. In mijn gevallen lijkt QA in 1 pm elke zondag.

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

Iedereen die zich bezighoudt met web hosting weet wat gevaar besmet gebruikers met malware, web schelpen etc. In gevallen Dit Algemeen gebruik h geen slechte script. Het beschikt over 3 dingen

  1. Is verschrikkelijk traag
  2. Het is verschrikkelijk traag en als het laat de bewaking modus server izgavri u
  3. Handhaaft zijn eigen database van md5 / hex definitie van slechte code.

Net laatste eigenschap maakt het nuttig, want afgezien van iets anders bestanden die niet zijn tot nu toe hebben ontdekt kunnen sabmitvash, en in een later stadium zal in databases komen. Zoals ik gedeeld in punt 1 en 2 snelheid is schrikbarend laag – bij lage belasting van de machine 70K bestand wordt gescand op ongeveer een uur en een half. Om deze reden ben ik begonnen met mijn goede vriend met ShadowX helpen Malmo – alternatieve maldet geschreven in Python met weinig flexibiliteit. Helaas, gebrek aan tijd (vooral, maar niet alleen) we hebben niet het project af, die op dit moment niet erg bruikbaar – er zijn vele bugs die moeten worden opgeruimd. In de afgelopen dagen had ik problemen met cliënten die besmet zijn met CryptoPHP die grote bestanden public_html ~ 60k + inod-en User had. Aangezien de totale moest worden gescand meer dan 200k dossier dat ruwweg zou nemen 5+ uur heb ik besloten om afstemmen van de configuratie van maldet, om de bestanden die worden gescand naar een redelijk aantal en de tijd verminderen. Terwijl het oppakken confit merkte de volgende regels

# 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

belangwekkend… Blijkbaar is er een mogelijkheid om te gebruiken ClamAV – die heeft ook grote snelheid, maar waarom niet proberen. Een snel geïnstalleerd

/scripts/update_local_rpm_versions --edit target_settings.clamav installed

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

Maldet-run en op een kleine map – Ik zie geen verschil in snelheid en het gedrag – Hij is met behulp van zijn van zijn perl-ski scanner in plaats van die van de ClamAV. Na een korte uitpluizen bron van maldet vond de volgende regels

 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

Yep maakte een die 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 пъти и половина по бързо в сравнение с преди.

Standaard wordt bij het installeren Munin Cpanel ontbreekt in een soort config die ze moeten maken met de hand. За мен един от тях е мониторинга на температурата на дисковете.

In het algemeen is de configuratie triviaal

1. We moeten de aard van onze stations te identificeren – Het kan een van de volgende zijn : zij, scsi, za[,auto][,N][+TYPE], usbcypress[,X], usbjmicron[,X][,N], usbsunplus, Marvell, areca,N / E, 3aardewerk,N, hpt,L / M / N, MegaRAID,N, cciss,N, auto, test. De makkelijkste manier is door middel van een kat “/proc / ide” of “/proc / scsi”. me:

# 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

 

 

Zoals te zien hebben 3 disc type ATA.

2. Om te beginnen om de temperatuur te bewaken zou moeten beschrijven in Munin knooppunt ons drijft. In het bestand /etc/munin/plugin-conf.d/hddtemp_smartctl items toevoegen uit het volgende 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

 

We kunnen test van onze toekomstige config hit op de 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

 

Als je waarden betekenen alles is ok. Als je een foutmelding krijgt moet u controleren of alles correct beschreven. Moet herstarten Munin knik-en u en wacht 10-15 min tot minder bevolkte gegevens en beginnen om afbeeldingen te tekenen. Можете да проверите /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

Vandaag heb ik besloten om een ​​aantal tests doen op een schone installatie voor Cpanel dat ik nodig heb meerdere gebruikers. Omdat ik niet wilde opzadelen werken servers inpakken back-up en overdracht van bestanden die worden gebruikt records uit de avond tevoren. De overdracht van alle bestanden in / home en vond dat Cpanel biedt geen herstel meer 1 rekening tegelijkertijd in zowel GUI en CLI in. In GUI als konden krijgen nummers besloten om gekunsteld met cli script restorepkg. Het gebruik ervan is uiterst eenvoudig

/scripts/restorepkg username.tar.gz

De actie wordt herhaald voor iedere gebruiker apart. Wanneer ik probeer te gebruiken * in plaats van de gebruikersnaam script derektno sneed me derhalve enigszins sierlijk worden benaderd –

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

for archive in $archives

do

/scripts/restorepkg --force $archive

done

Nu snelle uitleg. Maak een lijst van alle back-ups en archieven stoten in variabele en blader door de lijst één item start uitpakken voor elke record apart. Нищо кой знае колко сложно интересно защо пичовете от Cpanel не са изплзвали подобно решение за множество файлове.