От доста време не се занимавам с кодене и рядко ми се налага да чопля някакви извръщания в cli които не са UTF8 енкоднати. Днес ми се наложи да прегледам на бързо едни файлове и като го отворих почти веднага изпитах желание да направя rm -rf на папката където се съдържаха, някой малоумен индивид с половин мозъчна клетка е решил да напише коментарите си на кирилица. За щастие не супер адмиралските сили решават това недоразумение на природата с 1 ред в cli:

iconv -f cp1251 -t utf8 old_shitty_encoded_file -o new_good_encoded_file

Мисля че самите флагове говорят сами за себе си но нека да ги прегледаме на бързо:

  • -o outputfile
  • -t to-encoding
  • -t to-encoding

iconv има и друга много приятна екстра че може да транслитерира (където е възможно) като се зададе -t ASCII//TRANSLIT но за съжаление не работи с кирилица 🙂

Поради някакви (не много ясни ми причини) бях пропуснал да направя ъпгрейд на 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

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

Днес ми се наложи да пусна един fsck на един голям RAID масив ~6TB. В бързината не стартирах fsck с опция -C за да ми показва прогрес и след скромно чакане от 2 часа леко ми писна, че съм в неведение до къде е стигнала проверката. Готин трик за вече стартиран fsck да визуализира прогрес бар е:

kill -10 $(pidof fsck.ext3)

Изчаквате известно време при мен след около 2-3 мин се появи прогрес бара и показа 49% (кеф) още 3 часа чакане 🙁

Нека да сумаризираме какво правим изпращаме сигнал SIGUSR1 който оказва на fsck да показва прогрес бар. Ако искаме да го спрем по някаква причина 🙄 трябва да изпратим SIGUSR2 или

kill -12 $(pidof fsck.ext3)

Еми това е не е нещо супер сложно или трудно просто готин трик 🙂

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

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

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

Новият Debian Stable е факт от около седмица и ме сърбяха ръцете да си надградя виртуалката до него но нямах никакво време до днес. Тъй като денят ми стартира рано реших да посветя време на ъпгрейда. Промених сорс листа ми като промених wheezy  на jessie

sed -i "s/wheezy/jessie/g" /etc/apt/sources.list && apt-get update

Тук изгърмяха 2 огледала:

  • MariaDB – от това огледало вече няма нужда Jessie включва версия 10.0.6 в себе си което не ми се понрави много. След 5.5 мичетодб и mysql не са съвсем съвместими заради което към момента врътнах обратно към mysql 5.5.42 – той е по подразбиране в jessie
  • DotDeb – използвах го преди за php55 тук също е излишен защото Jessie идва с 5.6.7-1

След като разкарах излишните огледала и врътнах от MariaDB към Mysql apt-get dist-upgrade мина чисто, reboot и вече бях с Debian 8.0. Отворих си web server-а и за моя изненада работеше тук историята е дълга – с няколко думи Nginx-а ми е компилиран допълнително от source с допълнителни директиви. dpkg -l nginx-full 1.2 мдааа някой е забравил да си unhold-не пакетите. Unhold и upgrade всичко е по план nginx-а се счупи 😆 . Nginx-а работи обработва заявки и php-fpm процеса е up and runnign но php code не се изпълнява и не плюе грешки 🙄 ЛЮБИМОТО МИ.

След известно търсене на информация за промените открих следният пасаж

Fastcgi configuration issues ============================

nginx shipped a modified fastcgi_params, which declared SCRIPT_FILENAME fastcgi_param. This line has now been removed. From now on we are also shipping fastcgi.conf from the upstream repository, which includes a sane SCRIPT_FILENAME parameter value.

So, if you are using fastcgi_params, you can try switching to fastcgi.conf or manually set the relevant params.

Бинго. Промених виртуалните хостове да използват fastcgi.conf вместо да правя груби вмешателства и всичко запали. След това ударих един бърз diff за да видим разликата каква е между 2-та конфига


diff /etc/nginx/fastcgi_params /etc/nginx/fastcgi.conf
1a2
> fastcgi_param  SCRIPT_FILENAME    $document_root$fastcgi_script_name;

Което ми припомни че наливането на големи конфигурации във виртуаните хостове не е готина идея. Остава да си прекомпилирам отново Nginx-а с добавките които искам mod_sec + pagespeed но това може да почака. Далеч по важното е, че правилото ми се повтори ако нямаш огледа от 3-ти източници и кастъм изпълнения Debian не се чупи при dist-upgrade!

https://www.youtube.com/watch?v=gEQCny6zNF0