Той, хто займаецца вэб-хостынгу ведае, што пагроза заражаныя карыстальнікам шкоднасных праграм, вэб-абалонак і г.д.. У тых выпадках Агульнага прымянення гадзіну не дрэнны сцэнар. ён мае 3 рэчы

  1. жахліва павольна
  2. Гэта жудасна павольна, і калі ён дазваляе ў рэжыме маніторынгу будзе izgavri сервера, які вы
  3. Падтрымлівае сваю ўласную базу дадзеных md5 / шасціграннай вызначэння дрэннага кода.

Толькі апошняя характарыстыка робіць яго карысным, таму што акрамя ўсяго іншага можа sabmitvash файлы, якія не былі выяўленыя да гэтага часу, і на больш познім этапе уступіць у базах дадзеных. Як я падзяліўся ў кропцы 1 і 2 хуткасць шакіруюча нізкі – пры нізкай загрузцы файла машына 70K скануецца на працягу прыкладна паўтары гадзіны. Па гэтай прычыне я пачаў, каб дапамагчы майму добраму сябру з ShadowX Malmo – альтэрнатыва maldet напісана на Python з невялікай колькасцю гнуткасці. На жаль, не хапае часу (у асноўным, але не толькі) мы не скончылі праект, які ў дадзены момант не з'яўляецца вельмі карысным – Ёсць шмат памылак, якія павінны быць ачышчаны. У апошнія дні ў мяне былі праблемы з кліентамі, інфіцыраваных CryptoPHP, якія мелі велізарныя файлы public_html ~ 60k + inod-і карыстальніка. Паколькі агульны аб'ём павінен быў быць адсканаваныя над 200k файл, які б прыкладна 5+ гадзін я вырашыў наладзіць канфігурацыю maldet, каб паменшыць файлы, якія будуць адсканаваныя да больш разумнага колькасці і часу. У той час як збор конфы заўважыў наступныя радкі

# 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

цікава… Мабыць ёсць магчымасць выкарыстоўваць ClamAV – якая таксама мае вялікую хуткасць, але чаму б не паспрабаваць. хутка усталёўваецца

/scripts/update_local_rpm_versions --edit target_settings.clamav installed

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

Maldet перспектыве і на невялікай тэчцы – Я не бачу ніякай розніцы ў хуткасці і паводзін – Ён выкарыстоўвае яго яго жамчужна-лыжны сканер замест таго, што з ClamAV. Пасля кароткага прасейвання праз крыніца maldet знайшоў наступныя радкі

 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

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

Перад тым як гэта пачалося з другім маладым нянавісці да 50 s'tinki OS Я маю на ўвазе, што кожны дзень я павінен кіраваць ёй ведаць першай асобы адзіночнага ліку, а таксама. Сёння я правёў некаторы час, каб iztestvam новую чароўную нечуванае і нябачная функцыя абнаўлення distrubitiven (псеўда) 😀 . Першае, што мяне ўразіла гэта, што RedHat ў сваёй бясконцай мудрасьці, вырашыў спыніць падтрымку x86 архітэктуры 🙄 . Напълно съм наясно че сме 2014-та година и сървърни процесори с 32 трохі доўга інструкцыя адсутнічае. Мда ама какво правят потребителите на малки VPS-и – x64 лапа больш аператыўнай памяці, як вы глядзіце на яго, калі ў вас тонкія віртуальную машыну з 512-1 Гб аператыўнай памяці будзе змагацца за кожны megabay гэта і не марнаваць 20-30% Проста выкарыстоўваць вялікі набор інструкцый. Prepsuvah таму што я быў instalil CentOS x86 і x64 выцягнуў адзін. Адразу ж я ўбачыў розніцу ў ISO-й – ~ 100Мб пры мінімальнай 6.5. Prepsuvah яшчэ раз. Я зноў усталяваў virtualkata я вырашыў паглядзець, наколькі добра RedHat выканалі сваю працу – Я даў / вар і / USR асобных раздзелаў LVM 😈 . Пасля ўстаноўкі мадэрнізаваны ўстаноўкі і Апач ўсе пакеты, PHP, MySQL і прывязка – гэта было цікава, што будзе загарэцца абслугоўванне. Адкрыты як добры студэнт кіраўніцтва CentOS, каб абнавіць і пачаў старанна прытрымлівацца крок за крокам. Калі я дайшоў да моманту, каб пачаць фактычнага абнаўлення гэта горныя львы выразаныя мяне, че имам критичен проблем 🙄 . Агляд падрабязны вывад – мдаааа / USR ён не можа гэта асобны раздзел 😆 я ведаў, Я не быў бы расчараваны ў Джым Уайтхерст і кампаніі. эканоміць “экстрэмальны” Праблема была даволі паведамленні без знака пакетаў, konfizi файлы, якія не супадаюць, і г.д.. WTF не было нават выкарыстоўваць трэці рэпазітароў усё, што ад іх люстэркі выцягнуў мой, я не зрабіў якіх-небудзь налад толькі простыя ням ўсталяваць. Цяпер усё было ясна, так што даволі бесцырымонна прымусілі абнаўлення. Перазапусціце зноў старанна, як я, нарэшце, падкажыце сцэнар і ўсё скончылася для / USR раздзела. Я быў занадта лянівы,, якія спрабуюць выправіць, у любым выпадку гэта не было толькі для навуковых мэт, не серверны прадукт спосаб абнаўлення ў той час. Я злавіў пераўсталяваць ваш virtualkata на гэты раз усё засунуць яго ў 1 доля. Акрамя таго, я ўзяў ўрок, няма ніякіх дадатковых абнаўленняў sarvasi, пасля ўстаноўкі прамога абнаўлення. Заключны крок зноў падышоў Dosa дыялог, які распавёў мне, У мяне ёсць шмат непрыемнасцяў High – несапраўдныя пакеты, konfizi і г.д., але можа працягвацца. Я ведаў, што ў пачатку не робяць іх няправільныя рэчы. Я зноў перазагрузіцца і чакаў – о, што абнаўленне паспяхова завершана цуд. І гэта спрацавала, ці, прынамсі, загрузкі, а не спрабавалі ўсталяваць дадатковыя пакеты, але каманда прыпынку залежыць – SYS ўсё яшчэ павінны былі быць памылка 💡 . Пасля таго, як увесь гэты Tarapoto вырашыў усталяваць чыстую Centos 7 каб убачыць, калі мы рыкаючы для / загрузнага падзелу ў LVM – 6.5 не дапушчае такой пыху. ISO-я запускаю яго, і я быў злёгку шакаваны усталёўшчыкам – гэта было не вельмі камфортна “ахайны”, зусім нелагічна прыгожа. След известна борба успях със заветната цел и аха да се инсталира и гръмна, че трябва да си изнеса /boot-а извън LVM-a 👿 Това е крайно не сериозно и досадно, ако поради някаква причина забравиш да си увеличиш размера на boot дяла от 200МБ и понатрупаш стари ядра какво се случва.

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

Як лаяцца RHEL і CentOS гаўно-і ёсць некаторыя рэчы, якія яны вынайшлі вельмі пісьменныя. Напрыклад, дадаўшы шэраг дадатковых IP-я гады даволі добрая праца наша. Увогуле, калі вам трэба дадаць вялікая колькасць адрасоў я б падлічаны Баш skriptche, у якім цыкл для выканання аперацыі, што рука не працавала. У Centos / RHEL народа ён разабраўся даволі добры файл дыяпазону. Увогуле, стварыце файл / і г.д. / sysconfig / сеткі-скрыпты / 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 в нашият случай

 

У Centos-але менш цікавым ва ўсталёўцы маставых адаптараў. Я прымаю, што ўжо усталяваны мост-Utils пакет і eth0 (гэта ў маім прыкладзе) камплект, так што давайце разгледзім асноўныя крокі

  1. Капіраванне параметраў у eth0 BR0 (тут ужо калі вам патрэбен іншы назвах адаптары, каб выправіць яе)
  2. Zanestvate запісвае файл канфігурацыі eth0 br0
  3. замествате тыпу на адаптара ад Ethernet на Bridge
  4. Выдаленне MAC-адрасы BR0 канфігурацыі
  5. Ўсталяваць у канфігурацыі eth0, што мы будзем мець адаптар мост br0

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

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

Сёння sutinrta пачаў рабіць абнаўленне стандартнага адлегласць сервера Debian і Dovecot памёр наступнае паведамленне пра памылку 🙂

[….] Запуск IMAP / POP3 паштовы сервер: dovecotError: гняздо() не ўдалося: Сямейства адрасоў не падтрымліваецца пратаколам
памылка: абслугоўванне(pop3-Увайсці): слухаць(::, 110) не ўдалося: Сямейства адрасоў не падтрымліваецца пратаколам
памылка: гняздо() не ўдалося: Сямейства адрасоў не падтрымліваецца пратаколам
памылка: абслугоўванне(pop3-Увайсці): слухаць(::, 995) не ўдалося: Сямейства адрасоў не падтрымліваецца пратаколам
памылка: гняздо() не ўдалося: Сямейства адрасоў не падтрымліваецца пратаколам
памылка: абслугоўванне(Лагін-IMAP): слухаць(::, 143) не ўдалося: Сямейства адрасоў не падтрымліваецца пратаколам
памылка: гняздо() не ўдалося: Сямейства адрасоў не падтрымліваецца пратаколам
памылка: абслугоўванне(Лагін-IMAP): слухаць(::, 993) не ўдалося: Сямейства адрасоў не падтрымліваецца пратаколам
фатальны: Не атрымалася запусціць слухачоў
не ўдалося!

 

Ако се загледате внимателно в нея грешката вади очите на човек слухаць(::, 993) не ўдалося відавочна, спрабуючы слухаць IPv6-адрас, што я забараніла 😈 . Рашэнне гэтак жа ochevdino як сама памылка – трябва да накараме dovecot да работи само на ipv4, което се постига с следният ред в /etc/dovecot/dovecot.conf
listen=0.0.0.0
След което удряме един бърз рестарт на Dovecot и всичко е по реда си и можем да продължим с дистрибутивният ъпгрейд