Mint tudod CentOS 5 EOL (Az élet vége) március 31- 2017. Ami a következő nagyon érdekes probléma:

# 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

 

A probléma az, hogy a rövid listákat CentOS tükrök 5 Már virul, és megkísérli, hogy közvetlenül a tartalmak után kapott elutasítást:

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

 

Általában összességében a legóvatosabb ötlet, hogy újra az ón normális eloszlás, amely támogatja a dolgozó elosztó frissítés. Sajnos az enyém nem ez a helyzet, és nem áll opcióként az asztalon. Ezért kellett játszani egy kicsit cigány rendszer – elkezdi használni Vault tükör. Abban a pillanatban teljesen tiszta lény, és józanság tudni, Nem fogom kapni a frissítéseket nem célja a gyakorlat, és csak azt, hogy dolgozik yum telepíthető csomag, amit kell. Erre a célra megjegyzésbe minden mirrorlist változók és add baseURL a /etc/yum.repos.d/CentOS-Base.repo. Végül eljutunk yum repo, hogy milyen típusú

[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

Végül játszanak yum clean all && yum update. Ha minden véget ért anélkül, hogy hiba, így mi sikeresen befejezte a rendszer, és nyugodtan telepítse az elavult csomagok.

 

Mdadm szeretett barátja, de van valami, ami irritálja nagyon sokat – időszakos vizsgálatok és resink Biztonság Egészség RAID tömb- Például bizonyíték van a rossz szektor és, ami összetöri gép IO. Általában, miután bűnösnek találták choplene – kronove kezdődő általában körülbelül 1 óra minden vasárnap este. Az ötlet világos – bizonyossággal, hogy a tömb tökéletes állapotban van, és nem drámák információ. Ez jó, de minden héten látok egy csomó, úgyhogy átszervezni, hogy ranva minden első napjától a hónap.

Redhat-alapú származékos útját a korona /etc / /etc/cron.d/amit_akarsz fájlt / raid-ellenőrzés. Debian-alapú distrotsi út /etc / /etc/cron.d/amit_akarsz fájlt / mdadm. Kronovete viszont hívás scripts /usr / sbin / raid-ellenőrzés за CentOS stb и /usr / share / mdadm / checkarray A Debian és barátai. Paramétereket kell venni script /etc / sysconfig / raid-ellenőrzés s /etc / default / mdadm ahol teljesen letiltható bejelentkezés és, ami nem túl okos ötlet, mint.

 

Bárki, aki részt vesz tárhely tudja, milyen veszélyt jelent a fertőzött felhasználók malware, web kagyló stb. Azokban az esetekben jelen általános használatra h Nem rossz script. Jellemzője 3 a dolgok

  1. Szörnyen lassú
  2. Ez szörnyen lassú, és ha hagyja, hogy a monitoring módban izgavri szerver
  3. Megtartja saját adatbázisa md5 / hex meghatározása rossz kód.

Csak a múlt tulajdonság teszi hasznos, mert eltekintve bármi mást sabmitvash fájlokat, amelyeket nem mutattak ki eddig, és egy későbbi szakaszban lépnek adatbázisok. Amint azt a közös pont 1 és 2 sebesség megdöbbentően alacsony – kis terhelés a gép 70K fájl beolvasása körülbelül egy és fél óra. Emiatt kezdtem, hogy segítsen a jó barát ShadowX Malmö – alternatív maldet írt python kevés rugalmasságot. Sajnos, az idő rövidsége (elsősorban, de nem kizárólag) mi nem fejezte be a projekt, amely abban a pillanatban nem nagyon használható – sok hibát, hogy tisztázni kell. Az elmúlt napokban nem volt probléma az ügyfelek fertőzött CryptoPHP aki nagy fájlok public_html ~ 60k + inod-és felhasználói. Mivel összesen kellett szkennelni alatt 200K fájl, amely nagyjából tartana 5+ órát úgy döntöttem, hogy beállítsa a konfiguráció maldet, hogy csökkentse a fájlok lesznek vizsgálva, hogy egy ésszerű számban és időben. Míg szedés confit észrevette a következő sorokat

# 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

érdekes módon… Úgy látszik, van egy lehetőség, hogy használni ClamAV – amely szintén tartalmaz nagy sebességgel, de miért nem próbálja. A gyorsan telepíthető

/scripts/update_local_rpm_versions --edit target_settings.clamav installed

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

Maldet-futás és egy kis mappa – Nem látok különbséget a sebesség és a viselkedés – Ő használja az ő perl-ski szkenner helyett, hogy a clamav. Egy rövid szitálás forrása maldet talált a következő sorokat

 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

Ja tett amely clamscan és nagy meglepetésemre rájöttem, hogy clamav nem található elérési út, mi egy hülye Cpanel elhagyta őt csak a/usr/helyi/cpanel/3rdparty/bin/a házmester binarkite ahol. Egy gyors erősít a probléma ln:

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

Scan most maldet felső jelentések bíró

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

Után már használ ClamAV maldet véget ér a beolvasás 3-4-5 szer gyorsabb, mint korábban. A vizsgálat azt mutatta – 70k-izt″rkla inod őket a 25 min, ami körülbelül 3 és fél-szer gyorsabb, mint korábban.

Mielőtt elkezdte egy másik véletlenszerű gyűlöletet 50 s'tinki OS értem, hogy minden nap azt kell beadni neki, hogy az első személy egyes szám meglehetősen jól. Ma töltöttem időt iztestvam új mágikus hallott és látott funkció distrubitiven frissítés (ál) 😀 . Az első dolog, ami lenyűgözött engem, hogy RedHat végtelen bölcsességében úgy döntött, hogy hagyja abba támogatása x86 architektúra 🙄 . Én vagyok tisztában, hogy mi vagyunk az évben 2014 és kiszolgáló processzorok 32 kicsit hosszú használati hiányzik. Igen, de a felhasználók mit egy kis VPS és – x64 mancs több RAM, ahogy nézzük, ha vékony a virtuális gép 512-1 GB RAM harcolni fog minden megabay, és nem pazaroljuk 20-30% Csak, hogy egy nagy sor utasítást. Prepsuvah mert én instalil CentOS x86 és x64 kihúzott egy. Azonnal láttam a különbséget ISO-edik – ~ 100MB minimum при 6.5. Prepsuvah még egyszer. Telepítettem újra virtualkata úgy döntöttem, hogy milyen jól RedHat volna a munkát – Adtam a / var és / usr külön LVM partíciók 😈 . A telepítés után frissíteni az összes telepített csomagok és apache, php, mysql и kötődnek – Érdekes volt, hogy kifogja a tűzoltóság. Nyitott, mint egy jó tanuló vezetésével CentOS frissítéséhez és elkezdte szorgalmasan követni lépésről lépésre. Amikor elérte a pillanatban kezdődik a tényleges frissítés a hegyi oroszlán faragott nekem, Nekem van egy kritikus probléma 🙄 . Tekintse át részletes kimenet – mdaaaa / usr ez nem egy külön partíción 😆 Tudtam, Nem lennék csalódott Jim Whitehurst és a társaság. megment “szélső” probléma meglehetősen üzenetek aláíratlan csomagok, konfizi fájlokat, amelyek nem felelnek meg, stb. WTF nem is használja a harmadik adattárak mindent a tükör húztam nem tettem volna semmilyen beállítást csak egyszerű yum install. Most minden világos volt, így elég teketória nélkül kényszerű frissítési. Ismét újraindítani szorgalmasan végül kéri a forgatókönyvet, és ez volt az egész / usr partíció. Túl lusta voltam, hogy megpróbálja megjavítani, egyébként ez csak tudományos célra semmilyen módon kiszolgáló termék frissíteni idején. Elkaptam újratelepítését virtualkata ezúttal mindent lök a 1 részvény. Szintén vettem egy leckét, nem frissíti minden további sarvasi, telepítés után közvetlen frissítés. Az utolsó lépés ismét jött DOSA párbeszéd, aki azt mondta, Van egy csomó bajt Nagy – érvénytelen csomagokat, konfizi stb, de tudta folytatni. Tudtam, hogy az elején nem teszik őket rossz dolgokat. Azt indítsd újra a gépet, és vártam – ó, milyen csoda frissítés sikeresen befejeződött. És működött, vagy legalábbis csomagtartó, és nem próbált további csomagok telepítését, de halt parancsot függ – sys még volt, hogy egy hiba 💡 . Miután ez az egész Tarapoto úgy döntött, hogy telepíteni egy tiszta Centos 7 hogy ha morogva a / boot partíció LVM – 6.5 nem teszi lehetővé az ilyen arrogancia. ISO-én indít el, és nagyon enyhén sokkolt a telepítő – nem volt rendkívül kényelmes “takaros”, teljesen logikátlan, hogy gyönyörű. Után néhány harc kezelt-hoz felszerel a tömítéssel dédelgetett cél és igen, Meg kell oldania ki/boot-és azon túl-👿 egy LVM rendkívül súlyos, és nem zavaró, Ha részére némely ok ön elfelejt-hoz növekszik a méret, a rendszerindító partíció a 200 MB, és néhány régi magok mi történik.

Alapvetően én nem várok semmit, és én vagyok még mindig csalódott a CentOS.

Ami esküszöm RHEL és CentOS szar-és van néhány dolog, hogy ők találták elég írástudó. Például, hozzátéve, számos további IP-s egy nagyon szép munkát a miénk. Általában, ha kell hozzá egy nagy számú címek volna összeszámlálása egy bash skriptche amelyben ciklus végezze el a műveletet, hogy a kéz nem működik. CentOS / RHEL nép rájött, nagyon jó sor fájl. Általában, hozzon létre egy / etc / sysconfig / network-scripts / ifcfg-eth0-range0. Itt helyett eth0 hálózati adapter neve, ha nem eth0. Majd adja hozzá a következő tartalommal

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

mivel az érvek

  • IPADDR_START – kezdő IP-címe
  • IPADDR_END – végleges cím
  • HÁLÓZATI MASZK – alhálózati maszk
  • CLONENUM_START – számozás kezdődik a hálózati csatoló eth0:0 a mi esetünkben