După cum știți CentOS 5 EOL este (Sfârșitul vieții) începând cu 31 martie 2017. Ceea ce conduce la următoarea problemă foarte interesantă:

# 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

 

Problema este că listele scurte de oglinzi CentOS 5 deja lovind în și încercarea de a obține conținutul direct obținut după refuzul:

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

 

În general, ideea de ansamblu mai prudent să reinstalați staniu cu o distribuție normală de lucru care acceptă actualizarea distributiv. Din păcate, a mea nu este cazul și nu se opune ca o opțiune pe masă. Așa că a trebuit să joace un regim mic de țigani – începe să utilizeze oglindă Vault. În momentul de față creatura complet limpede și bun-simț știu, Nu voi primi actualizări care nu este scopul exercițiului, și doresc doar să aibă de lucru cu yum pentru a instala pachetul pe care am nevoie. În acest scop, a comentat toate variabilele mirrorlist și se adaugă baseurl în /etc/yum.repos.d/CentOS-Base.repo. În cele din urmă vom obține repo yum pe tipul de

[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

În cele din urmă joacă un yum curat toate && actualizare yum. În cazul în care totul s-a încheiat fără a obţine eroare deci am finalizat cu succes sistemul şi puteţi instala în condiţii de siguranţă vă Pachete învechite.

 

Mdadm prietenul meu iubit, dar este ceva care irita o mulțime – inspecții periodice și resink RAID matrice de sănătate de securitate- de exemplu, există dovezi în sectorul rău și, care, la rândul său, zdrobește mașină pentru IO. În general, după ce choplene găsit vinovat – kronove care încep de obicei în jurul valorii de 1 oră în fiecare duminică seara. Ideea este clară – certitudinea că matrice este în stare perfectă și fără drame cu informații. Acest lucru este bun, dar în fiecare săptămână am vedea mult, așa că am reconfigurat la ranva de fiecare data primei a lunii.

Pentru derivații bazate pe Redhat cale a coroanei suedeze este /etc / cron.d / raid verificare. Pentru bazate pe Debian rutier distrotsi este /etc / cron.d / mdadm. Kronovete rândul său, scripturi bash apel /usr / sbin / raid verificare за CentOS etc и /usr / share / mdadm / checkarray Pentru Debian și prieteni. Parametrii care urmează să fie luate din scripturi /etc / sysconfig / raid verificare s /etc / default / mdadm în cazul în care acesta poate fi dezactivat în întregime check-și, care nu este o idee foarte inteligent ca.

 

Oricine care este angajat în web hosting știe ce amenințare sunt utilizatori infectate cu malware, coji de web etc. În cazuri această utilizare generală h nu un script rău. acesta dispune de 3 lucruri

  1. Este teribil de lent
  2. Este teribil de lent și, dacă-l lăsa în modul de monitorizare va izgavri server de tine
  3. Își menține propria bază de date de definiție MD5 / hex de cod rău.

Ultima caracteristică doar o face utilă, pentru că în afară de orice altceva poate sabmitvash fișiere care nu au fost detectate până în prezent, iar într-o etapă ulterioară va intra în bazele de date. Așa cum am împărtășit la punctul 1 și 2 Viteza este foarte scăzută – la încărcare mică fișierul mașină 70K este scanat timp de aproximativ o oră și jumătate. Din acest motiv, am început să ajute bunul meu prieten cu ShadowX Malmo – maldet alternativă scrisă în Python cu puțină flexibilitate. Din păcate, lipsa de timp (în principal, dar nu numai) nu am terminat proiectul, care în acest moment nu este foarte ușor de utilizat – există mai multe bug-uri care trebuie să fie eliminate. In ultimele zile am avut probleme cu clienții infectați cu CryptoPHP care au avut fișiere de mari public_html ~ 60k + inod-și Utilizator. Din moment ce numărul total a trebuit să fie scanat peste 200k fișier care aproximativ ar lua 5+ ore am decis să tune configurația maldet, pentru a diminua fișierele care vor fi scanate într-un număr mai rezonabil și timp. In timp ce iau confit observat următoarele linii

# 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

Interesant… Se pare că există posibilitatea de a utiliza ClamAV – care oferă, de asemenea, viteza mare, dar de ce nu încercați. A instalat rapid

/scripts/update_local_rpm_versions --edit target_settings.clamav installed

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

Maldet-rula și într-un dosar mic – Nu văd nici o diferență în viteză și comportament – El folosește său de scanare sa-perl de schi în loc de cea a CLAMAV. După o scurtă cernerea prin sursa de maldet a constatat următoarele linii

 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

Da a făcut o care 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 пъти и половина по бързо в сравнение с преди.

Înainte de a fi început cu o altă ură aleatoare la 50 OS s'tinki Vreau să spun, că în fiecare zi trebuie să se administreze o cunosc first-person singular destul de bine. Astăzi am petrecut timp pentru a iztestvam magie noua facilitate neauzit și nevăzut de upgrade distrubitiven (pseudo) 😀 . Primul lucru pe care ma uimit este, că RedHat în înțelepciunea sa infinită s-au decis să întrerupă sprijinul pentru arhitectura x86 🙄 . Напълно съм наясно че сме 2014-та година и сървърни процесори с 32 instrucțiuni pic lung lipsă. Мда ама какво правят потребителите на малки VPS-и – x64 labei mai mult de RAM, așa cum te uiți la ea, dacă aveți mașină virtuală subțire, cu 512 MB-1GB de RAM va lupta pentru fiecare ea megabay și nu deșeuri 20-30% Doar pentru a utiliza un set mare de instrucțiuni. Prepsuvah pentru că am fost instalil CentOS x86 și x64 tras o. Imediat am văzut o diferență în ISO-lea – ~ 100MB minim при 6.5. Prepsuvah o mai mult timp. Am instalat din nou virtualkata am decis să văd cât de bine RedHat au făcut treaba – I-am dat / var și / usr partiții LVM separate pentru 😈 . După instalare, modernizate toate pachetele instalate și apache, PHP, mysql и bind – a fost interesant faptul că va prinde serviciu de foc. Deschis ca un lider bun student al CentOS pentru a actualiza și a început cu sârguință să urmeze pas cu pas. Când am ajuns la momentul în care, pentru a începe upgrade-ul real acest rasi ma sculptat, че имам критичен проблем 🙄 . Examinați ieșire detaliată – mdaaaa / usr nu poate este o partiție separată 😆 am știut, N-aș fi dezamăgit în Jim Whitehurst și compania. salva “extremă” problema a fost destul de mesaje nesemnate pachete, Fișierele konfizi care nu se potrivesc, etc.. WTF nu a fost folosit chiar noi arhive treia tot de la oglinzile lor tras mea nu am făcut nici o setare doar simplu yum install. Acum, totul a fost clar de upgrade, astfel destul de familiar forțat. Refaceți cu atenție ca și în cele din urmă am prompt scenariul și a fost peste tot pentru partiția / usr. Am fost prea leneș, care încearcă să Fix, oricum era numai în scopuri științifice, nici un produs server mod de a face upgrade la momentul respectiv. Am prins reinstalați virtualkata data asta tot ceea ce-l împinge în 1 acțiune. De asemenea, am luat o lecție, nu actualizează orice sarvasi suplimentară, după instalare de upgrade directă. Pasul final a venit din nou dialogul DOSA, care mi-a spus, Am o mulțime de probleme de mare – pachetele invalide, konfizi etc, dar ar putea continua. Am știut că la început nu le fac lucruri greșite. Am reporni din nou și am așteptat – oh ce un upgrade miracol finalizat cu succes. Și a funcționat, sau cel puțin de încărcare și nu au încercat să instaleze pachete suplimentare, dar comanda oprire depinde – sys încă a trebuit să fie un bug 💡 . Dupa ce tot acest Tarapoto a decis să instaleze un Centos curat 7 pentru a vedea dacă ne maraitul pentru partiția / boot în MVS – 6.5 nu permite o astfel de aroganță. ISO-am lansa și am fost șocat ușor de către instalator – nu a fost extrem de confortabil “ordonat”, complet ilogic frumos. След известна борба успях със заветната цел и аха да се инсталира и гръмна, че трябва да си изнеса /boot-а извън LVM-a 👿 Това е крайно не сериозно и досадно, ако поради някаква причина забравиш да си увеличиш размера на boot дяла от 200МБ и понатрупаш стари ядра какво се случва.

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

În ceea ce privește Jur RHEL și CentOS rahat și există unele lucruri pe care ei au inventat destul de știință de carte. De exemplu, adăugarea unui număr de suplimentare de IP-uri este un loc de muncă destul de frumos al nostru. În general, dacă aveți nevoie să adăugați un număr mare de adrese, aș fi contorizate un skriptche bash în care ciclul pentru a efectua operația care mâna nu a funcționat. La persoanele Centos / RHEL a dat seama destul de bine fișier gamă. În general, a crea un fișier / 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 в нашият случай