Едно от нещата който най много ме дразнят е когато в cli копирам/местя голяма директоря да нямам идея какъв процент от целият размер съм претъркалял. За съжаление cp/mv нямат подобни сили и се налага да прибегнем към алтернативни варианти. Има доста възможности но на мен лично най ми допада използването на rsync вместо pc/mv. В него има всичко вградено – запазване на правата над файлове и директории, прогрес бар както и възможност да изтрива копираните файлове.

В общи линии си направих 2 alias-а които вършат повече от чудна работа:


alias cpi='rsync -a --info=progress2'
alias mvi='rsync -a --info=progress2 --remove-source-files'

Поради някакви (не много ясни ми причини) бях пропуснал да направя ъпгрейд на postgresql демона при дистрибутивният ъпгрейд на един от Debian сървърите ми. Postgresql демона има хубавото свойство да не започва да използва новата си версия (за разлика от Mysql) докато не убедим, че новата е на пълно съвместима със старта – изключително полезно при големи бази данни. Самият процес по обновяване се ограничава до следните 2 стъпки:

  • pg_dropcluster
  • pg_upgradecluster

Преди да издропите клъстера pg демона трябва да е спрян!

pg_dropcluster 9.4 main

Тази команда преминава бързо, след което преминаваме към съществената част – самият ъпгрейд

pg_upgradecluster 9.1 main
Disabling connections to the old cluster during upgrade...
Restarting old cluster with restricted connections...
Creating new cluster 9.4/main ...
config /etc/postgresql/9.4/main
data   /var/lib/postgresql/9.4/main
locale en_US.UTF-8
Flags of /var/lib/postgresql/9.4/main set as -------------e-C
port   5433
Disabling connections to the new cluster during upgrade...
Roles, databases, schemas, ACLs...
Fixing hardcoded library paths for stored procedures...
Upgrading database postgres...
Analyzing database postgres...
Fixing hardcoded library paths for stored procedures...
Upgrading database template1...
Analyzing database template1...
Fixing hardcoded library paths for stored procedures...
Upgrading database xpqt...
Analyzing database xpqt...
Re-enabling connections to the old cluster...
Re-enabling connections to the new cluster...
Copying old configuration files...
Copying old start.conf...
Copying old pg_ctl.conf...
Copying old server.crt...
Copying old server.key...
Stopping target cluster...
Stopping old cluster...
Disabling automatic startup of old cluster...
Configuring old cluster to use a different port (5433)...
Starting target cluster on the original port...
Success. Please check that the upgraded cluster works. If it does,
you can remove the old cluster with

pg_dropcluster 9.1 main

Ако всичко е минло гладко трябва да получите съобщение като горното което ви подканва да разкарате старите данни от pg.

pg_dropcluster 9.1 main

В края на тая тарпана вече можете да стартирате процеса си отново. При мен базите са малки и за съжаление не мога да дам оценка за колко време преминава същественият ъпгрейд.

Лесно можем да избием всички mysql заявки на определн потребител с елегантното:

select concat('KILL ',id,';') from information_schema.processlist where user='user123';

Заместваме user123 с желаният от нас потребител и изпълняваме в mysql и всичко е ОК 🙂

Тъй като от netenberg изобщо не оправдаха очакванията ми за fantastico 3 та реших да го разкарам тоталка. Въпреки кореспонденцията която водихме преди много време и насоките които им дадох за подобряване на продукта им до конкурентно способно ниво на softaculous и installatron се стигна до момента в който трябваше да бъде деинсталиран техният плъгин от Cpanel сървърите ми. Тъй като няма инструкции как се премахва това недоразумения вдигнах тикет на support-а те ми дадоха следните инструкции.

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

Изпълних си командите за чистиха се файловете им като осъзнах нещо важно пичовете изобщо не споменаха как се де регистрира плъгина им от контролният панел 🙄  😆 Мдаа педераски номер но се случва то и аз трябваше да гледам повече. Също така имаше останала една камара техни файлове явно се надяват да се върна като техен клиент, тъй като имали най много скриптове за инсталация както каза съпорт (не думай това е най важното направо) :mrgreen: . Та нека да продължим с пълното изкормване:

Това е най важната стъпка която трябва да се направи преди да затриете всичко останало тъй като после ще се окажете бе плъгин но с икона в контролния панел тъй като все е още е регистриран.

/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/

Воала вече fantastico е извън играта и можете да спите спокойно. Причините поради които го смених с конкурентен продукт са 3 и то много семпли

  • Нямат API с което мога да си комуникирам ако искам да правя допълнения или някакви други магии
  • нямат hooks при определени действия да мога да се закачам и да дописвам функционалност
  • кофти support доста бавен и не много адекватен в отговорите си

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

Mdadm е мой любим приятел но има нещо което дразни ужасно много – периодични проверки и ресинк за сигурност на здравето на RAID масива- например има данни в bad sector-и, което от своя страна смачква машината от към IO. В общи линии след чоплене открих виновниците – кронове които се стартират обикновено около 1ч вечерта всяка неделя. Идеята е ясна – сигурност че масива е в перфектно състояние и няма драми с информацията. Това е добре ама ежеседмично ми се вижда много, затова си го преконфигурирах да се рънва на всяка първа дата от месеца.

За Redhat базираните деривати пътя на крона е /etc/cron.d/raid-check. За Debian базираните дистроци пътя е /etc/cron.d/mdadm. Кроновете от своя страна извикват bash скриптове /usr/sbin/raid-check за CentOS etc и /usr/share/mdadm/checkarray за Debian и приятели. Параметри към скриптовете се взема от /etc/sysconfig/raid-check или съответно /etc/default/mdadm където може да бъде забранен изцяло check-а, което не е много умно като идея.