Zoals u weet CentOS 5 EOL is (Eind van het leven) vanaf 31 maart 2017. Die leidt tot de volgende zeer interessant probleem:

# yum update
Loaded plugins: fastestmirror, security
Loading mirror speeds from cached hostfile
YumRepo Error: All mirror URLs are not using ftp, http[s] or file.
 Eg. Invalid release/
YumRepo Error: All mirror URLs are not using ftp, http[s] or file.
 Eg. Invalid release/
removing mirrorlist with no valid mirrors: /var/cache/yum/extras/mirrorlist.txt
Error: Cannot find a valid baseurl for repo: extras

 

Het probleem is dat de korte lijsten van CentOS spiegels 5 al schoppen in en proberen om rechtstreeks te krijgen inhoud verkregen na weigering:

# curl 'http://mirrorlist.centos.org/?release=5&arch=i386&repo=os'
Invalid release

 

In het algemeen over het algemeen het meest voorzichtige idee om het blik met een normale verdeling die ondersteuning biedt voor het werken distributieve upgrade opnieuw te installeren. Helaas is de mijne is niet het geval en het staat niet als een optie op de tafel. Dus moesten we een beetje zigeuner regeling spelen – beginnen te gebruiken Vault spiegel. Op dit moment helemaal duidelijk wezen en gezond verstand weet, Ik zal geen enkele update dat is niet het doel van de oefening te ontvangen, en wil gewoon werken met yum te gebruiken pakket dat ik moet installeren om hebben. Voor dit doel uitgecommentarieerd alle mirrorlijst variabelen en voeg baseurl in /etc/yum.repos.d/CentOS-Base.repo. Eindelijk krijgen we yum repo van het type

[base]
name=CentOS-$releasever - Base
#mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=os
baseurl=http://vault.centos.org/5.11/os/i386/
#baseurl=http://mirror.centos.org/centos/$releasever/os/$basearch/
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-5

#released updates
[updates]
name=CentOS-$releasever - Updates
#mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=updates
baseurl=http://vault.centos.org/5.11/updates/i386/
#baseurl=http://mirror.centos.org/centos/$releasever/updates/$basearch/
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-5

#additional packages that may be useful
[extras]
name=CentOS-$releasever - Extras
#mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=extras
baseurl=http://vault.centos.org/5.11/extras/i386/
#baseurl=http://mirror.centos.org/centos/$releasever/extras/$basearch/
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-5

Tot slot spelen een yum schoon alle && yum-update. Als het allemaal eindigde zonder getting vergissing zodat we de regeling voor het met succes afgerond en we veilig kunnen installeren uw verouderde pakketten.

 

Mdadm mijn geliefde vriend, maar er is iets dat heel veel irriteert – periodieke keuringen en Resink Security Health RAID-array- Zo zijn er aanwijzingen in de slechte sector en, die op zijn beurt verplettert machine IO. In het algemeen, na choplene schuldig bevonden – kronove die meestal beginnen rond 1u elke zondagavond. Het idee is duidelijk – zekerheid dat de array is in perfecte staat en er geen drama's met informatie. Dit is goed, maar elke week Ik zie een heleboel, dus ik geconfigureerd dat het ranva van elke eerste dag van de maand.

Voor-Redhat gebaseerde derivaten pad van de kroon is /etc / cron.d / raid-check. Voor Debian-gebaseerde distrotsi weg is /etc / cron.d / mdadm. Kronovete draai gesprek bash scripts /usr / sbin / raid-check TraceParts CentOS etc и /usr / share / mdadm / checkarray Voor Debian en vrienden. Parameters te worden genomen van scripts /etc / sysconfig / raid-check s /etc / default / mdadm waar het volledig kan worden uitgeschakeld inchecken en, dat is niet erg slim idee als.

 

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 в нашият случай