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

Voordat het begon met een andere willekeurige haat aan 50 s'tinki OS ik bedoel, dat elke dag heb ik te beheren haar leren kennen als eerste persoon enkelvoud vrij goed. Vandaag heb ik tijd om nieuwe magie ongehoord en ongezien functie distrubitiven upgrade iztestvam (pseudo) 😀 . Het eerste wat mij verbaasd is, dat RedHat in zijn oneindige wijsheid besloten om ondersteuning voor x86-architectuur te staken 🙄 . Напълно съм наясно че сме 2014-та година и сървърни процесори с 32 beetje lang instructie ontbreekt. Мда ама какво правят потребителите на малки VPS-и – x64 poot meer RAM-geheugen, als je er naar kijkt als je dunne virtuele machine met 512 MB-1 GB RAM zal vechten voor elke megabay het en geen afval 20-30% Gewoon om een ​​grote reeks instructies gebruiken. Prepsuvah want ik was instalil CentOS x86 en x64 trok een. Meteen zag ik een verschil in ISO-th – ~ 100 MB minimum при 6.5. Prepsuvah nog een keer. Ik opnieuw geïnstalleerd virtualkata ik besloten om te zien hoe goed RedHat hun werk hebben gedaan – Ik gaf / var en / usr aparte LVM partities 😈 . Na de installatie opgewaardeerd alle pakketten geïnstalleerd en apache, php, mysql и bind – het was interessant dat de brandweer zal vangen. Geopend als een goede leerling leiding van CentOS te werken en begon ijverig om stap voor stap te volgen. Toen ik het moment bereikt om de werkelijke upgrade beginnen deze berg leeuwen gesneden me, че имам критичен проблем 🙄 . Geef je mening over gedetailleerde uitvoer – mdaaaa / usr niet kan is een aparte partitie 😆 ik wist, Ik zou niet teleurgesteld worden in Jim Whitehurst en bedrijf. besparen “extreem” probleem was nogal berichten ondertekende pakketten, konfizi bestanden die niet overeenkomen, etc.. WTF was niet eens gebruik maken van de derde repositories alles uit hun spiegels trok mijn ik had geen instellingen gewoon simpel gedaan yum install. Nu is alles duidelijk was zo rustig zonder plichtplegingen gedwongen upgrade. Herstart weer ijverig als ik eindelijk gevraagd het script en het was allemaal voorbij voor / usr partitie. Ik was te lui, die proberen om Fix, toch was het slechts voor wetenschappelijke doeleinden geen manier server product te upgraden op het moment. Ik ving opnieuw uw virtualkata deze keer alles duw het in 1 aandeel. Ook nam ik een les, geen updates eventuele extra sarvasi, na installatie direct upgrade. De laatste stap kwam weer op DOSA dialoog die me vertelde, Ik heb veel moeite High – ongeldig pakketten, konfizi etc. maar hij kan verder. Ik wist dat er in het begin niet ze verkeerde dingen te maken. Ik reboot opnieuw en wachtte – oh wat een wonder upgrade succesvol afgerond. En het werkte, althans opstarten en niet geprobeerd om extra pakketten te installeren, maar halt commando hangt af – sys moest nog een bug 💡 . Na deze hele Tarapoto besloten om een ​​schone installatie van CentOS 7 om te zien of we grommen voor / boot partitie in LVM – 6.5 niet een dergelijke arrogantie toestaan. ISO-lanceer ik het en ik werd licht geschokt door de installateur – Het was niet erg comfortabel “ordelijk”, volkomen onlogisch om mooie. След известна борба успях със заветната цел и аха да се инсталира и гръмна, че трябва да си изнеса /boot-а извън LVM-a 👿 Това е крайно не сериозно и досадно, ако поради някаква причина забравиш да си увеличиш размера на boot дяла от 200МБ и понатрупаш стари ядра какво се случва.

В общи линии нищо не очаквах и пак съм разочарован от CentOS.

Zoals te zweren RHEL en CentOS poep-en er zijn een aantal dingen die ze uitgevonden heel geletterd. Bijvoorbeeld, het toevoegen van een aantal extra IP-s is een aardige baan van ons. In het algemeen, als u een groot aantal adressen toevoegen zou ik hebben een bash skriptche geteld waarin de fiets naar het uitvoeren van de operatie die de hand werkte niet. In Centos / RHEL mensen heeft hij bedacht vrij goed aanbod bestand. In het algemeen, maak je een bestand / etc / sysconfig / network-scripts / ifcfg-eth0-range0. Тук заменяме eth0 със името мрежовият адаптер ако не е eth0. След което добавяме следното съдържание

IPADDR_START=192.168.0.129
IPADDR_END=192.168.0.254
NETMASK=255.255.255.128
CLONENUM_START=0

като аргументите са

  • IPADDR_STARTначален IP адрес
  • IPADDR_ENDкраен адрес
  • NETMASKмрежова маска
  • CLONENUM_STARTномерация от която да започнат мрежовите адаптер eth0:0 в нашият случай

 

In Centos, maar minder interessant in de opzet van de brug adapters. Ik accepteer dat is al geïnstalleerd bridge-utils pakket en eth0 (dit is in mijn voorbeeld) reeks, dus laten we eens kijken naar de basisstappen

  1. Kopieer instellingen in eth0 br0 (hier al als u een andere naamgeving adapters nodig om het te corrigeren)
  2. Zanestvate registreert eth0 configuratiebestand br0
  3. zamestvate type Ethernet-adapter in de Bridge
  4. Het verwijderen van het MAC-adres van de configuratie br0
  5. Set in eth0 configuratie dat we een brug adapter br0 zal

За да спестя време си го разписах като елементарно bash скриптче

cd /etc/sysconfig/network-scripts/
cp ifcfg-eth0 ifcfg-br0
sed -i 's/eth0/br0/' ifcfg-br0
sed -i 's/Ethernet/Bridge/' ifcfg-br0
sed -i '/HWADDR/d' ifcfg-br0
echo 'BRIDGE="br0"' >> ifcfg-eth0

Vandaag sutinrta begon te doen de standaard dist upgrade van een Debian-server en Dovecot stierf de volgende fout 🙂

[….] Vanaf IMAP / POP3-mailserver: dovecotError: stopcontact() mislukt: Adres familie niet ondersteund door protocol
Fout: service(pop3-login): luister(::, 110) mislukt: Adres familie niet ondersteund door protocol
Fout: stopcontact() mislukt: Adres familie niet ondersteund door protocol
Fout: service(pop3-login): luister(::, 995) mislukt: Adres familie niet ondersteund door protocol
Fout: stopcontact() mislukt: Adres familie niet ondersteund door protocol
Fout: service(imap-login): luister(::, 143) mislukt: Adres familie niet ondersteund door protocol
Fout: stopcontact() mislukt: Adres familie niet ondersteund door protocol
Fout: service(imap-login): luister(::, 993) mislukt: Adres familie niet ondersteund door protocol
fataal: Kan luisteraars beginnen
mislukt!

 

Ако се загледате внимателно в нея грешката вади очите на човек luister(::, 993) mislukt uiteraard proberen om het IPv6-adres dat ik verbood om te luisteren 😈 . De oplossing is even ochevdino als zichzelf fout – трябва да накараме dovecot да работи само на ipv4, което се постига с следният ред в /etc/dovecot/dovecot.conf
listen=0.0.0.0
След което удряме един бърз рестарт на Dovecot и всичко е по реда си и можем да продължим с дистрибутивният ъпгрейд