З-за невдалої в netenberg мої очікування для fantastico 3 тому я вирішив позбутися від нього totalka. Хоча листування, які ми вели вже давно і керівних принципів, які давали їм покращити свій продукт на рівень конкурентоспроможності installatron і softaculous закінчився, поки я повинен був бути видалив свій плагін від мого Cpanel серверів. Оскільки немає ніяких інструкцій про те, як видалити непорозуміння, що я підібрав квиток підтримки- і вони дали мені наступні інструкції.

rm -rf /var/netenberg/fantastico_de_luxe/
rm -rf /usr/local/cpanel/whostmgr/docroot/cgi/fantastico/
rm -rf /usr/local/cpanel/3rdparty/fantastico*
rm -rf /usr/local/cpanel/base/frontend/*/fantastico
rm -f /usr/local/cpanel/base/frontend/x/cells/fantastico.html
rm -f /usr/local/cpanel/whostmgr/docroot/cgi/addon_fantastico.cgi

Изпълних си командите за чистиха се файловете им като осъзнах нещо важно пичовете изобщо не споменаха как се де регистрира плъгина им от контролният панел 🙄 😆 Мдаа педераски номер но се случва то и аз трябваше да гледам повече. Також було багато лівих над їх файли мабуть, сподіваюся, до його як своїх клієнтів, як багато скриптів для установки підтримки, як ви сказали (Ах, це найбільш важливо правильно) :лол: . Отже, Давайте продовжимо повного спустошення:

Це є найбільш важливим кроком, що повинно бути зроблено перед і все інше а потім зникає як то буде кінця вгору з піктограмою було, але плагін в панелі управління, тому що вона як і раніше зареєстрований.

/usr/local/cpanel/bin/unregister_cpanelplugin /var/netenberg/fantastico_f3/fantastico_f3
rm -rf /usr/local/cpanel/3rdparty/fantastico_f3
rm -rf /usr/local/cpanel/base/frontend/*/fantastico_f3
rm -rf /usr/local/cpanel/bin/fantastico_f3.cpanelplugin
rm -rf /usr/local/cpanel/whostmgr/addonfeatures/fantastico_f3
rm -rf /usr/local/cpanel/whostmgr/addonsfeatures/fantastico_f3
rm -rf /usr/local/cpanel/whostmgr/docroot/addon_plugins/fantastico_f3.jpg
rm -rf /usr/local/cpanel/whostmgr/docroot/cgi/addon_fantastico_f3.php
rm -rf /usr/local/cpanel/whostmgr/docroot/cgi/fantastico_f3
rm -rf /var/cpanel/apps/fantastico_f3_cpanel.conf
rm -rf /var/cpanel/apps/fantastico_f3_whm.conf
rm -rf /var/netenberg/fantastico_f3

У випадку, якщо ви пропустили крок unregister_cpanelplugi того, щоб грати більше додаткових крок:

mkdir --parents /var/netenberg/fantastico_f3
cd /var/netenberg/fantastico_f3 && curl -O http://174.120.165.106/fantastico_f3/sources.tar.bz2
cd /var/netenberg/fantastico_f3 && tar --bzip2 --extract --file sources.tar.bz2
/usr/local/cpanel/bin/unregister_cpanelplugin  fantastico_f3
rm -rf /var/netenberg/

Veil тепер fantastico вийшов, і ви можете спати. Причини, чому я змінив його конкурентоспроможний продукт 3 і це дуже просто

  • Немає API, з яким я можуть спілкуватися, якщо я хочу, щоб зробити доповнення або будь-які інші заклинання
  • у них немає гачки в певних дій може стьоб та dopisvam функціональність
  • Бад-підтримка досить повільно і не дуже адекватної у відгуках

PS. paper_lantern и x3 имаше останала икона която се разкарва с

rm  /usr/local/cpanel/base/frontend/paper_lantern/dynamicui/dynamicui_fantastico_f3.conf
rm /usr/local/cpanel/base/frontend/x3/dynamicui/dynamicui_fantastico_f3.conf

Деякі розробники просто не буде навчитися писати грамотними в RFC ніколи не. Я помітив, що кілька errror_log файлів, які накопичили величезний ряд відсталих попередження та повідомлення за недотримання стандарту PHP. Загалом, це важко пояснити користувачеві, що код, який ставиться є поганим і повинна бути фіксованою. У загальному випадку я помітив, що користувачі не порушити їх журнал помилок після запуску коду. В цілому, радикальний підхід, щоб зупинити повністю error_log файли, і хто хоче, щоб дозволити їм перейти, але в цілому створить дискомфорту для багатьох користувачів. Таким чином, зміцнити підхід 2 – adminski наддержав або 1 Bash лінія. Шукати файли, названий error_log з розміром більше, ніж 5 МБ (Тут я залишу мої цінності хоча 1 МБ складає більш ніж достатньо) і видаляти їх, щотижня. Цей ефект досягається за допомогою безлад знайти

find /home/ -name error_log -size +5M -type f -delete

Залишається тільки, щоб врізатися у короні виконувати як тільки через тиждень і у нас є багато persistentno рішення. У моєму випадку це здається ОК в 1 o ' увечері щонеділі.

0 1 * * 1 find /home/ -name error_log -size +5M -type f -delete >/dev/null 2>&1

Будь-хто, хто має справу з професійні веб-хостинг знає, що те, що вони являють собою загрозу інфіковані користувачів зловмисне програмне забезпечення, Web снарядів д. На obšiât, у випадку використовується maldet не погано скрипт. Це відрізняє 3 речі

  1. Жахливо повільна
  2. Це жахливо повільна і якщо ви помістіть його в режимі моніторингу буде плутатися з вашим сервером
  3. Зберегти свою власну базу даних з md5/hex definici для поганих кодом.

Його останньою риси робить його корисним, як ви можете s″bmitvaš файли яких не були виявлені до сих пір і на більш пізньому етапі увійде до бази даних. Як я поділяв, у розділі 1 і 2 її швидкість є вражаюче низькою – При невеликому навантаженні машина 70 к-файлу відскановані для про на півтори години. З цієї причини я почав, щоб допомогти моїм хорошим другом, ShadowX malmon – альтернативою maldet, написаний на python трохи більше гнучкості.. На жаль, через брак часу (в основному, але не єдиний) Ми не готового проекту, який в даний момент не є дуже корисна – Є чимало помилок, які повинні бути очищені. В останні кілька днів я мав проблеми з клієнтами, інфіковані CryptoPHP, який мав величезні public_html файли ~ 60 k + inod користувача. Оскільки загальна довелося бути перевірені займе більше 200 к-файл, який у грубі облікові записи 5+ я вирішив maldet конфігурацію Nip/Tuck годин, щоб зменшити файли, які мають бути перевірені на більш розумним число і час. При čopleh konfa я помітив наступні рядки

# 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 і клацніть папку, малий – Я не бачу різниці в швидкості і поведінка – Він використовував його perl скі сканер замість 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 пъти и половина по бързо в сравнение с преди.

За промовчанням під час інсталяції Munin у Cpanel зниклих без вести кілька гарний konfiga зробити їх вручну. За мен един от тях е мониторинга на температурата на дисковете.

В основному, це тривіальний конфігурації

1. Ми повинні визначити тип наших дисків – Він може бути однією з таких : Ата, SCSI, Сб[,Авто][,N][+ТИП], usbcypress[,X], usbjmicron[,x][,N], usbsunplus, Marvell, Бетельна,N/E, 3Посуд,N, HPT,L, M, N, megaraid,N, cciss,N, Авто, тест. Найпростішим способом для цього є через кіт “/proc/ide” або “/proc/scsi”. Мені:

# cat /proc/scsi/scsi
Attached devices:
Host: scsi0 Channel: 00 Id: 00 Lun: 00
  Vendor: ATA      Model: WDC WD1003FBYZ-0 Rev: 01.0
  Type:   Direct-Access                    ANSI  SCSI revision: 05
Host: scsi1 Channel: 00 Id: 00 Lun: 00
  Vendor: ATA      Model: WDC WD1003FBYX-0 Rev: 01.0
  Type:   Direct-Access                    ANSI  SCSI revision: 05
Host: scsi4 Channel: 00 Id: 00 Lun: 00
  Vendor: ATA      Model: TOSHIBA DT01ACA1 Rev: MS2O
  Type:   Direct-Access                    ANSI  SCSI revision: 05

 

 

Як ви можете бачити мене є 3 Тип приводу ATA.

2. Почати контролювати температуру необхідно описати в munin-вузол диски нас. У файлі додати такий тип entries/etc/munin/plugin-conf.d/hddtemp_smartctl

# cat /etc/munin/plugin-conf.d/hddtemp_smartctl
[hddtemp_smartctl]
user root
env.drives sda sdb
env.args_sda -d ata
env.args_sdb -d ata

 

Ми може потрапити в такий спосіб тестування конфігурації

# env drives="sda sdb sdc" args_sda="-d ata" args_sdb="-d ata" args_sdc="-d ata"  /etc/munin/plugins/hddtemp_smartctl
sda.value 32
sdb.value 33
sdc.value 33

 

Якщо ви отримаєте значення так все це ОК. Якщо ви отримуєте повідомлення про помилку слід переконатися, що воно правильно охарактеризували. Слід перезапустити munin а кивати на izčakte 10-15 хв до populirat деякі дані і почати малювати графіки. Можете да проверите /var/log/munin/munin-node.log за грешки и по лесното им отстраняване.

Ако искате да получавате email при критична температура на дисковете трябва да добавите описание за критична такава:

[example.com]
    address 127.0.0.1
    use_node_name yes
    hddtemp_smartctl.sda.critical 55
    hddtemp_smartctl.sdb.critical 55

Сьогодні я вирішив зробити деякі тести на чисту інсталяцію для Cpanel, які мені були потрібні для кількох користувачів. Так як я не хочу тягар роботи серверів з пакувальників резервного копіювання і передачі файлів, я використав архіви попередній ніч. Transferirah всі записи в/Головна і виявили, що Cpanel не пропонують повернення більше 1 рахунок як графічний інтерфейс так і CLI. Через GUI як не було ніякої можливості, щоб отримати число вирішив прослуховуватися з cli сценарій restorepkg. Її використання є дуже простий

/scripts/restorepkg username.tar.gz

Як дія повторюватиметься для кожного користувача окремо. Під час спроби використати на * замість імені користувача, сценарій лобового Шут мене так що мені потрібно підійти до більш витончено –

archives=$(ls /home/ | grep tar.gz)

for archive in $archives

do

/scripts/restorepkg --force $archive

done

Тепер швидко пояснення. Складіть список всіх записів і релізи його в змінній архіви, то патрулювання у списку елемент, елемент, як ми запускаємо razpaketiraneto для кожного Архів окремо. Нищо кой знае колко сложно интересно защо пичовете от Cpanel не са изплзвали подобно решение за множество файлове.