Mozilla огорчает

Последнее время складывается ощущение, что Mozilla Foundation сосредоточила свои усилия на уничтожении браузера Firefox.

И даже фигня, что какой-то альтернативно-одарённый решил изменить систему версий с классической вменяемой (первая цифра - движок, вторая - фичи, третяя - багфикс), на наглухо долбанутую (тупо новые циферки каждые пару месяцев), вызвав абсолютную неразбериху в системе плагинов (разработчики не могут отслеживать изменения API - плагины быстро отваливаются и долго ремонтируются). Кстати, именно с этого момента база пользователей Firefox стала драматически сокращаться.

И не так страшно, что они абсолютно просрали мобильный рынок своей косолапостью (и продолжают бушевать в посудной лавке).

Так вот куда более печальным событием стало решение кинуть своих Linux пользователей с поддержкой весьма и весьма популярной интернет-технологии Adobe Flash/Air.

Последнее особенно удручает, т.к. именно из Linux у этого браузера выросли ноги.  И расставание с этой платформой может стать основной причиной моего (и не только) с ним расставания. Согласитесь, не очень приятно под разными системами сидеть с разных браузеров.

Суть проблемы в том, что, как уже давно известно, Adobe решила дропнуть Flash плагин для Firefox формата NPAPI, выпуская только PPAPI версию оного.

В принципе, говно вопрос - если NPAPI имел ряд проблем (за что тоже спасибо MF), логично было со стороны Adobe отказаться от его поддержки в пользу PPAPI, используемого в Webkit и как следствие - на большей части браузеров на планете. Но главной печалью этой истории является то, что Mozilla наглухо отказывается реализовывать какую бы то ни было поддержку PPAPI, а следовательно Flash Player 11.2 - последняя версия флеша, которая будет работать в Firefox.

И они могут сколько угодно трендеть про всякие там глобальные замуты, и причины такого решения, но факт останется фактом - знатная часть юзеров не сегодня, так завтра тупо дропнут Firefox в пользу Google Chrome, лишенного этого порока (хотя обладающего рядом других, хоть и не столь существенных).

По совокупности действий, похоже Mozilla Foundation взяла основательный курс на свалку истории и судьба Firefox вероятно стремится к судьбе предшественника - Netscape.

А жаль.

Ububtu 12.10 и проблемы с cifs

Обновил свою убунту (ну не то чтобы совсем убунту - там Ubuntu+KDE SC), и вдруг мой NAS, который для совместимости с виндовой машиной и MAC OSX имеет шару SMB, отвалился.
Ох, как я "люблю" этих массовиков затейников, которые берутся в дистрибах "чинить" то, что работает...
В общем, поматюгался, посмотрел в инете, что эту болезнь не назовут в мою честь (она у многих), но ответов пока нет и взялся изучать вопрос самостоятельно.

В общем, оказалось, что в новом дистрибе старую утилиту smbfs заменили на cifs-utils, которая нифига не совместима со старой по синтаксису монтирования.

Раньше я монтировал ресурс такой строкой в /etc/fstab :

//192.168.1.5/Public/   /media/MEGAMI_Public    cifs    _netdev,auto,noperm,nocase,file_mode=0776,dir_mode=0776,user=USERNAME,password=PASSWORD,iocharset=utf-8    0       1

где _netdev - команда ОС, чтоб не пыталась монтировать ресурс до инициализации сети,
auto - чтоб само, noperm,nocase,file_mode/dir_mode - параметры системе, чтоб она не пыталась докапываться до сервера с unix'овскими замашками (без noperm ресурс подключится ro, без nocase не будет запрета на папку с одним и тем же именем но разным регистром, а без file_mode/dir_mode dolphin при каждом копировании на сервер будет выть, что у него не получается права поменять).

Из этой строки cifs-utils, как выяснилось, не понимает:
file_mode/dir_mode - но без них уже даёт системе правильные аргументы, так что dolphin не ругается,
iocharset - не знаю почему, но ругается
password - в новой утилите это просто pass

В общем итоге, строку пришлось заменить на:

//192.168.1.5/Public/   /media/MEGAMI_Public    cifs    _netdev,auto,noperm,nocase,user,user=USERNAME,pass=PASSWORD    0       1

С такой строчкой всё работает, как работало раньше. Собственно, чего и добивался.

UPD: Для OpenSuSE 12.3 (может и раньше, х.з.) всё ещё на шаг в сторону:
вместо user и pass надо вводить username и password целиком, иначе жалуется.

`Анонс идеи (с надеждой на содействие)

Столкнулся я давича с одной интересной проблемой. А именно - создание базы фотографий, в которой можно было бы нормально осуществлять поиск, которая была бы разбита на нужные мне разделы, причем так, чтобы одни и те же фотки могли быть видны из нескольких разных разделов одновременно. И чтоб с преферансом и куртизантками...

Состояние сервера

Так как сервер, над котором я эксперементирую достаточно древний, чтобы опасаться за его здоровье, возникла острая потребность наблюдать его состояние и условия работы.

Общее тестирование жёстких дисков с помощью утилиты smartctl, я рассмотрю чуть позже (в отдельной заметке), а тут остановимся на проверки условий работы.

За информацию о температурах системы и работе вентиляторов охлаждения в Linux отвечает утилита lm_sensors, а за температуру жёстких дисков. Так что первым делом надо их установить.

$sudo apt-get install hddtemp lm_sensors

или для OenSuSE:

#zypper install hddtemp sensors

Обратите внимание, что пакет lm_sensors в OpenSuSE зовётся просто sensors (по-началу меня это сбило с толку). Если hddtemp не окажется в репках OpenSuSE, пошарьте на software.opensuse.org - там всегда найдётся пара-тройка репок в которых они есть.

После установки стоит проверить работоспособность hddtemp вбив в терминале:

#hddtemp /dev/sda

С lm_sensors всё на шаг длиннее.

#sensors-detect

После этого lm_sensors будет сканировать подключённые устройства и вам многократно придётся жать "Enter".

По окончании процесса будет сформирован файл /etc/sysconfig/lm_sensors, а также будет предложено скопировать prog/init/lm_sensors.init в /etc/rc.d/init.d/lm_sensors - этого категорически делать нельзя. В вашем дистрибутиве уже есть этот файл, если вы его устанавливали из репок. Если собирали из сырцов - придётся править его в соответствии с особенностями вашего дистрибутива. Иначе, например в OpenSuSE он будет ругаться на line 39 в которой не хватает некоего /etc/init.d/function, а без него всё работать отказывается.

Следующим шагом необходимо добавить lm_sensors в загрузку. В OpenSuSE это делается через yast → System → System Services (Runlevel). Для других дистрибутивов нужно почитать специфику.

После этого по запросу

#sensors вам будет выдаваться таблица а ля:

adm1027-i2c-3-2e
Adapter: SMBus I801 adapter at c800
in0: +1.48 V (min = +0.00 V, max = +3.32 V)
Vcore: +1.50 V (min = +0.00 V, max = +2.99 V)
+3.3V: +3.34 V (min = +2.97 V, max = +3.63 V)
+5V: +5.05 V (min = +4.50 V, max = +5.50 V)
+12V: +11.92 V (min = +0.00 V, max = +15.94 V)
fan1: 3321 RPM (min = 0 RPM)
fan2: 0 RPM (min = 0 RPM)
fan3: 1058 RPM (min = 0 RPM)
fan4: 0 RPM (min = 0 RPM)
temp1: +46.8°C (low = -127.0°C, high = +127.0°C)
M/B Temp: +38.5°C (low = -127.0°C, high = +127.0°C)
temp3: +39.8°C (low = -127.0°C, high = +127.0°C)
cpu0_vid: +1.525 V

Вроде как всю нужную информацию мы теперь получить можем. Однако форма неудобоваримая и команд несколько. Поэтому попробуем сформировать нужные нам данные и записать всё в .bashrc.

Не мудрствуя лукаво, я притырил скрипт отсюда и слегка подправил его под свои дела:

test -s ~/.alias && . ~/.alias || true

function memdisp {

MEM=`free -mot | head -n 2 | tail -n 1`
COUNT=1
for ITEM in $MEM
do
if [ $COUNT -eq 2 ] ; then
printf " Total RAM:\t$ITEM Mb\n"
fi

if [ $COUNT -eq 3 ] ; then
printf " Used RAM:\t$ITEM Mb\n"

fi

if [ $COUNT -eq 4 ] ; then
printf " Free RAM:\t$ITEM Mb\n"
fi

COUNT=$[COUNT+1]
done

MEM=`free -mot | tail -n 2 | head -n 1`
COUNT=1
for ITEM in $MEM
do
if [ $COUNT -eq 2 ] ; then
printf " Total SWAP:\t$ITEM Mb\n"

fi

if [ $COUNT -eq 3 ] ; then
printf " Used SWAP:\t$ITEM Mb\n"

fi

if [ $COUNT -eq 4 ] ; then
printf " Free SWAP:\t$ITEM Mb\n"

fi

COUNT=$[COUNT+1]
done

}

UPTIME=`uptime`
D_UP=${UPTIME:2}

alias hi="
printf ' Hello \t`whoami`\n'
printf ' Today is:\t\t`date`\n'
printf ' Number of user login:\t\t`who | wc -l`\n'
printf ' uptime:\t$D_UP\n'
printf ' Sensors:\t`sensors -A`\n'
printf ' HDD1: \t`hddtemp -n /dev/sda`°C\n'
printf ' HDD2: \t`hddtemp -n /dev/sdb`°C\n'
memdisp
"

Теперь войдя в систему я просто пишу

#hi

и получаю в ответ сводку:

Hello root
Today is: Thu Aug 18 13:15:45 MSD 2011
Number of user login: 1
uptime: 3:15pm up 3:19, 1 user, load average: 0.00, 0.01, 0.05
Sensors: adm1027-i2c-3-2e
in0: +1.48 V (min = +0.00 V, max = +3.32 V)
Vcore: +1.47 V (min = +0.00 V, max = +2.99 V)
+3.3V: +3.35 V (min = +2.97 V, max = +3.63 V)
+5V: +5.06 V (min = +4.50 V, max = +5.50 V)
+12V: +11.84 V (min = +0.00 V, max = +15.94 V)
fan1: 3262 RPM (min = 0 RPM)
fan2: 0 RPM (min = 0 RPM)
fan3: 1056 RPM (min = 0 RPM)
fan4: 0 RPM (min = 0 RPM)
temp1: +47.8°C (low = -127.0°C, high = +127.0°C)
M/B Temp: +37.2°C (low = -127.0°C, high = +127.0°C)
temp3: +39.0°C (low = -127.0°C, high = +127.0°C)
cpu0_vid: +1.525 V
HDD1: 36°C
HDD2: 39°C
Total RAM: 495 Mb
Used RAM: 195 Mb
Free RAM: 300 Mb
Total SWAP: 2053 Mb
Used SWAP: 0 Mb
Free SWAP: 2053 Mb

Можно ещё причесать вывод Sensors, но пока руки не доходят ~_~.

В общем, то, что я хотел — я получил. Если кому пригодится — пользуйтесь :)

P.S. Вообще я считаю чрезвычайно странным, что утилиты по получению информации о состоянии железа не включены в ядро, не говоря уже про комплектацию дистрибутивов. Неужели никого не интересует в каком состоянии пребывает сервер?

Всякие там HDD ID

В связи с переездом на новый хард (обзавёлся "зелёным" WD на 2Тб) столкнулся с проблемой, которая раньше обходила меня стороной - с HDD ID.

Если кто не знает, некоторое время назад, стоило изменить разметку диска, как Linux терял свои разделы. Это было связано с тем, что разделы в fstab нумеровались по физическому положению на диске - т.е. sda1 - первый праймари раздел на первом диске, sda5 - первый расширенный раздел и т.д.

То есть стоило впихнуть перед sda5 ещё один раздел, как sda5 переезжал на sda6 и если на нём располагались жизненно важные структуры (типа /usr или /home) система грузиться отказывалась и приходилось грузиться с лайвсиди и править fstab и grub.

Так вот комьюнити решило исправить недостаток. Выявилось сразу несколько решений среди которых наибольшую популярность приобрели UUID и hdd ID.

UUID в первую очередь проталкивала Canonical в своём не безызвестном дистрибе Убунту. hdd ID нашёл прибежище, например, в моей SuSE.

Идея проста и на первый взгляд хороша - назначается каждому разделу уникальный ID, который не теряется при изменении таблицы разделов. Он представляет собой нечитаемое нагромождение буков и цифр, повторения среди которых быть просто не может.

Казалось бы - проблема решена.

Однако не всё так славно. ID привязан к жёсткому диску и при миграции раздела с одного жёсткого диска на другой, ID имеет свойство меняться.

Так и произошло у меня - GRUB выдал ERROR 17, я залез в fstab и обнаружил... уже упомянутые абсолютно не читаемые сочетания буков и цифр.

Возник вопрос, где взять оные для моих целей. Ответ выяснился довольно быстро, но не очевидно, что я в итоге и решил написать тут (как водится, чтоб самому не забыть).

Чтобы выяснить HDD ID нужно просто посмотреть что находится в папке /dev/disk/by-id
Так как этот вариант кодировки указывает на жёсткий диск прямо в названии, вы легко можете понять какой ID какому разделу принадлежит.

Чтобы выяснить UUID можно чисто теоретически заглянуть в /dev/disk/uuid однако это даст вам мало, т.к. бессистемное сочетание буков и цифр никак не скажет вам о своих корнях. Для того, чтобы выяснить UUID в сочетании с физическим расположением диска, можно воспользоваться командой blkid. Если написать её без аргументов (причём не важно из под рута или нет) она выдаст вам красивую таблицу соответствия.

Единственная беда - все эти id'шники надо вбить в fstab и, в моём случае, в меню grub. Не очень удобно хоть и очевидно.

Gallery2 и кириллица

История болезни

Есть такая дурная особенность веб-приложений и CMS написанных зарубежными авторами, а именно - отсутствие какого-либо респекта по отношению к чужим языкам в кодировках. В целом, Gallery2 построена вокруг UTF-8, что должно было в теории лишить её подобных недостатков. Однако, не тут то было.

После установки выяснилось, что в паре мест вместо русского текста наблюдаются кракозябры. Одно из них - список фотографий на боковой панели, второй - в сокращённом виде комментариев.

Попробовал погуглить, но решения своей проблемы не нашёл. Пришлось включать мозг :).
Итак, запустив firebug и разобрав страницу, я увидел функцию entitytruncate, которая замечательно подходила под оба описанных случая - и названия на боковой панели и сокращённые комментирии обрезаны, сиречь truncated.

Пошарив в папке галереи на предмет всяких обрезаний, нашёл следующее:

$find /usr/share/egroupware/gallery/|grep trunc
/usr/share/egroupware/gallery/gallery2/lib/smarty_plugins/modifier.entitytruncate.php
/usr/share/egroupware/gallery/gallery2/lib/smarty/plugins/modifier.truncate.php

Так как страничка под firebug'ом сослалась на entitytruncate, в него и заглянул.
И увидел там замечательные строки:

$string = GalleryUtilities::utf8ToUnicodeEntities($string);

с комментарием:

/*
* Convert multibyte characters to html entities and then get an entity-safe substring.
* Split the string exactly on the boundary. If there's no change, then we're done.
*/

который при переводе на понятный язык звучит, как "отрезаем ноги, чтобы член длинней казался".
И в дальнейшем все выводы преобразуются обрано строчкой типа

return GalleryUtilities::unicodeEntitiesToUtf8($piece);

Естественно, первым, что я попытался выяснить было "а накуа вообще переводить из utf-8 в старый юникод?"
И убрав все следы подобных переводов (первую строчку и в последующих убрав функцию

GalleryUtilities::unicodeEntitiesToUtf8() ).

Сохранив свою новую modifier.entitytruncate.php убедился, что решение работает.
Краказябры исчезли.

В принципе на этом можно было бы и остановиться, однако смутило одно - несмотря на указанное $breakWords=false обрезание происходит где попало, а в некоторых случаях на месте обрезки поперёк слова проявились символы �

Так как PHP я начал изучать относительно не давно, с ходу понять, что там не работает (с учётом того, что текст простенькой функции обрезания вызывает кучу других функций) у меня не получилось.

Однако перед этим чисто из праздного интереса я заглянул в файлик modifier.truncate.php и обнаружил там ту же функцию обрезки текста, только написанную на более человеческом языке и вполне мне понятную.

В общем, не долго думая, я переименовал modifier.truncate.php в modifier.entitytruncate.php, изменил в объявлении

function smarty_modifier_truncate($string, $length = 80, $etc = '...',
$break_words = false, $middle = false)

на

function smarty_modifier_entitytruncate($string, $length, $etc = '...',
$break_words = false, $middle = false)

и всё заработало на этот раз так, как полагается.

Коротко решение

1. Находим в каталоге галереи modifier.entitytruncate.php и modifier.truncate.php и заменяем второй на первый.

В моём случае это:

$cp gallery2/lib/smarty/plugins/modifier.truncate.php gallery2/lib/smarty_plugins/modifier.entitytruncate.php

2. Открываем полученный modifier.entitytruncate.php в любимом текстовом редакторе.

$vim gallery2/lib/smarty_plugins/modifier.entitytruncate.php

3. Меняем строку

function smarty_modifier_truncate($string, $length = 80, $etc = '...',
$break_words = false, $middle = false)

на

function smarty_modifier_entitytruncate($string, $length, $etc = '...',
$break_words = false, $middle = false)

4. Сохраняем файл и перезапускаем сервер:

#service apache2 restart

Дело сделано.

Массовый откат пакетов в Ubuntu

Эксперименты с весьма стабильными дистрибутивами редко приводят к чему-то хорошему. Примерно так произошло у меня с Ubuntu, на которую я решил натянуть новенький GNOME3. Всё естественно накрылось медным тазом, а поковырявшись с этим и придя к выводу, что тема ещё совсем сырая, я оказался перед вопросом "как сделать всё как было?".

Так как никаких резервных образов свеженастроенной в тестовых целях Ubuntu 11.4 у меня не было, а залез я в дебри не по самые ноздри, решил, что достаточно просто откатиться до версии GNOME 2 и всё само собой станет на свои места.

Только вот одна беда - как вообще откатить массово версии пакетов в Ubuntu? Покопавшись во встроенных функциях apt-get и synaptic, я уже было отчаялся (боже, как всё просто с YaST). Однако натолкнулся на утилиту ppa-purge подходящую по описанию на то что мне нужно.

И, как не странно, помогло.
Утилита делает примерно то, чего от нее ждут - откатывает версии пакетов с PPA на те, что с официальных репок. Работает она следующим образом:

В консоли набираем:
$ sudo ppa-purge ppa:/
Вместо и подставляем соответственно элементы адреса PPA репозитория (то, что после ppa.lounchpad.net). Посмотреть этот адрес можно в /etc/apt/sources.list или может быть в /etc/apt/sources.list.d/.
В моём случае строка выглядела так:
$ sudo ppa-purge ppa:gnome3-team/gnome3
После этого пришлось согласиться на невосполнимые патери в виде пакетов, завязанных на gnome 3 и дело в шляпе.