FlatPak, Snap, AppImage и прочие современные веяния

В борьбе с "адом зависимостей" и разношёрстностью дистрибутивов Linux, родились системы, которые призваны унифицировать подход к ПО сквозь все дистрибутивы. Их идея в одном - собрать пакет вместе с необходимыми библиотеками в одной программной капсуле. 

Однако, этот подход имеет два вполне известных изъяна:

- Проблема с безопасностью за счёт использования разных версий библиотек в программных "капсулах" и то, что часть из них может быть устаревшими;

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

Безопасность.

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

Минусы этого подхода также вполне очевидны - пользовательская папка таки доступна, ряд операций программа осуществлять обязана по своему функционалу и общей точкой отказа является подсистема (сам Snap, Flatpak и т.п.). То есть при использовании сильно устаревшей версии библиотеки в составе программы, дыра в безопасности таки будет. 

В то же время это вызывает ряд неудобств пользователям - если у пользователя несколько жёстких дисков и, скажем, дистрибутив монтирует их в media, то доступа к ним у программы просто не будет. Я с таким сталкивался на своём ПК, где 5 жёстких дисков и три операционные системы, две из которых из семейства Linux, а папка home преимущественно состоит из символьных ссылок на другой жёсткий диск (чтобы обеспечить прозрачность работы в разных версиях linux, не дублируя пользовательские библиотеки). В итоге после установки Snap версии Telegram Desktop, я не мог закинуть картинки из папки, т.к. программа не имела доступа через симвользую ссылку на другой диск. 

Объёмы данных

Куда более своеобразной является проблема с объёмом данных, который генерируют подобные системы. На картинке выше показана структура папки var, в которой установлены flatpak и snap. Как видно, один из них занимает более 30 Гб, второй более 7 Гб. Стоит напомнить, что полный комплект OS Linux с KDE, LibreOffice, VLC, Blender, Firefox, Chromium, Vivaldi, Skype, Telegram, Inkscape, Krita, Steam, Kdenlive, OBS, Kmail, Nomacs вполне нормально умещаются на 20Гб разделе жёсткого диска, не выползая за него, даже при том, что поддерживается 3 версии ядра. 

При этом, вот в тех 30+ Гб Flatpak содержится всего несколько небольших программ, которые без фарша весят от силы 0,5 Гб. Всё остальное - это по сути дублированные версии всей операционной системы за исключением ядра. "Рациональность" - это не про них. 

Есть, правда и вариант решения этой проблемы - это современные файловые системы типа BTRFS с работающей дедуплекацией данных. В этом случае система уничтожит знатную часть дублированной информации и указанный фарш изрядно похудеет. 

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

Также вопросы вызывают сами файловые системы, которые поддерживают дедупликацию. По хорошему из относительно стабильных их всего две - уже упомянутая BTRFS и ZFS. Про первую я уже как-то писал - она вызывает очень много вопросов, как только случается сбой. При этом если у вас была включена дедуплекация - вы никогда не восстановите файлы с поломанной файловой системы (будет каша из кусочков файлов в произвольном порядке, которую никто не разгребёт). А что касается ZFS, то при кажущейся большей надёжности, система во-первых супер-прожёрлива до оперативной памяти (готовы сделать файловую систему потребителем №1 в вашей операционке?) и её качества (настоятельно рекомендуют использовать ECC-корректируему память, т.к. множество небезопасных операций происходит именно в оперативке. А во-вторых она также доставляет трудности при восстановлении данных, широко распространённых открытых инструментов для чего просто не существует.

В итоге, единственным инструментом из всех имеющихся, которым я пользуюсь - остался AppImage. Он хоть и имеет перечисленные недостатки, позволяет сразу оценить масштаб трагедии - сколько будет весить программа по совокупности (а не то, что вам пишут что весит она, скажем 500 Мб, а к ней прилетает база в 11Гб) и позволяет решить вопрос ПО, которое выбилось из цикла поддержки репозиториями вашего дистрибутива нужных версий библиотек.

Как-то так. 

Mac OS X и древние привычки (клепать файлы .DS_Store)

 В отличие от большинства современных операционных систем, OSX Finder хранит настройки отображения папок в создаваемых файлах вида .DS_Store, которые изрядно так бесят, когда взаимодействуешь с другими системами. Чтобы хотя бы заставить систему не писать эти файлы на сетевых хранилищах и USB флешках, необходимо ввести в консоли следующие команды:

defaults write com.apple.desktopservices DSDontWriteNetworkStores -bool true

defaults write com.apple.desktopservices DSDontWriteUSBStores -bool true 

 После чего необходимо выйти и зайти в профиль. Каждый раз забываю эти команды, так что оставлю это здесь на память.

Битые картинки и как их выявить

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

Переключатель звуковых каналов в Linux для ленивых

Будучи любителем послушать музыку с комфортом, соединил свой компьютер с ресивером аудиосистемы с помощью TosLink/ S/PDIF и столкнулся с неприятной особенностью моей новой материнки. Так, она не умеет одновременно работать с аналоговым и цифровым выходом, так что старый трюк с добавлением виртуального устройства со вторым типом выхода не прокатил - второй выход оказался немым. В итоге, чтобы переключиться на S/PDIF, мне нужно каждый раз лезть в настройки PulseAudio и переключать выход на нужный в текущий момент (колонки/наушники у компа или аудиосистема по S/PDIF). Но, лень двигатель прогресса - меня этак картина быстро перестала устраивать и я озаботился переключателем, позволяющим быстро изменять режим звуковой карты. Поделюсь тут этим фокусом, может кому пригодится.

KXStudio и S/PDIF

Столкнулся с дурацкой особенностью связки ALSA+JACK Audio Toolkit. А именно, что по умолчанию он отказывается выводить звук через S/PDIF (что оптический, что коаксиальный). Долго плясал с бубном, пока не обнаружил указание на то, что в alsa цифровые выходы по умолчанию заглушены, т.к. у части звуковых карт нет поддержки одновременного вывода по digital/analog каналам. Так вот этот момент накладывается на то, что для перечисления устройств, Cadence использует команду aplay -l вместо aplay -L и получает упрощённый список а ля hw0:analog hw0:digital nvidia hdmi0 и т.д.  В общем, не показывается в этом списке, что часть каналов заглушена и запускается двумя параллельными триггерами. 

Решается это дело довольно просто - в Cadence нужно остановить JACK Server, затем запустить alsamixer, например в варианте alsamixergui (если не установлен - $sudo apt install alsamixergui), после чего видим весь список устройств и смотрим на значки сверху, что там заглушено - находим нужный интерфейс, включаем и вуаля - всё начинает работать. 

В заключении, хочется сказать, что для записи аудио - jack шикарная штука, а программы проекта KXStudio - великолепны, но вот для повседневной жизни это геморрой тот ещё - чтобы элементарно переключить канал входа или выхода, нужно зайти в Cadence → Configure → ALSA Driver → сменить вход/выход → JACK Stop → JACK Start → JACK Bridges: PulseAudio Start, иначе те же KDE не поймут, где у вас там звук и как он должен работать. 

В случае прямой работы ALSA → PulseAudio, KDE позволяет управлять звуковыми потоками очень гибко, вплоть до перебрасывания приложений между различными средствами вывода (бывает удобно, когда нужно, чтобы что-то шло через наушники, а что-то на громкую. 

Проблемы с тёмными темами и GTK2/MONO программами

Как любитель тёмных тем, время от времени сталкиваюсь с проблемами в некоторых криво написанных приложениях. Это относится, например, ко всему, что написано на .NET/Mono. К счастью, не много нормальных приложений написано на этой поделке от M$, но встречается. Так, например, произошло с замечательной лёгкой программой для математических вычислений SMath Studio (см. на картинке).

Проблемы с разрешениями для Transmission daemon и не только

Продолжаю настраивать свой домашний NAS и сгребать грабли.
Настроив SAMBA и получив весьма приличный результат по скорости копирования (>90МиБ/с), решил поставить и настроить Transmission daemon - чтоб NAS спокойно качал торренты, а пользователи могли ставить на закачку файлы через Transmission remote GUI, работающий, как с компов, так и с мобилок.

В общем, настройка Transmission daemon - не бог весть какая сложность - редактируешь себе /etc/ transmission daemon/settings.json , добавляешь нужных пользователей в группу transmission (в случае с Debian - это debian transmission), даёшь разрешения на нужные папки этому самому пользователю от которого работает transmission daemon (его можно проверить в конфиге /etc/init.d/transmission-daemon в разделе USER и, казалось бы, дело в шляпе.

Не тут то было. Всё сделал - при попытке скачать torrent получаю ошибку Permission denied.
Лезу, смотрю, что там с папкой:

$ls -l /share/HDB/Download 

Вижу ответ: drwxrwxrwx+ и по невнимательности своей думаю - ну всё ок вроде. Даю права владельца пользователю transmission - начало качать.
Вот только нафига нужны все файлы в одной свалке в "Download"? Не нужны - нужно перемешать в папки Video, Music и т.д. А там - такая же засада.

В общем, долго я мучился, пока не обнаружил тот самый идиотский "+" на конце. Оказывается, жолбаный QNAP, в чьём ведении до этого был жёсткий диск, умудрился проставить всем папкам и файлам ACL разрешения. А они ведь такая зараза, что перекрывают обычные nix'овые. Там и пользователи конкретные могут быть вписаны, и маски заданы.

В общем, снёс нахрен все ACL'ы с этих папок командой:

#setfacl -Rb /share/

Проблема разрешилась - transmission пишет во все нужные папки - жизнь удалась.

BTRFS is not so better

 Уже старая, вовремя не запощенная запись по BTRFS, родившаяся, как комент на хабрахабре про то, какая хорошая и перспективная файловая система этот бэтэрэфэс.
Оставлю тут в качестве предостережения. Уж поверьте, я с этой системой достаточно намаялся, чтобы предпочитать ей кривоватую связку ext4+LVM, для реализации некоторого функционала, не доступного в старых файловых системах.

Касательно btrfs, может у Facebook'а с его армией программистов низкого уровня и живёт это как-то, но мне кажутся полными камикадзами те, кто пытаются тащить в продакшн файловую систему к которой физически не существует полноценного инструментария для восстановления, с единственным аргументом «да она практически не ломается»… Ломается и ещё как ломается.

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

И коллектив разработчиков из «гениев», которые лепят ошибки, делают неполноценные фичи, ломающие работающий функционал и потом отмазывающиеся ответами типа «а ну это у нас в версии такой-то баг был, что у вас всё слетело кхерям, но уже исправили» или «ах, а мы и не знали, что новая фича ломает старую». И ладно бы эти косяки попадали только в unstable — в обычном ubuntu со стабильными ядрами такое возникает регулярно — просто потому, что, оказывается, вот таким вот специфическим функционалом файловой системы не многие пользуются и не отловили.

Отсутствие документации на функции и вообще невнятность работы некоторых функций тоже доставляют. До ядра 3.17 при исполнении btrfs check --init-csum-tree с описанием мол «перестраивает дерево чексумм», на деле просто сносило к чёрту дерево чексум и делало файловую систему не читаемой. Потом кто-то в мэйллисте на это тыкнул с вопросом «а нахрена это надо?» И получил ответ типа «а ну не нужно ей пользоваться она ещё не дописана, чтоб реально работала». А добавили так, просто, как кнопку «харакири», только под надписью «реанимация».

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

Ubuntu Server 16.04 LTS Застряла в перезагрузке

Давича решил соорудить из дешёвого ПК, маленький домашний сервер и столкнулся с проблемой - сразу после установки Ubuntu Server 16.04 впал в цикл бесконечной перезагрузки.

Причём вход в Recovery происходил нормально и если врубить пункт продолжения загрузки - всё вроде как грузилось. Изучение journalctl дало единственную наводку - ошибка с radeon drm.
Я так слегка прифигел, от того, что на серверной оси пытается грузиться графика, решил посмотреть, что там в целях загрузки у GRUB стоит и обнаружил:

$sudo systemctl get-default

graphical.target 

Исправил это дело на multiuser.target:

$sudo systemctl set-default multiuser.target

Перезагрузился и... нифига - всё так же.
Снова попал в систему через рекавери, и начал гуглить.
Наткнулся на другую проблему на Ask Ubuntu.
Решил проверить настройки GRUB и обнаружил строку:

GRUB_CMDLINE_LINUX_DEFAULT=""

Заполнив пространство между "" параметром "nomodeset" и обновив груб ($sudo update-grub) получил реальную загрузку в текстовом режиме и проблема решилась!

В общем, чтоб не забыть решение - оставлю тут.

Проблемы поиска

Регулярно задаюсь вопросом "почему разработчики систем поиска по компьютеру - такие пидорасы?".  Ведь нет ни одной вменяемой реализации этих систем - на MacOSX вечно задалбывает Spotlight, в Linux их море - и Beegle в GNOME и Nepomuk в KDE и Mediascanner в Ubuntu и другие, винда тоже старается не отставать в попытках проиндексировать все потроха ваших жёстких дисков.

Повесть о Linux и графическом интерфейсе (NVIDIA edition).

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

Очередные "новшества" Firefox

С обновления 34.1 и далее в 35, разработчики из Mozilla решили заменить строку поиска Firefox. Честно говоря, это строка - это одна из последних фич Firefox, которая меня удерживает в этом многострадальном браузере (все остальные Mozilla позиционно повыпиливала в предыдущих релизах). Ну не удобно мне искать всё через "поиск по умолчанию".  Благо в этот раз изменения можно откатить.

MAC OSX + BOOTCAMP и почему это плохо.

Всем, конечно же, известно, что есть такая фича в Mac OS X, как BootCamp, который позволят поставить на Мак Винду. Но вот так уж повелось, что не все понимают, как эта "фича" функционирует, и уж тем более не знают, какие проблемы это может вызвать.

Внезапные проблемы при обновлении MacOSX 10.7 до 10.8

Давича, почитав отчеты о том, что ёппл допилила наконец свою последнюю реинкарнацию MacOSX решил-таки обновить iMac.
Казалось бы, где тут могут возникнуть проблемы? А возникли.

После перезагрузки в установщик, макось напрочь отказалась устанавливаться в какой бы то ни было раздел на диске.  Выдавалось сообщение а ля "невозможно загрузить с этого диска", а при повторной попытке с выбором конкретно раздела с макосью - "на диске установлена защита".

Что за защита? В чём проблема? Мак ось на то она и макось, чтобы ничего никому не сказать об этом. Просто не могу и всё тут. Аналогичную сообразительность и дружелюбность проявляет и большая часть пользователей маков. Самым действенным советом, найденным в интернетах было - снести всё нахер и переустановить с ноля.
Круто, спасибо, не надо.

В общем, долгими поисками в абсолютно другом направлении (а именно - об установке Windows 8 в GPT раздел без костылей в виде bootcamp/bios emmulation/fuckyourself), я нашёл в кэше гугла (пользователь, который её писал забыл проплатить хостинг и теперь его блог не доступен), я обнаружил, что есть один косяк, который можно поймать при разделе жесткого диска с MacOSX. А именно - то, что после каждого раздела HFS+ должно быть не менее 128Mb не размеченного пространства.

Именно это и оказалось причиной столь грозного отказа макоси устанавливаться. После высвобождения этих злосчастных 128Мб макось без вопросов приняла обновление.


P.S. Если кто сталкивается с подобной проблемой, у нее может быть три причины:
- проблемы с правами доступа - просто запустите disk manager и восстановите привилегии
- диск шифрован и не тем пользователем, который собрался обновлять систему - нужно снять защиту диска в настройках безопасности
- собственно указанное отсутствие необходимых 128 Мб (снести их может например bootcamp при определенных обстоятельствах или любая сторонняя утилита разметки типа Paragon).

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

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