Tipinės problemos — Dedikuoti.lt

Kaip sukonfiguruoti dideliam srautui?

useris — Fri, 03 Feb 2023 17:58:27 +0000

Noreciau sukonfiguruoti serveri (pageidautina per Webmin), kad butu atlaikomas didelis uzklausu srautas i svetaine/faila (pvz iki 15K per valanda). Susiduriama, kad tenka matyti 500 Internal Server Error ar kt. klaida. PHP programos yra labai minimalios ir greitos - vos kelios paprastos funkcijos. Procesoriaus ir kitos apkrovos kiek buna rodomos, tai labai mazos. Net vienas CPU branduolys gal tik 50% pasiekia piko metu.

Kokius parametrus siulytumete nustatyti, kad kuo daugiau Entry Processes ir pan. galetu vykti ir uzklausos "nepakibtu"?

Centos8 DirectAdmin SMTP neveikia, nors pop3 veikia

Pauliusl — Thu, 23 Sep 2021 08:11:43 +0000

Sveiki,
isirasiau nauja serveri, susikonfiguravau praktiskai identiskai kaip centos6 DA (direct admin) (kuri turime)
sukuriu domena, ijungiu dkim, susikuriu el.pasto vartotoja, matau, testuoju: matau, kad paraso kad issiuncia, taciau po ~24val. gaunu Mail delivery failed laiska.
nors pop3 serveris veikia. Nesvarbu ar siunciu per gmail'o configuruota acc, ar per roundCube ar SquirrelMail, rezultatas tas pats - rodo issisiuncia, atsakymas - failed po ~24val.
Galbut kazko pasikonfiguravau cloudlflare'e? Nors dariau pagal sena kito domeno configuracija, tai tik spf record'as idetas:

"v=spf1 a mx ip4:SERVERIO_IP -all"

Centos8 Directadmin negaliu suinstaliuoti php81

Pauliusl — Fri, 10 Dec 2021 19:00:15 +0000

negaliu suinstaliuot php81 versijos nes gaunu klaida:
error: 'zend_class_unserialize_deny' undeclared (first use in this function); did you mean 'zend_unserialize_data'? xmlrpc_server_ce->unserialize = zend_class_unserialize_deny; ^~~~~~~~~~~~~~~~~~~~~~~~~~~
su php73 ir su php80 viskas gerai taciau su php81 jau nebe.

Ką daryti, jeigu jūsų serveris naudojamas šlamšto (spam) siuntimui?

iv_vytenisg — Fri, 18 Jun 2021 13:11:02 +0000

Pastebime, kad tai yra viena labiausiai paplitusių problemų su kurią patiria mūsų VPS naudotojai. Labiausiai tikėtina, kad susidūrėte ar susidursite ateityje su šia problema tam tikru momentu, kai naudojatės virtualiai dedikuotais serveriais. Mes nusprendėme sukurti šį straipsnį, kad atkreiptume dėmesį į galimus šlamšto problemos variantus ir sprendimus.

Kodėl jūsų serveris siunčia šlamštą?

Tam gali būti daugybė priežasčių, tačiau dažniausiai būna šios:

Jūsų VPS buvo nulaužtas;
Jūsų svetainė buvo nulaužta;
Jūs siunčiate spam laiškus.

Toliau šiame straipsnyje nagrinėsime dvi pirmąsias iš šių priežasčių atskirai ir pateiksime keletą pasiūlymų, kaip to išvengti.

Ką daryti, jei jūsų VPS buvo nulaužtas?

Darant prielaidą, kad jūsų VPS nenaudojamas svetainių talpinimui, o naudojamas duomenims saugoti, duomenims apdoroti, VPN ar kitam, jums nėra reikalingas pašto tarnyba.

Pirmas prevencinis veiksmas turėtų būti išjungti arba pašalinti visas pašto tarnybas, tokias kaip Exim, Postfix, Sendmail, iš savo serveryje.

Antra, užblokuokite visus su SMTP susijusius prievadus: 25 (naujai įsigytoms paslaugoms šis prievadas yra blokuojamas automatiškai), 465, 587. Tai galima padaryti naudojant iptables ar kitą jūsų naudojamą ugniasienės programinę įrangą. Skirtingos programinės įrangos diegimo instrukcijas rasite šioje forume skiltyje.

Kartais el. laiškus galima siųsti naudojant SSH tunelius taip, kad šlamštą siunčia iš localhost. Tai daroma atliekant prievado persiuntimą per SSH, kuris sukuria saugų ryšį tarp localhost ir nuotolinio įrenginio, per kurį galima perduoti užklausą, pvz., SMTP. Kadangi šiam metodui reikalinga prieiga prie kurio nors nulaužto serverio vartotojo, tai parodo, kaip svarbu sukurti sudėtingą slaptažodį, naudoti nestandartinį SSH prievadą, aktyvuoti ir naudoti SSH raktą. Savo prisijungimo duomenis ir prieigą prie serverio saugokite ir perduokite tik žmonėms, kuriais pasitikite.

Paskutinis, bet ne mažiau svarbus aspektas - visada atnaujinkite savo programinę įrangą. Atlikite įprastus saugumo patikrinimus ar antivirusinius patikrinimus.

Ką daryti, jei jūsų svetainė buvo nulaužta?

Tai yra labiausiai paplitęs šlamšto siuntimo metodas mūsų serveriuose, nes mūsų VPS yra orientuotas į svetainių talpinimą. Taigi kaip elgtis, jeigu svetainė buvo nulaužta?

Patikrinkite ir nuskenuokite serverį naudodami antivirusinę programinę įrangą. Dauguma atakų nėra vienetinės ir jau buvo vykdomos anksčiau, todėl kenkėjišką programą ar injekciją ras tinkami antivirusiniai įrankiai.
Įsitikinkite, kad jūsų turinio valdymo sistema yra atnaujinta, o jei ne, atnaujinkite ją! Atnaujinimai išleidžiami ne tik dėl to, kad į programinę įrangą įtraukta tam tikra nauja funkcija, bet ir siekiant pašalinti pažeidžiamumus, kurie tapo viešais ir kuriais trečioji šalis piktnaudžiavo. Būtinai nustatykite automatinius naujinimus arba bent reguliariai tikrinkite tai rankiniu būdu.
Jei jūsų VPS naudoja Apache kaip numatytąją web tarnybą, tam yra puikus įrankis, vadinamas ModSecurity, tai yra svetainės ugniasienė. Tai padeda nuskaityti ir užblokuoti daugybę įtartinų užklausų nukreiptų į jūsų svetainėms ir nuolat jas tikrinti. Tai puikus būdas užkirsti kelią jūsų svetainių užkrėtimui dažniausiai pasitaikančiomis injekcijomis. ModSecurity galima nustatyti, kad automatiniu būdu būtų blokuojamos nepageidaujamos ar įtartinos užklausos.
Įsitikinkite, kad savo TVS naudojate saugius ir patikimus slaptažodžius, nesidalinkite jais.
Nenaudokite nežinomų papildinių/įskiepių, nes juos galima kurti ir skelbti norint tik tam, kad patekti į jūsų svetainę.
Apribokite failų plėtinius, kuriuos leidžiate įkelti į savo svetaines.
Priskirkite savo failams ir aplankams tinkamas teises ir pabandykite išvengti 777 teisių.

Ką daryti, jei atlikote visus prevencinius veiksmus ir vis tiek gavote pranešimą, kad jūsų serveris siunčia spam?

Nepaisant to, kad šlamštas ir masinių laiškų siuntimas mūsų VPS neleidžiami, jūsų svetainės greičiausiai vis tiek retkarčiais siųs kai kuriuos el. laiškus. Tokie kaip registracijos patvirtinimo el. laiškai, slaptažodžio nustatymo iš naujo jūsų klientams, naujienlaiškio užsakymo laiškai, kai kurie jūsų sistemos informacijos pakeitimų žurnalai ir kt. Šie el. laiškai gali būti pažymėti kaip šlamštas ir atmesti, o tai galiausiai lemia tai, kad serveris įtraukiamas į juodąjį sąrašą. Žemiau pateikiame keletą idėjų, kaip padaryti šiuos el. Laiškus patikimesnius kitiems pašto serveriams.

Sukurkite ir naudokite SPF, DKIM įrašus savo domenui.
Venkite kai kurių spam laiškuose naudojamų raktinių žodžių. Tai iš esmės visi raktiniai žodžiai, susiję su pardavimu, siūlymu ir rinkodara apskritai.
Jūsų siunčiama informacija turėtų būti skirta tik bendrais ir informaciniais tikslais. Tokie el. laiškai jokiu būdu neturėtų būti susiję su rinkodaros tikslais ar kuriais naujienlaiškiais.

Baigiamosios pastabos

Visada patikrinkite savo pašto išrašus, serverio prieigos išrašus, norėdami pamatyti galimas anomalijas ar įsilaužimus. Atnaujinkite savo sistemą ir programinę įrangą. Jei patekote į juodąjį sąrašą, tai yra faktas, jog siuntimas vykodmas. Susitelkite į problemos tyrimą ir išsprendimą. Reklaminių laiškų siuntimas yra draudžiama veikla mūsų paslaugų teikimo sąlygose, kurias galite peržiūrėti paspausdami šią nuorodą.

Svarbiausia prisiminti. Šlamštą draudžia mūsų paslaugų teikimo sąlygos, kurias galite peržiūrėti paspausdami šią nuorodą.

Dažniausios serverio nepasiekiamumo per SSH priežastys

iv_almantasm — Thu, 26 Jul 2018 11:39:10 +0000

Pasitaiko atvejų, kai dėl vienos ar kitos priežasties prie serverio nepavyksta prisijungti per SSH tarnybą. Šioje pamokoje apžvelgsime dažniausiai pasitaikančias priežastis bei galimus problemų sprendimus. Daugumai problemų spręsti prie serverio reikės prisijungti per avariniam serverio administravimui skirtą konsolę. Kaip tai padaryti rasite šioje nuorodoje

1. Neveikia SSH tarnyba

Prisijungus per konsolę patikrinkite ar SSH tarnyba aktyvi:

/etc/init.d/sshd status

arba

service sshd status

Jei gaunate atsakymą panašų į:

openssh-daemon is stopped

SSH tarnybą galite paleisti su komanda:

/etc/init.d/sshd start

arba

service sshd start

2. Pakeistas standartinis SSH tarnybos prievadas

Standartiškai prie SSH tarnybos yra prisijungiama 22-u prievadu. Visgi neretai pasitaiko atvejų, kai standartinis prievadas saugumo sumetimais yra pakeičiamas į kitą ir apie tai pamirštama. Patikrinti koks prievadas naudojamas Jūsų serveryje, galite prisijungus prie serverio per konsolę. Paleiskite komandą:

netstat -nltup

CentOS7 atveju komanda bus:

ss -nltup

Viena iš eilučių turi būti tokia:

Proto Recv-Q Send-Q Local Address               Foreign Address             State       PID/Program name
tcp        0      0 0.0.0.0:22                  0.0.0.0:*                   LISTEN      5184/sshd

Jei skiltyje "Local Address" vietoj šio atveju matomo skaičiaus 22 matysite kitą skaičių - tai reiškia, kad naudojate ne standartinį prievadą ir prie serverio Jums reikia jungtis naudojant Jums nurodomą prievadą.

3. Neveikia tinklo sąsaja

Platesnę šios galimos problemos apžvalgą rasite šioje pamokoje

4. root naudotojui uždrausta jungtis per SSH

Prisijungus prie serverio per konsolę, patikrinkite failo /etc/ssh/sshd_config konfigūraciją. Jei matote, eilutę:

PermitRootLogin no

pakeiskite informaciją į:

PermitRootLogin yes

bei perkraukite SSH tarnybą:

/etc/init.d/sshd restart

arba

service sshd restart

5. IP adresas iš kurio bandoma prisijungti, blokuotas serverio ugniasienėje

Lengviausias būdas išvalyti serverio ugniasienės taisykles - prisijungti prie savo klientų sistemos.
Pasirinkite savo serverio paslaugą ir nuspauskite mygtuką "Išvalyti iptables". Visgi prieš atliekant šiuos veiksmus galite išsaugoti dabartines iptables taisykles. Tai atliksite prisijungę prie serverio per konsolę:

iptables-save > kelias_kur_išsaugoti_dabartines_taisykles (pvz. /var/tmp/saved_iptables)

Taisykles atstatyti galėsite su komanda:

iptables-restore <  kelias_kur_išsaugotos_taisyklės (pvz. /var/tmp/saved_iptables)

* Kitas būdas - peržiūrėti taisykles rankiniu būdu. Tai atliksite su komanda:

iptables -L -nv

Jei pastebėsite taisyklę, kuri blokuoja susijungimą ją galėsite pašalinti su komanda:

iptables -D

Taip pat, jei serveryje nėra taisyklės, leidžiančios prisijungti per SSH (22 prievadu), galite ją pridėti su komanda:

iptables -A INPUT -p tcp -m tcp --dport 22 -j ACCEPT

Kaip rasti daug disko vietos užimančius failus/direktorijas?

iv_vytenisg — Wed, 04 Jul 2018 16:21:01 +0000

Dažnai pasitaiko atveju kai serveryje išnaudojama disko vieta, tačiau serverio administratorius disko išnaudojimo priežasties nežino ir negali nustatyti, kokie failai ar direktorijos užima daug vietos. Tokiais atvejais dažnai padeda failų skaičiaus (inode) direktorijose pateikimas, tačiau būna atveju kai viename faile saugomas neįprastai didelis kiekis informacijos (pavyzdžiui: tarnybos išrašas (angl. log)).

Šioje pamokoje pateiksime kelis pavyzdžius, kaip ieškoti disko vietos išnaudojimo priežasties.

0. Preliminarūs reikalavimai:

- Dedikuotas serveris naudojantis vieną iš mūsų parengtų operacinių sistemų šablonų.

1. Failų kiekio serveryje (inode) pateikimas:

for i in `ls -1A`; do echo "`find $i | sort -u | wc -l` $i"; done | sort -rn | head -5

2. Failų, didesnių nei 1024k, išrikiavimas pagal dydį (50 vienetų):

find / -mount -size +1024k -type f -exec du -Sh {} \;|sort -rh | head -n 50

Jeigu naudojama konkreti direktorija (šiuo atveju /home):

find /home -mount -size +1024k -type f -exec du -Sh {} \;|sort -rh | head -n 50

3. Didžiausių direktorijų išrikiavimui naudojama komanda:

du -a / | sort -n -r | head -n 50

Jeigu naudojama konkreti direktorija (šiuo atveju /home):

du -a /home | sort -n -r | head -n 50

Šias komandas galima naudoti atsidarius konkrečią direktoriją - tada pateikiama tik konkrečios direktorijos informacija.

Kaip pavyzdžiui:

cd /home
du -a | sort -n -r | head -n 50

Tinklo neveikimas naudojant CentOS

iv_vytenisg — Fri, 04 May 2018 14:31:52 +0000

Administruodami serverius pastebėjome, kad ganėtinai dažnai pasitaikanti problema klientams, kurie naudoja CentOS operacinę sistemą, yra NetworkManager serviso naudojimas vietoje mūsų naudojamo standartinio network serviso. Jeigu serveryje būna aktyvuojamas NetworkManager servisas, serveris nebūna pasiekiamas dėl tinklo programinės įrangos nesuderinamumo. Dažniausiai NetworkManager būna įdiegimas kartu su kitais tinklo ar programų paketais, kai diegimas atliekamas tiksliais nepasirenkant konkrečių įrankių, o diegiant visą paketą iš karto. Ši problema dažniausiai nepasireiškia tik įdiegus NetworkManager, nes šis servisas automatiškai neaktyvuojamas. Problema pastebima perkrovus serverį kai automatiškai paleidžiami visi servisai ir vienu metu paleidžiami keli tinklo servisai.

Problemos sprendimas:

1. Nepaisant to, kad pasireiškus šiai problemai serveris nebus pasiekiamas, turėsite galimybę prisijungti prie serverio per klientų sistemoje esančią konsolę. Platesnę informaciją, kaip prisijungti prie serverio per konsolę galite rasti čia.

2. Prisijungę prie konsolės sustabdykite NetworkManager servisą įvykdydami komandą:

systemctl stop NetworkManager

3. Tada nurodome, kad sekantį kartą NetworkManager nebūtų įjungtas perkrovus serverį:

systemctl disable NetworkManager

4. Ir paleidžiame tinklo servisą:

/etc/ini.d/network start

arba 

service network start

5. Papildomai rekomenduojame pašalinti NetworkManager servisą:

rpm -qa | grep -i NetworkManager

6. Ir pašaliname RPM paketus:

rpm -e package_name

Ir viskas, šių veiksmų pilnai pakanka išspręsti problemą ir užkirsti kelią jos pasikartojimui ateityje. Be abejo, visada rekomenduojame sekti diegiamos programinės įrankos paketų įrankius - diekite tik tuos paketus, kurie Jums yra reikalingi ir bus naudojami.

Proceso limitavimas serveryje

iv_vytenisg — Fri, 20 Apr 2018 10:06:21 +0000

Pasitaiko atveju kai vienas procesas išnaudoja pakankamai didelį CPU kiekį taip trukdant kitiems procesams atlikti savo darbą. Vienas procesas turi laukti kol kitas pabaigs veiksmus ir tik tada pradėti savo darbą. Ši problema gali būti išsprendžiama limituojant CPU resursus pasitelkiant CPULimit programinę įrangą.

Pagrindis CPULimit tikslas yra sumažinti leidžiama CPU kiekį tuo metu kai atliekamas konkretus procesas. Limitavus nėra daroma įtaka nice reikšmei ar pirmenybių nustatymams - ribojamas konkretus CPU išnaudojimas. Taip pat, CPULimit adaptuojasi prie visos sistemos dinamiškai bei greitai.

0. Preliminarūs reikalavimai:

- OpenVZ virtualizacijos Linux serveris naudojantis mūsų parengtus Ubuntu/Debian/CentOS operacinės sistemos šablonus.

1. CPULimit diegimas:

Ubuntu/Debian operacinėse sistemose:

sudo apt-get install cpulimit

CentOS/Fedora operacinėse sistemoje visų pirma reikia įjungti EPEL repozitoriją:

sudo yum install epel-release

ir tada atlikti diegimą:

sudo yum install cpulimit

arba 

sudo dnf install cpulimit

2. Naudojimas:

Atlikus sėkmingą diegimą galite atlikti pavyzdinį CPU limitavimą. Visų pirma paleiskite komandą, kuri naudos didelį kiekį CPU. Susikurkite failą:

nano highcpu.sh

Ir įkelkite šį turinį:

#!/bin/bash
while :; do :; done;

Failą išsaugokite . Ši paprasta programa sukurs ciklą, kuris išnaudos maksimalų galima CPU resursą. Įgalinkite šį paleidimui:

chmod +x highcpu.sh

Ir paleiskite jį naudojant komandą:

./highcpu.sh &

Jums bus pateikiamas proceso ID numeris (PID), kaip pavyzdžiui:

[1] 1887

Ir patikrinkite, kiek resursų šis procesas išnaudoja paleisdami top komandą:

PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND     
 1887 root      20   0    9508   1200   1012 R  99.7  0.0   0:21.46 highcpu.sh  
  237 root      20   0   47564   1604   1108 S   0.7  0.0  11:51.14 rpcbind     
  379 root      20   0   71532   3108   1912 S   0.3  0.0   0:29.04 apache2     
    1 root      20   0   37396   3644   2108 S   0.0  0.0   0:09.13 systemd     
    2 root      20   0       0      0      0 S   0.0  0.0   0:00.00 kthreadd/1+ 
    3 root      20   0       0      0      0 S   0.0  0.0   0:00.00 khelper/15+ 
   72 root      20   0  133368  70296  70000 S   0.0  0.4   1:38.00 systemd-jo+ 
   75 root      20   0   41628   1452   1004 S   0.0  0.0   0:00.38 systemd-ud+ 
  239 message+  20   0   42828   2044   1492 S   0.0  0.0   0:00.29 dbus-daemon 
  246 root      20   0   28484   1596   1292 S   0.0  0.0   0:00.51 systemd-lo+ 
  248 root      20   0   26008   1128    892 S   0.0  0.0   0:00.60 cron        
  250 syslog    20   0  184624   2580   1184 S   0.0  0.0   0:31.92 rsyslogd    
  289 root      20   0   65448   2080   1364 S   0.0  0.0   0:17.71 sshd        
  318 root      20   0   89652   1280    336 S   0.0  0.0   0:00.00 saslauthd   
  320 root      20   0   89652    964     20 S   0.0  0.0   0:00.00 saslauthd   
  347 root      20   0   14996    832    640 S   0.0  0.0   0:00.00 xinetd      
  349 root      20   0   12780    844    708 S   0.0  0.0   0:00.00 agetty

Kaip pastebima iš top komandos atsakymo, highcpu.sh procesas išnaudoja 99.7% CPU. Kadangi yra išnaudojamas toks kiekis, nepavyktų dabar paleisti kito proceso. Po kelių minučių operacinė sistema užstrigtų. Šioje vietoje gali padėti CPULimit.

Galime apriboti šio proceso veikimas naudojant CPULimit įrankį. Šiuo atveju apribosime procesą iki 30% CPU:

cpulimit -l 30 -p 1887 &

* -l 30: apriboja procesą iki 30%;
* -p 2331: yra highcpu.sh PID.

Dabar patikrinkite CPU išnaudojimą su top komanda:

top

ir matome atsakymą:

PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND     
 1887 root      20   0    9508   1200   1012 R  30.7  0.0   0:21.46 highcpu.sh  
  237 root      20   0   47564   1604   1108 S   0.7  0.0  11:51.14 rpcbind     
  379 root      20   0   71532   3108   1912 S   0.3  0.0   0:29.04 apache2     
    1 root      20   0   37396   3644   2108 S   0.0  0.0   0:09.13 systemd     
    2 root      20   0       0      0      0 S   0.0  0.0   0:00.00 kthreadd/1+ 
    3 root      20   0       0      0      0 S   0.0  0.0   0:00.00 khelper/15+ 
   72 root      20   0  133368  70296  70000 S   0.0  0.4   1:38.00 systemd-jo+ 
   75 root      20   0   41628   1452   1004 S   0.0  0.0   0:00.38 systemd-ud+ 
  239 message+  20   0   42828   2044   1492 S   0.0  0.0   0:00.29 dbus-daemon 
  246 root      20   0   28484   1596   1292 S   0.0  0.0   0:00.51 systemd-lo+ 
  248 root      20   0   26008   1128    892 S   0.0  0.0   0:00.60 cron        
  250 syslog    20   0  184624   2580   1184 S   0.0  0.0   0:31.92 rsyslogd    
  289 root      20   0   65448   2080   1364 S   0.0  0.0   0:17.71 sshd        
  318 root      20   0   89652   1280    336 S   0.0  0.0   0:00.00 saslauthd   
  320 root      20   0   89652    964     20 S   0.0  0.0   0:00.00 saslauthd   
  347 root      20   0   14996    832    640 S   0.0  0.0   0:00.00 xinetd      
  349 root      20   0   12780    844    708 S   0.0  0.0   0:00.00 agetty

Kaip pastebite top komandos atsakyme, highcpu.sh yra sumažintas iki 30.7% (gali būti pastebima -3/+3% paklaida). Likę resursai gali būti naudojami kitiems procesams.

Papildomas galimas limitavimas yra naudojant vykdomosios programos failo pavadinimą. Kaip pavyzdžiui, mūsų failo highcpu.sh limitavimas būtų atliekamas naudojant šią komandą:

cpulimit -l 30 ./highcpu.sh &

Taip pat, galite pamatyti procesus, kurie veikia fone (angl. background) naudojant šią komandą:

fg

CPULimit taip pat gali būti naudojamas norint sužinoti aplikacijos elgseną kai procesui yra apribojamas CPU resursas.

Pakilusio apkrovimo problemos sprendimas naudojant DirectAdmin

iv_vytenisg — Thu, 19 Apr 2018 16:31:59 +0000

Jeigu pastebėjome, kad serverio apkrovimas yra pakilęs ir įvykdę top komandą matome, kad procesas dataskq išnaudoja daugiausia resursų, šioje pamokoje rasite šios problemos sprendimą.

0. Preliminarūs reikalavimai:

- OpenVZ virtualizacijos serveris naudojantis mūsų suteiktą DirectAdmin licenciją.

1. Situacijos patikrinimas:

Visų pirma patikrinkite serverio išrašus, kuriuos rasite:

/var/log/directadmin/system.log

Patikrinkite ar yra vykdomi skaičiavimai. Jeigu naudotojai yra nuolatos pridedami į išrašą (išraše yra įtraukiamai nauji įrašai), tokiu atveju gali būti, kad tai yra tiesiog naktiniai vertinimai, kas yra normalu (darant prielaidą, kad žurnalas toliau auga ir nėra įstrigęs ties vienu vartotoju).

2. Problemos paieškos:

Pradedant ieškoti problemos priežasties, reikėtų pateikti užklausą dataskq procesui:

killall -USR1 dataskq
tail -n 10 /var/log/directadmin/errortaskq.log

Ši komanda įkels vykdomo dataskq proceso vietą į errortaską.log išrašą. Pagal tai galėsime spręsti, kokius veiksmus reikės atlikti toliau:

* Jeigu pateikiamas atsakymas nurodys, kad problema su Maildir keliu, tai reiškia, kad yra perpildyta dėžutė, kuri bus patiekiama nurodytame kelyje (angl. path). Patikrinkite dėžutę ir pašalinkite nereikalingus laiškus.

* Jeigu pateikiamas atsakymas kreipia į brute_force ar panašu failą, tai reiškia, kad dataskq procesas yra apkraunamas nuo itin didelio kiekio bandymų prisijungti. Problemos sprendimus visų pirma įsitikinkite ar naudojate naujausią DirectAdmin versiją ir tada įvykdykite komandą:

cd /usr/local/directadmin/data/admin
ls -la brute_force*

Šiuo veiksmu mes ieškome didelio brute_log_entries.list failo. Jeigu failai atrodo didelės talpos (faila jau yra didelis kai užima daugiau nei 1MB), tai gali sukelti apkrovimą. Galite ištrinti failą brute_log_entries.list, nes tai nėra būtinas failas Brute Force Monitor veikimui. Šis failas yra skirtas tik tam, kad galėtumėte stebėti vykdomas atakas. DirectAdmin sukurs šį failą iš naujo automatiškai.

* Jeigu brute_log_entries.list toliau ir vėl augs, Jūs galite koreguoti šio failo dydį rankiniu būdų DirectAdmin valdymo pulte pasirinkite Admin Level > Admin Settings ir sumažinkite reikšmę šiam nustatymui:

Clear failed login attempts from log X days after entry was made.

Rekomenduojame palikti 2 dienų reikšmę. taip pat pakoreguokite kitas reikšmes:

Notify Admins after an IP has X login failures on any account.
Notify Admins after a User has X login failures from any IP.

kurios sumažins įrašų skaičių, kurie įvedami į brute_log_entries.list failą.

SPAM laiškų siuntimo šaltinio identifikavimas PostFix serveryje

iv_almantasm — Thu, 15 Feb 2018 12:27:08 +0000

Problemos identikavimas

1. Pirmiausia prisijungte prie serverio su 'root' naudotoju. Įsitikinkite, kad serverio 'php.ini' faile yra įtraukta eilutė

mail.add_x_header = On

Šį failą greičiausiai rasite kataloge /etc/php5/cli/php.ini

2. Tuomet patikrinti serverio laiškų eilę galite su komanda:

mailq

3. Pateiktame rezultate matysite šiuo metu serverio siunčiamus laiškus. Rezultatas bus panašus į:

5CFC194C2D20*     422 Thu Feb 15 11:27:25  webmaster@domenas.com
                                         gavejas@domenas.lt

4. Norint matyti išsamesnę informaciją apie siunčiamą laišką išsirinkite vieną ID ir įveskite:

postcat -q

pavyzdžiui:

postcat -q 5CFC194C2D20

5. Šiuo atveju mums bus aktuali eilutė “X-PHP-Originating-Script”, kuri matoma laiško antraštėse. (Ši eilutė matysis, jei serverio nustatymuose bus įtraukta anksčiau minėta eilutė "mail.add_x_header = On"). Įveskite komandą:

postcat -q 5CFC194C2D20 | grep X-PHP-Originating-Script

ir gaunamas rezultatas bus panašus į:

X-PHP-Originating-Script: 45:spamas.php

Skaičius 45 nurodo, kuris Linux naudotojas atlieka siuntimą (UID), į pavadinimas "spamas.php", kuris failas atlieka laiškų siuntimą.

6. Taigi šiuo atveju telieka surasti reikiamą failą bei jį pašalinti. Žinoma, jei buvo įterptas vienas toks failas, tikėtina, kad Jūsų serveryje yra saugumo spragų, kurias reikėtų pašalinti.

7. Jei laiško antraštėse rezultatas, rezultatas "X-PHP-Originating-Script" nėra randamas, tai reikštų, kad greičiausiai nepageidaujamų laiškų siuntimui naudojamas ne įterptas žalingas kodas, tačiau viena iš pašto dėžučių. Įveskite komandą:

postcat -q 5CFC194C2D20 | grep sasl_username

Ji parodys, kurios pašto dėžutės prisijungimo duomenys buvo naudojami išsiunčiant laišką su ID 5CFC194C2D20.

Gautas rezultatas bus panašus į

named_attribute: sasl_username=info@mano-svetaine.lt

8. Taigi šiuo atveju reikėtų pakeisti pašto dėžutės "info@mano-svetaine.lt" prisijungimo duomenis, bei antivirusine programa patikrinti šio naudojo įrenginius iš kurių buvo jungtasi prie pašto dėžutės.

Laiškų išvalymas

1. Išvalyti siunčiamų laiškų eilę galėsite su komanda:

postsuper -d ALL

Jei serverio laiškų eilėje yra reikalingų laiškų, kuriuos gavėjai turi gauti, nepageidaujams laiškus galite ištrinti nurodant konkretaus nepageidaujamo laiško ID, pavyzdžiui:

postsuper -d 5CFC194C2D20

Kaip nustatyti ir pašalinti dažniausiai kylančias Docker problemas?

iv_vytenisg — Wed, 29 Nov 2017 12:29:45 +0000

Docker palengvina aplikacijų administravimą naudodamas konteinerių technologiją. Tačiau pasitaiko atveju kai tenka susidurti su problemomis integruojant papildinius, kurių reikalauja Jūsų naudojamos aplikacijos laikomos konteineriuose, ypač jeigu nesate patyręs Docker naudotojas. Dažniausiai pasitaikančios problemos yra susijusios su bibliotekomis, moduliais bei susijungimais su kitais konteineriais.

0. Preliminarūs reikalavimai

KVM Linux serveris su įdiegtu Docker. Docker diegimas gali būti atliekamas pagal šią pamoką.

1. Dockerfile problemų sprendimas

Dažniausiai susiduriama su problemomis kai kuriama Docker image. Visų pirma pateikiame skirtumą tarp image ir konteinerių:

Image yra resursas turintis tik nuskaitymo galimybę. Šis resursas gali būti sukuriamas naudojant Dockerfile. Tai yra resursas, kurį galite dalintis su kitais konteineriais Docker aplinkoje.
Konteineris tai yra įrašomas bei skaitomas resursas, kurį galite sukurti naudodami image, kurią jau sukūrėte anksčiau.

Peržiūrėjus Dockerfile galite matyti žingsnį po žingsnio visus veiksmus, kuriais buvo sukurtas image. Tai reiškia, kad jeigu matote aiškius įvykdytus žingsnius, visi anksčiau buvę žingsniai yra sėkmingai įvykdyti.

Pasibandymui galime sukurti nedidelį image tam, kad susipažintume su Dockerfile. Sukurkite docker_image direktorijoje, kurį būtų pagrindinėje direktorijoje ir naudodami Nano teksto redagavimo įrankį sukurti Dockerfile:

mkdir ~/docker_image
nano ~/docker_image/Dockerfile

Ir įkelkite žemiau pateiktą tekstą:

# base image
FROM debian:latest

# install basic apps
RUN aapt-get install -qy nano

Toliau galite sukurti image iš šio failo tam, kad pamatytumėte, kaip Docker apdoroja nekorektišką komandą. Sukurti image naudodami šį kodą:

docker build -t my_image ~/docker_image

Ir pamatysite šį pranešimą terminale:

Step 2 : RUN aapt-get install -qy nano
  ---> Running in 085fa10ffcc2
/bin/sh: 1: aapt-get: not found
The command '/bin/sh -c aapt-get install -qy nano' returned a non-zero code: 127

Pranešimas nurodo, kad problema yra antrame žingsnyje. Šį kartą mes naudojome aapt-get vietoje apt-get. Bet tai taip pat reiškia, kad ankstesnis žingsnis buvo įvykdytas korektiškai.

Toliau koreguosime Dockerfile ir pašalinsime klaidingą komandą:

# install basic apps
RUN apt-get install -qy nano

Paleiskite docker build komandą pakartotinai:

docker build -t my_image ~/docker_image

Ir pamatysite pateikiamą tekstą:

Sending build context to Docker daemon 2.048 kB
Step 1 : FROM debian:latest
---> ddf73f48a05d
Step 2 : RUN apt-get install -qy nano
---> Running in 9679323b942f
Reading package lists...
Building dependency tree...
E: Unable to locate package nano
The command '/bin/sh -c apt-get install -qy nano' returned a non-zero code: 100

Su korekcijomis procesas buvo atlikti truputi greičiau, nes Docker buvo išsisaugojęs pirmą žingsnį ir nebesiuntė iš naujo bazinės image. Tačiau yra gaunamas naujas klaidos kodas. Norint jį ištaisyti reikia modifikuoti Dockerfile ir atlikti išvalymą bei gražinti į pradžios stadiją. Atsidarykite konfigūracinį failą:

nano ~/docker_image/Dockerfile

Pridėti paryškintą eilutę aukščiau nei komanda įrašyti Nano:

# base image
FROM debian:latest

# clean and update sources
RUN apt-get clean && apt-get update

# install basic apps
RUN apt-get install -qy nano

Išsaugokite failą ir paleiskite docker build dar kartą:

docker build -t my_image ~/docker_image

Šį kartą procesas bus įvykdytas sėkmingai:

Sending build context to Docker daemon 2.048 kB
Step 1 : FROM debian:latest
 ---> a24c3183e910
Step 2 : RUN apt-get install -qy nano
 ---> Running in 2237d254f172
Reading package lists...
Building dependency tree...
Reading state information...
Suggested packages:
  spell
The following NEW packages will be installed:
  nano
...

 ---> 64ff1d3d71d6
Removing intermediate container 2237d254f172
Successfully built 64ff1d3d71d6

Patikrinkime, kas atsitiks kai pridėsime Python 3 ir PostgreSQL driver'ius į image. Atidarykite Dockerfile dar kartą:

nano ~/docker_image/Dockerfile

Ir pridėkite paryškintas eilutes:

# base image
FROM debian:latest

# clean and update sources
RUN apt-get clean && apt-get update

# install basic apps
RUN apt-get install -qy nano

# install Python and modules
RUN apt-get install -qy python3
RUN apt-get install -qy python3-psycopg2

Išsaugokite failą, išeikite iš jo ir sukurkite image dar kartą:

docker build -t my_image ~/docker_image

Kaip pastebite iš pateikiamo atsakymo, paketai buvo įdiegti sėkmingai. Procesai yra įvykdomi greičiau, nes buvo procesai buvo išsaugoti laikinojo atmintyje. Pateikiamas atsakymas:

Sending build context to Docker daemon 2.048 kB
Step 1 : FROM debian:latest
 ---> ddf73f48a05d
Step 2 : RUN apt-get clean && apt-get update
 ---> Using cache
 ---> 2c5013476fbf
Step 3 : RUN apt-get install -qy nano
 ---> Using cache
 ---> 4b77ac535cca
Step 4 : RUN apt-get install -qy python3
 ---> Running in 93f2d795fefc
Reading package lists...
Building dependency tree...
Reading state information...
The following extra packages will be installed:
  krb5-locales libgmp10 libgnutls-deb0-28 libgssapi-krb5-2 libhogweed2
  libk5crypto3 libkeyutils1 libkrb5-3 libkrb5support0 libldap-2.4-2 libnettle4
  libp11-kit0 libpq5 libsasl2-2 libsasl2-modules libsasl2-modules-db
  libtasn1-6
Suggested packages:
  gnutls-bin krb5-doc krb5-user libsasl2-modules-otp libsasl2-modules-ldap
  libsasl2-modules-sql libsasl2-modules-gssapi-mit
  libsasl2-modules-gssapi-heimdal python-psycopg2-doc
The following NEW packages will be installed:
  krb5-locales libgmp10 libgnutls-deb0-28 libgssapi-krb5-2 libhogweed2
  libk5crypto3 libkeyutils1 libkrb5-3 libkrb5support0 libldap-2.4-2 libnettle4
  libp11-kit0 libpq5 libsasl2-2 libsasl2-modules libsasl2-modules-db
  libtasn1-6 python3-psycopg2
0 upgraded, 18 newly installed, 0 to remove and 0 not upgraded.
Need to get 5416 kB of archives.
After this operation, 10.4 MB of additional disk space will be used.

...

Processing triggers for libc-bin (2.19-18+deb8u6) ...
 ---> 978e0fa7afa7
Removing intermediate container d7d4376c9f0d
Successfully built 978e0fa7afa7

Visada rekomenduojame įdėmiai peržiūrėti pateikiamus atsakymus komandinėje eilutėje. Paleiskite atnaujinimus build time aplinkoje būdami konteineryje tam, kad nebūtumėte sustabdyti laikinojoje atmintyje esančiu paketų sąrašu.

2. Konteinerių pavadinimų problemos:

Kuo daugiau konteinerių turėsite, tuo daugiau šansų, kad susidursite su konteinerių pavadinimų problemomis - kai kurie konteineriai turės tokius pačius pavadinimus. Panagrinėkime kaip pervadinti ar pašalinti konteinerius tam, kad išvengti užvardinimo problemų.

Paleiskite konteinerį iš anksčiau naudoto image. Įvykdykite šią komandą:

docker run -ti my_image bash

Kai konteineris startuos pamatysite, kad naudojatės pagrindiniu konteinerio naudotoju:

root@80a0ca58s6ec:/#

Kai jau turite veikiantį konteinerį peržvelkime su kokiomis problemomis yra galimybė susidurti.

Kai paleidžiate konteinerį be konkretaus pavadinimo, kaip padarėme dabar, Docker atsitiktinai parenka konteineriui pavadinimą. Galite matyti visus veikiančius konteinerius paleisdami komandą docker ps atsijungę iš konteinerio. Atsijunkite iš konteinerio ir įvykdykite komandą:

docker ps

Ši komanda pateiks veikiančių konteinerių sąrašą, kaip pavyzdžiui:

CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS              PORTS               NAMES
80a0ca58d6ec        my_image            "bash"              22 seconds ago      Up 28 seconds                           docker_container

Jums bus pateikiamas kitoks pavadinimas nei docker_container. Docker automatiškai parenka pavadinimą ir tai gali sukelti problemų norint nustatyti, koks tai konteineris.

Norint nustatyti konkretų konteinerį galime naudoti - -name argumentą paleidžiant konteinerį. Arba galime pervadinti konteinerį į konkretesnį pavadinimą. Paleiskite komandą:

docker rename jūsų_konteinerio_pavadinimas python_box

Tada peržiūrėkite konteinerių sąrašą:

docker ps

Pateikiamame atsakyme matysite, kad sėkmingai pervadinimo konteinerį:

CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS              PORTS               NAMES
80a0ca58d6ec        my_image            "bash"              24 minutes ago      Up 24 minutes                           python_box

Norint uždaryti konteinerį įveskite exit būdami konteinerio direktorijoje:

root@80a0ca58d6ec:/# exit

Taip pat, galite išjungti konteinerį jame nebūdami:

docker kill python_box

Kai išjungsite konteinerį tokiu būdu, Docker pateiks atsakymą koks konteineris buvo išjungtas:

python_box

Tam, kad įsitikintumėte, kad konteineris neegzistuoja, paleiskite komandą:

docker ps

Gausite atsakymą:

CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS              PORTS               NAMES

Šiuo atveju panašu, kad galima būtų sukurti kitą konteinerį su tokiu pačiu pavadinimu, tačiau patikrinkime ar pavyks. Naudosime - -name argumentą nustatant konteinerio pavadinimą:

docker run --name python_box -ti my_image bash

Pateikiamas atsakymas:

docker: Error response from daemon: Conflict. The name "/python_box" is already in use by container 80a0ca58d6ecc80b305463aff2a68c4cbe36f7bda15e680651830fc5f9dda772. You have to remove (or rename) that container to be able to reuse that name..
See 'docker run --help'.

Jūs negalite perrašyti konteinerio pavadinimo (image pavadinimą galima pervadinti), kuris jau egzistuoja. Docker rašo, kad toks konteineris egzistuoja nepaisant to, kad mes jį pašalinome. Jis nėra veikiantis, tačiau vis dar išlieka galimybė jį startuotį. Mes jį sustabdėme, bet nepašalinome. Komanda docker ps rodo tik veikiančius konteinerius, todėl nėra matomas sustabdytas konteineris.

Tam, kad paleistume visus konteinerius yra naudojama komanda:

docker ps -a

Dabar konteineris python_box bus matomas sąraše:

CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS                        PORTS               NAMES
80a0ca58d6ec        my_image            "bash"              12 minutes ago      Exited (137) 6 minutes ago                       python_box

Konteinerio statusas yra Exited (137), todėl mes ir susidūrėme su pervadinimo problema kai bandėme sukurti konteinerį tuo pačiu pavadinimu.

Norint pilnai pašalinti konteinerį yra naudojama komanda:

docker rm python_box

Ir Docker pateikia konteinerio pavadinimą, kurį pašalino:

python_box

Toliau sukurkime naują serverį su pavadinimu python_box, kurį pašalinome anksčiau:

docker run --name python_box -ti my_image bash

Procesas sėkmingai įvykdomas ir automatiškai prijungiame prie konteinerio root direktorijos:

root@c05ac9d0c010:/#

Atlikus testavimus reikėtų pašalinti šį konteinerį tam, kad nekiltų problemų ateityje. Išėję iš konteinerio atlikite komandą:

docker kill python_box && docker rm python_box

Mes sujungėme dvi komandas į vieną, todėl bus pateikiamas konteinerio pavadinimas du kartus. Pirmas nurodys, kad išjungėme konteinerį, o antras, kad pašalinome:

python_box
python_box

Naudokite docker ps -a norėdami patikrinti ar konteineris yra tikrai pašalintas ir galima naudoti jo pavadinimą naujo konteinerio sukūrimui.

3. Susijungimų tarp konteinerių problemų sprendimas

Kadangi konteineriai atskiria skirtingas aplikacijas ir leidžia lengviau jam modifikuoti, pasitaiko atveju kai vienas iš konteinerių būna sugadinamas. Tada tenka jį pakeisti nauju, kas dažnai iššaukia susijungimo problemas.

Testavimui atlikti susikursime du skirtingus konteinerius - Python ir PostgreSQL. Visų pirma sukursime konteinerį su PostgreSQL duomenų baze. Konteinerio užvadinimui naudosime - -name argumentą. Pavadinimas bus postgre_box:

docker run --name postgres_box --detach postgres

Kaip pastebėjote, naudojamas ir - -detach argumentas, kuris leidžia paleisti konteinerį ir automatiškai neprijungia prie jo. Taip pat naudojamas postgres argumentas leidžiantis paleisti PostgreSQL duomenų bazę konteinerio viduje. Atlikus aukščiau pateiktą komandą gausite atsakymą, kuriame matysite konteinerio pilną ID:

Unable to find image 'postgres:latest' locally
latest: Pulling from library/postgres
6a5a5368e0c2: Already exists
193f770cec44: Pull complete
...
484ac0d6f901: Pull complete
Digest: sha256:924650288891ce2e603c4bbe8491e7fa28d43a3fc792e302222a938ff4e6a349
Status: Downloaded newer image for postgres:latest
f6609b9e96cc874be0852e400381db76a19ebfa4bd94fe326477b70b8f0aff65

Atsidarykite konteinerių sąrašą tam, kad matytumėte ar konteineris veikia:

docker ps

Pateikiamas atsakymas, kuris nurodo, kad postgres_box veikia naudojant 5432 prievadą:

CONTAINER ID        IMAGE               COMMAND                  CREATED                  STATUS              PORTS               NAMES
7a230b56cd64        postgres_box            "/docker-entrypoint.s"   Less than a second ago   Up 2 seconds        5432/tcp            postgres

Dabar laikas paleisti Python konteinerį. Tam, kad jis matytų postgres_box konteinerį reikia nurodyti kito konteinerio vietą naudojant - -link argumentą. Python konteinerio paleidimui naudojama komanda:

docker run --name python_box --link postgres_box:postgres -ti my_image bash

Dabar atliksime PostgreSQL konteinerio sujungimą su python_box konteineriu:

root@3053f74c8c13:/# nano pg_test.by

Ir pridėkite žemiau pateiktą tekstą:

"""Test PostgreSQL connection."""
import psycopg2

conn = psycopg2.connect(user='postgres')
print(conn)

Dabar galime sužinoti, kas atsitiks kai bandysite kreiptis į kitą konteinerį:

root@3053f74c8c13:/# python3 pg_test.py

Ir Jums bus patiekiamas atsakymas:

Traceback (most recent call last):
  File "pg_test.py", line 5, in 
    conn = psycopg2.connect(database="test", user="postgres", password="secret")
  File "/usr/lib/python3/dist-packages/psycopg2/__init__.py", line 164, in connect
    conn = _connect(dsn, connection_factory=connection_factory, async=async)
psycopg2.OperationalError: could not connect to server: No such file or directory
    Is the server running locally and accepting
    connections on Unix domain socket "/var/run/postgresql/.s.PGSQL.5432"?

Kaip matote, nepavyksta susijungti su duomenų baze, nes Python bando susijungti su duomenų baze lokaliai, o tai nepavyks padaryti, nes duomenų bazė yra kitame konteineryje. Tai tas pats, kad bandytumėte susijungti lokaliai su kitame serveryje esančia duomenų baze.

Susijungimą galite įvykdyti naudojant konteinerio pavadinimą ir peržiūrint etc/hosts failą ptyhon_box konteineryje:

root@3053f74c8c13:/# cat /etc/hosts

Pamatysite, kad postgres yra tikrai pasiekiamas:

127.0.0.1       localhost
::1     localhost ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
172.17.0.2      postgres f6609b9e96cc postgres_box
172.17.0.3      3053f74c8c13

Todėl dabar galime modifikuoti Python skriptą ir pridėti serverio pavadinimą. Atsidarykite failą:

root@3053f74c8c13:/# nano pg_test.py

Ir nurodykite serverio pavadinimą taip, kaip pavyzdyje:

"""Test PostgreSQL connection."""
import psycopg2

conn = psycopg2.connect(host='postgres', user='postgres')
print(conn)

Išsaugokite tekstą ir paleiskite skriptą iš naujo:

root@3053f74c8c13:/# python3 pg_test.py

Šį kartą skriptas suveiks sėkmingai be problemų:

Visada stenkitės naudoti konteinerių vardus tam, kad sėkmingai įvykdytumėte susijungimus.

4. Apibendrinimas

Katik apžvelgėme pagrindines problemas su kuriomis tenka susidurti administruojant Docker. Docker taip pat turi - -debug argumentą, kuris naudojamas Docker kūrėjų. Tačiau jeigu norite sužinoti daugiau apie Docker problemas, naudokite šią komandą:

docker -D [command] [arguments]

Taip pat rekomenduojame susipažinti su pagrindinėmis taisyklėmis bei eko sistema ir manome, kad dauguma konceptų, kurie iš pradžių atrodė nežinomi, turėtų tapti aiškesni.

SPAM pobūdžio laiškų siuntimo šaltinio identifikavimas EXIM serveryje

IV_RomanL — Thu, 05 Feb 2015 10:03:31 +0000

Pamoka kaip greitai ir labai lengvai nustatyti iš kur tiksliai serveryje yra siunčiami SPAM pobūdžio laiškai. Šis metodas deja veiks tik jei naudojamas Exim servisas el.pašto laiškų siuntimui.

1. Prisijunkite prie serverio SSH konsolės ir įvykdykite komandą:

grep cwd /var/log/exim/mainlog | grep -v /var/spool | awk -F"cwd=" '{print $2}' | awk '{print $1}' | sort | uniq -c | sort -n

Komandos paaiškinimas:

grep cwd /var/log/exim/mainlog - ši dalis nurodo Exim serviso log failo vietą. Tad "/var/log/exim/mainlog" turėtų būti kelias iki Exim mainlog failo. Jei reikia, pakoreguokite šį parametrą.

grep -v /var/spool - ši dalis pažymi jog pateiktame rezultate nebūtų eilutės "/var/spool". Šios eilutės keisti nereikia.

awk -F"cwd=" '{print $2}' | awk '{print $1}' - ši komanda pateikia rezultatą lengvai perskaitoma forma. Šios eilutės keisti nereikia.

sort | uniq -c | sort -n - eilutė atsakinga už rezultato rikiavimą. Ši komanda rikiuos rezultatus nuo mažiausio iki didžiausio. Šios eilutės keisti nereikia.

2. Įvykdžius minėta komandą išvedamas rezultatas turėtų būti panašus į tai:

10 /home/vartotojas/public_html/aplankas
30 /home/vartotojas/public_html
10000 /home/vartotojas/public_html/aplankas2

Skaičius pradžioje pažymi kiek laiškų buvo išsiųsta iš tam tikro aplanko. Kaip matote aplankas "/home/vartotojas/public_html/aplankas2" atsakingas už 10000 laiškų išsiuntimą, tad tikėtina jog tai ir bus katalogas kuriame talpinamas kenkėjiškas failas.

3. Peržiūrėkime kokie script'ai yra įtartiname aplanke:

ls -lahtr /home/vartotojas/public_html/aplankas2

Rezultatas turėtų būti panašus į:

drwxr-xr-x 17 vartotojas vartotojas 4.0K Jan 20 10:25 ../
-rw-r--r-- 1 vartotojas vartotojas 5.6K Jan 20 11:27 scriptas.php
drwxr-xr-x 2 vartotojas vartotojas 4.0K Jan 20 11:27 ./

Tikėtina, jog problemą sukelia failas pavadinimu "scriptas.php".

4. Peržiūrime įtartino failo statistinę informaciją:

grep "scriptas.php" /home/vartotojas/access-logs/domenas.tld | awk '{print $1}' | sort -n | uniq -c | sort -n

Svarbu:

/home/vartotojas/access-logs/domenas.tld - ši dalis privalo būti pakeista atitinkamai pagal tai, kur yra jūsų domeno apache "access log" žurnalas.

Įvykdžius komandą rezultatas bus panašus į:

2 123.123.123.126
2 123.123.123.125
2 123.123.123.124
10000 123.123.123.123

Tai yra IP adresai ir jų užklausų kiekis į scriptas.php failą.

Kaip matote IP adresas 123.123.123.123 pateikė 10000 užklausų į scriptas.php failą.

Rekomenduojami atlikti veiksmai:

1. Jei tai yra failas kuris reikalingas korektiškam jūsų svetainės veikimui, peržiūrėkite jo kodą, gal jame bus patalpintas kenkėjiškas kodas kuris vykdo SPAM pobūdžio laiškų siuntimą. Pašalinkite kenkėjišką kodą nedelsiant.

2. Jei tai yra failas kuris nėra jūsų svetainės dalis, tuomet nedelsiant jį pašalinkite ir atlikite visos svetainės kodo reviziją, taip pat pakeiskite FTP prisijungimo slaptažodį.

3. Blokuokite piktybinį IP adresą iš kurio buvo kreiptasi į kenkėjišką failą (tą galite atlikti IPtables pagalba, .htaccess failo pagalba).

4. Išvalykite susikaupusių laiškų eilę ir stebėkite ar joje nesikaupia nauji laiškai.

Tinklo sąsajos atstatymas naudojantis klientų sistemos konsole

IV_VygandasS — Tue, 12 Aug 2014 13:58:45 +0000

Šioje trumpoje pamokoje nurodysime būdus kuriais po nekorektiškai startavusių tarnybų galite atstatyti tinklo sąsają serveriui.

1. Prisijungiame prie serverio konsolės per mūsų klientų sistemą.

2. Prisijungiame su "root" vartotoju.

3. Patikriname ar problema yra nestartavusioje tinklo sąsajoje ar tiesiog nepasileido ssh tarnyba.

Pamatyti tinklo sąsajų informaciją galime naudojant šią komandą:

ifconfig -a

Pamatyti atvirus prievadus, kuriuos startuojant ssh tarnyba atidaro galime, naudojant šią komandą:

netstat -tulpn

arba

netstat -tulpn | grep ssh

4. Jeigu tinklo sąsaja nėra pakilusi atliekame tai rankiniu būdu:

/etc/init.d/network restart

arba:

/etc/sysconfig/network-scripts/ifup venet0:0

5. Jeigu dėl tam tikrų priežasčių tinklo sąsaja nepakyla. Pridedame ją rankiniu būdu:

ip addr add dev venet0 /32
ifconfig venet0 up
route add default dev venet0

6. Atveju jeigu ssh tarnyba nestartavus, paleidžiame ją rankiniu būdu:

/etc/init.d/sshd restart

Dažniau pasitaikančios problemos dėl kurių tarnybos nestartuoja:

Nekorektiškai koreguotas /etc/fstab failas.
Trūkstami paketai /bin/ kataloge. Kaip pvz.: ne visos tarnybos nestartuoja korektikšai jeigu trūksta rm įrankio.
Nekorektiška sąsajų konfigūracija, ar papildomi konfigūracijos failai. Pvz.: blogos sintaksės /etc/network/interfaces.tail failas. Kurio turinys galiausiai yra įterpiamas į bendrą /etc/network/interfaces konfigūraciją.

Debian OS dist-upgrade atveju gali būti pašalintas "upstart" paketas ir pakeistas "sysvinit" paketu. Tokiu atveju sutrinka konteinerio korektiškas startavimas.

Sprendimas:

apt-get install upstart

Tipinės svetainės neveikimo priežastys

IV_VygandasS — Thu, 12 Jun 2014 16:25:59 +0000

Šiame informaciniame straipsnyje glaustai aptarsime tipines problemas dėl kurių Jūsų svetainė gali būti neatvaizduojama.

Tipinių problemų skirstymas

Dažniausiai nesėkmingai bandant priversti naują svetainę veikti reikia atsakyti į šiuos klausimu:

Ar web serverio tarnybą įdiegta?
Ar web serverio tarnyba yra paleista?
Ar web serverio konfigūracijos sintaksė yra teisinga?
Ar sukonfigūruoti prievadai yra atidaryti/pasiekiami?
Ar DNS nukreipimai yra atlikti korektiškai?
Ar yra tinkamai nurodytas svetainės šakninis katalogas?
Ar web serveris pateikia tinkamus indekso failus?
Ar svetainės failų ir katalogų teisės bei savininkai yra nurodyti teisingai?
Ar per konfigūracinius failus nėra ribojama prieiga?
Jeigu svetainė naudoja duomenų bazes, ar duomenų bazių tarnyba yra paleista?
Ar svetainė sėkmingai prisijungia prie reikalingos duomenų bazės?
Ar web serveris yra tinkamai sukonfigūruotas atvaizduoti dinaminį turinį?

Pirma vieta kur reikėtų ieškoti problemos priežasties yra atitinkamos tarnybos žurnalų išrašai. Įprastai žurnalų išrašai serveryje yra laikomi /var/log/ kataloge, bei jo subkataloguose.

Pavyzdžiui, jeigu mūsų web serveris yra Apache, tuomet priklausomai nuo operacinės sistemos Apache žurnalų išrašus rasime /var/log/Apache2/ arba /var/log/httpd/ kataloguose. Taip pat jeigu turime duomenų bazių serverį, tuomet duomenų bazių tarnybos žurnalų išrašus taip pat rasime /var/log/ kataloge.

Taip pat svarbu atkreipti dėmesį, kokį klaidos pranešimas pateikia (jeigu pateikia) tarnyba kai ši yra paleidžiama, bei koks klaidos pranešimas yra pateikiamas bandant apsilankyti pačioje pageidaujamoje svetainėje.

Tiek pagal gaunamus klaidų pranešimus apsilankant pačioje svetainėje, tiek žurnalų išrašuose yra pakankamai patogu susirasti problemos priežastį naudojantis pageidaujama paieškos sistema.

Ar web serverio tarnyba įdiegta?

Pirmas ir pagrindinis dalykas kuris yra reikalingas atvaizduojant internetinę svetainę tai žinoma yra web serverio tarnyba.

Žinoma visuose serveriuose aptarnaujančiuose internetines svetaines vienu ar kitu momentu buvo/yra įrašyta web serverio tarnyba. Tačiau pasitaiko atvejų kai atliekant operacijas su kitų tarnybų paketais, web serverio tarnyba yra paprasčiausiai pašalinama kartu su kitais paketais.

Todėl pastebėjus jog visgi web serverio tarnyba buvo tyčia ar netyčia pašalinta, iš naujo įdiegti web serverio tarnybą galime naudojant šias komandas:

Naudojant Ubuntu ar Debian operacines sistemas, šiomis komandomis bus įdiegiamas Apache web serveris:

sudo apt-get update
sudo apt-get install apache2

Šiose sistemose Apache procesas yra vadinamas Apache2.

Naudojant Ubuntu ar Debian operacines sistemas, šiomis komandomis bus įdiegiamas Nginx web serveris:

sudo apt-get update
sudo apt-get install nginx

Šiose sistemose Nginx procesas yra vadinamas Nginx.

Naudojant CentOS ar Fedora operacines sistemas, šiomis komandomis bus įdiegiamas Apache web serveris:

sudo yum install httpd

Šiose sistemose Apache procesas yra vadinamas httpd.

Naudojant CentOS ar Fedora operacines sistemas, šiomis komandomis bus įdiegiamas Nginx web serveris:

sudo rpm -Uvh http://download.Fedoraproject.org/pub/epel/6/i386/epel-release-6-8.noarch.rpm
sudo yum install nginx

Šiose sistemose Nginx procesas yra vadinamas Nginx.

Ar web serverio tarnyba yra paleista?

Įsitikinus jog web serverio tarnyba yra įdiegta, reikia įsitikinti jog ji yra paleista.

Vienas iš būdų kaip tai galime atlikti yra patikrinimas ar Apache tarnyba yra atidariusi prievadą. Tai galime pamatyti įvykdžius šią komandą:

sudo netstat -plunt | grep apache2

Numatomas rezultatas:

tcp6       0      0 :::80           :::*            LISTEN      2000/apache2

Pastaba: komandoje naudojamą Apache2 reikėtų pakeisti į mūsų serveryje naudojamą web serverio proceso pavadinimą.

Jeigu prieš tai pateikta komanda negrąžina jokio rezultato, tuomet tikėtina jog web serverio tarnyba nėra paleista.

Taip pat patikrinti ar Apache procesas yra paleistas galime pažiūrėti pačio proceso statusą sistemoje, šiomis komandomis:

Ubuntu ar Debian:

sudo service apache2 status

CentOS ar Fedora:

sudo service httpd status

Tokiu atveju priklausomai nuo naudojamos operacinės sistemos web serverio tarnybą paleisti galime žemiau pateiktų komandų principu:

Ubuntu ar Debian:

sudo service apache2 start

CentOS ar Fedora:

sudo /etc/init.d/httpd start

arba

sudo service httpd start

Jeigu web serverio tarnyba yra startavo, tuomet pakartotinai patikriname netstat komandos rezultatą.

Ar web serverio konfigūracijos sintaksė yra teisinga?

Jeigu paleisti web serverio tarnybos visgi nepavyksta, dažniausiai tai indikuota problemą tarnybos konfigūraciniame faile. Tiek Apache tiek Nginx turi pakankamai griežtus reikalavimus direktyvų sintaksei.

Konfigūraciniai failai įprastai yra laikomi /etc/ direktorijos subkataloge, kuris yra vadinamas pagal pačio proceso pavadinimą.

Ubuntu ar Debian į pagrindinę Apache direktoriją mes galime patekti įvykdę šią komandą:

cd /etc/apache2

CentOS ar Fedora į pagrindinę Apache direktoriją mes galime patekti įvykdę šią komandą:

cd /etc/httpd

Šiuose kataloguose konfigūracija gali būti išmėtyta per kelis skirtingus konfigūracinius failus. Todėl pradžiai reikia patikrinti būtent tą konfigūracinį failą, kuriame startuojant tarnyba aptiko klaidą.

Siekiant tikrinimą supaprastinti galime naudoti konfigūracijos sintaksės tikrinimui skirtas komandas:

Naudojant Apache naudojama ši komanda:

apache2ctl configtest

Numatomas rezultatas:

AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 127.0.0.1. Set the 'ServerName' directive globally to suppress this message
Syntax OK

Naudojant Nginx naudojama ši komanda:

sudo nginx -t

Numatomas teigiamas rezultatas:

Nginx: the configuration file /etc/Nginx/Nginx.conf syntax is ok
Nginx: configuration file /etc/nginx/nginx.conf test is successful
As you can see, this process checks your syntax as well. If we remove an ending semi-colon from a line in the file (a common error for Nginx configurations), you would get a message like this:

Numatomas neigiamas rezultatas:

Nginx: [emerg] invalid number of arguments in "tcp_nopush" directive in /etc/nginx/nginx.conf:18
nginx: configuration file /etc/nginx/nginx.conf test failed
There is an invalid number of arguments because nginx looks for a semi-colon to end statements. If it doesn't find one, it drops down to the next line and interpret that as further arguments for the last line.

Gavus netinkamos konfigūracijos pranešimą reikia peržiūrėti rezultate pateikto failo sintakse, ties nurodyta eilute. Bei pakartotinai atlikti konfigūracijos tikrinimą, tai atlikinėti tol kos konfigūracijos testavimas nurodys teigiamą rezultatą.

Ar sukonfigūruoti prievadai yra atidaryti/pasiekiami?

Įprastai web serveriai klausosi 80 prievado, o TLS/SSL susijungimams naudoja 443 prievadą. Siekiant pasiekti serveryje esančias svetaines, šie prievadai turi būti atidaryti/pasiekiami.

Tai patikrinti galime tiek naudojant prieš tai nurodytą netstat komandą:

sudo netstat -plunt | grep apache2

Tiek naudojant netcat įrankį, vykdant šią komandą:

sudo nc -z 111.111.111.111 80

Pastaba: vykdomoje komandoje pakeičiame 111.111.111.111 į mūsų serverio IP adresą, o 80 į pageidaujamą patikrinti prievadą.

Jeigu prievadas yra atidarytas/pasiekiamas, tuomet nc komandos rezultatas bus grąžintas beveik iš karto. Kitu atveju netcat įrankis bandys pakartotinai vykdyti susijungimą daugybę kartų. Taigi pageidaujant nutraukti nc komandos vykdymą galime tai atlikti nuspaudus klavišų kombinaciją CTRL+C.

Jeigu prievadai nėra pasiekiami vertėtų peržiūrėti serverio ugniasienės taisykles. Tikėtina, jog jose yra nurodytas draudimas pasiekti serverį 80 ir 443 prievadais.

Ar DNS nukreipimai yra atlikti korektiškai?

Jeigu svetainė yra pasiekiama naudojant tiesioginį serverio IP adresą, tačiau to nepavyksta atlikti naudojant svetainės domeną vertėtų peržvelgti domeno DNS nustatymus.

Siekiant per domeną pasiekti pageidaujamą svetainę, domeno DNS nustatymuose turi būti "A" arba "AAAA" (IPv6 atveju) tipo įrašas nukreipiantis domeną į mūsų serverį.

Patikrinti "A" tipo įrašą pageidaujamam domenui galime naudojant dig įrankį:

host -t A example.com

Numatomas rezultatas:

example.com has address 93.184.216.119

Grąžinamame rezultate IP adresas turi atitikti mūsų serverio IP adresą.

Atliekant pakeitimus domeno aptarnaujamuose DNS serverių nustatymuose būtina atsižvelgti, jog pakeitimams įsigalioti yra reikalingas pakankamai nemažas laiko tarpas kol informacija apie naują domeno nukreipimą bus išplatinta tarp visų DNS serverių.

Ar yra tinkamai nurodytas svetainės šakninis katalogas?

Jeigu DNS nustatymai yra tinkami, vertėtų patikrinti pačios tarnybos konfigūraciją. T.y. peržiūrėti ne tik sintaksę, tačiau ir parametrų nustatytas vertes. Kadangi tiek teisingai sukonfigūruoti Apache virtual host failai tiek Nginx server block failai užtikrina tinkamą užklausų apdorojimą.

Apache virtual host poskyris atrodytų daug maž taip:


    ServerName example.com
    ServerAlias www.example.com
    ServerAdmin admin@example.com
    DocumentRoot /var/www/html
. . .

Šis virtual host yra sukonfigūruotas atsakinėti į bet kokias užklausas ateinančias example.com domeną per 80 prievadą.

Panašiu principu veikia iš Nginx server block, kurie atrodytų daug maž taip:

server {
    listen 80 default_server;
    listen [::]:80 default_server ipv6only=on;
    root /usr/share/nginx/html;
    index index.html index.htm;
    server_name example.com www.example.com;
. . .

Šis server block yra sukonfigūruotas atsakinėti į identikas užklausas, kaip ir prieš tai nurodytas Apache virtual host.

Taip pat šiuose konfigūracijų segmentuose yra itin svarbus šakninio katalogo parametras, kuris nurodo kuriame serverio kataloge Apache ar Nginx web serveriai ieškos pačios svetainės failų kas kartą kai gaus užklausas.

Apache atveju tai būtų šis parametras:

DocumentRoot /var/www/html

Šiuo atveju svetainės failų būtų ieškoma /var/www/html/ kataloge.

Nginx atveju tai būtų šis parametras:

root /usr/share/nginx/html;

Šiuo atveju svetainės failų būtų ieškoma /usr/share/nginx/html/ kataloge.

Ar web serveris pateikia tinkamus indekso failus?

Jeigu svetainės šakninis katalogas yra nurodytas teisingas, tuomet galimai problemą sukelia blogai nurodytas konfigūracijoje svetainės indekso failas. Tai yra pradinis failas kuris yra pateikiamas lankytojui apsilankius domeną, kuris veda į mūsų serverį.

Apache atveju indekso failai yra nurodomi DirectoryIndex parametru:


...
    DirectoryIndex index.html index.php
...

Nginx atveju indekso failai yra nurodomi index parametru:

server {
...
    index index.html index.htm;
...

Šiuo atveju abiejose pavyzdinėse parametrų vertėse yra nurodyta iš pradžių ieškoti index.html indekso failo, kurio neradus būtų ieškoma index.php failo šakniniame svetainės kataloge.

Ar svetainės failų ir katalogų teisės bei savininkai yra nurodyti teisingai?

Viena iš dažniausiai pasitaikančių problemų, kurios yra atsakingos už svetainių neatvaizdavimą yra netinkamai nurodyti katalogų ir failų savininkai bei teisės. Siekiant jog web serveris galėtų pasiekti ir nuskaityti svetainės failus svetainės failai ir katalogas turi priklausyti tinkamai vartotojų grupei, bei turėti atitinkamas teises.

Vartotojų ir vartotojų grupės reikalingos tam jog web serveris galėtų pasiekti ir nuskaityti svetainės failus gali kisti priklausomai nuo naudojamos operacinės sistemos distribucijos.

Ubuntu ar Debiant įprastai tai yra www-data vartotojas/grupė. Tiek Apache, tiek Nginx atveju.

CentOS ar Fedora įprastai tai yra apache vartotojas/grupė. Nginx atveju būtų vartotojas grupė - nginx.

Peržiūrėti failų ar katalogų teises bei savininkus galime naudojant šią komandą:

ls -l /path/to/web/root

Siekiant pakeisti savininką naudojame komandą paremtą šia sintakse:

sudo chown savininkas_vartotojas:savininkas_grupe /kelias/iki/failo/

Siekiant pakeisti savininką rekursyvai pridedamas -R parametras.

Pvz.:

sudo chown -R savininkas_vartotojas:savininkas_grupe /kelias/iki/failo/

Ar per konfigūracinius failus nėra ribojama prieiga?

Verta įsitikinti jog priegia prie svetainės nėra apribota per svetainės šakniname kataloge esantį .htaccess failą ar pačioje Apache konfigūracijoje.

Apache konfigūracijoje ribojimas būtų matomas direktyvoje:


    AllowOverride None
    Order deny,allow
    Deny from all

Nginx atveju priegos ribojimas būtų aprašomas tokiu principu:

location /usr/share {
    deny all;
}

Jeigu svetainė naudoja duomenų bazes, ar duomenų bazių tarnyba yra paleista?

Taip pat kaip ir tikrinant ar web serverio tarnyba yra paleista atveju kai svetainė naudoja duomenų bazes yra reikalinga patikrinti ar duomenų bazių tarnyba yra paleista.

MySQL atveju patikrinti galime naudojant šią komandą:
sudo netstat -plunt | grep mysql

Numatomas rezultatas:

tcp        0      0 127.0.0.1:3306        0.0.0.0:*         LISTEN      3356/mysqld

Ar svetainė sėkmingai prisijungia prie reikalingos duomenų bazės?

Atsižvelgiant į tai jog turinio valdymo sistemoms yra reikalinga galimybė prisijungti prie konfigūracijoje nurodytos duomenų bazės. Patikrinti pagal pvz. Wordpress config.php faile nurodytus parametrus galime patikrinti ar susijungimas vykdomas korektiškai.

Tai galime atlikti naudojant šia sitakse paremtą komandą:

mysql -u DB_USER_value -pDB_PASSWORD_value DB_NAME_value

Ar web serveris yra tinkamai sukonfigūruotas atvaizduoti dinaminį turinį?

Svetainėje pateikiant dinaminį turinį (pvz. PHP), serveryje turi būti įdiegti užklausas į tokį turinį galintys apdoroti paketai.

Apache web serveriui Ubuntu ar Debian aplinkoje tai atlikti galime naudojant šias komandas:

sudo apt-get update
sudo apt-get install php5 libapache2-mod-php5
sudo a2enmod php5

Apache web serveriui CentOS ar Fedora aplinkoje tai atlikti galime naudojant šias komandas:

sudo yum install php php-mysql
sudo service httpd restart

Su Nginx web serveriu yra šiek tiek sudėtingiau, kadangi Nginx neturi PHP modulio kuris gali būti tiesiog įjungtas. Todėl reikia įsitikinti, jog php-fpm yra įdiegtas mūsų konfigūracijoje.

Nginx web serveriui Ubuntu ar Debian aplinkoje tai atlikti galime naudojant šias komandas:

sudo apt-get update
sudo apt-get install php5-fpm php5-mysql

Nginx web serveriui CentOS ar Fedora aplinkoje tai atlikti galime naudojant šią komandas:

sudo yum install php-fpm php-mysql

Disko vietos sąnaudų nustatymui skirtos komandos/įrankiai

IV_VygandasS — Tue, 06 Aug 2013 16:22:17 +0000

Šiame straipsnyje pateiksime komandas/įrankius, kurios padėtų nustatyti serveryje daugiausiai vietos užimančius bei daugiausiai failų talpinančius katalogus. Tai pravartu, kai serveryje dėl neaiškių priežasčių pastebimas disko vietos stygius. Arba pačios disko vietos stygiaus nėra, tačiau matoma, kad yra pasiekta Inode limito riba. Tuomet svarbu yra išsiaiškinti, kurie katalogai labiausiai išnaudoja reikalingus resursus.

Komandos:

Peržiūrėti katalogus pagal failų kiekį mažėjančia tvarka, tikrinamame kataloge ir subkataloguose:

find  -type d |  while    read line  ; do    echo "$( find "$line" -maxdepth 1 | wc -l) $line"  ; done |  sort -rn | less 
Pvz.: find /home/ -type d |  while    read line  ; do    echo "$( find "$line" -maxdepth 1 | wc -l) $line"  ; done |  sort -rn | less

Arba:

find / -type f | awk  '{$NF="";a[$0]++}END{for (i in a) print a[i],i }' FS=/ OFS=/ | sort -rn | less
Pvz.: find /home -type f | awk  '{$NF="";a[$0]++}END{for (i in a) print a[i],i }' FS=/ OFS=/ | sort -rn | less

Peržiūrėti katalogus pagal failų kiekį mažėjančia tvarka, tikrinamame kataloge:
```
find . -xdev -type f | cut -d "/" -f 2 | sort | uniq -c | sort -rn
```

Peržiūrėti Inode kiekį sistemoje:

df -i

Rezultato pvz.:

Filesystem            Inodes   IUsed   IFree IUse% Mounted on
/dev/simfs           1000000   93618  906382   10% /
none                  524288     154  524134    1% /dev

Peržiūrėti rekursyviai bendrą failų kiekį pasirinktame kataloge:
```
find . -type f | wc -l
```
Peržiūrėti kataloge daugiausiai vietos užimantį failus ar katalogus, tikrinamame kataloge:
```
du -h -s * | sort -nr
Pvz.: du -h -s /* | sort -nr
```
Peržiūrėti kataloge daugiausiai vietos užimantį failus ar katalogus, tikrinamame kataloge ir subkataloguose (surikiuoja pagal žmogui lengvai suprantamus dydžius):
```
du -k * | sort -nr | cut -f2 | xargs -d '\n' du -sh | less
Pvz.: du -k /* | sort -nr | cut -f2 | xargs -d '\n' du -sh | less
```

Lengvesnei peržiūrai naudojami įrankiai:

ncdu įrankis

1. Įdiegiame įrankį:

yum install ncdu -y

Jei gausite klaidos pranešimą, kad toks paketas neegzistuoja, tuomet aktyvuokite EPEL repozitoriją su komanda:

yum install epel-release -y

Ją išjungti galėsite faile /etc/yum.repos.d/epel.repo vietoj enabled=1 nurodant enabled=0

2. Įrankio paleidimas:

ncdu

Visą skripto naudojimo sintaksę rasime įrankio dokumentaciniame puslapyje:

man ncdu

Įrankio pateikiama vartotojo sąsaja:

gt5 bash programino kodo skriptas

1. Atsisiunčiame gt5 archyvą:

wget http://downloads.sourceforge.net/project/gt5/gt5/gt5%2C%20version%201.4.0/gt5-1.4.0.tar.gz

2. Išskleidžiame archyvą:

tar xvf gt5-1.4.0.tar.gz

3. Pereiname į išarchyvuotą katalogą:

cd gt5-1.4.0/

4. Naudojimas:

bash gt5 
Pvz.: bash gt5 /

Visą skripto naudojimo sintaksę rasime ./README faile.

Įrankio pateikiama vartotojo sąsaja:

Dedikuoto serverio problemų diagnozė

IV_RomanL — Mon, 09 Jan 2012 16:21:16 +0000

Kokių konkrečių veiksmų reiktų imtis norint lokalizuoti galimas nepageidaujamas dedikuoto serverio apkrovas? Šiame informaciniame straipsnyje pateikiamos gairės kuriomis vadovaujantis galėsite nustatyti nemažą dalį problemas keliančių priežasčių ir jų galimus sprendimus. Bet kokiu atveju, problemas diagnozuoti ir jas šalinti turėtų jūsų dedikuoto serverio administratorius, tokiu būdu rizika suklysti bus minimali.

1. Padidėjęs serverio procesoriaus apkrovimas

Atsiradus dedikuoto serverio sutrikimui dėl aukšto procesoriaus panaudojimo, reiktų nustatyti kas išnaudoja šį resursą. Priežastys galinčios lemtį šį sutrikimą:

* Nepakankama esamo dedikuoto serverio procesoriaus galios serveryje vykdomoms programoms;
* Staiga padidėjus vykdomų programų skaičiui;
* Dėl nekorektiškai veikiančios (-ų) programos (-ų);

Prisijungiame prie serverio SSH konsolės ir vykdome komandą:

top

ir tuomet nuspauskite klavišus SHIFT + M

Prieš jūsų akis turėtų būti pateikta grafa, pavyzdys:

top - 14:08:25 up 38 days, 8:02, 1 user, load average: 1.70, 1.77, 1.68
Tasks: 107 total,   3 running, 104 sleeping,   0 stopped,   0 zombie
Cpu(s): 11.4%us, 29.6%sy, 0.0%ni, 58.3%id, .7%wa, 0.0%hi, 0.0%si, 0.0%st
Mem:   1024176k total,   997408k used,    26768k free,    85520k buffers
Swap:  1004052k total,     4360k used,   999692k free,   286040k cached

  PID USER    PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 9463 mysql   16   0  686m 111m 3328 S   53  5.5 569:17.64 mysqld
18749 apache  16   0  140m 134m 1868 S   12  6.6   1345:01 php_defunct
24636 apache  17   0 34660  10m  712 S    8  0.5   1195:15 php_defunct
22442 apache  24   0  6048 2024 1452 S    8  0.1   0:00.04 php_defunct

Pateikta lentelė su realiu laiku veikiančiomis aplikacijomis dedikuotame serveryje. Paanalizuokime pateiktus duomenis.

Eilutė:

Cpu(s): 11.4%us, 29.6%sy, 0.0%ni, 58.3%id, .7%wa, 0.0%hi, 0.0%si, 0.0%st

čia:

* us: vartotojo CPU laikas (user CPU time) - tai reikšmė parodanti kokios aplikacijos veikia varotojo vardu. Šiuo atveju pagal pavyzdį veikia "mysql" ir "apache" programos. Jei ši reikšmė yra didesnė už kitas, reiškia apkrova generuoja vartotojo vykdoma programa.
* sy: sistemos CPU laikas (system CPU time) - tai pačios operacinės sistemos branduolio apkrovos reikšmė.
* id: budinčio CPU procentas (idle CPU time) - ši reikšmė parodo kiek procentų CPU nėra panaudojamas. Kuo ši reikšmė didesnė tuo geriau. Jei ši reikšmė itin didelė (daugiau nei 80-85 procentai) tai indikuoja jog sistemos sulėtėjimą lemia ne CPU resurso perkrova.
* wa: nuskaitymo/įrašymo laukimas (I/O wait) - ši reikšmė parodo laiką kurį turi laukti CPU iki kol bus įrašyti/nuskaityti duomenys (dažniausiai kietojo disko). Jei ši reikšmė itin didelė ir jūsų dedikuoto serverio darbas sulėtėjęs, tai gali reikšti kietojo disko problemą arba RAM gedimą.

Eilutė:

   PID USER    PR  NI  VIRT  RES  SHR S  %CPU %MEM    TIME+  COMMAND
  9463 mysql   16   0  686m 111m 3328 S   53  5.5 569:17.64 mysqld
 18749 apache  16   0  140m 134m 1868 S   12  6.6   1345:01 php_defunct
24636 apache  17   0 34660  10m  712 S    8  0.5   1195:15 php_defunct
22442 apache  24   0  6048 2024 1452 S    8  0.1   0:00.04 php_defunct

Čia:

* CPU: indikuoja dedikuotame serveryje veikiančios aplikacijos CPU sunaudojimą. Kuo šis skaičius didesnis, tuo daugiau aplikacija reikalauja CPU galios. Jei matote jog šis skaičius itin didelis ties viena iš aplikacijų (pvz.: mysql), tuomet problema mySQL serveryje.

Mūsų atveju programa mysql kuri vykdoma vartotojo mysql vardu, sunaudoja 53 procentus CPU resurso.

Ką daryti jei serveryje veikianti aplikacija pradėjo naudoti itin daug CPU resurso?

a. Nustatyti būtent kokia aplikacija išnaudoja CPU resursą;
b. Aplikaciją optimizuoti ar sukonfigūruoti geresniai dedikuoto serverio resursų eksploatacijai:
MySQL - konfigūracijos/optimizacijos gidas
Apache - konfigūracijos/optimizacijos gidas
c. Serverio resursų didinimas esant poreikiui (dedikuoto serverio plano didinimas)

2. Padidėjęs serverio virtualios atminties apkrovimas

Atsiradus dedikuoto serverio sutrikimui dėl aukšto virtualios atminties (RAM) panaudojimo, reiktų nustatyti kas išnaudoja šį resursą. Priežastys galinčios lemtį šį sutrikimą:

* Nepakankamas virtualios atminties (RAM) kiekis, serveryje vykdomoms programoms;
* Staiga padidėjus vykdomų programų skaičiui;
* Dėl nekorektiškai veikiančios (-ų) programos (-ų);

Vykdome komandą top serverio SSH konsolėje (1 punkto pavyzdys). Pateikiama lentelė su realiu laiku veikiančiomis aplikacijomis, pavyzdys:

   PID USER    PR  NI  VIRT  RES  SHR S  %CPU %MEM    TIME+  COMMAND
    9463 mysql   16   0  686m 111m 3328 S   2  60 569:17.64 mysqld
   18749 apache  16   0  140m 134m 1868 S   1  6.6   1345:01 php_defunct
24636 apache  17   0 34660  10m  712 S    0.8  0.5   1195:15 php_defunct
22442 apache  24   0  6048 2024 1452 S    0.8  0.1   0:00.04 php_defunct

Čia:

* MEM: indikuoja dedikuotame serveryje veikiančios aplikacijos RAM sunaudojimą. Kuo šis skaičius didesnis, tuo daugiau aplikacija reikalauja RAM atminties. Jei matote jog šis skaičius itin didelis ties viena iš aplikacijų (pvz.: mysql), tuomet problema mySQL serveryje.

Tam jog peržiūrėtumėte laisvos virtualios atminties kiekį, įvykdykite komandą SSH konsolėje:

free -m

Jums bus pateikta lentelė su duomenimis, pavyzdžiui:

total            used              free         shared    buffers     cached
Mem:          4096        415       3680          0          0          0
-/+ buffers/cache:        415       3680

Čia:

* total: iš viso alokuotos atminties kiekis dedikuotam serveriui. Šis kiekis išreiškiamas Megabaitais (MB).
* used: naudojama atmintis.
* free: laisva, galima panaudoti atmintis.

Ką daryti jei serveryje veikianti aplikacija pradėjo naudoti itin daug RAM resurso?

a. Nustatyti būtent kokia aplikacija išnaudoja RAM resursą;
b. Aplikaciją optimizuoti ar sukonfigūruoti geresniai dedikuoto serverio resursų eksploatacijai:
MySQL - konfigūracijos/optimizacijos gidas
Apache - konfigūracijos/optimizacijos gidas
c. Serverio resursų didinimas esant poreikiui (dedikuoto serverio plano didinimas)

3. Serverio klaidos žurnalai.

Tam jog lokalizuoti dedikuoto serverio problemą, reiktų peržiūrėti aplikacijų ar paties serverio generuojamus klaidos žurnalus. Bendruoju atveju klaidos žurnalai saugomi aplanke /var/log . Šiame kataloge galite rasti daugelio programų klaidos žurnalus, pavyzdžiui:

* Apache
* MySQL
* Postfix
* Java

Pastaba: norint įjungti lėtų užklausų dokumentavimą MySQL sistemai, reiktų atitinkamai papildyti my.cnf failą šiuo įrašu (papildžius būtina perkrauti mysql serverį):

log-slow-queries

4. Išaugusios disko vietos sąnaudos/Inode kiekis.

Reikia surasti daugiausiai vietos serveryje užimančius ir didžiausią failų kiekį turinčius katalogus. Daugiau informacijos apie tai galite rasti šiame straipsnyje:

"Disko vietos sąnaudų nustatymui skirtos komandos/įrankiai"