136 changed files with 5515 additions and 0 deletions
@ -0,0 +1,35 @@
|
||||
--- |
||||
title: Краткие впечатления от установки ArchLinux 0.7.1 (Noodle) |
||||
author: hatred |
||||
--- |
||||
|
||||
Коллега на работе загорелся мыслью поставить себе лялих на свой ноут, и начал всех мучать вопросами что же ему ставить... |
||||
|
||||
К тому времени на просторах тырнета я случайно набрел на дистрибутив Arch Linux, но опробовать его как-то руки недоходили: было жалко сносить уже давно поставленный Slackware Linux 9.1 дополненный самодельными скриптами для поддержки репозитариев CRUX и обновленный до хрен знает какой версии :) |
||||
|
||||
Короче, системка работала и не жужжала... поэтому я сразу прикинул, что коллега сможет стать так сказать, подопытным кроликом в части освоения Arch. |
||||
|
||||
--- |
||||
|
||||
Началось с того что я выкачал базовый образ размером в 150 метром с официального сайта, дома подвинул на старом 8гиговом винте FAT раздел в освободившееся место я собствнно поставил базовую установку, которая надо сказать не вызвала затруднений, особенно если для начала посетить сайт дистрибутива и поискать в Wiki статьи по слову install ;) Там есть хороший толмут на эту тему, плюс про базовые настройки. |
||||
|
||||
После установки базового образа имеем аскетичную систему с только самыми жизненно-необходимыми утилитами, я сразу поднял GPRS (оператор MTS), и первой командой после логина под рутом было: ``pacman -Sy`` синхронизировал базу данных пакетов, после чего началась череда выкачиваний пакетов и их установка в систему, для просмотра пакетов которые возможны для установки: ``pacman -Sl`` а установка: ``pacman -S`` |
||||
|
||||
Собственно говоря, pacman - утилита для управления бинарными пакетами в системе ArchLinux, поддерживает репозитарии удаленные, синхронизация, поддерживает зависимости, удобно :) Помимо бинарных пакетов есть система ABS - Arch Build System, опять таки, синхронизируем дерево с CVS, просто запускаем команду abs от root при подключенном интернете, далее идем в ``/var/abs/`` и смотрим, что у нас там есть, а есть там описания сборки пакетов, формат не сложный понять можно быстро самому, замечу одно, для самостоятельнос собранных пакетов рекомендуется из помещать в ``/var/abs/local/`` и после создания запостить в комьюнити, что бы вашими трудами имогли насладиться все жедающие (пакет туда попадет не сразу, а после ревизии) |
||||
|
||||
По запросу ``pacman -S xorg`` поставилось все что необходимо для запуска иксов, надо сказать что ставятся иксы Xorg 11R7, шустрые надо сказать :). |
||||
Установка дров для nvidia тоже не составила труда, угадайте какой командой? :) Правильно: ``pacman -S nvidia`` |
||||
|
||||
все остальное оборудование стартануло из коробки. Кстати, насчет оборудования, комьюнити Arch Linux написало утилиту ``hwd``, установите ее, хорошее дополнение таким утилитам как ``lspci``, ``scanpci``, ``scanusb`` |
||||
|
||||
Основные настроки системы делаются через файл ``/etc/rc.conf``, тут можно указать какие демоны и в какой последовательности будут запускаться, локаль, сетевые настройки, сетевые настройки поддерживают профили, что удобно если вы работаете в разных сетях, и особенно если там статические IP, подробнее о профилях смотрите в документации. Тут задается часовой пояс. Для остальных конфигов выделено место в ``/etc/conf.d/`` допустим если бутовый скрипт конфигурируется, и при этои является опциональным, т.е. не обязательно будет стоять в системе, то его конфиг помещается сюда. Надо сказать что никаких гуевых конфигураторов нет, все делается редактированием конфигурационных файлов, что в купе с продуманной организацией последних достаточно удобно и не утомительно. |
||||
|
||||
Еще могу добавить, что обновления пакетов довольно динамичный процесс. Обновления довольно регулярные. Про все ошибки рекомендую сообщать в BagTrack систему на [](http://archlinux.org), исправляются тоже довольно оперативно. Кроме того там же советую пошерстить Wiki. |
||||
|
||||
И вот уже полет более трех месяцев, система нареканий не вызывает, все довольно вкусно и замечательно, тут задался мыслью переделывать на x86_64, но этим буду заниматься после сдачи диплома. (кстати, уже сделал вот только написать как-то руки не доходят) |
||||
|
||||
За время пользования столкнулся с проблемой что в системе ABS нельзя вытягивать сырцы посредством rsync протокола, а такой нужен допустим что бы словари с mova.org для dict сервера стянуть. Ну чтож, тикет обрабатывался довольно долго как малоприоритетная задача, пока написал свой патч, работает, запостил же его на трекенговую систему. |
||||
|
||||
За время пользования родилось некоторое количество самосборных пакетов, которые будут выложены в скором времени. |
||||
|
||||
(c) Alexander Drozdoff (aka Hatred), Vladivostok, 2006 |
||||
@ -0,0 +1,89 @@
|
||||
--- |
||||
title: ArchLinux, nForce4: настройка сенсоров |
||||
tags: archlinux, hardware |
||||
--- |
||||
|
||||
- Делаем раз: ``pacman -Sy lm_sensors`` |
||||
- Редактируем `/etc/rc.conf`, в загружаемые модули добавляем (MODULES): ``i2c-nforce2 i2c-isa eeprom it87`` |
||||
- В `/etc/rc.local` добавляем строчку ``sensors -s`` |
||||
- Открываем `/etc/modprobe.conf`, добавляем: |
||||
|
||||
# I2C module options |
||||
alias char-major-89 i2c-dev |
||||
|
||||
--- |
||||
|
||||
Сохраняем патч ниже в файл `nforce4-sensors.diff` |
||||
|
||||
--- sensors.conf.orig 2005-10-03 03:38:49.000000000 +1100 |
||||
+++ sensors.conf 2006-06-18 23:13:52.000000000 +1100 |
||||
@@ -1504,7 +1504,7 @@ |
||||
# Voltage monitors as advised in the It8705 data sheet |
||||
- label in0 "VCore 1" |
||||
+ label in0 "VCore" |
||||
label in1 "VCore 2" |
||||
label in2 "+3.3V" |
||||
label in3 "+5V" |
||||
@@ -1517,6 +1517,11 @@ |
||||
# vid is not monitored by IT8705F |
||||
# comment out if you have IT8712 |
||||
ignore vid |
||||
+ ignore in1 |
||||
+ ignore in5 |
||||
+ ignore in6 |
||||
+ ignore in7 |
||||
+ ignore in8 |
||||
# Incubus Saturnus reports that the IT87 chip on Asus A7V8X-X seems |
||||
# to report the VCORE voltage approximately 0.05V higher than the board's |
||||
@@ -1524,10 +1529,11 @@ |
||||
# the next line should bring the readings in line with the BIOS' ones in |
||||
# this case. |
||||
# compute in0 -0.05+@ , @+0.05 |
||||
+compute in0 0.03+@ , @-0.03 |
||||
# If 3.3V reads 2X too high (Soyo Dragon and Asus A7V8X-X, for example), |
||||
# comment out following line. |
||||
- compute in2 2*@ , @/2 |
||||
+ #compute in2 2*@ , @/2 |
||||
# |
||||
compute in3 ((6.8/10)+1)*@ , @/((6.8/10)+1) |
||||
compute in4 ((30/10) +1)*@ , @/((30/10) +1) |
||||
@@ -1560,6 +1566,8 @@ |
||||
set in0_min 1.5 * 0.95 |
||||
set in0_max 1.5 * 1.05 |
||||
+ #set in0_min 1.2 |
||||
+ #set in0_max 1.8 |
||||
set in1_min 2.4 |
||||
set in1_max 2.6 |
||||
set in2_min 3.3 * 0.95 |
||||
@@ -1591,12 +1599,14 @@ |
||||
# (see ignore statement right below). |
||||
label temp1 "M/B Temp" |
||||
- set temp1_over 40 |
||||
+ #set temp1_over 40 |
||||
+ set temp1_over 45 |
||||
set temp1_low 15 |
||||
label temp2 "CPU Temp" |
||||
- set temp2_over 45 |
||||
+ #set temp2_over 45 |
||||
+ set temp2_over 50 |
||||
set temp2_low 15 |
||||
-# ignore temp3 |
||||
+ ignore temp3 |
||||
label temp3 "Temp3" |
||||
set temp3_over 45 |
||||
set temp3_low 15 |
||||
@@ -1618,6 +1628,9 @@ |
||||
set fan2_min 3000 |
||||
# ignore fan3 |
||||
set fan3_min 3000 |
||||
+ label fan1 "CPU fan" |
||||
+ label fan2 "CHA fan" |
||||
+ label fan3 "CHIP fan" |
||||
# The following is for the Inside Technologies 786LCD which uses either a |
||||
# IT8705F or a SIS950 for monitoring with the SIS630. |
||||
|
||||
Помещаем его в каталог `/etc` и делаем ``patch -p0`` |
||||
|
||||
Вызываем sensors и любуемся. |
||||
|
||||
(c) Hatred, 2006 |
||||
@ -0,0 +1,132 @@
|
||||
--- |
||||
title: UTF8 локаль в ArchLinux |
||||
tags: archlinux, unicode |
||||
--- |
||||
|
||||
Дизель выложил в свое время замечательную [ссылочку](http://linuxdv.org/forum/viewtopic.php?id=105) на форуме по поднятию UTF8 локали в Arch Linux |
||||
|
||||
Здесь я хочу что бы все желающие выдавали свои дополнения, оформенные в виде статьи. |
||||
|
||||
Итак, положим начало... |
||||
|
||||
--- |
||||
|
||||
Имена файлов |
||||
------------- |
||||
|
||||
На старой koi8-r системе было довольно приличное количество файлов в русскими именами, естественно в кодировке koi8-r. Что делать, в UTF локали с такими именами файлов работать несподручно... |
||||
|
||||
На решение проблемы навел запуск такой команды: |
||||
|
||||
LANG=ru_RU.KOI8-R ls | iconv -f koi8-r |
||||
|
||||
Эта команда вывела список имен файлов с русскими именами как и положено, русскими буковками. Так родился скрипт: |
||||
|
||||
#!/bin/bash |
||||
|
||||
# |
||||
# Recode all file names in given codepage to UTF8 |
||||
# on UTF8 system |
||||
# |
||||
|
||||
CODE_FROM="KOI8-R" |
||||
recursive=0 |
||||
scan_only=0 |
||||
|
||||
function parse_cmd_line() |
||||
{ |
||||
prev_arg="" |
||||
need_next=0 |
||||
for i in "$@" |
||||
do |
||||
if [ $need_next -eq 0 ]; then |
||||
case $i in |
||||
"-f") |
||||
prev_arg="-f" |
||||
need_next=1 |
||||
;; |
||||
"-r") |
||||
recursive=1 |
||||
;; |
||||
"-s") |
||||
scan_only=1 |
||||
;; |
||||
esac |
||||
else |
||||
case $prev_arg in |
||||
"-f") |
||||
CODE_FROM=`echo $i | tr '[:lower:]' '[:upper:]'` |
||||
;; |
||||
esac |
||||
prev_arg="" |
||||
need_next=0 |
||||
fi |
||||
done |
||||
} |
||||
|
||||
function recode_file() |
||||
{ |
||||
|
||||
old_name="$@" |
||||
new_name=`echo $@ | iconv -f $CODE_FROM` |
||||
stat1=$? |
||||
mid_name=`echo $@ | iconv -f UTF8 2>/dev/null` |
||||
stat2=$? |
||||
|
||||
if [ x"$old_name" != x"$new_name" -a $stat1 -eq 0 -a x"$mid_name" != x"$old_name" ]; then |
||||
if [ $scan_only -eq 0 ]; then |
||||
echo "Recode: $old_name -> $new_name" |
||||
mv "$old_name" "$new_name" |
||||
else |
||||
echo `pwd`"$@" |
||||
fi |
||||
fi |
||||
} |
||||
|
||||
parse_cmd_line $@ |
||||
|
||||
oldIFS=$IFS |
||||
IFS=$'\n' |
||||
files=`ls -1 --color=none` |
||||
for i in $files |
||||
do |
||||
if [ -d "$i" ]; then |
||||
if [ $recursive -eq 1 ]; then |
||||
name=`basename $0` |
||||
if [ `dirname $0` == "." ]; then |
||||
prefix=`pwd` |
||||
else |
||||
prefix=`dirname $0` |
||||
fi |
||||
cd "$i" |
||||
|
||||
$prefix/$name "$@" |
||||
|
||||
cd .. |
||||
fi |
||||
fi |
||||
|
||||
recode_file "$i" |
||||
done |
||||
|
||||
Запускам сей скрипт из директории содержимое которой нужно привести к виду UTF8: |
||||
|
||||
recodedir |
||||
|
||||
Скрипт понимает ключи: |
||||
|
||||
* **-r** говорит что перебрать все каталоги рекурсивно, начиная с текущего |
||||
* **-s** просканирует каталоги и выдаст список файлов которые нужно изменять |
||||
* **-f <кодировка>** задает кодировку из которой перекодировать, по умолчанию **KOI8-R** |
||||
|
||||
Кроме того, можно использовать готовую утилиту "convmv" из репозитория "extra". Умеет она намного больше, чем вышеописанный скрипт, но требует установленный perl в системе. |
||||
|
||||
Midnight Commander |
||||
------------------- |
||||
|
||||
Есть два вариант, mc-utf8 из репозитария **community** либо вот этот образец: [http://pupykins.googlepages.com/mc.html](http://pupykins.googlepages.com/mc.html) |
||||
|
||||
Автор mc-cru и автор порта в community - суть один человек, имя ему Сергей Пупыкин (надеюсь правильно написал фамилию) в том виде в котором идет mc-cru очень нелицеприятный. Что бы привести его в чувство, смержил utf8 патч с той версии что в репозитарии, плюс сделал пееркодировку в редакторе (но тут кроется бага... страшная, которую пока лень решать, при перекодировке в редакторе не работает поиск и замена). |
||||
|
||||
Итак, по этой ссылке можно скачать правило для сборки для makepkg и [патч](mc-cru.tar.gz) |
||||
|
||||
@ -0,0 +1,37 @@
|
||||
--- |
||||
title: Создание PXE загрузчика на любом носителе |
||||
tags: hardware, pxe, network |
||||
--- |
||||
|
||||
Когда нет под рукой сетевой платы с загрузчиком PXE или нужно загрузиться по сети, а в BIOS не предусмотренно такой возможности на помощь приходит проект [gPXE](http://etherboot.org). |
||||
|
||||
gPXE - это open source реализация сетевого загрузчика поддерживающая большое количество сетевых плат, без необходимости размещения загрузчика в ПЗУ. Т.е. для сетевой загрузки нам потребуется сетевая плата, дискета(USB flash, CD диск и т.п.) и образ загрузчика с сайта [автоматического создания](http://rom-o-matic.net/) образов. Для любителей сбора образов из исходников смотреть [тут](http://kernel.org/pub/software/utils/boot/gpxe/). |
||||
|
||||
!!! По умолчанию подключаются все известные модели сетевых плат, поэтому для уменьшения размера образа можно выбрать только используемую(мые) модели |
||||
|
||||
Создание PXE загрузочной дискеты |
||||
--------------------------------- |
||||
|
||||
Загрузить образ с сайта [автоматического создания](http://rom-o-matic.net/) образов с расширением `*.dsk*` или собрать из исходного кода командой ``make bin/gpxe.dsk`` |
||||
|
||||
Записать образ на дискету ``dd if=bin/gpxe.dsk of=/dev/fd0`` или ``cat bin/gpxe.dsk > /dev/fd0`` |
||||
|
||||
Создание PXE загрузочного диска |
||||
-------------------------------- |
||||
|
||||
Загрузить образ с сайта [автоматического создания](http://rom-o-matic.net/) образов с расширением `*.iso*` или собрать из исходного кода командой ``make bin/gpxe.iso`` |
||||
|
||||
Записать образ на диск ``dd if=bin/gpxe.iso of=/dev/cdrom`` или воспользоваться программой записи дисков. |
||||
|
||||
Создание PXE загрузочной флешки |
||||
-------------------------------- |
||||
|
||||
Загрузить образ с сайта [автоматического создания](http://rom-o-matic.net/) образов с расширением `*.usb` или собрать из исходного кода командой ``make bin/gpxe.usb`` |
||||
|
||||
Записать образ на флешку ``dd if=bin/gpxe.usb of=/dev/sdX`` |
||||
|
||||
Вместо /dev/sdX необходимо указать флешку и главное не спутать с жестким диском. :-) |
||||
|
||||
!!! Путь bin/gpxe.x может отличаться истинного расположения, поэтому необходимо подставить свое местоположение образа |
||||
|
||||
Статья подготовлена на основе вики-статьи с сайта [etherboot.org](http://etherboot.org/wiki/removable) |
||||
@ -0,0 +1,36 @@
|
||||
--- |
||||
title: Описание ключевых значений стандарта FreeDesktop |
||||
--- |
||||
|
||||
Ключевые значения могут быть опциональными(OPTIONAL) или обязательными(REQUIRED). Если ключ опционален, то он может быть, а может и не быть представлен в файле. Однако, если его нет, то реализация стандарта должна корректно обрабатывать данную ситуацию и подставлять некоторое значение по-умолчанию. |
||||
|
||||
Некоторые ключи зависят от других, специфических ключей и имеют значение только если этот специфический ключ так же представлен и установлен в специальное значение. Такие ключи не должны быть использованы, если специфический ключ не представлен или установлен в отличное от необходимого значение. Например, ключ `Terminal` может быть использован, только когда значение ключа `Type` установлено в `Application`. |
||||
|
||||
Если требующий ключ действителен в контексте другого ключа, установленного в специальное значение, то он должен быть представлен, если другой ключ установлен в специальное значение. Например, ключ `URL` представлен тогда и только тогда, когда ключ `Type` установлен в значение `Link`. |
||||
|
||||
Примеры ключей: Name[C], Comment[it]. |
||||
|
||||
Таблица 2. Стандартные ключи |
||||
----------------------------- |
||||
|
||||
| Ключ | Описание | Тип значения | Ключ обязателен? | Тип | |
||||
| ''Type'' | Эта спецификация определяет 3 типа элементов рабочего стола: ''Application''(тип 1 - приложение), ''Link''(тип 2 - ссылка) и ''Directory''(тип 3 - директория). Для возможности добавить новые тип в будущем, реализации стандарта должны игнорировать элементы неизвестного типа. | строковый | ДА | | |
||||
| ''Version'' | Версия Спецификации Элементов Рабочего стола которой отвечают элементы рабочего стола. Элементы отвечающие с этой версией спецификации должны использовать ''1.0''. Примечание: поле версии не является обязательным. | строковый | НЕТ | 1-3 | |
||||
| ''Name'' | Имя приложения, например, "Mozilla" | строка в системной локали | ДА | 1-3 | |
||||
| ''GenericName'' | Название класса приложения, например, "Web Browser" | строка в системной локали | НЕТ | 1-3 | |
||||
| ''NoDisplay'' | ''NoDisplay'' означает, что "это приложение создано, но не будет отображено в меню". Это может быть полезно для ассоциирования с приложениями по MIME типа, и это дает возможность запускать его прямо из файлового менеджера(или другого приложения), без необходимости создавать пункт в меню для него(есть тысячи хороших причин для этого, включающие такие штуки, как ''netscape -remote'' или ''kfmclient openURL'') | булево | НЕТ | 1-3 | |
||||
| ''Comment'' | Подсказка для пункта меню, например "Просмотр страниц в интернете". Значение должно отличаться от значений ключей ''Name'' и ''GenericName''. | строка в системной локали | НЕТ | 1-3 | |
||||
| ''Icon'' | Иконка для отображения в менеджере файлов, меню и тд. Если имя является абсллютным путем, будет использован этот файл. Если имя это не абсолютный путь, то будет выбран алгоритм поиска иконки, описанный в [[http://freedesktop.org/wiki/Standards/icon-theme-spec|Спецификации Тем Иконок]]. | строка в системной локали | НЕТ | 1-3 | |
||||
| ''Hidden'' | ''Hidden''(скрытый) должно называться ''Deleted''(удаленный). Это означает что-то удаленное пользователем (на этом уровне), что было представлено (на более высоком уровне, например, в системной директории). Это эквивалентно тому, что .desktop-файл не создан ввиду участия пользователя. Это так же может быть использовано для "удаления" созданных файлов (например, в результате переименования) - давая ''make install'' установливать файлы с ключем ''Hidden=true'' в них. | булево | ДА | 1-3 | |
||||
| ''OnlyShowIn'', ''NotShowIn'' | Список строк, определяющий в каких окружениях элемент должен/не должен быть показан. Только один из этих ключей может присутствовать в группе (смотри возможные значения [[http://www.freedesktop.org/Standards/menu-spec|здесь]]) | строка(и) | НЕТ | 1 | |
||||
| ''TryExec'' | Путь до исполняемого файла, используемый, чтобы определить, действительно ли установлена программа. Если это не абсолютный путь, файл ищется в местах, указанной переменной окружения $PATH. Если файла не существует, или если он не имеет прав на исполнение, элемент может быть проигнорирован. (например не показан в меню) | строка | НЕТ | 1 | |
||||
| ''Exec'' | Программа для выполнения, может быть с параметрами. | строка | ДА | 1 | |
||||
| ''Path'' | Устанавливает рабочую директорию для запуска для элементов типа ''Application''(приложение). | строка | НЕТ | 1 | |
||||
| ''Terminal'' | Устанавливает, должна ли программа запускаться в терминале. | булево | НЕТ | 1 | |
||||
| ''MimeType'' | Тип(ы) MIME, поддерживаемые приложением. | булево | НЕТ | 1 | |
||||
| ''Categories'' | Группы меню, в которых элемент должен показываться (возможные значения смотри [[http://www.freedesktop.org/Standards/menu-spec| здесь]]) | строка(и) | НЕТ | 1 | |
||||
| ''StartupNotify'' | Если ''true'', приложение отправит сообщение ''remove''(об удалении), когда запускается с установленной переменной окружения ''DESKTOP_STARTUP_ID''. Если ''false'', приложение не будет использовать оповещение при запуске (не будут показываться какие-либо окна, прерываться при использовании ''StartupWMClass'' и тд). Если отсутствует, то действия зависят от реализации (считается равным ''false'', используется ''StartupWMClass'' и тд). (дополнительную информацию смотри в [[http://www.freedesktop.org/Standards/startup-notification-spec|Протоколе Оповещения при Запуске]]). | булево | НЕТ | 1 | |
||||
| ''StartupWMClass'' | Если определено, то приложение отобразит как минимум одно окно с переданной строкой в качестве ''WM Class'' или ''WM name'' (подробнее смотри в [[http://www.freedesktop.org/Standards/startup-notification-spec|Протоколе Оповещения при Запуске]]). | строка | НЕТ | 1 | |
||||
| ''URL'' | Если элемент типа ''Link'', определяет его URL. | строка(и) | ДА | 2 | |
||||
|
||||
Это перевод страницы из спецификации FreeDesktop. Ссылка на [оригинал](http://standards.freedesktop.org/desktop-entry-spec/latest/ar01s05.html). |
||||
@ -0,0 +1,160 @@
|
||||
--- |
||||
title: Доступ в интернет через связку Linux+Bluetooth+Mobile+GPRS на примере Arch Linux |
||||
tags: bluetooth, hardware, archlinux |
||||
--- |
||||
|
||||
В этом руководстве без лишних слов и очень кратко описывается весь процесс настройки USB Bluetooth адаптера и ppp соединения для доступа в интернет через мобильный телефон. |
||||
|
||||
В качестве примера приведены настройки для двух операторов сотовой связи Приморья: [НТК](http://www.vntc.ru/) и [МегаФон Дальний Восток](http://www.megafondv.ru/). |
||||
|
||||
Для начала давайте разберемся, что мы будем делать и для чего нам это нужно. Наша конечная цель - заставить работать связку Linux+Bluetooth+Mobile+GPRS. То есть первое, что нам нужно: |
||||
|
||||
- Заставить работать Bluetooth адаптер (в этом руководстве речь пойдет о USB адаптерах). |
||||
- Настроить соединение между телефоном и компьютером посредством bluetooth. Будем использовать стек [Bluez](http://www.bluez.org/). |
||||
- Настроить соответствующим образом pppd. |
||||
- Ура! Работает! Или не работает... |
||||
|
||||
Ну, а теперь обо всем по порядку. |
||||
|
||||
Настройка ядра |
||||
--------------- |
||||
|
||||
Я настраивал адаптер Tekram TM-304. Для того, чтоб заставить эту штуку работать, сначала скомпилируем некоторые модули ядра. |
||||
|
||||
Если вы используете ``make menuconfig`` для конфигурирования ядра, то вот как нужно расставить флажки: |
||||
|
||||
Networking support |
||||
Bluetooth subsystem support ---> |
||||
<M> L2CAP protocol support |
||||
< > SCO links support |
||||
<M> RFCOMM protocol support |
||||
[*] RFCOMM TTY support |
||||
< > BNEP protocol support |
||||
<M> HIDP protocol support |
||||
Bluetooth device drivers ---> |
||||
<M> HCI USB driver |
||||
|
||||
Ну а если вы используете make config или решили вручную включить нужные опции в конфиге ядра (обычно это файл `/ust/src/linux/.config`), то вот они: |
||||
|
||||
CONFIG_BT=m |
||||
CONFIG_BT_L2CAP=m |
||||
CONFIG_BT_RFCOMM=m |
||||
CONFIG_BT_RFCOMM_TTY=y |
||||
CONFIG_BT_HIDP=m |
||||
CONFIG_BT_HCIUSB=m |
||||
|
||||
Все. Можно собирать модули. Не забудьте позаботиться о загрузке необходимых модулей при каждой перезагрузке (если udev не настроен должным образом). |
||||
|
||||
Если у вас нет желания возиться с модулями или религия не позволяет их использовать, можете собрать ядро монолитно. Должно работать. Не проверял. |
||||
|
||||
А сейчас подгрузим эти модули вручную, так как перезагружаться для этого нам лень. |
||||
|
||||
$ modprobe bluetooth |
||||
|
||||
По зависимостям он должен автоматически потянуть модули: rfcomm, hidp, l2cap, hci_usb. Если этого не произошло, то грузим их все по порядку, а в самую последнюю очередь модуль bluetooth. |
||||
|
||||
Переходим к настройке стека bluetooth и сопутствующих утилит |
||||
------------------------------------------------------------- |
||||
|
||||
Ставим необходимый набор утилит для работы с bluetooth стеком [Bluez](http://www.bluez.org/). Через зависимости тянется пакет bluez-libs. ``$ pacman -S bluez-utils`` |
||||
|
||||
Запускаем всю bluetooth подсистему: ``$ /etc/rc.d/bluetooth start`` Сразу не забываем добавить автоматический запуск этого скрипта при загрузке системы. Для этого в файле `/etc/rc.conf` в переменную DEAMONS добавляем соответствующую запись. |
||||
|
||||
Проверяем, что в телефоне включен bluetooth и что он виден всем. |
||||
|
||||
Теперь попытаемся найти все bluetooth устройства, находящихся в зоне досигаемости нашего bluetooth адаптера. ``$ hcitool scan`` Запомните (шутка) запишите адрес bluetooth адаптера, соответствующий вашему телефону. |
||||
|
||||
В файле `/etc/rfcomm.conf` в параметре device указываем адрес нашего телефона. И не забываем установить значение параметра "bind" в "yes"! Иначе не будет автоматически создан файл устройства `/dev/rfcomm0` и его созданием придется заморачиваться отдельно. |
||||
|
||||
В файле `/etc/hcid.conf` в качестве параметра pin_helper указываем `/usr/bin/simplepin`. Разбираться с навороченым bluezpin, который идет в комплекте, да еще и написан на питоне, совсем не охота. Мы напишем скрипт немного проще: |
||||
|
||||
`/usr/bin/simplepin`: |
||||
|
||||
#!/bin/sh |
||||
echo "PIN:1234" |
||||
|
||||
Вот и весь скрипт. |
||||
|
||||
Перезапускаем всю bluetooth подсистему: |
||||
|
||||
$ /etc/rc.d/bluetooth stop |
||||
$ /etc/rc.d/bluetooth start |
||||
|
||||
Теперь можно проверить, работает ли у нас bluetooth соединение. Для этого установим соединение: ``$ hcitool cc <адрес bluetooth адаптера вашего телефона>`` |
||||
|
||||
Если все прошло гладко, то команда ``$ hcitool con`` должна выдать информацию об установленном соединении. |
||||
|
||||
Теперь попробуем отправить запрос на аутентификацию: ``$ hcitool auth <адрес bluetooth адаптера вашего телефона>`` |
||||
|
||||
После выполнения этой команды телефон должен у вас спросить PIN. Вводим то, что вы указали в скрипте `simplepine`. В нашем случае 1234. Если все прошло гладко, то соединение будет установлено и в списке активных устройств вашего телефона должна появиться соответствующая запись. |
||||
|
||||
Для удобства использования я добавил в своем телефоне адрес bluetooth адаптера компьютера в список сопряженных устройств и разрешил этому устройству подключаться автоматически. После этого можно включить скрытый режим в параметрах bluetooth и больше не вводить pin-код при каждом подключении. |
||||
|
||||
Переходим к настройке ppp соединения |
||||
------------------------------------- |
||||
|
||||
Вот здесь есть, где напороть косяков и потом долго догадываться: почему у меня все правильно, но нифига не работает. |
||||
|
||||
Содержимое файла `/etc/ppp/peers/ntc-gprs`: |
||||
|
||||
lcp-echo-failure 0 |
||||
lcp-echo-interval 0 |
||||
connect /etc/ppp/peers/ntc-gprs-connect-chat |
||||
/dev/rfcomm0 |
||||
115200 |
||||
crtscts |
||||
local |
||||
noipdefault |
||||
ipcp-accept-local |
||||
defaultroute |
||||
#replacedefaultroute |
||||
usepeerdns |
||||
novj |
||||
nobsdcomp |
||||
novjccomp |
||||
nopcomp |
||||
noaccomp |
||||
noauth |
||||
mtu 1400 |
||||
|
||||
Здесь стоит обратить внимание на последнюю строку: "mtu 1400". По умолчанию значение параметра [mtu](http://ru.wikipedia.org/wiki/MTU) (Maximum Transfer Unit) равно 1500. А у нашего провайдера максимальный размер пакета ограничен цифоркой несколько меньшей. Какая это точно цифра, мне узнать не удалось, но со значением 1400 все работает на ура. Если этот параметр не указать, то интернет у вас тоже будет работать, но, поработав немного, вы заметите, что, оказывается, не можете добавлять в форумы сообщения, состоящие более чем из одной-двух строк. Неприятно. mtu 1400 спасет отца русской демократии. |
||||
|
||||
Содержимое файла `/etc/ppp/peers/ntc-gprs-connect-chat`: |
||||
|
||||
exec chat -vS \ |
||||
'' \rAT \ |
||||
TIMEOUT 12 \ |
||||
OK ATH \ |
||||
OK ATE1 \ |
||||
OK 'AT+CGDCONT=1,"IP","internet.ntc"' \ |
||||
OK ATD*99***1# \ |
||||
TIMEOUT 22 \ |
||||
SAY "\nwaiting for connect...\n" \ |
||||
CONNECT "" \ |
||||
SAY "\nConnected." |
||||
|
||||
Здесь, в зависимости от того, какой у вас оператор мобильной связи, может меняться только один параметр: APN (точка входа). Здесь я привел пример для [НТК](http://www.vntc.ru/). Если, например, у вас "Мегафон дальний восток", то в качестве APN нужно указать internet.dv. |
||||
|
||||
Содержимое файла `/etc/resolv.conf`: |
||||
|
||||
# Для NTC IP адреса DNS серверов будут такими: |
||||
nameserver 80.243.64.67 |
||||
nameserver 80.243.68.34 |
||||
|
||||
# Для "Мегафон дальний восток" такими: |
||||
nameserver 83.149.52.77 |
||||
nameserver 194.186.112.18 |
||||
|
||||
Вот и все. После этого все должно работать. Пробуем подключиться: |
||||
|
||||
$ pppd call ntc-gpts |
||||
|
||||
Материалы по теме: |
||||
|
||||
- [Пингвин показывает зубки (Linux + Bluetooth...)](http://www.linuxrsp.ru/artic/Linux-Bluetooth.html) |
||||
- [Алё, говорит Linux. Как слышно? Приём! (Linux + OBEX + GPRS...)](http://www.linuxrsp.ru/artic/Linux-OBEX-GPRS.html) |
||||
- [Подключение GPRS/EDGE в GNU/Linux](http://ru.wikibooks.org/wiki/%D0%9F%D0%BE%D0%B4%D0%BA%D0%BB%D1%8E%D1%87%D0%B5%D0%BD%D0%B8%D0%B5_GPRS/EDGE_%D0%B2_GNU/Linux) |
||||
|
||||
P.S.: Очень рекомендую источник [[3](http://ru.wikibooks.org/wiki/%D0%9F%D0%BE%D0%B4%D0%BA%D0%BB%D1%8E%D1%87%D0%B5%D0%BD%D0%B8%D0%B5_GPRS/EDGE_%D0%B2_GNU/Linux)]. Обнаружил я эту статью уже после того, как написал свою. Кстати, телефон у автора такой же как у меня ;) |
||||
|
||||
(c) Rayven, 2006. |
||||
@ -0,0 +1,56 @@
|
||||
--- |
||||
title: Небольшое облегчение жизни с инфракрасником Tekram 410w |
||||
tags: hardware |
||||
--- |
||||
|
||||
Сделано с помощью udev. |
||||
|
||||
--- |
||||
|
||||
Для начала пишем правило для udev: |
||||
|
||||
/etc/udev/rules.d/irda.rules: |
||||
|
||||
# Tekram 410w |
||||
SUBSYSTEM=="net", ACTION="add", DEVPATH=="*/irda*", SYSFS{idVendor}=="066f", SYSFS{idProduct}=="4200", RUN+="/lib/udev/irda.sh" |
||||
# Rule for all Irda devices: |
||||
#SUBSYSTEM=="net", ACTION="add", DEVPATH=="*/irda*", RUN+="/lib/udev/irda.sh" |
||||
SUBSYSTEM=="net", ACTION="remove", DEVPATH=="*/irda*", RUN+="/lib/udev/irda.sh" |
||||
|
||||
Пишем скрипт-хелпер `/lib/udev/irda.sh`: |
||||
|
||||
#!/bin/bash |
||||
DEBUG=0 |
||||
DEV=`basename $DEVPATH` |
||||
PID=`ps auxwww | grep irattach | grep $DEV | grep -v grep | awk '{print($2)}'` |
||||
if [ x"$DEBUG" = "1" ]; then |
||||
echo >> /tmp/irda.txt |
||||
echo `date` >> /tmp/irda.txt |
||||
echo $ACTION >> /tmp/irda.txt |
||||
echo $DEVPATH >> /tmp/irda.txt |
||||
echo $DEV >> /tmp/irda.txt |
||||
echo $PID >> /tmp/irda.txt |
||||
echo $SUBSYSTEM >> /tmp/irda.txt |
||||
echo $@ >> /tmp/irda.txt |
||||
echo "--" >> /tmp/irda.txt |
||||
fi |
||||
if [ x"$PID" != x"" ]; then |
||||
kill $PID |
||||
fi |
||||
if [ x"$ACTION" = x"add" ]; then |
||||
/usr/sbin/irattach $DEV -s |
||||
fi |
||||
|
||||
idVendor и idProduct можно узнать набрав `lsusb -v`, при помощи них можно делать специфичные настройки для определенного инфракрасника, если ничего подобного не предусматривается, эту строчку закомментить, а сточку на действие add без idVendor/idProduct раскомментировать. |
||||
|
||||
От root'а делаем ``udevcontrol reload_rules`` |
||||
|
||||
Теперь, если инфракрасник зависнет, нужно будет просто переткнуть его в порт... |
||||
|
||||
Поиск решения что бы сие чудо не зависало вообще идет, приветствуются все идеи. |
||||
|
||||
Кстати, это решение дает реальный хот-плаг для инфракрасника, т.е. ничего больше не нужно химичить если его воткнуть на лету :) |
||||
|
||||
Эти действия решает так же проблему: [Проблема с IrDa](http://vl-lug.ru/forum/viewtopic.php?id=39). |
||||
|
||||
(c) Alexander Drozdoff (aka Hatred), Vladivostok, 2006 |
||||
@ -0,0 +1,155 @@
|
||||
--- |
||||
title: Миграция Windows -> Linux на рабочих местах (Заметки путешественника) |
||||
tags: migration |
||||
--- |
||||
|
||||
Некоторые детали: |
||||
|
||||
ОС на рабочих местах - Debian 5.0 Lenny. Рабочие места используют сервисы сервера (MS Windows 2000): |
||||
|
||||
* авторизация - Active Directory; |
||||
* приложения - RDP; |
||||
* совместное использование файлов. |
||||
|
||||
План миграции в общих чертах |
||||
----------------------------- |
||||
|
||||
- Заменить Win32 приложения на кроссплатформенные аналоги, которые будут использоваться после перехода на Линукс. |
||||
- Обучение и привыкание пользователей. Решение возникших проблем несовместимости. Длительность курса лечения - по состоянию пациентов и загруженности докторов. |
||||
- Замена ОС с переносом файлов и профилей кросплатформенных приложений. |
||||
- Обучение, привыкание, решение проблемм... |
||||
- Profit! |
||||
|
||||
Русские символы в имени и пароле пользователя для авторизации. |
||||
--------------------------------------------------------------- |
||||
|
||||
Русские символы можно использовать при авторизации через winbind. Авторизация через kerberos с русским паролем не работает. kerberos необходим только лишь для добавления компьютера в домен AD, для этого используйте учетную запись с паролем только из ascii символов. |
||||
|
||||
No logon servers! |
||||
------------------ |
||||
|
||||
На некоторых компьютерах при попытке входа пользователя AD в систему выдается ошибка: "No logon servers". Если перезапустить winbind, то авторизация начинает работать. |
||||
|
||||
Причина - NetworkManager перезапускает сетевую карту после того, как gdm уже запустился. Попытка исправить это, повесив на события ifup и dhcp перезапуск winbind, не дает устойчивого результата. Самое надежное решение - удалить NetworkManager. Для стационарных рабочих мест с сетевой авторизацией нужды в этой программе нет. |
||||
|
||||
Время |
||||
------ |
||||
|
||||
По умолчанию ntp не устанавливается. Надо настроить синхронизацию времени. Иначе при расхождении времени в несколько минут перестает работать авторизация в AD и kerberos. |
||||
|
||||
OpenOffice: поддержка форматов MS Office |
||||
----------------------------------------- |
||||
|
||||
Нужно установить последнюю версию OpenOffice. Причина одна - лучше взаимодействует с MS Office. Некоторые документы .doc могут не открываться OpenOffice'ом из Debian Stable. Установите OpenOffice из Unstable. |
||||
|
||||
OpenOffice: редактирование таблицы, сохраненной 1С v7.7 |
||||
-------------------------------------------------------- |
||||
|
||||
Если сохранить отчет 1С как таблицу excel, открыть OO Calc, затем сохранить его в том же формате, то кодировка символов ломается. Чтобы кодировка не портилась, нужно сделать "Сохранить как..." и выбрать тип файла "Excel 97/2000/XP". |
||||
|
||||
Обычно, пользователи забывают сделать это, при этом теряются внесенные ими данные. Это сильно портит всем кровь! Чтобы избежать этого, можно отучить OO экспортировать в файлы типа "Excel 5.0". |
||||
|
||||
В файле `/usr/lib/openoffice/basis3.0/share/registry/modules/org/openoffice/TypeDetection/Filter/fcfg_calc_filters.xcu` для этого формата убрать флаг EXPORT. |
||||
|
||||
diff -C 1 orig/fcfg_calc_filters.xcu noexcel50/fcfg_calc_filters.xcu |
||||
*** a/fcfg_calc_filters.xcu 2009-06-26 15:26:48.000000000 +1100 |
||||
--- b/fcfg_calc_filters.xcu 2009-06-26 15:31:51.000000000 +1100 |
||||
*************** |
||||
*** 83,85 **** |
||||
<node oor:name="MS Excel 5.0/95" oor:op="replace"> |
||||
! <prop oor:name="Flags"><value>IMPORT EXPORT ALIEN PREFERRED</value></prop> |
||||
<prop oor:name="UIComponent"/> |
||||
--- 83,85 ---- |
||||
<node oor:name="MS Excel 5.0/95" oor:op="replace"> |
||||
! <prop oor:name="Flags"><value>IMPORT ALIEN PREFERRED</value></prop> |
||||
<prop oor:name="UIComponent"/> |
||||
|
||||
Не открываются файлы `*.shs` |
||||
---------------------------- |
||||
|
||||
Это файл MS Office. Может содержать все, что угодно. OO его не умеет открывать и никогда, думаю, не будет этого делать. Такие файлы нужно открыть офисом и сохранить в формат doc, xls, etc... |
||||
|
||||
RAR-архивы |
||||
----------- |
||||
|
||||
Для этого формата есть две версии программ: free и non-free. Свободная версия не поддерживает новые форматы файла. Надо подключить non-free репозиторий и установить из него unrar. |
||||
|
||||
Письма MS Outlook |
||||
----------------- |
||||
|
||||
Outlook умеет делать такие письма: |
||||
|
||||
Content-Type: text/html; charset=windows-1251 |
||||
X-Mailer: Microsoft Office Outlook 11 |
||||
Content-transfer-encoding: 8bit |
||||
|
||||
<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns="http://www.w3.org/TR/REC-html40"> |
||||
<head> |
||||
<meta http-equiv=Content-Type content="text/html; charset=koi8-r"> |
||||
<meta name=Generator content="Microsoft Word 11 (filtered medium)"> |
||||
|
||||
Обратите внимание на charset. Свободные клиенты неправильно отображают такие письма. В этом случае либо руками всякий раз указывать кодировку koi8-r, либо завести специальную папку, установить для неё кодировку и перекладвывать в неё такие письма. |
||||
|
||||
Русская раскладка по умолчанию при входе в систему (gdm) |
||||
--------------------------------------------------------- |
||||
|
||||
Исторически сложилось, что имя и пароль для входа в домен состоит из русских символов. И пользователи привыкли, что при входе в систему по умолчанию включена русская раскладка клавиатуры. |
||||
|
||||
Чтобы сделать так, как все привыкли, надо: |
||||
|
||||
- в xorg.conf делаем первой ru: XkbLayout = "ru,us"; |
||||
- из-за того, что на первом месте теперь стоит ru, а не us, ломается обработка Ctrl+AnyKey в некоторых программах, которые считают, что первая раскладка всегда us. |
||||
|
||||
Чтобы исправить, после входа в систему нужно опять делать us первой раскладкой: |
||||
|
||||
- открываем DE -> параметры клавиатуры -> Раскладки и видим "Россия, США" |
||||
- удаляем "Россия", добавляем "Россия", получается "США, Россия". Или `setxkbmap -layout us,ru`, если в DE нет рафической настройки раскладки. |
||||
|
||||
Отправка изображений почтой |
||||
---------------------------- |
||||
|
||||
Пользователи привыкли к такому сценарию отправки изображений почтой: |
||||
|
||||
- выделить графические файлы в проводнике; |
||||
- в контекстном меню выбрать "отправить..."; |
||||
- в появившемся окне выбрать уменьшение размера изображений; |
||||
- в получившемся письме вставлены уменьшенные изображения. |
||||
|
||||
Решение для Линукса. Требования: файловый менеджер, поддерживающий freedesktop, например, nautilus, bash, GraphicsMagick, zenity, icedove. Также в скрипт "жестко вбит" получаемый размер изображений. Файл `/usr/bin/sendpicture`: |
||||
|
||||
#!/bin/bash |
||||
n=$# |
||||
d=`mktemp -d /tmp/attachments.XXXXXXXXXX` |
||||
echo -n > "$d/list.txt" |
||||
(while [ -n "$1" ] ; do |
||||
echo $((($n - $#) * 100 / $n )) |
||||
f="$d/`basename "$1"`" |
||||
gm convert -resize 800 "$1" "$f" |
||||
echo -n "file://$f," >> "$d/list.txt" |
||||
shift |
||||
done) | zenity --title="Отправка изображений" \ |
||||
--text "Уменьшение размеров изображений.\nВсего выбрано: $n шт." \ |
||||
--auto-close --progress --auto-kill \ |
||||
&& icedove -compose "subject=Отправка изображений,attachment='`cat $d/list.txt`'" |
||||
|
||||
Файл `/usr/share/applications/sendpicture.desktop`: |
||||
|
||||
[Desktop Entry] |
||||
Name=Send pictures |
||||
Name[ru]=Отправить изображения |
||||
Comment=Resize pictures and send |
||||
Comment[ru]=Уменьшить размер изображений и отправить |
||||
TryExec=sendpicture |
||||
Exec=sendpicture %F |
||||
Icon=document-send |
||||
StartupNotify=false |
||||
NoDisplay=true |
||||
Terminal=false |
||||
Type=Application |
||||
MimeType=image/bmp;image/gif;image/jpeg;image/jpg;image/pjpeg;image/png;image/tiff;image/x-bmp;image/x-gray;image/x-icb;image/x-ico;image/x-png;image/x-portable-anymap;image/x-portable-bitmap;image/x-portable-graymap;image/x-portable-pixmap;image/x-xbitmap;image/x-xpixmap;image/x-pcx;image/svg+xml;image/svg+xml-compressed;image/vnd.wap.wbmp; |
||||
|
||||
Теперь сценарий такой: |
||||
|
||||
- в файлом менеджере выделить графические файлы; |
||||
- в контекстном меню выбрать открыть программой "Отправить изображения"; |
||||
- будет создано письмо с вложенными уменьшенными изображениями. |
||||
@ -0,0 +1,174 @@
|
||||
--- |
||||
title: Настройка Сканера (USB, LPT) в ОС Linux |
||||
tags: software, sane |
||||
--- |
||||
|
||||
Это документ расчитан, прежде всего, на начинающего пользователя ОС Linux, а так же на тех, кому лень самому читать документацию к указанным пакетам. |
||||
|
||||
Отмечу, что я не являюсь экспертом в данной области и операционной системе Linux, поэтому возможно при аписании этого документа были допущены ошибки и неточности. Лучшим источником информации по прежнему остается документация к описываемым пакетам и соответствующие man-страницы. Со всеми замечаниями и предложениями обращайтесь сюда: 4rayven [ at ] gmail [ dot ] com |
||||
|
||||
Настройка ядра для LPT сканера |
||||
------------------------------- |
||||
|
||||
В ядре Вам необходимо включить поддержку параллельного порта: |
||||
|
||||
Конфигурация ядра 2.4.x |
||||
------------------------ |
||||
|
||||
Parallel port support ---> |
||||
<*> Parallel port support |
||||
|
||||
Конфигурация ядра 2.6.x |
||||
------------------------ |
||||
|
||||
Device Drivers ---> |
||||
Parallel port support ---> |
||||
<*> Parallel port support |
||||
|
||||
Если Вы любитель модульного ядра - ваше право, хотя в документации к ядру все же рекомендуют включить этот драйвер монолитно. Модуль будет называться parport. |
||||
|
||||
Настройка ядра для USB сканера |
||||
------------------------------- |
||||
|
||||
Конфигурация ядра 2.4.x |
||||
------------------------ |
||||
|
||||
General setup ---> |
||||
[*] Support for hot-pluggable devices |
||||
|
||||
(Эта опция дает возможность подключать устройства на уже запущенной машине) |
||||
|
||||
File systems ---> |
||||
[*] /proc file system support |
||||
|
||||
USB support ---> |
||||
<*> Support for USB |
||||
[*] Preliminary USB device filesystem |
||||
|
||||
Поддержка host-контроллера: |
||||
|
||||
<*> UHCI (Intel PIIX4, VIA, ...) support |
||||
|
||||
или |
||||
|
||||
<*> OHCI (Compaq, iMacs, OPTi, SiS, ALi, ...) support |
||||
|
||||
Что из них следует выбрать Вам зависит от Вашего чипсета. Можно включить сразу оба - хуже не будет, хотя и некрасиво это выглядит. |
||||
|
||||
<*> USB Scanner support |
||||
|
||||
(собственно поддержка USB-сканера) |
||||
|
||||
Конфигурация ядра 2.6.x |
||||
------------------------ |
||||
|
||||
General setup ---> |
||||
|
||||
[*] Support for hot-pluggable devices |
||||
(пояснения см. выше) |
||||
|
||||
File systems ---> |
||||
Pseudo filesystems ---> |
||||
[*] /proc file system support |
||||
|
||||
Device Drivers ---> |
||||
USB support ---> |
||||
<*> Support for Host-side USB |
||||
[*] USB device filesystem |
||||
<*> OHCI HCD support</code> |
||||
или |
||||
<*> UHCI HCD (most Intel and VIA) support |
||||
(об этом сказано выше) |
||||
|
||||
На этом конфигурация ядра завершена. Пересобираем ядро и перезагружаем машину. |
||||
|
||||
Установка необходимого программного обеспечения |
||||
------------------------------------------------ |
||||
|
||||
libusb |
||||
------- |
||||
|
||||
Для USB-сканера необходимо скачать и установить библиотеку [libusb](http://libusb.sourceforge.net/). |
||||
|
||||
Распаковываем и устанавливаем как обычно: |
||||
|
||||
$ tar -zxvf libusb.tar.gz |
||||
$ cd libusb |
||||
$ ./configure |
||||
$ make |
||||
$ make install |
||||
|
||||
(X)SANE |
||||
-------- |
||||
|
||||
Непосредственно для сканирования существует замечательный программный пакет SANE (с интерфейсом командной строки) и графический интерфейс пользователя для него(на GTK+): XSANE. Любителям командной строки последний пакет не понадобится. Скачать последнюю версию можно отсюда: http://www.sane-project.org/ Обращу Ваше внимание, что мне так и не удалось заставить работать XSANE версии младше 0.92 под ядром 2.6.x. |
||||
|
||||
Распаковываем и устанавливаем как обычно: |
||||
|
||||
$ tar -zxvf sane.tar.gz |
||||
$ cd sane |
||||
$ ./configure |
||||
$ make |
||||
$ make install</code> |
||||
|
||||
Если вам нужен GUI, тогда ставим и его: |
||||
|
||||
$ tar -zxvf xsane.tar.gz |
||||
$ cd xsane |
||||
$ ./configure |
||||
$ make |
||||
$ make install |
||||
|
||||
Конфигурация sane |
||||
------------------ |
||||
|
||||
Вообще говоря проблематично дать какие-то конкретные рекомендации ввиду того, что сканеры от разных производителей конфигурируются по-разному. Для получения более подробной информации следует набрать команду man sane |
||||
|
||||
В разделе "BACKENDS FOR SCANNERS" этого документа Вcы найдете список всех фирм производителей, сканеры которых поддерживаются, а так же ссылку на конкретную man-страницу для каждого из них. Хочется пожелать Вам удачи. Но все же я попробую помочь и дам несколько примеров из моей практики. |
||||
|
||||
Счастливые обладатели USB-сканеров Mustek теперь могут набрать команду ``sane-find-scanner`` |
||||
|
||||
Смотрим что она нам написала. Если среди всего вывода есть вот такое: |
||||
|
||||
# No USB scanners found. If you expected something different, make sure that |
||||
# you have loaded a driver for your USB host controller and have installed a # kernel scanner module. |
||||
|
||||
То либо читаем все сначала, либо читаем документацию. man sane все победит! =) |
||||
|
||||
Если же Вы получили что-то подобное: |
||||
|
||||
Можете начинать радоваться жизни и читать ман по scanimage(это для любителей командной строки), ну или просто под иксами дать комманду xsane - там все понятно. Остальные за мной. ---- |
||||
|
||||
Опыт подключения LPT-сканера Mustek-1200CP+ |
||||
-------------------------------------------- |
||||
|
||||
С LPT сканерами существует ряд проблем и сложностей, ввиду того, что отвечающие за их работу модули еще находится в стадии разработки. Но, тем не менее, эти устройства вполне работоспособны. |
||||
|
||||
**[!] Внимание! Если во время Ваших экспериментов со сканером вы услышите низкий щелкающий звук, НЕМЕДЛЕННО ВЫКЛЮЧИТЕ СКАНЕР!!! [!]** |
||||
|
||||
LPT-сканерам Mustek посвящена man-страница sane-mustek_pp. В любом случае, вам лучше прочитать ее пред тем, как что-то делать. |
||||
|
||||
Этот сканер мне удалось победить так: В файле `/etc/sane.d/dll.conf` я раскомментировал строку `mustek_pp` и в файле `/etc/sane.d/mustek_pp.conf` раскоммнетировал строку `scanner Mustek-1200CP+ 0x378 cis1200+` Здесь 0x378 - адрес LPT-порта. Возможно вам понадобится указать другое значение(например 0x278 или 0x3BC). Cis1200+ - название драйвера, котрый следует использовать. Указание неправильного драйвера может повредить ваш сканер(но мне повезло, когда я перепутал %) )! |
||||
|
||||
Формат строки можно узнать среди комментариев этого же файла, либо на странице man sane-mustek_pp |
||||
|
||||
После того, как я проделал все вышеуказанные действия сканер заработал! Хочу обратить ваше внимание, что программа sane-find-scanner не способна увидеть LPT-сканер и один из способов проверить его работоспособность - это запустить scanimage или xsane. ---- |
||||
|
||||
Опыт подключения сканера Epson Perfection 1670 со слайд модулем |
||||
---------------------------------------------------------------- |
||||
|
||||
Настройка этого сканера несколько отличается от примеров приведенных выше, но все различия заключаются лишь в необходимости использования дополнительного бинарного файа: `ESFW30.BIN` который можно взять на диске с драйверами сканера. Мне удалось найти его в интернете. |
||||
|
||||
Этот сканер подключается бо USB интерфейсу, поэтому файл `/etc/sane.d/epson.conf` у меня имеет такой вид: ``usb /dev/usb/scanner0`` |
||||
|
||||
Да, всего одна строка! В зависимости от вашего дистрибутива файл устройства, отвечающий за USB сканер может называться и так: `/dev/usbscanner0`. Проверьте наличие того или иного файла и исправьте соответствующим образом файл `epson.conf`. |
||||
|
||||
Осталось подправить файл `/etc/sane.d/snapscan.conf`. Раскомментируйте строки: ``firmware /etc/sane.d/ESFW30.BIN /dev/usb/scanner0 bus=usb`` |
||||
|
||||
и измените соответствующим образом путь к указанному файлу. |
||||
|
||||
Вот, собственно, и вся настройка. Сканером можно пользоваться. Слайд адаптер тоже работал можно сказать "как в винде" :) Дело в том, что попавший ко мне экземпляр сканера в режиме сканирования слайдов безбожно глючил как под линуксом, так и под виндой. Причину проявившегося глюка установить так и не удалось, но проблема, видимо, заключалась именно в железе так как проявлялась с прогревом сканера и при сканировании обычных документов все было отлично. |
||||
|
||||
На этом пока все. Больше подопытных сканеров мне пока найти не удалось. Будут еще сканеры - будут и описания их настройки. |
||||
|
||||
Удачи. © *Rayven, 2004.* |
||||
@ -0,0 +1,117 @@
|
||||
--- |
||||
title: Настройка принтера Samsung ML-1520P |
||||
tags: hardware, samsung |
||||
--- |
||||
|
||||
!!! Этот принтер больше не поддерживается Samsung, соответственно драйвера они больше для него не пишут. Более того, у них на сайте их тоже уже нет. На свой страх и риск выкладываю [тут](http://hatred.homelinux.net/~hatred/samsung/20061102191855421_UnifiedLinuxDriver.tar.gz). Описание настройки закрытого драйвера оставлено в исторических целях. |
||||
|
||||
Открытый драйвер samsung GDI |
||||
---------------------------- |
||||
|
||||
Встренный в ghostscript. На [странице принтера](http://www.linuxprinting.org/show_printer.cgi?recnum=Samsung-ML-1520P) отмечен как рекомендуемый. |
||||
|
||||
Проверить наличие можно так: |
||||
|
||||
$ gs --help | grep samsunggdi |
||||
psrgb pswrite pxlcolor pxlmono r4081 rinkj rpdl **samsunggdi** sgirgb sj48 |
||||
|
||||
Далее установка происходит следущим образом, рассказ для CUPS и для ArchLinux. |
||||
|
||||
- Заходим [сюда](http://www.linuxprinting.org/show_driver.cgi?driver=gdi&fromprinter=Samsung-ML-1520P), выбираем принтер ML-1520, ставим чекбокс в download и нажимаем кнопку Generate PPD file, сохраняем файл себе на жесткий диск, имя: Samsung-ML-1520-gdi.ppd |
||||
- Для работы нужен фильтр foomatic-rip, находится в пакете foomatic-filters, ставим его: ``pacman -S foomatic-filters`` у кого нет такого пакета, посмотрите [сайт](http://www.linuxprinting.org/foomatic.html) на предмет наличия. |
||||
- Запускаем браузер (CUPS думаю у вас уже запущен), заоходим на http://localhost:631 и далее: |
||||
- Идем в [Manage printers](http://localhost:631) и удаляем принтер со старыми драйверами |
||||
- Идем в [Add printer](http://localhost:631/admin?OP=add-printer): |
||||
* Name: любое, пусть будет ml1520 |
||||
* Location: "моя комната" или "мой кабинет" или "далеко далеко далече" |
||||
* Description: описание принтера |
||||
- Нажимаем Continue, попадаем в "Device for ml1520" |
||||
* Выбираем Device, у меня принтер на паралельном порту (он может работать и через USB), поэтому устройство выглядит так: "Samsung ML-1520P LPT #1" |
||||
- Нажимаем Continue, попадаем в "Model/Driver for ml1520" |
||||
* В Provide a PPD file выбираем наш сохраненный Samsung-ML-1520-gdi.ppd |
||||
- Нажимаем Add Printer. Принтер добавлен |
||||
- Переходим опять в Manage Printers, устанавливаем опции печати, в частности формат листа A4, можно проверить печать, напечатав пробую страницу. |
||||
|
||||
Открытый драйвера splix |
||||
------------------------ |
||||
|
||||
Есть так же в репозитарии ArchLinux, или качается с http://splix.ap2c.org, там же смотрится список поддерживаемых принтеров. Драйвер отмечен как: "This driver contains algorithms which are (possibly) patented (See license text)". |
||||
|
||||
- Ставим ``pacman -S splix`` |
||||
- Перестартуем CUPS после: ``/etc/rc.d/cups restart`` |
||||
- Все шаги проделываются аналогично установке samsunggdi, за исключением установки foomatic-filters и в списке принтеров вместо указания PPD, он выбирается из списка: "Samsung ML-1520, SpliX V. 2.0.0 (en)" |
||||
|
||||
Закрытый драйвер |
||||
----------------- |
||||
|
||||
С закрытыми драйверами бывает очень много разного необычного и загадочного, вот и с принтером ML-1520 не все получилось гладко. Основная проблема в том, что когда стояла старая Slackware 9.1 этот принтер завелся с полуоборота на с теми дровами что были с ним на диске. После обновления до Slackware 9.1 он работать наотрез отказался, такое же поведение наблюдалось и на свеженьком Arch Linux 0.7.1. Все дело было в том что фильтр из состава драйвера валился в сигфолт, думается из-за несоответствия версии glibc в системе и glibc с которой был скомпилирован фильтр. Обновление драйверов с официального сайта samsung.com (не берите драйвера с samsung.ru, там таааакое старье!) тоже не помогло... |
||||
|
||||
Так и стоял этот принтер без работы почти все лето... |
||||
|
||||
Ну вот подумав, что, возможно, драйвера еще раз обновили и решили эти проблемы, опять полез на samsung.com. И надо же, действительно, обновление было ;) Скрестив пальчики поставил на закачку (14 метров по gprs это да...). После окончания скачивания мы имеем архив: |
||||
|
||||
20060710181110812_UnifiedLinuxDriver.tar.gz |
||||
|
||||
распаковываем его: |
||||
|
||||
tar xzf 20060710181110812_UnifiedLinuxDriver.tar.gz |
||||
|
||||
Переходим в каталог: |
||||
|
||||
cd cdroot |
||||
|
||||
Смотрим на заманчивый файл `autorun` и еще более заманчивый `Linux/install.sh` и... нет не угадали, нифига мы их не запускаем. Попробую объяснить почему, в двух словах: |
||||
|
||||
После инсталляции стандартным путем, принтер нафиг отказывается работать! почему - хз, как настраивать - хз. (ну точнее не полностью непонятно, но объяснять то что у самого в голове сумбурно - бред) |
||||
|
||||
Далее идем по инструкции (делаем от рута): |
||||
|
||||
- Создаем каталог: ``mkdir -p /opt/Samsung/mfp`` |
||||
- Копируем все из Linux/i386/at_opt в вышеуказанный каталог (вместо i386 может быть x86_64): ``cp -r Linux/i386/at_opt /opt/Samsung/mfp/`` |
||||
- Копируем все из Linux/i386/at_root ``cp -r Linux/i386/at_root /opt/Samsung/`` |
||||
- Делаем симлинки: |
||||
|
||||
ln -s /opt/Samsung/usr/lib/cups/backend/* /usr/lib/cups/backend |
||||
ln -s /opt/Samsung/usr/lib/cups/filter/* /usr/lib/cups/filter |
||||
ln -s /opt/Samsung/usr/lib/sane/* /usr/lib/sane |
||||
ln -s /opt/Samsung/usr/lib/libmfp.so.1.0.1 /usr/lib/ |
||||
|
||||
- Копируем qt библиотеку с которой собрана конфигурационная морда и создаем линк: |
||||
|
||||
cp Linux/i386/lib/libqt-mt.so.3 /opt/Samsung/usr/lib ln -s /opt/Samsung/usr/lib/libqt-mt.so.3 /usr/lib |
||||
|
||||
- Копируем все из noarch/at_opt/share в /opt/Samsung/mfp/share ``cp -r noarch/at_opt/share/* /opt/Samsung/mfp/share`` |
||||
- Копируем noarch/at_root ``cp -r noarch/at_root/* /opt/Samsung/`` |
||||
- Делаем линк ``ln -s /opt/Samsung/etc/sane.d/* /etc/sane.d/``\ (7-8 пункты не имеют к настройке принтера никакого отношения но могут быть полезны при настройке комбайнов и сканеров от самсунга) |
||||
- Пройдитесь ldd по фильтрам и вообще всем бинарникам: |
||||
|
||||
ldd /opt/Samsung/mfp/bin/* |
||||
ldd /opt/Samsung/usr/lib/cups/backend/* |
||||
ldd /opt/Samsung/usr/lib/cups/filter/* |
||||
|
||||
Если не найдены библиотеки типа libstdc++ попробовать сначала доставить из дистрибутива или из noarch/ |
||||
|
||||
- Скопировать OEM.ini ``cp Linux/OEM.ini /opt/Samsung/mfp/share/`` |
||||
- Остановить cups: ``/etc/rc.d/cups stop`` |
||||
- Отредактировать ``/etc/cups/printers.conf`` |
||||
|
||||
<DefaultPrinter ml1520> |
||||
Info |
||||
Location |
||||
DeviceURI parallel:/dev/lp0 |
||||
State Idle |
||||
Accepting Yes |
||||
JobSheets none none |
||||
QuotaPeriod 0 |
||||
PageLimit 0 |
||||
KLimit 0 |
||||
</Printer> |
||||
|
||||
- Скопировать ML-1520spl2.ppd: ``cp /opt/Samsung/mfp/share/ppd/ML-1520spl2.ppd /etc/cups/ppd/ml1520.ppd`` |
||||
- Запустить cups ``/etc/rc.d/cups start`` |
||||
- Запустить программу конфигурации ``/opt/Samsung/mfp/bin/Configurator |
||||
- Настроить свой принтер |
||||
|
||||
Все, после этого все должно работать, возможно сделаю спек для утилиты makepkg из состава ArchLinux что бы автоматизировать этот процесс |
||||
|
||||
Alexander 'Hatred' Drozdoff, Vladivostok, 2006.08.22, updated: 2009.03.31 |
||||
@ -0,0 +1,145 @@
|
||||
--- |
||||
title: Слакварное ./configure |
||||
tags: slackware |
||||
--- |
||||
|
||||
> Сколько же это сможет продолжатся? |
||||
> Столько сколько это будет возможным.... |
||||
> Матрица часть 3 РЕВОЛЮЦИЯ |
||||
|
||||
Отличительной чертой Slackware подобных дистрибутивов, к которым относится используемый мной MOPS LINUX, является простота, надежность, и как следствие невероятная гибкость и мощь, позволяющая эффективно решать любые задачи. Но владение столь великолепным инструментом почти автоматически заставляет желать большего - большей отзывчивости системы, большего комфорта, наконец. |
||||
|
||||
Итак, задача — взять от железа всё что можно, причем используемая технология должна быть: |
||||
|
||||
- эффективной |
||||
- малозатратной |
||||
- массовой (легко переносимой на другие компы) |
||||
- легкой в управлении и обслуживании |
||||
|
||||
Решение - пересборка приложений под конкретное железо, с обязательной регистрацией в базе установленного софта (пакетного менеджера) |
||||
|
||||
--- |
||||
|
||||
Казалось бы трудностей не возникнет, но — [статья](http://wiki.mopslinux.org/index.php/Управление_пакетами_программ), описывающая процесс создания пакетов, не дописана, обрывается на самом интересном месте... На форуме есть много мнений, но нет рецептов. Есть сборка слакбилдами, есть тулза paskadebulder , есть замечательный и функциональный менеджер пакетов, умеющий кроме всего прочего работать с репозиториями — mpkg. Но! Слакбилд надо ещё найти (не всегда удаётся) параметры paskadebulder относительно архитектуры и конфигурации собираемой программы можно задать, но для этого нужно знать, что задать. К тому же оптимизация приложений не так проста, как кажется. Ещё не факт, что программа соберётся с указанными флагами компилятора, и вовсе не факт, что эти флаги будут использованы при сборке. Автоматизировать сей процесс трудно, почти невозможно. Словом опять получается так: скачиваем сырцы |
||||
|
||||
./configure --help |
||||
|
||||
затем курим слакбилд (paskadebulder), выставляя потребные флаги и архитектуру и добиваясь правильной сборки, а не проще ли |
||||
|
||||
./configure && make install ? |
||||
|
||||
В общем, получается как в том анекдоте когда учёные мужи засунули обезьяну внутрь некой конструкции, имеющей только два выхода, и уселись наблюдать какой из двух путей она выберет. Обезьяна нашла третий путь. |
||||
|
||||
Резонный вопрос — а стоит ли этим заниматься? Безусловно! И чем лучше ваш процессор, чем дальше используемая архитектура от стандартной (i486-i686) тем более значительный выигрыш вы получите. Ускоряется всё: файловые операции, работа с сетью, вывод на экран. Массаракш!, такое впечатление,что я не успеваю убрать палец с кнопки, а прога уже запустилась и работает. Глюки и баги оптимизированных прог? А вот не замечал как-то. |
||||
|
||||
Всё нижеизложенное есть по сути компиляция идей с различных форумов и блогов, с поправками на специфику MOPS LINUX и здравого смысла автора. Ну или того, что автор понимает под «здравым смыслом». |
||||
|
||||
Для начала отметим, что пакеты в slackware (да и в Мопсе) это, по сути, архивы tar.gz , а зависимости Мопс держит в файле data.xml, который модно редактировать как угодно. Описывать собственно приемы оптимизации я не стану, инфы в сети достаточно, отмечу лишь, что наиболее эффективные флаги компилятора (далее Фк) под мой 2-х ядерный атлон выглядят так - |
||||
|
||||
CFLAGS="-O3 -march=native -mtune=native -mfpmath=387" CXXFLAGS="-O3 -march=native -mtune=native -mfpmath=387" |
||||
|
||||
Задать их можно либо |
||||
|
||||
Фк ./configure [ параметры проги ] либо |
||||
make Фк |
||||
|
||||
Либо непосредственно редактируя Makefile (или ``*.pro``) в случае использования cmake или qmake. В случае qmake искомые параметры нужно можно задавать через скрипт вида |
||||
|
||||
find . -type f -name '*.pro' | while read FILE; do |
||||
echo "QMAKE_CXXFLAGS_RELEASE = %Фк" >> "$FILE" |
||||
echo "QMAKE_CFLAGS_RELEASE = %Фк" >> "$FILE"; |
||||
done |
||||
|
||||
Если же используется scons, редактировать нужно файл параметров сборки. Кстати, такой метод — редактирование — есть самый надежный и он же самый затратный, поэтому использую я его только тогда, когда не проходят другие способы (последний довод королей!) :-D Под 2-х ядерный проц лучше задать |
||||
|
||||
make -j4 |
||||
|
||||
оно быстрее будет (общая фрмула -j2 * кол-во ядер), но внимательно следите за температурой проца - на таких задачах возможен перегрев, если охлаждение вам делал пьяный китаец Сяо. |
||||
|
||||
За процессом сборки желательно наблюдать лично, часто проги норовят проигноривать заданные опции сборки (используются ли ваши Фк можно узнать из вывода на экран в процессе компиляции). Если же таковые собшения на экан не выводятся (cmake например любит скрывать вывод отладки) - не беда даём команду типа cmake -LAN, и вообще доки рулят. |
||||
|
||||
Теперь, когда сборка и оптимизация закончена: |
||||
|
||||
- Создаём каталог ~/pak (название условное) |
||||
- Создаём в нем 2 подкаталога /install и /usr (подразумевается что мы задали--prefix=/usr) |
||||
- В подкаталоге install создаём 2 файла: data.xml и slack-desk |
||||
|
||||
data.xml должен иметь следующий вид: |
||||
|
||||
<?xml version="1.0" encoding="utf-8"?> |
||||
<package> |
||||
<name> |
||||
ecikal |
||||
</name> |
||||
<version> |
||||
1.1 |
||||
</version> |
||||
<build> |
||||
bdn |
||||
</build> |
||||
<arch> |
||||
4a |
||||
</arch> |
||||
<short_description> |
||||
клиент dс++ |
||||
</short_description> |
||||
<description> |
||||
o3 athlon64 |
||||
</description> |
||||
</package> |
||||
|
||||
slack-desk, вообще говоря, обычный тесктовой файл: |
||||
|
||||
psi: psi charts SMP CPU, load, Disk, and all active net interfaces |
||||
psi: automatically. An on/off button and online timer for the PPP interface |
||||
psi: is provided. Monitors for memory and swap usage, file system, internet |
||||
psi: connections, APM laptop battery, mbox style mailboxes, and cpu temps. |
||||
psi: Also includes an uptime monitor, hostname label, and clock/calendar. |
||||
|
||||
В МОПС он не используется и я даже не утруждаю себя его заполнением, сохраняю только потому, что туда удобно записывать различные замечания по работе программы, да и менеджер пакетов ругается, если его не находит. |
||||
|
||||
Теперь создаем скрипт сборки: |
||||
|
||||
#!/bin/bash |
||||
cd ~/pak/usr |
||||
chown -Rc root:root . |
||||
find . -perm 777 -exec chmod 755 {} \; |
||||
find . -perm 555 -exec chmod 755 {} \; |
||||
find . -perm 444 -exec chmod 644 {} \; |
||||
find . -perm 666 -exec chmod 644 {} \; |
||||
find . -perm 666 -exec chmod 644 {} \; |
||||
# Выставляем правильные права и владельца файлов перед инсталляцией |
||||
cd ~/pak && \ |
||||
tar -czf gk.tgz install/ usr/ && |
||||
# Архивируем |
||||
mpkg convert gk* && |
||||
# Конвертируем в формат пакетов мопса |
||||
mpkg gendeps2 gk* && |
||||
# Генерируем зависимости |
||||
rm gk.tgz && |
||||
rm -rf /home/den/pak/usr && |
||||
mkdir /home/den/pak/usr && |
||||
chown user:users ~/pak/usr |
||||
# Чистим за собой |
||||
|
||||
И только теперь выполняем (***от пользователя!***) |
||||
|
||||
make DESTDIR=~/pak/usr install |
||||
|
||||
В случае сборки cmake это будет |
||||
|
||||
make INSTALLROOT=~/pak/usr install |
||||
|
||||
Возможны и такие конструкции - |
||||
|
||||
make prefix=~/pak install |
||||
|
||||
Ну или: |
||||
|
||||
cmake -DCMAKE_CXX_FLAGS="flags" -DCMAKE_INSTALL_PREFIX="install prefix" - DDATA_INSTALL_DIR="data dir" |
||||
|
||||
Читайте доки для задания правильного префикса! Запускаем paket.sh (``**от рута!**``) и получаем готовый к инсталляции пакет ecikal-1.1-bdn.tgz (название будет в зависимости от того что написано в data.xml, редактировать его надо каждый раз) в котором прямо указаны зависимости, и который можно сразу же инсталлировать командой |
||||
|
||||
mpkg install ecikal-1.1-bdn.tgz |
||||
|
||||
Отмечу, что по данной методике собрано уже порядка 30-ти программ и они установлены на 50-ти с гаком компах, всё нормально работает. Менджер пакетов МОПСа довольно умен, сам добавляет в пакет не только зависимости но и скрипты очистки от старых библитек, т.е если я ставлю новую версию уже сушествуюшей проги она нормально обновляется и регистрируется в базе. |
||||
@ -0,0 +1,37 @@
|
||||
--- |
||||
title: Список тем для обучения преподавателей работе со СПО (список программ) |
||||
tags: school, altlinux |
||||
--- |
||||
|
||||
Настоящая статья содержит список основных программ, поставляемых в рамках пакета СПО для школ и вузов. Список ПО взят из "Соглашения об организации работ по внедрению в общеобразовательных учреждениях РФ пакета СПО". Полный текст [здесь](http://www.government.ru/content/governmentactivity/rfgovernmentdecisions/archive/2007/10/22/6660883.htm). |
||||
|
||||
Рассматриваемый пакет основан на дистрибутиве [AltLinux](http://www.altlinux.ru) с [KDE](http://www.kde.org) ([Русскоязычное сообщество](http://kde.ru)) в качестве основной среды. |
||||
|
||||
--- |
||||
|
||||
Список программ, с которыми должен уметь работать среднестатистический учитель, на уровне, достаточном для обучения других: |
||||
|
||||
- Операционная система (Linux + KDE). |
||||
- ПО для сжатия и архивирования файлов (Ark). |
||||
- ПО для защиты от вирусов и всех других типов вредоносных программ, а также от хакерских атак и спама (KlamAV + ClamAV, alterator-firewall)((видимо собственная разработка)). |
||||
- ПО для электронного многоязычного словаря (Stardict). |
||||
- ПО для оптического распознавания документов (Ocrad). |
||||
- ПО для создания и редактирования текстов (OpenOffice.org Writer). |
||||
- ПО для создания и редактирования электронных таблиц (OpenOffice.org Calc). |
||||
- ПО для создания и редактирования мультимедийных презентаций (OpenOffice.org Impress) |
||||
- ПО для создания и редактирования блок-схем (OpenOffice.org Draw). |
||||
- ПО для управления базами данных (OpenOffice.org Base). |
||||
- ПО для управления электронной почтой и персональными контактами (Mozilla Thunderbird). |
||||
- ПО для рисования и редактирования цифровой живописи (GIMP). |
||||
- ПО для обработки и редактирования растровой и векторной графики (Inkscape). |
||||
- ПО для обработки и редактирования графических цифровых изображений (GIMP). |
||||
- ПО для верстки и подготовки публикаций (Scribus). |
||||
- ПО для обработки и монтажа аудио-записей (Audacity). |
||||
- ПО для обработки и монтажа видео-записей (Kino). |
||||
- ПО для создания и редактирования интернет-приложений (Quanta Plus). |
||||
- ПО для объектно-ориентированного программирования и разработки приложений (Kdevelop, Lazarus, Gambas). |
||||
- ПО для управления общеобразовательным учреждением. |
||||
- ПО для исключения доступа учащихся к интернет-ресурсам, несовместимым с задачами их воспитания (Squid и модуль сопряжения с федеральным сервером фильтрации контента). |
||||
- ПО для создания и редактирования интерактивных мультимедийных материалов (OpenOffice.org Impress). |
||||
|
||||
[Ссылка](http://ru.wikipedia.org/wiki/%D0%9F%D0%B5%D1%80%D0%B5%D1%87%D0%B5%D0%BD%D1%8C_%D1%88%D0%BA%D0%BE%D0%BB%D1%8C%D0%BD%D0%BE%D0%B3%D0%BE_%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%BD%D0%BE%D0%B3%D0%BE_%D0%BE%D0%B1%D0%B5%D1%81%D0%BF%D0%B5%D1%87%D0%B5%D0%BD%D0%B8%D1%8F) на аналогичную статью в Википедии |
||||
@ -0,0 +1,75 @@
|
||||
--- |
||||
title: Fluxbox — красная таблетка |
||||
tags: software, fluxbox |
||||
--- |
||||
|
||||
> Синяя таблетка — так себе, ни в дугу ни в Красную Армию, зато красная — чистый термояд. |
||||
> (Эпиграф из Матрицы (В переводе Гоблина)) |
||||
|
||||
Для того, что бы настаивать что-то нужно знать, что и где настраивать, ну или хотя бы представлять конечный результат. Цель сего опуса — настроить Fluxbox так, чтобы обеспечить комфортную работу, разумеется все нижеприведенное исключительно моё ИМХО, буду рад если это будет кому-нибудь полезным. |
||||
|
||||
--- |
||||
|
||||
Начнем пожалуй с консоли, как наиболее мощного и гибкого средства настройки всего остального. В МОПС мне понравился urxvt, вот только шрифты и оформление оставляли желать лучшего. В меню fluxbox пишем: |
||||
|
||||
[exec] (urxvt) {urxvt -bg black -fg white -fn xft:Terminus-12} |
||||
|
||||
Теперь urxvt имеет вполне пристойный вид (кому надо донастроит). Кстати, настоятельно рекомендую создавать свой личный файл с меню (`~./fluxbox/mymenu`, например и прописать это в `~./fluxbox/init` как `session.menuFile: ~/.fluxbox/mymenu`. Также можно задать клавиатурное сочетание для запуска этой команды , добавляем в ~/.fluxbox/keys что то вроде |
||||
|
||||
Mod 4 М : ExecCommand urxvt и тд... |
||||
|
||||
Теперь по нажатию Win(Super) + M выскакивает настроенный терминал. Можно это сделать и через файл `.Xdefaults` добавляя что то вроде |
||||
|
||||
URxvt*geometry: 84x28 |
||||
URxvt*background: #ffffff |
||||
URxvt*foreground: #000000 |
||||
URxvt.font: xft:Terminus-14 |
||||
|
||||
Через этот файл можно настроить почти всё X приложения, дерзайте! |
||||
|
||||
В Мандриве urxvt оказался каким-то глючным, впрочем там есть gnome-teminal — хорошо настраиваемая и функциональная программа. Еще совет — Когда в терминале ходишь стрелками по истории команд, вываливается всё подряд. Следующие строки позволяют выводить из истории только те команды, которые начинаются с уже набранных букв: |
||||
|
||||
Это нужно добавить в `/etc/inputrc`: |
||||
|
||||
"\e[A": history-search-backward |
||||
"\e[B": history-search-forward |
||||
|
||||
Всё хорошо но как монтировать флешки и двд? Может быть возможно подружить fluxbox и KDEшные службы, но в MOПCе я делал так: точки монтирования записываем в `etc/fstab`, чтобы user мог это монтировать, пишем скрипт следующего вида: |
||||
|
||||
mount /mnt/dvd || umount /mnt/dvd |
||||
# здесь пустая строка |
||||
# не знаю почему но без неё оператор if работает не правильно |
||||
mount -l | grep /mnt/dvd > vivod.grep |
||||
if [ -s vivod.grep ]; then |
||||
urxvt -e mc /mnt/dvd |
||||
else |
||||
xmessage " Device Unmounted!!! " |
||||
fi |
||||
|
||||
Затем добавляем в `~/.fluxbox/keys` что то вроде: |
||||
|
||||
Mod 4 D : ExecCommand (путь к скрипту) |
||||
|
||||
Теперь по нажатию Win(Super)+D выводится окно mc со списком файлов на двд, или, если закрыть это окно, и снова нажать эти кнопки двд размонтируется с сообщением, "Devise Unmounted!!!". Для визуализации процесса можно использовать gkrellm (собсвенно он и монтировать умеет, но на ноуте удобнее 2 клавиши нажать чем по тачпаду елозить. Кстати если флешка и или другой монтируемый девайс имееют несколько разделов, это не проблема. Просто модифицируем скрипт натравив на подключаемое устройство fdisk , а затем grep и маунт для каждого раздела (и со своими параменрами если надо). Между прочим это единственный способ которым я смог сразу подключать винты с NTFS разделами на запись. Ну не знаю почему, но в Мандриве 2008.1 для этого приходилось таки лезть в консоль, а теперь с этим скриптом — нет, монтирует правильно и быстро. |
||||
|
||||
Демон hal я уж просто отключил. Вообще я стараюсь не захламлять систему глямурными примочками типа krandrtray, ну зачем? Если нужно спешно поменять разрешение экрана или частоту есть команда xrandr которая умеет и то и другое, лучше и удобнее., а еще это команда умеет правильно и качественно выводить изображения на 2 монитора, (или тв) В общем читайте доки! |
||||
|
||||
Если нужно управлять микшером, также нет никакой нужды запускать kmix! В файл keys пишем |
||||
|
||||
178 : ExecCommand aumix -v +5 # Увеличить громкость на 5 % |
||||
179 : ExecCommand aumix -v -5 # Уменьшить гомкость на 5% |
||||
177 : ExecCommand aumix -v 0 # Выключить звук |
||||
|
||||
177-179 - коды соответствующих клавиш, узнать код можно запустив программу xev. Для визуализации уровня громкости также можно использовать gkrellm — отличная программа, рекомендую. |
||||
|
||||
Может показаться, что я противник графических утилит, нет, я сторонник простоты и эффективности. Пример - в Мандриве (да и Виндовс) я настраивал сеть и интернет с помощью графических утилит, 5 минут тыркаешь мышью, и готово. Но вот я в МОПСе ... графическую тулзу запускать лень. В консоли пишем |
||||
|
||||
su |
||||
ifconfig бла-бла-бла |
||||
route add бла-бла-бла |
||||
|
||||
10 секунд и интернет работает (и по сей день работает). Заодно (в связи с использованием собственных скриптов и клавиатурных команд) отключил пару стартовых служб дабы ускорить загрузку ноута и сэкономить батарею. Кому как а мне понравилось. |
||||
|
||||
Впрочем отказ от графических тулз вовсе не означает, что ваш рабочий стол выглядит сурово, по спартански... |
||||
|
||||
[Продолжение следует](/articles/2010/01/02/fluxbox_2_reboot/) |
||||
@ -0,0 +1,32 @@
|
||||
--- |
||||
title: Fluxbox — последняя перезагрузка. |
||||
tags: fluxbox, software |
||||
--- |
||||
|
||||
> После системного сбоя следует перезагрузка |
||||
> Матрица часть 2 RELOADED |
||||
|
||||
Почему Fluxbox? А вот надоело мне читать блоги и статьи на тему "Как сделать загрузку Убунты за 40 сек" и тому подобные вещи. KDE и Gnome безусловно заслуживают уважения, но: |
||||
|
||||
- Это рабочие среды призванные удовлетворить максимальное количество юзерских требований, громоздкие и универсальные. Швейцарским ножом можно забивать гвозди, но добрый старый молоток сумеет это лучше. Если вы точно знаете что вам нужно, и как это делать, лучше использовать специализированный инструмент. |
||||
- Количество глюков и багов в рабочей среде прямо пропорционально размеру кода этой среды. |
||||
|
||||
--- |
||||
|
||||
Примеры - Мой ноут с Fluxbox на борту приводится в боевое состояние за 25 сек. С Кде 40 сек. Под КДЕ запуск игр (грешон батюшка!) сопровождался залипанием кнопок в DOOM 3 , полосами по экрану в GTI RASING , а уж в шахматы на chessplanet играть вообще было проблематично. И как я намучился в своё время с аськой Oskar v 4 ! Экспериментальным путем было установлено , что частые перезагрузки и отрубания сетевого кабеля лечат некоторые глюки (пусть и не надолго) . Впрочем мои изыскания по части новых заклинаний в духе удэгейских шаманов кончились ... После очередной перезагрузки (шла турнирная партия на Chessplanet наша команда играла с немцами , битва была жестокой, а меня опять выкинуло) я нажал куда-то не туда, в окне логина, оказавшись во Fluxbox вместо KDE . Ну есть оказывается в Мандриве такая штука! К счастью я не растерялся — сумел найти там консоль, снова запустить wine, и даже довести партию до победы. Когда отгремели победные залпы , я вспомнил , что глюков (больших и мелких) не было! И это была моя последняя вынужденная перезагрузка .... Конечно изучать новый WM это не малину у тётки трескать, но терпение ! Оно того стоит. |
||||
|
||||
Далее идут рекомендации из личного опыта |
||||
|
||||
Стоит скачать последнюю версию Fluxbox, и даже перекомпилировать её из сырцов , независимо от того есть ли она в дистрибутиве. В Мандриве 2008.1 всё необходимые gevel пакеты уже были. В блистательной Слаке (точнее её православной ипостаси MOPS 6.2) пришлось установить библиотеку imlib2 , что не вызвало затруднений. Ссылок на соответствующие ресурсы не привожу, резонно полагая , что джентльмен вооруженный гуглом , сумеет найти даже янтарную комнату Петра I , а про какую то прогу и говорить смешно. |
||||
|
||||
Компилить лучше с параметром ./configure —prefix=/usr —enable-nls , дабы включить русский язык . Перед выполнением make install удалите пакет fluxbox средствами дистрибутива. Конечно после этого невозможно будет выбрать fluxbox при загрузке из kdm (или другого dm) но это не беда. Просто идем в /etc/x11 ищем там скрипты запуска WM правим чтобы запускать fluxbox вместо icewin например , вуаля! А если вы пользуетесь командой startx , достаточно сделать в домашней директории исполняемый файл .xinitrc и прописать прописать там `Fluxbox &` Заготовки xinitrc в дистрибутиве несомненно найдутся , тонкости поцесса там расписаны лучше чем это сделал бы я . |
||||
|
||||
Итак Fluxbox запушем переходим к настройке. |
||||
|
||||
P.S. |
||||
|
||||
«Я бы для "пакетно-ориентированных" дистрибутивов не стал рекомендовать ставить софт через make install. Лучше собрать пакет и установить из него. Скачиваем src.rpm нужного пакета из репозитория дистрибутива, извлекаем .spec, слегка правим его (указываем новую версию/релиз, файл с исходниками и т.д.) и запускаем скрипт rpmbuild. Обычно этого хватает. Иногда приходится более глубоко копаться в .spec-файле, но там всё просто, проблем возникнуть не должно. Заодно в .spec-файле можно реализовать создание "скриптов запуска WM"» |
||||
|
||||
Сие замечание представляется мне идеологически правильным, сообственно сборка пакетов не столь сложна как кажется. Начать осваиваить её, стоит впрочем, с более простых приложений. |
||||
|
||||
[Продолжение следует](/articles/2010/06/06/fluxbox_3_awakening/) |
||||
@ -0,0 +1,186 @@
|
||||
--- |
||||
title: Fluxbox — пробуждение |
||||
tags: software, fluxbox |
||||
--- |
||||
|
||||
> Истинная свобода — самоограничение. © АниMатрица |
||||
|
||||
- [Часть первая](/articles/2010/01/02/fluxbox_1_red_pill/) |
||||
- [Часть вторая](/articles/2010/01/02/fluxbox_2_reboot/) |
||||
|
||||
Любая оконная среда есть средство запуска софта, эффективность и качество WM (или DE) определяется в первую очередь возможностями комфортной работы с соответствующими приложениями. Конечно, тут всё зависит от личных предпочтений, поэтому, нижеследующее есть исключительно ИМХО автора. |
||||
|
||||
--- |
||||
|
||||
Навигация и ЛВС |
||||
---------------- |
||||
|
||||
Ну с консолью все ясно — лучше МС (Midnight Commander) не найти. А вот с графикой... Ну не нравятся мне однопанельные менеджеры типа thunar, а из двух панельных заслуживает внимания только krusader, но как и любое KDE приложение, запуск его во fluxbox происходит неторопливо и неповоротливо. |
||||
|
||||
Собственно есть ещё Double Commander и BeeSoft Commander (список велик!) но их приходится долго и упорно настраивать, добиваясь приемлемого внешнего вида и функционала. А krusader умеет всё "из коробки". |
||||
|
||||
Решением стало пересборка krusader 2.0 из исходников с оптимизацией под конкретный процессор. Фрагмент сборочного скрипта: |
||||
|
||||
SLKCFLAGS="-O3 -march=presscott -mtune=presscott" |
||||
cmake \ |
||||
-DCMAKE_C_FLAGS:STRING="$SLKCFLAGS" \ |
||||
-DCMAKE_CXX_FLAGS:STRING="$SLKCFLAGS" \ |
||||
|
||||
Создание пакетов в OC MOPS Linux рассматривалось в статье [«Слакварное ./configure»](/articles/slakvarnoe_._configure/) , поверьте функционал и удобство krusader (кроме всего прочего поддерерживаются протоколы ftp: smb: lan:) вас не разочаруют! Теперь имеем существенное ускорение времени загрузки и выполнения файловых операций. К тому же — данная программа умеет запускаться в лотке и может быть настроена на запуск только одной копии приложения (смотрите настройки!). |
||||
|
||||
Из многочисленных фич и хинтов существующих для mc и его графического собрата, приведу один — но забойный! Сколько раз видел как люди заходят в папку (~100 файлов и начинают тупо скроллить пока не найдут нужный... Расслабьтесь. Нажмите **Ctrl + s** (для mc) и наберите первую букву имени нужного файла, дело пойдёт веселее! А в krusader достаточно просто зайти в папку и сразу же ввести нужную букву с клавиатуры, доки рулез! |
||||
|
||||
В ``~/.fluxbox/startup`` пишем: |
||||
|
||||
krusader & |
||||
|
||||
Чтобы избежать дублирования экземпляров программ лучше оформить так |
||||
|
||||
pgrep krusader >> /dev/null || krusader & |
||||
|
||||
В `~/.fluxbox/menu:` |
||||
|
||||
[exec] (krusader) {krusader} |
||||
|
||||
В ``~/.fluxbox/keys``: |
||||
|
||||
Mod4 K :Exec krusader |
||||
|
||||
Получаем, krusader стартующий в трее (вместе с fluxbox) и вызываем его на рабочий стол либо мышью (через меню, а во fluxbox меню вызывается щелчком по любому месту десктопа), либо через клавиатурное сочетания, (в нашем случае **WIN + K**) Быстро, красиво, удобно! |
||||
|
||||
Интернет и почта |
||||
----------------- |
||||
|
||||
Лично я использую сразу несколько браузеров. В ЛВС это firefox. Пересборка и тут даёт неплохие результаты но поскольку прога «тяжёлая» (размер исходников ~ 50MB), то это на любителя. |
||||
|
||||
Команда ниже позволит несколько ускорить работу браузера: |
||||
|
||||
for f in ~/.mozilla/firefox/*/*.sqlite; do |
||||
sqlite3 $f 'VACUUM; REINDEX;'; |
||||
done |
||||
|
||||
Если скачать расширение Firetray и стартовать в лотке, то будет совсем хорошо. Тоже самое я делаю с почтовым клиентом Thunderbird. Методика старта при загрузке и назначения клавиатурных сочетаний — аналогично. В интернет в использую оперу, исходники этой замечательной программы, увы, недоступны. Добавить огоньку можно запуская её командой - `opera -nomail`, если конечно вы не используете встроенный в этот браузер почтовым клиент. |
||||
|
||||
Дополнительно отметим, что fluxbox умеет группировать окна, а также запускать их на заданном рабочем столе, с нужными размерами и расположением. Это задаётся через `~/.fluxbox/apps`: |
||||
|
||||
[group] |
||||
[app] (name=thunderbird) (class=Thunderbird) |
||||
[app] (name=opera) (class=Opera) |
||||
[app] (name=firefox) (class=Firefox) |
||||
[Dimensions] {1168 994} |
||||
[Position] (UPPERLEFT) {0 0} |
||||
[Deco] {NORMAL} |
||||
[Close] {yes} |
||||
[Alpha] {255 201} |
||||
[end] |
||||
|
||||
Теперь оба браузера (и почтовый клиент), будут группироваться в единый таб, что достаточно удобно. Переключение между табами можно задать своё (``~/.fluxbox/keys``) |
||||
|
||||
Мультимедиа |
||||
------------ |
||||
|
||||
С аудио приложениями всё прекрасно, есть консольный mocp, или гламурный qmmp, на который существует огромное количество скинов. А вот с видео... Попытка посмотреть некий DVD-DL диск имеющий 93 (sic!) главы закончилась неудачей. Перепробовал всё имеющиеся в системе плееры, безрезультатно. Изумленный я написал на форум MOPSа , где меня первым делом спросили как называется кино, (дабы не покупать его), а также высказали предположение, что причиной является именно большое кол-во глав. |
||||
|
||||
А чего этот же диск на этом же железе в ОС Windows нормально воспроизводится — Патрег его знает! Добро б на DVD-DL выходили бы только избранные места из переписки Клаудии Собчак и Вишнавантана Тимати, так там же и нужные вещи бывают! Стало ясно , что надо брать дело в свои руки. |
||||
|
||||
Решением стал *vlc 0.9.8a* (любимый ранее кафеин разочаровал задумчивым стартом, иные видеопроигрыватели также не глянулись (dvd-dl никто из них так и не показал)) |
||||
|
||||
Вы думаете я решил не маяться с пересборкой и просто скачал готовый пакет с репы MOPSa? Да, но скачанный от туда плеер мало что не воспроизводил звук с ``*.VOD``, на показывал HD видео, он еще и крашился от малейшего изменения настроек. |
||||
|
||||
Изумленный я скачал его из реп Slackware 12, но лучше не стало. Короче, я его пересобрал, пришлось разобраться с дюжиной кодеков, кое что собрать с нуля, или просто пресобрать что посвежее. Зато теперь имею прогу которая показывает все что у меня есть, стартует быстро, работает качественно, fluxbox-way, что ещё скажешь. |
||||
|
||||
Монтирование носителей |
||||
----------------------- |
||||
|
||||
Вообще-то я долго считал, что hal мне не нужен, и монтировал носители, собственными скриптами. Увы прогресс не стоит на месте, мало того, что появились mp3 плееры, usb-HDD и usb-DVD. В обшем я наивно считал , что hal и d-bus мне помогут , ага . Во первых оказалось, что hal монтирует носители, руководствуясь не заданными мной правилами (``*.fdi``) а неизвестно чем , во вторых что он не умеет монтировать NTFS … Собственно проблема (добавить hal свои опции монтирования) уже [известна](http://archlinux.org.ru/node/146) вот здесь предлагается и решение. Но увы, чем-то мне оно не понравилось. Недолгие поиски привели к использованию демона halevt, его особенности |
||||
|
||||
- Монтирует как и в иксах так и в консоли |
||||
- Может быть настроен отдельно для каждого пользователя. |
||||
- Позволяет задать опции, точки монтирования, выполняемые перед (после ,вместо) монтированием действия и много чего еще. |
||||
|
||||
Фрагмент конфига ``/usr/local/etc/halevt.xml``: |
||||
|
||||
<halevt:Device match="&MOUNTABLE; &hal.volume.fstype=vfat"> |
||||
<halevt:OnInit exec="halevt-mount -u $hal.udi$ -o quiet , -o flush"/> |
||||
<halevt:Insertion exec="halevt-mount -u $hal.udi$ -o quiet , -o flush"/> |
||||
</halevt:Device> |
||||
<halevt:Device match="MOUNTABLE" hal.volume.fstype=ntfs-3g"> |
||||
<halevt:OnInit exec="halevt-mount -u $hal.udi$ -o quiet"/> |
||||
<halevt:Insertion exec="halevt-mount -u $hal.udi$ -o quiet"/> |
||||
</halevt:Device> |
||||
|
||||
Нетрудно приделать и отображение сообщений о присоединенных устойствах : |
||||
|
||||
<halevt:Device match="hal.block.device & hal.block.is_volume = true & hal.volume.mount_point"> |
||||
<halevt:Property name="hal.volume.is_mounted"> |
||||
<halevt:Action value="true" exec="halevt-mount -s"/> |
||||
<halevt:Action value="true" exec="notify-send -i "/usr/share/icons/oxygen/48x48/devices/media-optical-audio.png" "$hal.volume.fstype$ ""$hal.volume.fsversion$"" USB диск смонтирован в" $hal.volume.mount_point$;"/> |
||||
</halevt:Property> |
||||
</halevt:Device> |
||||
|
||||
А также выпоняемые с устройством действия : |
||||
|
||||
<halevt:Device match="hal.volume.disc.is_videodvd = true"> |
||||
<halevt:Insertion exec="vlc dvd:///dev/sr0"/> |
||||
</halevt:Device> |
||||
|
||||
Меня напрягало, что в Windows (да в Linux если использовать thunar) попытка отмонтировать занятое устройство вызыват сообщение "Устройство занято попробуйте позже", но без указания конкретного приложения, занявшего девайс. Нижеследующий скрипт решает эту проблему: |
||||
|
||||
#!/bin/sh |
||||
# Халевт записывает устройства ( и добавляет записи о точках монтирования в ~/.halevt-mount/uditab , |
||||
# поскольку (от)монтирование |
||||
# может быть выполнено не только халевт но и другими средствами |
||||
# (например из консоли), полезно "синхронизировать базу" |
||||
halevt-mount -s |
||||
# Эта конструкция встретится дважды - оформим как функцию . |
||||
pro() |
||||
{ |
||||
grep "media" ~/.halevt-mount/uditab | cut -d: -f 2- > ~/.halevt-mount/ze |
||||
} |
||||
|
||||
pro |
||||
|
||||
# получим адрес (/dev/XXX) устройства |
||||
if [ -e ~/.halevt-mount/uditab ]; then |
||||
if [ -s ~/.halevt-mount/ze ]; then |
||||
halevt-umount -a |
||||
# Если устройство существует - отмонтируем - если нет - известим юзера |
||||
sleep 1.5 |
||||
pro |
||||
if [ -s ~/.halevt-mount/ze ]; then |
||||
st=$(cat ~/.halevt-mount/ze | cut -d : -f 1) |
||||
ss=$(lsof $st | cut -d " " -f -2) |
||||
# Выясняем кто занял устройство |
||||
notify-send "Устройство занято приложением" " <b>$ss</b> попробуйте позже " |
||||
else |
||||
st=$(cut -d : -f 2 ~/.halevt-mount/uditab) |
||||
notify-send "Можно извлечь" " <b>$st</b> из компа " |
||||
fi |
||||
else |
||||
notify-send "Смнотированных дисков нет!" |
||||
fi |
||||
else |
||||
notify-send "Флеш диски не найдены " |
||||
fi |
||||
|
||||
Tеперь присоединение флешки сопровождается сообщением от том, какую фс она использует, куда она смонтирована, при этом вызывается mc (показывая имеющиеся файлы), при отмонтировании также выводится сообщение об успехе операции, или уведомление, что такое то приложение мешает сделать это. Лепота! |
||||
|
||||
Напомню что приведённый скрипт также можно повесить на горячую клавишу или приписать в меню ( для удобства вызова). Ситуация с NTFS также решена уже , соответствующие правила hal можно взять например [здесь](http://wiki.archlinux.org/index.php/HAL). |
||||
|
||||
Игры |
||||
----- |
||||
|
||||
Ну какой же русский не любит быстрой езды? Описания запуска под wine Need For Speed и GtiRasing оставим более продвинутым камрадам :-P заметим только , что наилучшая производительность и стабильность достигается при запуске игр в отдельной сессии Х-ов например так |
||||
|
||||
В `~/.fluxbox/menu` пишем: |
||||
|
||||
[exec] (GTI Racing) {startx /home/den/Скрипты/Script/GtiRacing -- :1} |
||||
|
||||
cd /home/den/.wine/drive_c/'Program Files'/'GTI Racing' |
||||
wine GTIRacing.exe |
||||
|
||||
Напоследок скажу - из многих WM и DE перепробованых мною, fluxbox оказался самым простым и удобным. Ну не знаю почему авторы некотрых из них (не будем тыкать пальцем) так любят интерфейс WIN 95, мне он кажется просто неудачным. Не понимаю и моды писать конфиги в xml или (Сохрани Создатель!) в виде win подобного реестра... |
||||
|
||||
Кстати, в других оконных средах мне так и не удалось запускать в при старте 14 (А я совершенно не вижу почему бы благородному дону...) разных программ, и чтоб ничего не глючило и не тормозило. А во fluxbox я еще и 2 копии ChessMaster 9000 запускаю, + почту + музыку + все что взбредёт в голову. Повторить же этот подвиг под каким нибуть awesome до сей поры не удавалась , увы. Fluxbox для меня сочетание молненосной быстроты и невообразимой мощи, кажется нечего лучшего просто нет ... |
||||
|
||||
*Продолжение вероятно* |
||||
@ -0,0 +1,74 @@
|
||||
--- |
||||
title: rar2zip |
||||
tags: shell, linux, repost |
||||
--- |
||||
|
||||
> программист - это такой вид идиота, который потратит час на пятиминутную работу, чтобы потом её за секунду сделал компьютер. |
||||
|
||||
Фичи: |
||||
---- |
||||
|
||||
* Запароленные архивы пропускаются |
||||
* Даты модификации файлов в внутри архивов - сохраняются как есть. |
||||
* Работает полностью автоматически, если невозможно создать файл в исходной директории - матерится и переходит к следующему архиву. |
||||
* Выдает лог работы |
||||
* Понимает как относительные, так и абсолютные пути |
||||
|
||||
* Использует для своей работы системную временную директорию (обычно это /tmp), берегитесь переполнения. |
||||
Ограничения: |
||||
|
||||
--- |
||||
|
||||
#!/bin/bash |
||||
|
||||
LOGFILE=$(mktemp) |
||||
|
||||
if [ -z "$1" ]; then |
||||
echo "usage: $0 <dir>" |
||||
exit 1 |
||||
fi |
||||
|
||||
find "$1" -name *.rar | while read FILE |
||||
do |
||||
if [ ! -w "$FILE" ]; then |
||||
echo "can't write to file, skipped: $FILE" |
||||
continue |
||||
fi |
||||
|
||||
# path to file must be absolute, non relative |
||||
if [ "${FILE:0:1}" != "/" ]; then |
||||
FILE="$(pwd)/$FILE" |
||||
fi |
||||
|
||||
unrar t -p- "$FILE" 1> /dev/null 2> /dev/null |
||||
if [ "$?" -ne 0 ]; then |
||||
echo "Password-protected file, please, repack manually: $FILE" | \ |
||||
tee "$LOGFILE" |
||||
continue |
||||
fi |
||||
|
||||
OWNER=$(stat -c "%u" "$FILE") |
||||
GROUP=$(stat -c "%g" "$FILE") |
||||
FMODE=$(stat -c "%a" "$FILE") |
||||
TDIR=$(mktemp -d) |
||||
NFILE=$(basename "$FILE" .rar) |
||||
NFILE="${NFILE}.zip" |
||||
DEST=$(dirname "$FILE") |
||||
|
||||
pushd "$TDIR" > /dev/null |
||||
unrar x -ts -ow -idq "$FILE" && \ |
||||
zip --latest-time --quiet --recurse-paths "$NFILE" * |
||||
|
||||
chown "$OWNER:$GROUP" "$NFILE" && chmod "$FMODE" "$NFILE" && \ |
||||
mv -i "$NFILE" "$DEST/" && rm "$FILE" && echo "Repacked: $FILE" |
||||
popd > /dev/null |
||||
|
||||
rm -rf "$TDIR" |
||||
# exit 0 |
||||
done |
||||
|
||||
echo "See logfile for possible errors: $LOGFILE" |
||||
|
||||
# vim: set syntax=sh ts=2 noet |
||||
|
||||
Единственная проблема: У меня больше не осталось rar-архивов... :-( |
||||
@ -0,0 +1,20 @@
|
||||
--- |
||||
title: Простой способ перекидывания файлов по сети между nix машинами |
||||
tags: linux, shell, repost |
||||
--- |
||||
|
||||
Способ не претендует на оригинальность, но, по моим наблюдениям, им мало кто пользуется. Не требуется rsync, самба, nfs, ftp и прочее. Только стандартный tar и netcat. Две строчки команд, по одной на машину. |
||||
|
||||
--- |
||||
|
||||
На машине-источнике: `tar -cv src/dir/ | nc -c -t <dest ip> <port>` |
||||
|
||||
На машине приемнике: `cd dest/dir nc -t -l -c -p <port> | pv | tar -x` |
||||
|
||||
pv - используется в качестве прогресс-бара, его можно не включать в конвеер и обойтись параметром «-v» у tar'а. |
||||
|
||||
Если абсолютно уверены в надежности сети между машинами, «-t» у netcat'а можно заменить на «-u» (tcp -> udp), будет чуть быстрее. |
||||
|
||||
UPD: Похоже, в некоторых случаях, последний файл в архиве "бьётся". Неплохо бы было выяснить почему. Обойти можно добавив в конец архива ещё какой-нибудь один файл. |
||||
|
||||
UPD2: Похоже, я не первый кто наступает на эти грабли. Проблема описана [здесь](http://sourceforge.net/tracker/?func=detail&aid=1115190&group_id=52204&atid=466046). |
||||
@ -0,0 +1,83 @@
|
||||
--- |
||||
title: CA в "школьном" AltLinux'е |
||||
tags: altlinux, debian, ненависть, сертификаты, school, репост |
||||
--- |
||||
|
||||
В рамках совместного с AlAn'ом проекта по созданию "школьной образовательной среды", как он это называет, наткнулся на интересные грабли в настройке альтовского сервера. Возможно, кому-то пригодится и сэкономит пару выходных. |
||||
|
||||
Общие описание найденных граблей |
||||
--------------------------------- |
||||
|
||||
В прошлые выходные столкнулся с граблями при настройке альтовского сервера. |
||||
|
||||
Зачем это понадобилось: стоит этакий "контроллер домена" на альте, на нем стоит ldap с альтератором, рядом стоит файлсервер с самбой, где хранится большая часть файлá в сети. Возникает логический вопрос - "а не сделать ли нам авторизацию самбы через альтовский ldap?". А поскольку гонять информацию plaintext'ом между серверами мягко говоря небезопасно, нужно шифрование. |
||||
|
||||
--- |
||||
|
||||
Переношу корневой сертификат на файлсервер, добавляю в бандл с корневыми (см ниже). Прописываю все нужные опции в ldap.conf, libnss_ldap.conf (см ёще ниже). Пытаюсь настроить - хрен, дебиан ни в какую не хочет доверять альтовским сертификатам. WTF? |
||||
|
||||
openssl s_client -connect ldap.school80.lan:636 \\ |
||||
-CAfile /etc/ssl/certs/ca-certificates.crt |
||||
gnutls-cli -p 389 --print-cert --x509certfile \\ |
||||
/etc/ssl/certs/ca-certificates.crt ldap.school80.lan |
||||
|
||||
Обе команды ругаются на самоподписанный сертификат, причем вторая показывает на причину - слабый алгоритм подписи md5WithRSAEncryption. |
||||
|
||||
Ага, значит косяк в альтовском сервере. ЧСХ - используемый релиз дебиана вышел этим летом и с тех пор мной не обновлялся, а вот альт, хоть и вышел уже достаточно давно, но обновлен он по самые помидоры - декабрьскими репами. |
||||
|
||||
Пляшем с бубном для того, чтобы заставить альт использовать sha1 и увеличить длину ключа[^fn1], регенерируем сертификаты. Проверяем ещё раз - работает. |
||||
|
||||
Описание плясок с бубном |
||||
------------------------- |
||||
|
||||
Лезем в админку альта и видим что опции сертификатов нихрена не настраиваются. Готовим напильник, лезем в консоль и начинаем озираться в поисках настроек. Правим openssl.cnf - перегенерируем сертификаты - хрен там, опять килобайтный ключ и md5 вместо подписи. [^fn2] Материмся, ищем по ФС, где у нас лежат сертификаты: |
||||
|
||||
# find / -name *.crt |
||||
/usr/share/ca-certificates/ca-bundle.crt |
||||
/etc/httpd2/conf/ssl.crt |
||||
/etc/httpd2/conf/ssl.crt/server.crt |
||||
/var/lib/ldap/usr/share/ca-certificates/ca-bundle.crt |
||||
|
||||
ГДЕ?! Бандлы вижу, причем в 2х экземплярах (как оказалось, они слинкованы между собой.) Материмся, идем опять в админку, внимательно смотрим на ссылку "скачать сертификат". Формат "pem"[^fn3]. Блжад. Поиск по ФС, дубль 2: |
||||
|
||||
# find / -name *.pem |
||||
/var/srv/public/ca-root.pem (1) |
||||
/var/lib/ssl/certs/postfix.pem (2) |
||||
... |
||||
/var/lib/alterator-ca/CA/cacert.pem (3) |
||||
... |
||||
/var/lib/ldap/var/lib/ssl/certs/postfix.pem (4) |
||||
... |
||||
|
||||
Поскипаны файлы в одинаковых директориях. Нихрена не понятно, что, откуда и куда кладется. Экспериментально получено, что 3 директория - это то, что нам нужно, на её основе генерируется всё остальное. Причем (2) - это сами сертификаты демонов, (4) - их дубли в чруте для лдапа (нахрен они все там нужны?), а (1) - это отдельно положенный корневой сертификат в пределах досягаемости вебсервера. (2) и (4) слинкованы между собой на уровне файлов. |
||||
|
||||
Поскольку если просто "в лоб" поменять сертификаты на правильно сгенерированные - не выйдет - после нажатия кнопки в админке всё вернется "взад", то будем разбираться, откуда же берутся параметры. |
||||
|
||||
В общем, в конечном счете - нашел. 2 файла в /usr/bin: ca-sh-functions, cert-sh-functions и 1 файл в /usr/share/alterator-ca[^fn4]: CA.cnf . В первых 2х жестко прописаны размеры ключей - 1024 байта, во втором - так же жестко задан их алгоритм - md5. [^fn5] |
||||
|
||||
Меняем на нужное, перегенерируем корневой сертификат, ключи и остальные сертификаты. |
||||
|
||||
Проблема в том, что после обновления эта хрень опять сломается. В ca-sh-functions есть параметр, отвечающий за местоположение конфига, но если верить grep'у он больше нигде не упомянут, поэтому задать его "извне" не получится. |
||||
|
||||
Размеры ключей вообще прописаны без всяких переменных, тупо числом. Претензия, собственно, у меня только одна - "какого хрена не используется системный конфиг openssl?". |
||||
|
||||
Настройка Debian'а |
||||
------------------- |
||||
|
||||
Добавление корневого сертификата там производится через помещение его в /usr/local/share/ca-certificates/ и запуска либо update-ca-certificates (неинтерактивно) либо dpkg-reconfigure (интерактивно), после этого, наш сертификат будет добавлен в основной бандл /etc/ssl/certs/ca-cerificates.crt, используемый всеми, кому не попадя. |
||||
|
||||
Настройка libnss и pam_ldap - через сначала dpkg-reconfigure, потом правим руками опции для tls: ssl start_tls, tls_cacertfile [^fn6], uri. Конфиги лежат в /etc: libnss_ldap.conf и pam_ldap.conf. В первый рекомендую дописать "debug <n>", где <n> - уровень отладки. -1 выдаст что-то, по размеру напоминающее "Войну и мир". |
||||
|
||||
Также нужно поправить /etc/ldap/ldap.conf: URI и BASE - чтобы не указывать их каждый раз, дописать "TLS_CACERT /etc/ssl/certs/ca-cerificates.crt" - чтобы использовало корневые сертификаты и "TLS_REQCERT hard", чтобы даже не думало лезть в каталог без шифрования. |
||||
|
||||
[^fn1]: второе не обязательно, но раз уж взялись, то заодно и это поправим |
||||
|
||||
[^fn2]: вот это один из примеров "нескучности" альта и причин такой ненависти к нему |
||||
|
||||
[^fn3]: если посмотреть на него повнимательнее, то это тоже особый, альтовский "pem" - вместо сертификата с ключом в этом файле содержится текстовая информация о сертификате, сам сертификат ...и всё |
||||
|
||||
[^fn4]: основной конфиг в /usr, поразительно и ...нескучно |
||||
|
||||
[^fn5]: не "default", не "md5, sha1", как в дебиане, нет, "md5 с маленьким ключом хватит всем" |
||||
|
||||
[^fn6]: осторожно, грабли - `tls_cacertdir` не реализован и работать не будет |
||||
@ -0,0 +1,428 @@
|
||||
--- |
||||
title: Сборка пакета с препятствиями |
||||
tags: debian, school |
||||
--- |
||||
|
||||
Ниже описаны процесс сборки одного нестандартного пакета под дебиан, а также замечания по ходу сборки и возникших проблем. |
||||
|
||||
Пакет который я пытался собрать - обучающая среда "КуМир", созданная нашими славными российскими разработчиками. |
||||
Представляет с собой что-то наподобие IDE - редактор с подсветкой синтаксиса, лексическим анализатором, отладчиком и несколькими "исполнителями". "Исполнитель" в данном случае - аналог разделяемой библиотеки. |
||||
|
||||
--- |
||||
|
||||
debhelper - описание |
||||
-------------------- |
||||
|
||||
Основным способом сборки пакетов под deb-based дистрибутивы является сборка с помощью debhelper. |
||||
Это набор скриптов, призванных, в теории, упростить жизнь создателям и мейнтейнерам пакетов. |
||||
|
||||
Прежде чем начать, прочитайте [руководство сборщика пакетов Debian](http://www.debian.org/doc/manuals/maint-guide/index.ru.html), хотя бы по диагонали, чтобы примерно представлять себе как с этим обращаться. |
||||
|
||||
Технически, файлы описание пакета представляют собой кучу мелких файликов строго определенного формата в директории debian/ в корне пакета. Чтобы не создавать их вручную, воспользуйтесь ``dh_make`` - это развернет типовой шаблон для выбранного типа пакета. |
||||
|
||||
tar -xzf kumir-1.7.3.2369.tar.gz |
||||
cd kumir-1.7.3 |
||||
dh_make -f ../kumir-1.7.3.2369.tar.gz |
||||
<отвечаем на вопросы dh_make> |
||||
|
||||
Нам выдается предупреждение, что пакет должен уметь устанавливаться в произвольную директорию определяемой переменной DESTDIR[^fn1] |
||||
|
||||
Сразу после этого можно поудалять лишнее, чтобы не мозолило глаза. |
||||
Для данного пакета это будет так: |
||||
|
||||
* changelog - меняется с помощью dch -i (от DebianChangelog --increase) |
||||
* compat - оставляем без изменений, служебный файл |
||||
* control - файл описания пакета: название, версия, лицензия, зависимости, зависимости для сборки, и т.д. |
||||
* copyright - это лицензия на вашу работу по "дебианизации" пакета |
||||
* docs - файлы в пакете, которые считаются документацией |
||||
* <del>emacsen-*.ex</del> |
||||
* <del>init.d.ex</del> - это не демон, нет необходимости запускать его при старте системы |
||||
* <del>kumir.default.ex</del> - параметры для init-скрипта |
||||
* <del>kumir.cron.d.ex</del> - приложение не должно выполняться системным планировщиком (cron) |
||||
* <del>kumir.doc-base.ex</del> - документацию к проекту нужно будет оформлять отдельно |
||||
* <del>manpage.*.ex</del> - у нас нет документации в формате manpage |
||||
* menu.ex - файл, добавляющий программу в меню DE |
||||
* post*.ex - скрипты, выполняющиеся после установки и удаления пакета |
||||
* <del>pre*.ex</del> - скрипты выполняющиеся до установки и перед удалением пакета, |
||||
* README.Debian |
||||
* README.source |
||||
* rules - этот файл отвечает за сам процесс сборки пакета |
||||
* source |
||||
* <del>watch.ex</del> - файл описания для системы слежения за появлением новых версий пакетов |
||||
|
||||
О файле "rules" стоит упомянуть отдельно. По синтаксису - это обычный make-файл, но с фиксированными целями: ``binary binary-arch binary-indep build clean install``. При типичной сборке последовательность выполнения целей такова: ``build -> binary -> install`` |
||||
В новых версиях этот файл по умолчанию содержит следующее: |
||||
|
||||
#!/usr/bin/make -f |
||||
\%: |
||||
dh $@ |
||||
|
||||
При выполнении, эти правила (а \% + @$ говорят нам что это "неявные правила" (implicit rules)) разворачиваются вот так: |
||||
|
||||
build: |
||||
dh build |
||||
|
||||
binary: |
||||
dh binary |
||||
|
||||
install: |
||||
dh install |
||||
|
||||
"Но и это ещё не всё!" © dh - это на самом деле скрипт, который вызывает некоторую последовательность более низкоуровневых команд. (в документации он называется sequencer'ом). т.е. следующим шагом это развернётся так: |
||||
|
||||
#!/usr/bin/make -f |
||||
|
||||
\%: |
||||
dh $@ |
||||
|
||||
build: |
||||
dh_testdir |
||||
dh_auto_configure |
||||
dh_auto_build |
||||
dh_auto_test |
||||
|
||||
binary: |
||||
dh_testroot |
||||
dh_prep |
||||
dh_installdirs |
||||
dh_auto_install |
||||
dh_install |
||||
dh_installdocs |
||||
dh_installchangelogs |
||||
dh_installexamples |
||||
dh_installcatalogs |
||||
dh_installdebconf |
||||
dh_installinfo |
||||
dh_pysupport |
||||
dh_installinit |
||||
dh_installmenu |
||||
dh_installmime |
||||
dh_installmodules |
||||
dh_installlogcheck |
||||
dh_installlogrotate |
||||
dh_installppp |
||||
dh_installwm |
||||
dh_installxfonts |
||||
dh_bugfiles |
||||
dh_lintian |
||||
dh_icons |
||||
dh_perl |
||||
dh_usrlocal |
||||
dh_link |
||||
dh_compress |
||||
dh_fixperms |
||||
dh_strip |
||||
dh_makeshlibs |
||||
dh_shlibdeps |
||||
dh_installdeb |
||||
dh_gencontrol |
||||
dh_md5sums |
||||
dh_builddeb |
||||
|
||||
В свою очередь ``dh_*`` - это тоже скрипты, которые вызывают ещё более низкоуровневые команды, которые уже и выполняют, собственно, полезную работу. |
||||
|
||||
Т.е мы имеем минимум 3 слоя абстракции в системе сборки. Вот [здесь](http://russian.joelonsoftware.com/Articles/LeakyAbstractions.html) есть хорошее чтиво на эту тему. |
||||
|
||||
Система рассчитана опять же, на сборку сферичного пакета в вакууме. Но в реальности это не работает, обязательно всплывут какие-либо ньюансы™. Но пока что мы о них не знаем и только лишь рихтуем файл "control" примерно до такого состояния: |
||||
|
||||
--- a/debian/control 2012-03-15 12:02:36.000000000 +1100 |
||||
+++ b/debian/control 2012-03-16 14:25:15.000000000 +1100 |
||||
@@ -1,15 +1,17 @@ |
||||
Source: kumir |
||||
-Section: unknown |
||||
+Section: Education |
||||
Priority: extra |
||||
-Maintainer: unknown <user@vm9.test.lan> |
||||
-Build-Depends: debhelper (>= 7.0.50~) |
||||
+Maintainer: Alex 'AdUser' Z <ad_user@mail.ru> |
||||
+Build-Depends: dpatch, debhelper (>= 7.0.50~), qt4-qmake, libqt4-dev, libx11-dev, libxext-dev, python (>= 2.5), |
||||
Standards-Version: 3.8.4 |
||||
-Homepage: <insert the upstream URL, if relevant> |
||||
-#Vcs-Git: git://git.debian.org/collab-maint/kumir.git |
||||
-#Vcs-Browser: http://git.debian.org/?p=collab-maint/kumir.git;a=summary |
||||
+Homepage: http://www.niisi.ru/kumir/ |
||||
+Vcs-Svn: svn://lpm.org.ru/svn/kumir/branches/1.7/ |
||||
+Vcs-Browser: http://lpm.org.ru/svn/kumir/ |
||||
|
||||
Package: kumir |
||||
-Architecture: any |
||||
-Depends: ${shlibs:Depends}, ${misc:Depends} |
||||
-Description: <insert up to 60 chars description> |
||||
- <insert long description, indented with spaces> |
||||
+Architecture: i386 |
||||
+Depends: libqt4-core, libqt4-gui, libqt4-network, libqtscript4-core, libqt4-svg, libqt4-xml, libqt4-webkit, ${shlibs:Depends}, ${misc:Depends} |
||||
+Description: Kumir Language Implementation |
||||
+ Implementation of Kumir programming language, designed by academic Ershov. |
||||
+ Includes compiler, runtime, IDE, Robot and Draw. |
||||
+ Also includes addons: Turtle, Aquarius, Grasshopper. |
||||
|
||||
|
||||
Описания всех полей смотрите в документации по ссылке выше. Зависимости определяются по следующему алгоритму: |
||||
|
||||
- ищем в исходниках список зависимостей указанный разработчиком |
||||
* смотрим в README/INSTALL/BUILD/... |
||||
* если нашли - ищем подобные пакеты через apt-cache/aptitude/synaptic/... |
||||
* ищем подобные пакеты, но с суффиксом "-dev" |
||||
- если программа собрана для другого дистрибутива |
||||
* смотрим зависимости там |
||||
* опять ищем подобные пакеты, как в предыдущем шаге |
||||
- прописываем то, что нашли - через запятую в поле "Depends" (а пакеты с суффиксом "-dev" - в Build-Depends) |
||||
- пробуем собрать пакет через ``dpkg-buildpackage -rfakeroot`` |
||||
- если не собралось - смотрим, на чем остановились, и здесь уже гугл в помощь |
||||
- повторять предыдущий пункт пока не соберется |
||||
- всё что мы забыли - допишет в зависимости макрос ${shlibs:Depends} |
||||
|
||||
debhelper - сборка |
||||
------------------ |
||||
|
||||
С теорией вроде разобрались, теперь посмотрим, как же нам всё-таки собрать конкретно этот пакет. |
||||
|
||||
В корне директории есть configure.py и ссылка "configure" на него. Ага, начало стандартное[^fn2]. |
||||
|
||||
Здесь нас поджидают первые грабли, заботливо разложенные разработчиками - этот файл не исполняемый, т.е. ``./configure`` - не сработает. Запускать нужно явно, через ``python ./configure.py`` |
||||
|
||||
Вроде что-то отработало, попробуем дальше - ``make``. На этом этапе сборка может прерваться из-за неустановленных зависимостей. Но вроде тоже всё в порядке. |
||||
|
||||
Пробуем последний этап: ``make DESTDIR=/tmp/ install`` и сборка валится с сообщением об отказе в доступе для "/usr/local". $DESTDIR не работает, плохо, придется разбираться в системе сборки и смотреть как это поправить. |
||||
|
||||
В качестве системы сборки здесь используется qmake. |
||||
|
||||
qmake |
||||
----- |
||||
|
||||
Небольшое лирическое отступление. Зачем вообще нужен qmake? Дело в том, что Qt - это фреймворк и уже давно включает в себя модули на все случаи жизни. Эти модули периодически переписывают, добавляя новый функционал, убиряя устаревший, а иногда и и просто ради эстетичности и "красоты" кода. Так вот, qmake нужен, чтобы автоматически отслеживать зависимости и подставлять нужные флаги при линковке приложения. |
||||
|
||||
Файлы описания проекта выглядят как куча файлов *.pro, раскиданная по дереву с исходниками. |
||||
Типовой файл выглядит примерно так (Kumir/Kumir.pro): |
||||
|
||||
FORMS += Forms/ProgramTab.ui \ |
||||
<пропущен список файлов> |
||||
Forms/multifilesavewizard.ui |
||||
HEADERS += Headers/strtypes.h \ |
||||
<пропущен список файлов> |
||||
../TaskControl/csInterface.h |
||||
SOURCES += Sources/mainwindow.cpp \ |
||||
<пропущен список файлов> |
||||
Sources/kummodules.cpp |
||||
TRANSLATIONS = Languages/english.ts \ |
||||
Languages/russian.ts \ |
||||
Languages/french.ts |
||||
TEMPLATE = app |
||||
DEPENDPATH += ../Libraries/kpython |
||||
INCLUDEPATH += Headers |
||||
INCLUDEPATH += ../ |
||||
INCLUDEPATH += ../Libraries/kpython |
||||
INCLUDEPATH += ../Addons/protoModule |
||||
|
||||
QT += xml \ |
||||
script \ |
||||
svg \ |
||||
network\ |
||||
webkit |
||||
RESOURCES += Resources/MainWindow.qrc \ |
||||
Resources/Assistant.qrc |
||||
TARGET = kumir |
||||
macx:ICON=../app_icons/mac/kumir.icns |
||||
linux-g++: LIBS += -lX11 |
||||
linux-g++64: LIBS += -lX11 |
||||
include(../Scripts/common.pri) |
||||
unix:dummy.extra=python ../Scripts/install_kumir.py --spec=unix --prefix=$$PREFIX --kumir-dir=$$KUMIR_DIR |
||||
macx:dummy.extra=../Mac/Kumir/embed_macosx_resources.sh |
||||
win32:dummy.extra=python ../Scripts/install_kumir.py --spec=win32 --prefix=$$PREFIX --kumir-dir=$$KUMIR_DIR |
||||
dummy.path=./ |
||||
INSTALLS = dummy |
||||
|
||||
Следите за руками. Видимо, неосилив qmake в части установки целей средствами самого qmake, разработчики, недолго думая, написали скриптик на питоне, который это будет делать за qmake - install_kumir.py[^fn3]. Скриптик, естественно, ни про какой DESTDIR слыхом не слыхивал и вообще имел его ввиду. |
||||
|
||||
Обратите внимание на "FORCE" и "dummy.extra". ".extra", как следует из документации, предназначен для выполнения **дополнительных** действий после установки, и использование его для самой установки противоречит "философии" qmake. |
||||
|
||||
Чтение документации по qmake также показало, что существует местный аналог DESTDIR - INSTALL_ROOT, но его использование тоже не работает, из-за тех же "нескучных" питоновских скриптов. |
||||
|
||||
Битва за $DESTDIR |
||||
----------------- |
||||
|
||||
Что можно сделать? |
||||
|
||||
- можно исправить строчку с вызовом питоновского скрипта на $$DESTDIR/$PREFIX. Неудачная идея. В выходном Makefile $$DESTDIR разворачивается и мы получаем неверный префикс для приложения. |
||||
- можно исправить параметр ".path", но этого тоже делать не стоит, скрипт просто не найдет нужного файла. |
||||
- наконец, можно исправить сам питоний скрипт, чтобы он учитывал, собака такая, наши пожелания. |
||||
|
||||
Действуем по третьему варианту. Накладываем следующий патчик на Scripts/install_kumir.py: |
||||
|
||||
--- src/Scripts/install_kumir.py 2012-03-20 21:23:59.628590648 +1100 |
||||
+++ dst/Scripts/install_kumir.py 2012-03-20 21:24:56.186145954 +1100 |
||||
@@ -1,5 +1,6 @@ |
||||
#!/usr/bin/python |
||||
|
||||
+import os |
||||
import sys |
||||
|
||||
for arg in sys.argv: |
||||
@@ -14,6 +15,11 @@ |
||||
if PREFIX=="": PREFIX="/usr/local" |
||||
if KUMIR_DIR=="": KUMIR_DIR = PREFIX+"/kumir" |
||||
|
||||
+env = os.environ |
||||
+if env.has_key('DESTDIR'): |
||||
+ PREFIX = os.environ['DESTDIR']+PREFIX |
||||
+ KUMIR_DIR = os.environ['DESTDIR']+KUMIR_DIR |
||||
+ |
||||
from install_generic import * |
||||
|
||||
if SPEC=="unix": |
||||
|
||||
В результате получим это: |
||||
|
||||
#!/usr/bin/python |
||||
|
||||
import os |
||||
import sys |
||||
|
||||
for arg in sys.argv: |
||||
if arg.startswith("--prefix="): |
||||
PREFIX = arg[9:] |
||||
if arg.startswith("--spec="): |
||||
SPEC = arg[7:] |
||||
if arg.startswith("--kumir-dir="): |
||||
KUMIR_DIR = arg[12:] |
||||
|
||||
if SPEC=="": SPEC="unix" |
||||
if PREFIX=="": PREFIX="/usr/local" |
||||
if KUMIR_DIR=="": KUMIR_DIR = PREFIX+"/kumir" |
||||
|
||||
env = os.environ |
||||
if env.has_key('DESTDIR'): |
||||
PREFIX = os.environ['DESTDIR']+PREFIX |
||||
KUMIR_DIR = os.environ['DESTDIR']+KUMIR_DIR |
||||
|
||||
from install_generic import * |
||||
|
||||
if SPEC=="unix": |
||||
install_file("../kumir",KUMIR_DIR+"/kumir",True) |
||||
create_shell_link(KUMIR_DIR+"/kumir",PREFIX+"/bin/kumir") |
||||
elif SPEC=="win32": |
||||
install_file("../kumir.exe",KUMIR_DIR+"/kumir.exe",True) |
||||
install_dir("Config",KUMIR_DIR+"/Kumir") |
||||
install_dir("Environments",KUMIR_DIR+"/Kumir") |
||||
install_dir("Examples",KUMIR_DIR+"/Kumir") |
||||
install_dir("Help",KUMIR_DIR+"/Kumir") |
||||
install_dir("HyperText",KUMIR_DIR+"/Kumir") |
||||
install_dir("Macro",KUMIR_DIR+"/Kumir") |
||||
install_dir("PDScripts",KUMIR_DIR+"/Kumir") |
||||
install_dir("Languages",KUMIR_DIR+"/Kumir") |
||||
install_dir("Images/customwindow_pixmaps",KUMIR_DIR+"/Kumir") |
||||
if SPEC=="unix": |
||||
install_file("Images/kumir.png", |
||||
PREFIX+"/share/pixmaps/kumir.png",False) |
||||
install_file("X-Desktop/kumir.desktop", |
||||
PREFIX+"/share/applications/kumir.desktop",False) |
||||
|
||||
Пробуем собрать и установить цель kumir: |
||||
|
||||
cd Kumir |
||||
make |
||||
make DESTDIR=/tmp install |
||||
|
||||
Работает! Обрабатываем по образу и подобию остальные скрипты ``Script/install_*.py`` |
||||
|
||||
Из-за нестандартного 'configure' разворачиваем ``dh build`` в ``debian/control`` и заменяем ``dh_auto_configure`` на наш вариант: |
||||
|
||||
|
||||
build: |
||||
dh_testdir |
||||
- dh_auto_configure |
||||
+ python ./configure.py --prefix=/usr --target-dir=/opt/kumir |
||||
dh_auto_build |
||||
dh_auto_test |
||||
|
||||
"--target-dir" нужен, т.к. у нас нестандартное размещение бинарников, ресурсов и т.д., если его не указывать, всё поставится в ``/usr/kumir``[^fn4]. |
||||
|
||||
Пробуем собрать пакет ...успешно. :-) |
||||
|
||||
Опять qmake |
||||
----------- |
||||
|
||||
После успешной сборки, казалось бы можно перевести дух, но не тут-то было. Смотрим в содержимое пакета и помимо ожидаемых "opt" и "usr" видим также "home" с полным путем до места сборки и пустые директории для всех целей, которые он собирал. Непорядок, этого мусора в пакете быть не должно. |
||||
|
||||
Возвращаемся к файлу проекта и внимательно смотрим на параметр ".path". Читаем документацию и выясняем, что в зависимости от его значения, он разворачивается по разному в выходном Makefile, что добавляет немного wtf'ака в процесс сборки. :-) Причем вышеупомянутый $INSTALL_ROOT подставляется ко всем устанавливаемым файлам неявно и автоматически (ещё один wtf'к). |
||||
|
||||
extra.path = ./ -> /home/user/build/.../.../ |
||||
extra.path = / -> / |
||||
|
||||
У нас стоит "./" что и вызывает создание "home" в выходной директории. Исправление на "/" решило бы проблему, но этого делать нельзя, чтоб не поломать сборку под win и mac, починив сборку под *nix. Это тоже хак, и в идеале здесь должно быть что-то типа "$$PREFIX/bin", но чтобы сделать правильно, придётся переделать половину системы сборки для этого пакета. |
||||
|
||||
Проблему решаем, добавив строчку "unix:extra.path = /", что будет применяться только для сборки под *nix, не затрагивая остальные системы. Этот «/» при установке будет дополнен питоновским скриптом до правильного пути. |
||||
|
||||
Все изменения выше оформляем в виде патчей, складываем в debian/patches и переписываем имена патчей в debian/patches/series: |
||||
|
||||
cp Scripts/install_kumir.py Scripts/install_kumir.py.old |
||||
nano Scripts/install_kumir.py |
||||
cd .. |
||||
diff -durN kumir-1.7.3/Scripts/install_kumir.py.old kumir-1.7.3/Scripts/install_kumir.py >> debian/patches/001-build.patch |
||||
echo 001-build.patch >> debian/patches/series |
||||
|
||||
"После сборки - обработать напильником" |
||||
--------------------------------------- |
||||
|
||||
Ставим получившийся пакет и пробуем его запустить. Как бы не так. |
||||
Пробуем запустить из терминала - "Нет такого файла или каталога". Смотрим на файл /usr/bin/kumir и видим, что он представляет shell-скрипт, запускающий ``/home/user/build/.../.../opt/kumir/kumir``[^fn5]. Похоже, мы опять налажали с путями. Ищем место, где создается этот скрипт и находим его опять в ``install_kumir.py`` |
||||
|
||||
Ага, вот эти ребята: |
||||
|
||||
if SPEC=="unix": |
||||
install_file("../kumir",KUMIR_DIR+"/kumir",True) |
||||
create_shell_link(KUMIR_DIR+"/kumir",PREFIX+"/bin/kumir") |
||||
|
||||
Модифицируем скрипт так: |
||||
|
||||
--- Scripts/install_kumir.py.old 2012-03-20 21:29:18.036593285 +1100 |
||||
+++ Scripts/install_kumir.py 2012-03-20 21:30:17.976651480 +1100 |
||||
@@ -17,6 +17,7 @@ |
||||
|
||||
env = os.environ |
||||
if env.has_key('DESTDIR'): |
||||
+ KUMIR_DIR_ORIG = KUMIR_DIR |
||||
PREFIX = os.environ['DESTDIR']+PREFIX |
||||
KUMIR_DIR = os.environ['DESTDIR']+KUMIR_DIR |
||||
|
||||
@@ -24,7 +25,7 @@ |
||||
|
||||
if SPEC=="unix": |
||||
install_file("../kumir",KUMIR_DIR+"/kumir",True) |
||||
- create_shell_link(KUMIR_DIR+"/kumir",PREFIX+"/bin/kumir") |
||||
+ create_shell_link(KUMIR_DIR_ORIG+"/kumir",PREFIX+"/bin/kumir") |
||||
elif SPEC=="win32": |
||||
install_file("../kumir.exe",KUMIR_DIR+"/kumir.exe",True) |
||||
install_dir("Config",KUMIR_DIR+"/Kumir") |
||||
|
||||
|
||||
Пересобираем пакет, ставим, пробуем запустить. Теперь ругается на отсутствующий ``/opt/kumir/Addons/turtle.ini``. Прогресс, однако. |
||||
|
||||
Ищем в документации, как в пакет можно положить дополнительные файлы, и находим - dh_install. |
||||
Разворачиваем ``dh binary``, заменяем вызов dh_install на следующий: |
||||
|
||||
- dh_install |
||||
+ dh_install Addons/turtle.ini opt/kumir/Addons/ |
||||
|
||||
Обратите внимание, вторым аргументом указывается **директория**, в которую будет помещён файл. |
||||
|
||||
Опять пересобираем пакет, ставим, запускаем, радуемся жизни. |
||||
|
||||
Вот так это выглядит в запущенном виде: главное окно. FIXME (заливка файлов не работает) |
||||
|
||||
Вместо заключения |
||||
----------------- |
||||
|
||||
Чистого времени на сборку понадобилось ~ 3 вечера, один из которых я читал документацию. Сложность конкретно этого пакета оцениваю на 4 из 10. Замечания, дополнения, просьба оставлять в "обсуждении". |
||||
|
||||
Но если учесть распространённость формата, время его появления и груз обратной совместимости - несмотря на недостатки он ещё долго будет в ходу. |
||||
|
||||
[^fn1]: на самом деле она является стандартом "де-факто", в LSB она не описана |
||||
|
||||
[^fn2]: опять же - стандарт "де-факто" для сборки из исходников - ``configure && make && make install`` |
||||
|
||||
[^fn3]: фирменные грабли №2 |
||||
|
||||
[^fn4]: фирменные грабли от разработчиков №3 |
||||
|
||||
[^fn5]: кстати, кто-нибудь объяснит мне, почему нельзя было обойтись простым симлинком? |
||||
@ -0,0 +1,313 @@
|
||||
--- |
||||
title: Система резервного копирования и быстрого развёртывания ОС - Clonezilla |
||||
tags: software |
||||
--- |
||||
|
||||
Clonezilla - проект по созданию свободной системы резервного копирования, клонирования, восстановления и массового развертывания операционных систем и данных. Позиционируется как аналог и замена для Norton Ghost (упомянуто на оффсайте). Также, многие её возможности повторяют, а кое-в чем и обгоняют аналогичные проприетарные решения от Paragon и Acronis. |
||||
|
||||
Изначально, эта статья планировалась как обзор, где подробно разбирались бы возможности, отличия от конкурентов, но, поскольку это невыразимо скучно, я решил углубиться в общие принципы работы самой идеи развертывания систем вместо их установки заново. |
||||
|
||||
--- |
||||
|
||||
Возможности |
||||
----------- |
||||
|
||||
Поддержка файловых систем: |
||||
|
||||
* FAT, |
||||
* NTFS, |
||||
* ext{2,3,4}, |
||||
* reiserfs{3,4}, |
||||
* XFS, |
||||
* JFS, |
||||
* VMFS (VMWare ESX) |
||||
* UFS, (*BSD) |
||||
* HFS+, (Mac) |
||||
* все остальные (посекторно, с помощью dd) |
||||
|
||||
Сравнение с аналогами |
||||
--------------------- |
||||
|
||||
^ Основные параметры ^ Clonezilla ^ Paragon ^ Acronis ^ |
||||
^ требования к памяти | 128-256m | 512 | 160m | |
||||
^ графический интерфейс | нет | да | да | |
||||
^ интеграция в другие продукты | да | нет | нет | |
||||
^ live-система основана | linux | vista | linux | |
||||
^ изменяемость live-системы | да | нет | нет | |
||||
|
||||
^ Поддерживается загрузка с ^ Clonezilla ^ Paragon ^ Acronis ^ |
||||
^ * cd/dvd | да | да | да | |
||||
^ * usb | да | нет | да (хак) | |
||||
^ * pxe (по сети) | да | нет | да (хак) | |
||||
|
||||
^ Сохранение образов дисков ^ Clonezilla ^ Paragon ^ Acronis ^ |
||||
^ локальное устройство | + | + | + | |
||||
^ smb (cifs) | + | + | + | |
||||
^ nfs | + | - | ?? | |
||||
^ ssh | + | - | - | |
||||
^ ftp | ~ | ?? | + | |
||||
^ (unix-supported) | ~ | - | - | |
||||
|
||||
^ Дополнительные "возможности" ^ Clonezilla ^ Paragon ^ Acronis ^ |
||||
^ головняк с версиями лицензий | нет | ?? | да | |
||||
^ красивый сайт с тонной рекламных лозунгов | нет | да | да | |
||||
|
||||
Ограничения |
||||
----------- |
||||
|
||||
Ограничений достаточно много, большая часть - из-за недостаточной гибкости интерфейса. Там описаны только типовые операции, для нестандартных случаев - готовьтесь принять управление на себя и использовать консоль. |
||||
|
||||
Чисто технические ограничения: |
||||
|
||||
* поддержка восстановления только на раздел, больший или равный исходному. (это всё равно можно переопределить, но правильность восстановления в этом случае - не гарантируется) |
||||
* нет возможности работать с данными внутри образа, даже несжатого[^fn1] |
||||
|
||||
Всё остальное - ограничения чисто интерфейса, например: |
||||
|
||||
* нет возможности отдельно настроить опции бэкапа для отдельных разделов, приходится полагаться на автоматику |
||||
* начальная поддержка LVM, опять же, нет возможности бэкапить отдельные тома |
||||
* разделение на «образы дисков» и «образы разделов». (отличие - в одном файле) |
||||
* программа "видит" образы только в корневой директории примонтированного хранилища |
||||
* и т.д. |
||||
|
||||
Применимость |
||||
------------ |
||||
|
||||
Смысл в изучении и использовании системы появляется при: |
||||
|
||||
* частом выполнении операции развертывания системы |
||||
* большом парке обслуживаемой техники |
||||
* неприемлемости/невозможности использования платных аналогов |
||||
* необходимости гарантии максимально полного восстановления данных из бэкапа даже при его повреждении |
||||
|
||||
Для типичного win-эникейщика с руками достаточной кучерявости - вещь практически неподъёмная или очень ограниченная в возможностях, поскольку с консолью он работать не умеет, а интерфейс позволяет только типовые операции. Тем не менее, при желании учиться, освоение системы займет от 3 дней (базовый уровень) - до месяца (поскольку потребуется объяснять, что на самом-то деле нет такого понятия как "буквы дисков"). |
||||
|
||||
Для линуксоида с хотя бы полугодовым опытом и базовыми навыками работы в консоли, обучение займет от одного до 5и дней до появления т.н. «чувства системы». После прочтения данного материала - смею надеяться - ещё меньше. |
||||
|
||||
Необходимый уровень знаний - на уровне |
||||
|
||||
* записать N байт из заданного смещения многогигабайтного файла по заданному смещению на диске, |
||||
* настроить сеть из консоли, |
||||
* редактирование mbr fdisk'ом и понимание отличия между сектором и цилиндром диска |
||||
* не промахнуться мимо нужного диска/раздела |
||||
|
||||
Особенности клонирования |
||||
------------------------ |
||||
|
||||
Вещи, на которые стоит обратить внимание при массовом развертывании систем. |
||||
|
||||
**nix**: |
||||
|
||||
* ssh-ключи |
||||
* ip-адрес и настройки сети (неактуально для dhcp) |
||||
* hostname |
||||
* UUID дисков |
||||
* имена и uid пользователей, если используется авторизация на локальной машине |
||||
* имена групп lvm |
||||
* имена сетевых интерфейсов (для случая, когда их больше одного) |
||||
|
||||
Первые 3 - рекомендованы к изменению, остальные - по желанию. |
||||
|
||||
**win**: |
||||
|
||||
* SID машины и пользователей |
||||
* netbios-имя |
||||
* настройки сети |
||||
|
||||
SID, судя по статье Руссиновича, менять необязательно, но рекомендовано. NB-имя - менять обязательно, если машины будут работать в одной сети, иначе получите гарантированные глюки и медленную работу win-сети. |
||||
|
||||
Подготовка систем к развертыванию |
||||
--------------------------------- |
||||
|
||||
Иначе говоря - создание образов установленных и настроенных систем. |
||||
|
||||
Общий принцип - старайтесь всегда отделять пользовательские данные от системных, это значительно сэкономит время на бэкапы и упростит развертывание ОС и замену комплектующих. |
||||
|
||||
Также, старайтесь делать образы дисков минимального размера - это автоматически обходит ограничения clonezilla на невозможность развертывания образа на меньший по размеру раздел диска и экономит время на развертывание за счет передачи меньшего объема данных. |
||||
|
||||
Разметка дисков |
||||
--------------- |
||||
|
||||
**nix**: |
||||
|
||||
Здесь всё просто - выделяется 100Мб раздел под «/boot», выделяется второй раздел под всё остальное (рекомендуемый объем для работы системы). |
||||
|
||||
Первый раздел нужен, чтобы использовать lvm на втором, поскольку поддержку его в самом загрузчике имеет только grub2. Кроме того, так проще будет проводить исправление проблем с загрузчиком и редактирование его конфигурации. Рекомендуемый размер - 70-150Мб |
||||
|
||||
Второй раздел полностью отводится под физический том lvm и уже в нём динамически выделяется место под различные нужды. Рекомендуемый размер - 4-8 Гб, в зависимости от ДЕ, дистрибутива и количества софта. Этот раздел должен использоваться для работы системы, хранение на нем пользовательских данных - крайне нежелательно. |
||||
|
||||
Для себя я определил такую схему логических томов: |
||||
|
||||
* tmp - 256-512 Мб, noexec,nodev,nosuid. Этот раздел можно впоследствии выделить целиком в оперативной памяти, а логический том - удалить. |
||||
* home - 512Мб, relatime, по желанию - noexec |
||||
* swap - 256-1024Мб |
||||
* root - всё остальное |
||||
|
||||
Почему именно так: конечно, будучи бывалым гуру, вы бы выделили /var/log и /var/run в память, возможно разбили бы /usr ещё на несколько разделов. Но здесь основная задача - чтобы система проработала максимально долго без внешнего вмешательства. И чтобы когда её принесли с диагнозом "не работает, хз почему" - можно было бы максимально быстро установить по логам что именно случилось. Ситуации «в разделе с логами кончилось место, поэтому всё поотваливалось» - недопустимы. |
||||
|
||||
Небольшой раздел с «/home» - это своего рода заглушка, для демонстрации работы системы, в дальнейшем этот раздел переносится на другой, более вместительный, а место - возвращается под системные нужды. В случае, когда *nix используется второй системой - он не удаляется, но в домашнюю директорию монтируется раздел с данными (не поверх, а отдельно и на видном месте). |
||||
|
||||
Итоговая разбивка диска будет такой: |
||||
|
||||
[boot][XXXXXXXXXXXXXX LVM XXXXXXXXXXXXXXXX] |
||||
^ ^ |
||||
[[tmp][swap][ root ][home]] |
||||
|
||||
На реальный диск это может быть развернуто так: |
||||
|
||||
[boot][XXX LVM XXX][ data ] |
||||
|
||||
или так: |
||||
|
||||
[system1][ data ][boot][XXX LVM XXX] |
||||
|
||||
или даже так: |
||||
|
||||
[XXX LVM XXX][ data ][boot] |
||||
|
||||
В последних 2х случаях есть вероятность того, что система не сможет загрузиться, поскольку нужный раздел может находится за пределами пространства на диске, которое может адресовать BIOS. |
||||
|
||||
**win**: |
||||
|
||||
Здесь всё проще и одновременно - сложнее. |
||||
|
||||
Поскольку путь к профилям пользователя привязывается к абстрактной «букве диска», которые после развертывания назначаются для остальных разделов произвольно, таких фокусов как с /home - выше - мы позволить себе не можем. Поэтому оставляем всё как есть, после развертывания вручную переносим особо «злачные» места на раздел с данными, обычно это «рабочий стол» и «документы». Кроме того, не существует очевидного способа перенести их так, чтобы сохранились все права на файлы. (да, я знаю про переназначение путей, проблему с файлами это не снимает). монтирование раздела с данными в папку профиля вызывает засорение его настройками, кроме того, это порочная практика для win*. |
||||
|
||||
В новых версиях, начиная с Vista, система при установке норовит выделить себе отдельный раздел под файлы загрузки[^fn2], так вот - не давайте ей это делать, иначе после перестановки разделов она не загрузится, поскольку определение раздела с системой происходит старым добрым способом - по номеру в mbr[^fn3]. |
||||
|
||||
Операции внутри системы |
||||
----------------------- |
||||
|
||||
**nix**: |
||||
|
||||
Как правило необходимы только для данных, идентифицирующих систему - те же ssh-ключи и необходимость убедиться, что initrd собран со всеми возможными драйверами. |
||||
|
||||
Для данных можно написать скриптик, делающий всю работу при первой загрузке и прописать его куда-нибудь в «/etc/rc.local». Важно, чтобы потом он себя оттуда удалил. |
||||
|
||||
**win**: |
||||
|
||||
Здесь потребуется намного больше действий[^fn4]. |
||||
Как минимум нужно убедиться в следующем: |
||||
|
||||
* используются «стандартные» драйвера для дисковых контроллеров ide. |
||||
* установлен как минимум один sata-контроллер со «стандартными» драйверами ahci-sata |
||||
* отключена вся периферия и оставлено минимум устройств |
||||
* отключены все «сетевые» диски, и очищены все записи в реестре и ссылки, могущие ссылаться на них |
||||
* файловая система раздела не содержит ошибок |
||||
|
||||
Создание эталонного образа |
||||
-------------------------- |
||||
|
||||
После выполнения всех указанных выше действий можно приступать к сохранению образа системы. Можно довериться автоматике, можно всё сделать вручную. В случае, если вы этот образ планируете разворачивать мультикастом сразу на несколько машин - делайте «автоматически». |
||||
|
||||
В первом случае - выбираем режим сохранения разделов, выбираем нужные, жмем «сохранить» и идем пить чай с доширакой. На выходе получим директорию с десятком файлов, или жуткое сообщение об ошибке. |
||||
|
||||
Во втором случае - придется потратить 5 минут на введение команд. Для случая ``linux/sdb(sdb1(ext3) sdb2(lvm) <del>sdb3</del>)`` они будут следующими: |
||||
|
||||
T="/path/to/save/image" |
||||
mount "$T" /mnt |
||||
fdisk -u -l /dev/sdb >> "$T" |
||||
# чтобы впоследствии смотреть геометрию диска и размеры разделов |
||||
partclone.ext3 -c -s /dev/sdb1 -o "$T/sda1.ptcl.ext3.uncomp" |
||||
# имя может быть любое, но предложенная разработчиками схема достаточно неплоха |
||||
partclone.dd -c -s /dev/sdb2 | gzip -5 - > "$T/sda2.ptcl.lvm-raw.gz" |
||||
# в отличие от предыдущей команды - здесь используется несильное сжатие |
||||
dd if=/dev/sdb of="$T/mbr.bin" bs=446 count=1 |
||||
# сохраняем начальный загрузчик |
||||
dd if=/dev/sdb of="$T/data-arfer-mbr.bin" bs=512 count=2047 skip=1 |
||||
# сохраняем данные за mbr. |
||||
# 2047 - количество секторов до начала первого раздела |
||||
# 512 - размер сектора в байтах |
||||
# skip=1 - значит, что мы пропускаем один сектор (т.к. это mbr) |
||||
|
||||
Образ, сделанный "вручную" придется разворачивать так же - вручную. Из плюсов - ничего лишнего. |
||||
|
||||
Развертывание образа / исправление загрузки |
||||
------------------------------------------- |
||||
|
||||
По умолчанию - поддерживается только grub (обе ветки) и ntldr, остальные - настраиваются и исправляются вручную. |
||||
|
||||
Теоретическое отступление. Загрузка типового IBM-PC-совместимого компьютера происходит в несколько этапов: |
||||
|
||||
* BIOS определяет порядок устройств для загрузки, считывает первый сектор с первого доступного устройства в очереди загрузки и передает ему управление. |
||||
* Загруженный сектор (mbr) ищет у себя запись о разделе диска с пометкой 0x80 (загрузочный), опять читает с него один сектор и передает управление ему. Это - вторичный загрузчик. |
||||
* Вторичный загрузчик уже производит необходимые действия для загрузки. Как правило - выводит меню выбора вариантов загрузки, ищет по необходимому смещению на разделе ядро операционной системы, загружает код для обеспечения работы ядра на начальном этапе (тот самый initrd) проводит модификацию флагов разделов в загруженной mbr и т.д.. |
||||
|
||||
Всё вышесказанное относится к типовому IBM-PC-совместимому компьютеру с BIOS. На машинах с [U]EFI, думаю всё будет немного по другому. |
||||
Специфичные шаги для загрузчиков: |
||||
|
||||
**grub**: |
||||
|
||||
Внимание! grub хранит часть своих данных в области непосредственно за mbr и до начала первого раздела, обычно это - 62 сектора (т.е. 32кб), первый раздел же начинается с 63го. |
||||
Во второй ветке grub'а - 62х секторов ему уже мало, так что выделяйте 2048 - это рекомендуется по умолчанию большинством дистрибутивов перешедших на него. |
||||
|
||||
При необходимости - редактируется конфиг загрузчика (например - при указании корневого устройства как /dev/hda1, а систему развернули на sda2). Это можно выполнить и в самом меню загрузки, главное - до него добраться. |
||||
|
||||
Коды ошибок: stage1 - первый сектор раздела, stage1.5 - данные за mbr, stage2 - данные и конфигурация основного загрузчика на загрузочном разделе. |
||||
|
||||
**ext/syslinux**: |
||||
|
||||
Исправляются элементарно: |
||||
|
||||
Для syslinux'а: |
||||
|
||||
syslinux -i -t <offset> [-d dir/] /dev/sdX |
||||
syslinux [-d dir/] -i /dev/sdXY |
||||
|
||||
Где <offset> - смещение начала загрузочного раздела в байтах, sdX - устройство, с которого будем грузится. (Обратите внимание - в этом случае - не раздел, а само устройство). Во втором случае - offset - не нужен. Обе команды выше - делают то же самое. Важно! если конфиг лежит не в корне ФС раздела, а в поддиректории - мы должны указать её с помощью параметра «-d» при установке загрузчика. |
||||
|
||||
Для extlinux'а: |
||||
|
||||
extlinux -i /boot/[dir/] |
||||
|
||||
Здесь важно указать правильный путь до директории, где лежит конфиг загрузчика. Символические ссылки поддерживаются. Обратите внимание, что все пути в конфигах пишутся относительно директории с первичным конфигом загрузчика. |
||||
|
||||
Для syslinux загрузочный раздел должен быть отформатирован в ФС FAT, для extlinux, соответственно, - в ext2/3/4/btrfs |
||||
|
||||
Дальнейшие действия загрузчика описываются в конфиг-файле, это уже понятно. Если мы получили работающий загрузчик, читающий конфиг - можно сказать мы победили, осталось поправить этот самый конфиг до работающего. |
||||
|
||||
**lilo**: |
||||
|
||||
Самый вредный и непредсказуемый из описываемых загрузчиков. |
||||
|
||||
Для установки и изменения параметров требует подобия загруженной системы: как минимум корень с конфигом в /etc/, /boot/ с ядрами и initrd (если он на отдельном разделе), /dev/ для доступа к устройствам и /proc/ для чтения разделов. |
||||
|
||||
Чинится так: |
||||
|
||||
mount /dev/sda2 /mnt/new_root |
||||
mount /dev/sda1 /mnt/new_root/boot |
||||
mount --bind /dev /mnt/new_root/dev |
||||
chroot /mnt/new_root |
||||
mount -t proc none /proc |
||||
{vi, nano, ed, ...} /etc/lilo.conf |
||||
lilo |
||||
exit |
||||
reboot |
||||
|
||||
Если промахнулись в опциях ядра - вспоминаем, дописываем в приглашении, иначе - вышеуказанное - повторить. |
||||
|
||||
Грабли возможны с параметрами: |
||||
|
||||
* bigmem - если размер initrd достаточно велик - он перепишет часть кода ядра со всеми вытекающими |
||||
* lba32 - если режим адресации на диске отличается от указанного - longjump промахнется мимо ядра |
||||
|
||||
**ntldr**: |
||||
|
||||
Второй по вредности и непредсказуемости. |
||||
Зависит от 3х файлов в корне раздела - ntldr, ntdetect и boot.ini. Первый читается с раздела напрямую по заранее заданному смещению, исправить его можно так: |
||||
|
||||
partclone.ntfsfixboot -w /dev/sdXY |
||||
|
||||
Также, в boot.ini должен быть прописан правильный номер раздела (partition(X), счет начинается с единицы). |
||||
|
||||
**ntldr в системах Vista и выше**: |
||||
|
||||
Терминальный звиздец, руками из под доса исправлению не поддается, настройки хранит в отдельной ветке реестра. С вероятностью 70% исправляется загрузочным диском/встроенной графической утилиткой. В остальных 30% - в морг^W^W только переустанавливать снова. |
||||
|
||||
[^fn1]: наработки [[http://www.idealworldinc.com/partclone-utils/|есть]], но это ещё глубокая альфа |
||||
|
||||
[^fn2]: что-то мне это напоминает |
||||
|
||||
[^fn3]: что линуксу - хорошо, то венде - смерть :-) |
||||
|
||||
[^fn4]: Фактически, подготовка к клонированию здесь начинается с создания своего установочного образа и интеграции драйверов в него. Т.е. поставив систему с «официального» диска, добится нормальной переносимости системы мы не сможем |
||||
@ -0,0 +1,93 @@
|
||||
--- |
||||
title: Установка времени из initramfs |
||||
tags: network, pxe, debian |
||||
--- |
||||
|
||||
При работе на старом оборудовании может возникать ситуация, когда время в BIOS'е на рабочих станциях постоянно сбрасывается на заводское значение. При использовании корневой ФС семейства ext\*, это может вызвать отказ в монтировании со следующей ошибкой: ``Superblock last mount time is in the future``. |
||||
|
||||
--- |
||||
|
||||
Решение |
||||
------- |
||||
|
||||
Решение проблемы может быть достигнуто несколькими способами: |
||||
|
||||
* синхронизировать при запуске время из initrd (+10 секунд к времени запуска), |
||||
* следить за железом, |
||||
* каждый раз при обновлении e2fsprogs перекомпилировать пакет с патчем для отключения этой проверки |
||||
|
||||
Наиболее простой в плане поддержки - первый вариант. Его и будем реализовывать. |
||||
|
||||
При использовании Debian'а или его производных, нам потребуется написать 2 скрипта, которые: |
||||
|
||||
- при обновлении ядра будут добавлять ntpdate со всеми зависимостями в initrd. |
||||
- при загрузке, при указании определённого параметра будут выполнять команду ntpdate <our-ntp-server> |
||||
|
||||
Ниже - пример одной из возможных реализаций. |
||||
|
||||
/etc/initramfs-tools/hooks/ntpdate: |
||||
|
||||
#!/bin/sh |
||||
|
||||
case $1 in |
||||
prereqs) |
||||
exit 0 |
||||
;; |
||||
esac |
||||
|
||||
. /usr/share/initramfs-tools/hook-functions |
||||
|
||||
copy_exec /usr/sbin/ntpdate /sbin |
||||
cp /etc/services ${DESTDIR}/etc/ |
||||
cp /etc/nsswitch.conf ${DESTDIR}/etc/ |
||||
cp /lib/libnss_files* ${DESTDIR}/lib/ |
||||
|
||||
/etc/initramfs-tools/scripts/local-top/ntpdate: |
||||
|
||||
#!/bin/sh |
||||
|
||||
case $1 in |
||||
prereqs) |
||||
exit 0 |
||||
;; |
||||
esac |
||||
|
||||
for x in $(cat /proc/cmdline); do |
||||
case $x in |
||||
ntp-server*) |
||||
NTP_SERVER="${x#ntp-server=}" |
||||
;; |
||||
esac |
||||
done |
||||
|
||||
if [ -z "$NTP_SERVER" ]; then |
||||
exit 0 |
||||
fi |
||||
|
||||
. /scripts/functions |
||||
|
||||
log_begin_msg "Syncing local time" |
||||
|
||||
/sbin/ntpdate -v "$NTP_SERVER" |
||||
|
||||
Оба файла должны иметь права на выполнение. Второй скрипт должен быть назван так, чтобы при сортировке по имени, он должен идти после того, который подключает корневую ФС, т.к. в ней, как правило, проводится настройка сети (у меня они называются nbd и ntpdate соответственно). |
||||
|
||||
Если при запуске ntpdate выдаётся ошибка ``Servname not supported for ai_socktype(-8)`` или подобная - это означает, что не работает разрешение имен. Причиной этого является следующее: ntpdate использует стандартную функцию getaddrinfo(). Эта функция первоначально считает всё, что ей подали на вход - dns-именем, поэтому пытается разрешить его в ip-адрес, даже если на входе уже ip-адрес. Для работы разрешения имён необходимо в initrd также добавить конфигурационные файлы /etc/services, /etc/nsswitch.conf и библиотеку /lib/libnss_files.so[^fn1] |
||||
|
||||
После добавления файлов нужно обновить inird: |
||||
|
||||
update-initramfs -k all -u # -k all - для всех найденных версий ядра, -u - update (обновить) |
||||
|
||||
Обновлённый initrd копируется в директорию с файлами для бездисковой загрузки, в конфиг-файле pxelinux'а дописывается параметр nbd-server=<ip>, где <ip> - адрес ntp-сервера. |
||||
|
||||
Отладка |
||||
------- |
||||
|
||||
Для прерывания загрузки на различных этапах в debian'е можно использовать параметр break в параметрах загрузки. |
||||
Возможные значения этого параметра можно посмотреть так: |
||||
|
||||
# grep -n maybe_break /usr/share/initramfs-tools/init |
||||
|
||||
В моём случае это: ``top, modules, premount, mount, mountroot, bottom, init``. Для прерывания непосредственно перед монтированием корневой ФС используйте значение "mountroot". |
||||
|
||||
[^fn1]: проследите, чтобы это была именно библиотека, а не ссылка на неё. Впрочем, можно добавить и то и другое |
||||
|
After Width: | Height: | Size: 10 KiB |
|
After Width: | Height: | Size: 6.3 KiB |
|
After Width: | Height: | Size: 4.6 KiB |
|
After Width: | Height: | Size: 9.4 KiB |
|
After Width: | Height: | Size: 5.5 KiB |
|
After Width: | Height: | Size: 3.3 KiB |
@ -0,0 +1,401 @@
|
||||
--- |
||||
title: Доводка до кондиции различных дистрибутивов линукса |
||||
tags: software |
||||
--- |
||||
|
||||
Путь к освоению линукса начинается с постановки вопроса "что я хочу получить от системы", или в упрощённой форме "чем я занимаюсь за компьютером". После получения ответа хотя бы на уровне "фильмы смотреть / сидеть в интернете" можно продолжать. |
||||
|
||||
--- |
||||
|
||||
Выбор дистрибутива |
||||
--- |
||||
|
||||
Следующим этапом является выбор дистрибутива[^fn1]. Все они различаются по следующим основным признакам: |
||||
|
||||
* основной формат пакетов |
||||
* модель разработки (фиксированные релизы/без релизов) |
||||
* распространённость |
||||
* ориентация (универсальный/специализированный) |
||||
* разработчик (компания/сообщество/совместное) |
||||
|
||||
Наиболее распространённые дистрибутивы, подходящие для использования на десктопе: |
||||
|
||||
* Ubuntu и её вариации: Kubuntu, Xubuntu, etc |
||||
* Debian |
||||
* LinuxMint |
||||
* openSUSE |
||||
|
||||
Также, к списку выше можно добавить ещё несколько дистрибутивов «второго эшелона», по тем или иным причинам подходящим для более опытных пользователей. |
||||
|
||||
* Mageia |
||||
* Fedora |
||||
* Archlinux |
||||
* Altlinux |
||||
|
||||
Схема отношений DEB-based дистрибутивов: |
||||
|
||||
[](deb-based-distro-relations.png) |
||||
|
||||
Ветки дистрибутивов для нового юзера с точки зрения сложности: |
||||
|
||||
[](novice-path.png) |
||||
|
||||
Выбор DE |
||||
-------- |
||||
|
||||
Следующим вопросом является выбор DE[^fn2]. Это грубо говоря всё то, что делает удобным работу с компьютером. DE позволяет управлять окнами программ, съёмными носителями, энергосбережением, сетевыми подключениями, рабочим столом, выводит список доступных программ и т.д. |
||||
|
||||
Различаются по: |
||||
|
||||
* организации интерфейса |
||||
* панельный (он же классический) |
||||
* киосочный |
||||
* базовой графической библиотеке (также называемой тулкитом) |
||||
* Gtk2/3 |
||||
* Qt |
||||
* интеграции компонентов |
||||
|
||||
Ниже, основные представленные DE сведены в табличку. |
||||
|
||||
^ DE ^ Интерфейс ^ Тулкит ^ Интеграция ^ Настройки ^ Расход памяти ^ |
||||
^ ------------------------ основные DE --------------------------------------- | |
||||
^ KDE | панельный | Qt | сильная | много | ~800Mb | |
||||
^ LXDE | панельный | Gtk2 | слабая | мало | ~90Mb | |
||||
^ Gnome3 | киосочный | Gtk3 | сильная | мало | ??? | |
||||
^ XFCE | панельный | Gtk2 | средняя | средне | ~200Mb | |
||||
^ Unity | киосочный | | сильная | мало | ??? | |
||||
^ -------------------- DE «второго эшелона» ---------------------------------- | |
||||
^ Mate | панельный | Gtk2 | сильная | средне | ~250Mb | |
||||
^ Cinnamon | панельный | Gtk3 | сильная | мало | ~300Mb | |
||||
^ Razor-Qt | панельный | Qt | средняя | мало | ??? | |
||||
|
||||
Схема отношений DE семейств Gnome и KDE: |
||||
|
||||
[](de-relations.png) |
||||
|
||||
Небольшие примечания по каждому из DE: |
||||
|
||||
* KDE - на данный момент - KDE4[^fn3]. Считается достаточно требовательной к ресурсам, что частично исправляется отключением функций "семантического десктопа" - приложений nepomuk/baloo[^fn4] и strigi[^fn5]. Совсем удалить их не удастся, но отключить можно. |
||||
* LXDE - считается легковесной средой. Слабая интеграция компонентов позволяет заменять их по своему усмотрению на аналоги. Потребление ресурсов ~ 90Мб. |
||||
* Gnome (вторая ветка) - сейчас присутствует только в Debian (stable). Развитие закончено, поддержка закончена, пользователям рекомендуется переходить на другое DE. (см Mate.) |
||||
* Gnome (третья ветка) - один из представителей "новых веяний в дизайне интерфейса". Основной девиз - "если что-то можно преднастроить - сделайте это". |
||||
* Unity - аналог Gnome3, встречается только в дистрибутивах из семейства Ubuntu. |
||||
* Mate - Форк[^fn6] второй ветки Gnome. Новых возможностей не по факту добавляется, только поддержка существующего. Встречается в LinuxMint, Archlinux, Debian (testing). |
||||
* Cinnamon - Форк третьей ветки Gnome, направленного на воссоздание интерфейса и функционала второй ветки на основе наработок третьей. Встречается в LinuxMint. |
||||
* Razor-Qt - достаточно молодой проект, ставит целью создание легковесного DE на базе Qt. Входит в официальные репозитории Mageia, так же доступен в виде неофициальных пакетов для для большинства основных дистрибутивов. |
||||
|
||||
Установка/удаление программ |
||||
--------------------------- |
||||
|
||||
Первое и основное правило - не надо ничего ставить "вручную" без крайней необходимости. Как правило, необходимая уже присутствует в репозиториях выбранного дистрибутива, упакованная в необходимый формат и снабжённая метаданными. |
||||
|
||||
Основной задачей остаётся найти название программы с нужными возможностями, дальше пакетный менеджер сделает всё остальное для её корректной установки. |
||||
|
||||
Список основных менеджеров пакетов с разбивкой по дистрибутивам: |
||||
|
||||
^ Название ^ Интерфейс ^ Комментарии ^ |
||||
^ --------------------- Debian/*buntu/LinuxMint --------------------------------------- | |
||||
^ dpkg | cli | низкоуровневые операции, установка отдельных пакетов | |
||||
^ apt-* | cli | в большинстве руководств используется именно он | |
||||
^ aptitude | cli/ncurses | первый предлагаемый вариант решения зависимостей - | |
||||
^ - - - | - - - | не всегда оптимален, пользуйтесь '<' и '>' | |
||||
^ synaptic | gui | | |
||||
^ SoftwareCenter | gui | только в *buntu. Действует достаточно брутально, | |
||||
^ - - - | - - - | может легко выкачать по зависимостям пару гигабайт | |
||||
^ -------------------- openSUSE ------------------------------------------------------- | |
||||
^ rpm | cli | низкоуровневые операции, установка | |
||||
^ zypper | cli | | |
||||
^ yast | gui | На самом деле это целый комплекс для настройки системы | |
||||
^ -------------------- Fedora --------------------------------------------------------- | |
||||
^ rpm | cli | низкоуровневые операции, установка отдельных пакетов | |
||||
^ yum | cli | | |
||||
^ -------------------- Altlinux ------------------------------------------------------- | |
||||
^ rpm | cli | | |
||||
^ apt-rpm | cli | команды идентичны с apt-* | |
||||
^ synaptic | gui | | |
||||
^ -------------------- Mageia --------------------------------------------------------- | |
||||
^ rpm | cli | низкоуровневые операции, установка отдельных пакетов | |
||||
^ urpmi | cli | | |
||||
^ -------------------- Archlinux ------------------------------------------------------ | |
||||
^ pacman | cli | | |
||||
|
||||
Список типичных операций для управления пакетами в консоли (на примере apt'а): |
||||
|
||||
* install - установка программы с разрешением зависимостей |
||||
* remove - удаление программы (без её зависимостей) |
||||
* autoremove - удаление программы (с её зависимостями, не используемыми кем-то ещё) |
||||
* purge - удаление конфигурационных файлов и файлов, созданных при работе программы |
||||
* upgrade - установка доступных обновлений для установленных программ |
||||
* update - обновление сведений о доступных программах и их версиях |
||||
|
||||
Заостряю внимание на т.н. «рекомендованных» зависимостях. Они не являются зависимостями как таковыми, но могут оказаться полезными при работе с основной программой. Но следует помнить, что такие зависимости увеличивают размер установленной системы и, как правило, остаются при удалении основной программы[^fn7]. Отключение же этих зависимостей может потребовать дополнительных шагов для поиска нужных программ[^fn8]. |
||||
|
||||
Типичные ошибки: |
||||
|
||||
- Установка пакета из другого дистрибутива, или другой ветки дистрибутива. Это грозит проблемами с зависимостями, нарушением расположения файлов в системе. |
||||
- Смешивание веток дистрибутива. Разновидность предыдущей ошибки, также грозит проблемами с зависимостями. Например, при обновлении DE до более свежей ветки и **не**обновления всей остальной системы - может возникнуть ситуация, когда половина программ связаны со старой системной библиотекой (`*libc`), а половина - с новой, в результате чего первая половина просто не работает. |
||||
- Установка традиционным способом, через ``make install``. Возможны конфликты файлов в системе. |
||||
- Кольцевые зависимости - практически не встречаются в пределах "официальных" репозиториев, но могут возникать при подключении сторонних. Как правило исправляются удалением одного или обоих из конфликтующих пакетов без их зависимостей и установкой этих пакетов заново. |
||||
|
||||
Управление репозиториями |
||||
------------------------ |
||||
|
||||
Практически во всех дистрибутивах помимо основных репозиториев существует один или несколько сторонних, для пакетов, которые не могут быть включены в основные по лицензионным соображениям, либо слишком специфичны, чтобы тратить время на их поддержку. |
||||
|
||||
Пакеты в таких репозиториях могут как заменять пакеты в основных, так и ставиться в дополнение к ним. В первом случае может потребоваться явно указать пакетному менеджеру, какому репозиторию отдавать предпочтение. |
||||
|
||||
Примерами могут являться [rpmfusion](http://rpmfusion.org) для Fedora, [PPA](https://launchpad.net/ubuntu/+ppa/) для `*buntu`[^fn9], содержит от одной-двух до десятков программ)), [Packman](http://packman.links2linux.org) для openSUSE, [notesalexp](http://notesalexp.org) для Debian/`*buntu`, [AUR](https://aur.archlinux.org) для Archlinux, [sisyphus](http://sisyphus.ru) для Altlinux. |
||||
|
||||
Списки неофициальных репозиториев на сайтах дистрибутивов: |
||||
|
||||
* [Debian](http://wiki.debian.org/UnofficialRepositories) |
||||
* [openSUSE](http://ru.opensuse.org/Дополнительные_репозитории) |
||||
* [Archlinux](https://wiki.archlinux.org/index.php/Unofficial_User_Repositories) |
||||
* [Fedora](http://repos.fedorapeople.org) |
||||
|
||||
Локализация |
||||
----------- |
||||
|
||||
На текущий момент уже практически неактуально. |
||||
|
||||
Язык сообщений в системе как правило определяется через переменные окружения, которые определены на 2х уровнях: системном (язык для системы по умолчанию) и пользовательском - может быть уникально для каждого пользователя. |
||||
|
||||
Что нам нужно, чтобы получить русский язык в системе. |
||||
|
||||
* локаль нужного языка |
||||
* Шрифты с поддержкой нужного набора символов |
||||
* переведённые сообщения программ в нужном формате |
||||
|
||||
Как они связаны между собой: |
||||
|
||||
* Локаль определяет правила вывода символов, формат даты, времени, разделителей числовых разрядов, а также даёт подсказку программам, какой язык сообщений использовать для вывода. |
||||
* Шрифты нужны для непосредственного отображения символов |
||||
* Третий пункт отвечает за сам текст сообщения |
||||
|
||||
Как определить, где проблема: |
||||
|
||||
- И в консоли и в обычных программах все сообщения на английском |
||||
* не сгенерирована нужная локаль |
||||
* не выставлены переменные окружения |
||||
- Сообщения на английском отображаются нормально, те что должны быть на русском - отображаются неправильно. |
||||
* используются шрифты без поддержки кириллицы |
||||
- Некоторые программы на английском |
||||
* возможно, что их ещё никто не перевёл |
||||
* возможно, что нужный язык локализации поставляется отдельным пакетом, т.к. занимает значительное место (примеры: OpenOffice, Firefox, документация к Gimp) |
||||
* наименее вероятно - отсутствует/повреждён файл с переведёнными сообщениями |
||||
- Некоторые сообщения в программе на русском, а некоторые на английском |
||||
* неполный перевод |
||||
* повреждён файл с переведёнными сообщениями |
||||
|
||||
Что делать: |
||||
|
||||
Обычно, достаточно поставить из репозитория метапакет[^fn10] с соответствующей локализацией. Этот пакет может быть как общесистемным, так и специфичным для выбранной DE. что-то вроде ``kde-l10n-ru``. Поиск по словам "l10n" и "i18n" покажет список таких пакетов. |
||||
|
||||
Также, потребуется переключить язык в настройках DE или менеджера входа в систему. |
||||
|
||||
Также, для экономии места на корневом разделе может пригодиться пакет localepurge, который удаляет файлы локализации для неиспользуемых языков. |
||||
|
||||
Шрифты |
||||
------ |
||||
|
||||
В linux cуществует множество действительно хороших семейств шрифтов, которые можно использовать без боязни глазных заболеваний. Из тех что я использовал и могу рекомендовать лично: |
||||
|
||||
* Liberation |
||||
* DejaVu |
||||
* Droid |
||||
|
||||
Моменты на которых стоит заострить внимание: |
||||
|
||||
- технология сглаживания шрифтов cleartype запатентована, поэтому в большинстве дистрибутивов собирают шрифтовую подсистему без её поддержки. В зависимости от дистрибутива потребуется либо поискать репозиторий с пересобранными пакетами, либо пересобрать их самому с нужными патчами. |
||||
- помимо cleartype существует ещё одна реализация сглаживания шрифтов. Её изначально разработала Canonical для использования в *buntu, но никто не мешает использовать их наработки и в другом дистрибутиве. |
||||
- ещё одной проблемой, до недавнего времени, было отсутствие уточнения шрифтов на основе данных самого шрифта, поскольку эта технология также была запатентована. С середины 2010 года эта проблема уже неактуальна, и встретить вы её сможете только в достаточно старых дистрибутивах. |
||||
|
||||
Также, могу порекомендовать хорошую [шпаргалку](https://ru.wikibooks.org/wiki/Шрифты_в_Linux) по теории. |
||||
|
||||
Кодеки |
||||
------ |
||||
|
||||
На данный момент, в linux существует несколько подсистем для работы с аудио/видео (без учёта библиотек, специфичных для разных форматов): |
||||
|
||||
* gstreamer |
||||
* ffmpeg |
||||
* xine (устарел) |
||||
|
||||
Также, есть проигрыватель mplayer, который по большей части все форматы декодирует сам. Теоретически, поставив его, мы получим возможность воспроизведения чего угодно. На практике же, мы опять столкнёмся с тем, что для поддержки некоторых форматов, защищёнными патентами. |
||||
|
||||
Ярким примером может являться dvdcss, отвечающий за поддержку dvd, защищённых от копирования. |
||||
|
||||
Таким образом, большинство проблем с кодеками решаются доустановкой пакетов (возможно, с подключением сторонних репозиториев). Как правило это: |
||||
|
||||
* gstreamer-plugins-{bad,ugly} |
||||
* libdvdcss |
||||
* libfaad, libfaac |
||||
* и так далее |
||||
|
||||
Повышенной щепетильностью в этом вопросе отличается проигрыватель totem, идущий как стандартный в gnome-based окружениях. |
||||
|
||||
Отдельным пунктом идёт воспроизведение flash-контента в интернете. Для его поддержки требуется доустановить flash-plugin из репозитория. Можно использовать как свободную разработку - gnash(поддерживается далеко не всё), так и пакет с оригинальным плагином от adobe. |
||||
|
||||
С оригинальным пакетом вы можете встретится со следующими проблемами: |
||||
|
||||
* нестабильная работа на 64битных системах |
||||
* проблемы с использованием аппаратного ускорения (внешне выглядит как "артефакты"[^fn11]) - исправляется отключением ускорения в настройках |
||||
* проблема с цветопередачей (эффект "аватара") - решения пока нет |
||||
|
||||
В качестве обхода проблемы на youtube можно использовать просмотр с использованием html5. Для этого достаточно зайти [сюда](http://www.youtube.com/html5) и нажать "включить html5". |
||||
|
||||
Смена DE по умолчанию |
||||
--------------------- |
||||
|
||||
Общий алгоритм такой: |
||||
|
||||
- ставим нужное DE |
||||
- выходим из системы |
||||
- меняем сессию по умолчанию |
||||
- пробуем зайти в систему |
||||
- если всё удачно - осторожно удаляем ненужное DE |
||||
|
||||
Обращаю внимание, что зачастую то или иное DE ставится одним или несколькими метапакетами. Т.е. если удалить такой метапакет - компоненты DE и их неиспользуемые зависимости должны также автоматически удалиться. Перед применением изменений внимательно просмотрите список удаляемых пакетов. |
||||
|
||||
"Железо" |
||||
-------- |
||||
|
||||
В большинстве случаев, для компонентов компьютера драйвера идут в виде модулей ядра и установки не требуют. Единственное что, в некоторых дистрибутивах может потребоваться установить загружаемую прошивку для устройства из репозитория. Как правило, это требуется для некоторых сетевых карт. |
||||
|
||||
Принцип диагностики такой - физически устанавливаем устройство в компьютер, загружаемся, смотрим, видится ли устройство ядром. Для этого можно использовать набор утилит ls{dev,pci,pcmcia,blk,cpu,usb}, скрипт hwinfo, либо посмотреть вывод dmesg, там перечислены все устройства, которые распознало ядро при загрузке[^fn12]. |
||||
|
||||
Для устройств, подключаемых по usb/fireware можно посмотреть сообщения ядра, которые появляются при подключении устройства (команда dmesg). |
||||
|
||||
Возможно вам потребуется добавить себя в соответствующую системную группу (printer, scanner, cdrom, video, audio, ...). (консольная команда: gpasswd -a <username> <group> или используйте системный конфигуратор) |
||||
|
||||
Что делать, если устройство не заработало: |
||||
|
||||
* Постарайтесь узнать точную модель устройства |
||||
* Посмотрите таблицы совместимости оборудования (список ниже). |
||||
* И наконец, спросите у ближайшего поисковика, как оно работает с линуксом (запрос должен быть вида «<device name> linux»). |
||||
|
||||
Таблицы совместимости для некоторых типов оборудования: |
||||
|
||||
* [беспроводные сетевые карты](http://linuxwireless.org/) |
||||
* [звуковые карты](http://linux-sound.org/hardware.html) |
||||
* [принтеры](https://www.openprinting.org/printers/) |
||||
* [сканеры](http://www.sane-project.org/sane-mfgs.html) |
||||
* видеокарты: [общий список](http://xorg.freedesktop.org/wiki/Projects/Drivers), [ATI/AMD](http://www.x.org/wiki/RadeonFeature), [nvidia](http://nouveau.freedesktop.org/wiki/FeatureMatrix) |
||||
* [usb-устройства](http://www.linux-usb.org) |
||||
* [видео-/webкамеры](http://www.teaser.fr/~hfiguiere/linux/digicam.html) |
||||
* [мобильные устройства](http://tuxmobil.org) |
||||
* [различные устройства](http://hardware4linux.info/types) |
||||
|
||||
Некоторые устройства, например принтеры, потребуют также настроить управляющую ими программу (для принтеров - cups). |
||||
|
||||
Примерные названия пакетов, требуемые некоторыми типами устройств: |
||||
|
||||
* bluetooth: bluez |
||||
* printers: cups, foomatic (HP - hplip, samsung - splix) |
||||
* scanners: sane |
||||
* audio: alsa, alsa-utils |
||||
* wifi: ``wpa_supplicant`` (требуется только для сетей с шифрованием) |
||||
* video (input): v4l |
||||
* video (output): xorg, mesa |
||||
|
||||
Автоматизация процесса |
||||
---------------------- |
||||
|
||||
Для точного воссоздания системы "с нуля" обычно достаточно 4х вещей: |
||||
|
||||
* списка установленных пакетов |
||||
* копии директории «/etc/» |
||||
* копии директории «/home/» |
||||
* копии директории «/var/» |
||||
|
||||
Алгоритм восстановления такой: |
||||
|
||||
* ставим минимальную систему |
||||
* скармливаем пакетному менеджеру список пакетов |
||||
* копируем на место «/etc» и «/var» |
||||
* подключаем «/home» |
||||
* всё |
||||
|
||||
Для архивирования директорий «/etc» и «/var» - используем команду ``tar``. «/home» обычно ещё при установке выносится отдельным разделом, поэтому главное не подключить его слишком рано. |
||||
|
||||
для получения списка пакетов - обратитесь к документации по вашему пакетному менеджеру, я лишь приведу пару примеров: |
||||
|
||||
* для Debian'a/Ubuntu/LinuMint - ``aptitude search '~i' | awk '{ print $2 }'`` - выведет список всех пакетов, установленных в системе. |
||||
* для Archlinux'a - pacman -Qe (обратите внимание, что в этом случае выводятся только пакеты, установленные вручную, остальные ставятся как зависимости первых) |
||||
|
||||
Известные проблемы |
||||
------------------ |
||||
|
||||
Здесь приведён список подсистем, с которыми регулярно возникают проблемы а также симптомы появляющиеся при этом. |
||||
|
||||
**pulseaudio** |
||||
|
||||
Симптомы: проблемы со звуком: задержки, искажения, полная неработоспособность. |
||||
Быстрое решение: переключиться в нужном приложении на другую подсистему вывода звука: alsa. |
||||
Капитальное решение: удаление pulseaudio. |
||||
|
||||
**selinux** |
||||
|
||||
Fedora-специфично. |
||||
|
||||
Симптомы: сообщения "недостаточно прав" при файловых операциях или работе программ. |
||||
Быстрое решение: настройка прав selinux.\\ |
||||
Капитальное решение: отключение или перевод подсистемы selinux в "разрешающий режим". |
||||
|
||||
**kit'ы** |
||||
|
||||
Симптомы: сообщения вида "действие запрещено администратором", "недостаточно прав" и "not authorized" при подключении/отключении флэшек, выключении/перезагрузке компьютера.\\ |
||||
Быстрое решение: [PolicyKit](https://wiki.archlinux.org/index.php/PolicyKit) |
||||
|
||||
Где искать помощь |
||||
----------------- |
||||
|
||||
При возникновении вопросов, помощь стоит поискать: |
||||
|
||||
* на официальном сайте дистрибутива обязательно есть раздел посвящённый новичкам, в первую очередь - посетите его |
||||
* на специализированных форумах дистрибутивов |
||||
* в местном Linux User Group, если такой имеется [список](http://lug.ru/lugs) |
||||
* на форумах, посвящённых linux и СПО (в качестве примера - [unixforum](http://unixforum.org), [linuxforum](http://linuxforum.ru) |
||||
* на местных форумах (как правило - технические разделы) |
||||
* в конференциях [jabber.ru](http://jc.jabber.ru) |
||||
|
||||
Что я смогу сделать сам? |
||||
------------------------ |
||||
|
||||
Для начинающего пользователя главная задача - учиться. В первую очередь [искать](http://citforum.ru/operating_systems/linux/kandminimum2/) и правильно [задавать вопросы](http://segfault.kiev.ua/smart-questions-ru.html). К сожалению, и то и другое нарабатывается только практикой, прочитать пару руководств недостаточно. |
||||
|
||||
К моменту, когда вы освоитесь в «готовой» системе (минимальный срок - полгода, максимального срока нет), можно попробовать перестроить её под себя. Это даст дополнительный опыт и, что самое важное, понимание, как работает та или иная подсистема или программа. На этом этапе самое важное - научиться исправлять последствия своих экспериментов. |
||||
|
||||
Этот уровень - необходимый минимум для пользователя linux. |
||||
|
||||
Если вы хотите большего, вам открыты все пути - можно сообщать об ошибках разработчикам, можно помогать новым пользователям через форумы/irc/jabber/..., можно присоединиться к какому-либо интересному проекту, можно даже создать свой дистрибутив[^fn14]. |
||||
|
||||
В этом и состоит основное преимущество linux - в свободе действия. |
||||
|
||||
[^fn1]: Дистрибутив - это набор компонентов и программ, интегрированных между собой |
||||
|
||||
[^fn2]: сокращение от Desktop Environment, окружение рабочего стола |
||||
|
||||
[^fn3]: т.е. четвертая ветка |
||||
|
||||
[^fn4]: хранение персональных данных, теги |
||||
|
||||
[^fn5]: индексация и поиск |
||||
|
||||
[^fn6]: ответвление проекта, развиваемого другой командой разработчиков |
||||
|
||||
[^fn7]: что по прошествии времени вызывает вопрос - «откуда взялись все эти программы?» |
||||
|
||||
[^fn8]: Отсюда вывод - знаете что вам нужно - отключайте их. |
||||
|
||||
[^fn9]: на самом деле это целая куча мелких репозиториев создаваемых пользователями |
||||
|
||||
[^fn10]: т.е. пакеты-«пустышки», сами по себе не содержащие файлов, но зависящие от всех пакетов определённой группы |
||||
|
||||
[^fn11]: полоски неправильного цвета, "шлейф" за движущимися объектами и т.д. |
||||
|
||||
[^fn12]: но также и многое другое, к делу не относящееся |
||||
|
||||
[^fn13]: а ещё их можно использовать как ключевые слова при поиске |
||||
|
||||
[^fn14]: правда, к этому моменту пользователь осознаёт бессмысленность создания **ещё одного** дистрибутива. |
||||
|
After Width: | Height: | Size: 47 KiB |
|
After Width: | Height: | Size: 62 KiB |
|
After Width: | Height: | Size: 3.9 KiB |
@ -0,0 +1,123 @@
|
||||
--- |
||||
title: Сборка и развертывание образа бездискового клиента с корнем на nbd |
||||
tags: debian, linux, nbd, pxe |
||||
--- |
||||
|
||||
nbd - это тип устройства, а также прикладной сетевой протокол в linux, который позволяет работать с блочными устройствами (либо файлами как блочными устройствами) по сети. |
||||
|
||||
Ближайший аналог - [iSCSI](http://xgu.ru/wiki/iSCSI), но есть некоторые отличия. Например, nbd внутри значительно проще, протокол предусматривает набор команд для блочного устройства, например чтение, запись, указание смещения от начала устройства. iscsi же реализует внутри себя весь его (scsi) функционал - например определение типа устройства, копирование между устройствами, работа с несколькими устройствами по одному каналу, и т.д. |
||||
|
||||
Ещё один аналог - [AoE](http://xgu.ru/wiki/AoE), но опять же есть отличия. AoE работает на одном уровне с ip, что уменьшает накладные расходы, но позволяет использовать его только в пределах одной подсети, т.к. он немаршрутизируемый. AoE не гарантирует целостность передаваемых данных и зависит от надежности оборудования. |
||||
|
||||
--- |
||||
|
||||
Бездисковая загрузка может быть организована двумя основными способами: |
||||
|
||||
* с использованием сетевой ФС |
||||
* с использованием блочных устройств |
||||
|
||||
Поскольку nbd подразумевает использование второго варианта, возникает вопрос как лучше организовать установку ОС на это самое блочное устройство, а также её (ОС) настройку и обновление впоследствии. Во-первых необходимо определится, что это будет за устройство: {диск, раздел на диске, файл}. Во-вторых - определится с методом установки ОС для клиента: {chroot, установка в виртуалке, установка на реальном железе}. |
||||
|
||||
Я лично - использую обычный файл в качестве устройства и виртуалку[^fn1]. Почему именно так: |
||||
|
||||
Во-первых, ставить современный "user-friendly" дистрибутив через chroot - то ещё удовольствие, не рассчитаны они на это. (для примера - попробуйте поставить 12й минт с корнем внутри lvm). Опять же, если есть инсталлер, который значительно экономит время - почему бы его не использовать. |
||||
|
||||
Во-вторых, почему именно файлы, а не разделы на диске или тома lvm - да, работает медленнее, но значительно проще управление и перенос на другой компьютер. Типичная моя виртуалка - директория с двумя файлами - сам «диск» и shell-скрипт запуска. При использовании в качестве формата диска qcow или что-то подобное - место расходуется только по необходимости. Например, на 30-гиговом разделе спокойно умещаются 6 виртуалок с типовыми дисками по 8Гб. Впрочем, я отвлекся. |
||||
|
||||
Подготовка клиента |
||||
------------------- |
||||
|
||||
Создаем файл диска минимально необходимого размера. |
||||
|
||||
qemu-img create diskless.raw 4G |
||||
|
||||
На самом деле, можно использовать любую виртуалку и любой поддерживаемый её формат, но raw-формат позволяет лазить внутрь образа с помощью loop-устройства. В другие распространенные форматы - тоже можно, но уже при помощи qemu-nbd, что требует установленного qemu. |
||||
|
||||
Запускаем в минимальной конфигурации, добавить опций по вкусу: |
||||
|
||||
qemu -vga std -m 512M \ |
||||
-net nic,macaddr=52:54:00:XX:XX:XX \ |
||||
-hda "diskless.raw" \ |
||||
-cdrom "install-cd.iso" |
||||
|
||||
Обратите внимание, что сетевой адаптер создается с определенным mac-адресом, иначе он может меняться при каждом запуске. Ставим систему как обычно, в минимально возможной конфигурации. Несколько рекомендаций: |
||||
|
||||
* initrd собирается с полным набором модулей для сетевых карт, всё остальное безжалостно выкидывается. Если это не настраивается - собирается со всеми модулями. Проследите, чтобы туда попал модуль nbd. |
||||
* размер свопа - подбирается в зависимости от наличия памяти на клиентах, чем её больше, тем своп меньше. |
||||
* в качестве загрузчика - syslinux или lilo[^fn2], функционал grub'а здесь нафиг не нужен. |
||||
* чем меньше разделов - тем лучше, снижается вероятность нехватки места где-либо, lvm - ещё одна прослойка, добавляющая тормозов. |
||||
* планировщик для «диска» с nbd - noop, серверная часть сама разберется как и когда ей писать на диск. |
||||
* отключайте NetworkManager и ему подобные для основного интерфейса, во избежание выстрела себе в ногу. Если возможно - не ставьте совсем. |
||||
* ничего лишнего в демонах и автозагрузке. |
||||
|
||||
После установки - делаем бэкап диска, настраиваем/обновляем систему и делаем второй бэкап. После этого можно готовить систему к работе по сети. На что нужно обратить внимание при настройке: |
||||
|
||||
* в fstab - корень вида "none / auto defaults,relatime 0 0", все остальные разделы - подключаются по uuid или по метке. Это позволит использовать систему как в виртуалке, так и в развернутом виде. root= и rootfstype= указываются в параметрах загрузчика. |
||||
* проследите, чтобы сеть не опускалась при перезагрузке/выключении, иначе вы получите kernel-panic вместо ожидаемого. |
||||
* проследите, чтобы сетевые интерфейсы не менялись местами (если их несколько) и сразу после загрузки удалялись файлы hal'а/udev'а, отвечающие за их наименование. Обычно это что-то вида ``*-persistent-net-*.rules`` в ``/{etc,lib}/{hal,udev}/``. Иначе получите eth(X+1) вместо ожидаемого eth(X). А ещё лучше - перевесьте интерфейс виртуалки, где это всё собирается - на какой-нибудь eth5. Примерное содержание фала `/etc/udev/rules.d/70-persistent-net.rules`: |
||||
|
||||
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="aa:bb:cc:dd:ee:ff", ATTR{dev_id}=="0x0", ATTR{type}=="1", КERNEL=="eth*", NAME="eth5" |
||||
|
||||
TODO: дописать этот раздел |
||||
|
||||
Развертывание |
||||
-------------- |
||||
|
||||
Нужна машина с dhcp, tftp и nbd сервером. Канал до свитча с клиентами - желательно гигабитный, но и 100-мегабитного, по моим наблюдениям, машин на 10 должно хватить. [^fn3]. |
||||
|
||||
Требования к месту на диске - при использовании copy-on-write - <размер образа> * <количество клиентов> - максимально, минимально - смотреть по ситуации. Без использования - только под размер образа. |
||||
|
||||
Требования к dhcp - уметь отдавать кроме, собственно, ip-адреса - параметры "next-server" и "filename". |
||||
|
||||
Требования к tftp - уметь отдавать файлы :-). Дополнительно - поддерживать согласование ``blocksize``. это сильно ускоряет отдачу файлов. |
||||
|
||||
Требования к nbd - подойдет любой. Дополнительно - поддержка copy-on-write, это позволяет не сильно напрягаться насчет мест в образе, куда требуется запись (снижает требования к памяти у клиентов (tmpfs) + убирает необходимость монтировать что-то ещё чисто "под запись"). |
||||
|
||||
Заливаем получишийся образ на сервер, кладем в отдельную директорию, выставляем владельца/права на файлы примерно так: |
||||
|
||||
drwxrwxr-x 2 admin nbd 4,0K янв. 01 00:00 . |
||||
drwxr-xr-x 3 root root 4,0K янв. 01 00:00 .. |
||||
-rwxrwxr-x 1 admin nbd 4,0G янв. 01 00:00 diskless.bin |
||||
|
||||
TODO: выложить конфиг nbd с комментариями. |
||||
|
||||
Вытаскиваем из образа ядро и initrd, кладем в директорию, доступную tftpd. Переписываем опции загрузчика из образа в конфиг pxelinux, у меня получилось что-то вроде этого: |
||||
|
||||
label debian |
||||
kernel /_boot/debian/vmlinuz |
||||
append initrd=/_boot/debian/initrd.img quiet vga=789 **nbdroot=192.168.0.1,2004 root=/dev/nbd0p2** |
||||
|
||||
Пути нужно поправить, выделенное ``**`` - добавлено[^fn4]. |
||||
|
||||
Обновление |
||||
----------- |
||||
|
||||
TODO |
||||
|
||||
Замеченные грабли |
||||
------------------ |
||||
|
||||
- При использовании файловых систем семейства ext? и древнего железа может возникнуть следующая ситуация: ФС (в т.ч. корень) может отказаться монтироваться, если в биосе на клиенте слетели настройки времени из-за сдохшей батарейки и/или отключения света. "Last mount time in the future, run fsck manually." и всё, курите бамбук. UPD: [решение](/articles/2013/02/06/diskless_client_nbd/) этой задачи вынесено в отдельную статью. |
||||
- Сочетание cow + atime в параметрах монтирования вызывает взрывной рост diff-файла. Используйте noatime/relatime где только можно. |
||||
- Если используется обновление образа с помощью одной из машин, нужно удалять правила udev'а для назначения имени сетевым картам выключения, иначе «поплывет» нумерация сетевух. |
||||
- Связано с предыдущим пунктом - получение сетевых настроек по dhcp и их применение без конфигурации самого интерфейса. Это нужно для того, чтобы при смене адреса dns-сервера (например) не лезть в образ. При использовании в качестве клиента dhcpcd - это делается с помощью ключа «-s» с пустым параметром (т.е. dhcpcd -s «» <iface>)[^fn5]. В других клиентах - смотреть в мане, как включается тип сообщений ``DHCP_INFORM``. |
||||
- Нужно как-то чистить diff'ы образа после отключения клиента. Есть идея пропатчить сервер, чтобы он создавал и сразу удалял diff-файл, т.о. проблема чистки решится автоматически - с закрытием соединения/вылетом nbd-сервера/перезагрузкой машины файл будет удален. Пока не знаю, будет ли это работать, это зависит от того используется ли там mmap/seek+write и работают ли они для удаленных, но не закрытых файлов. Если это не работает - пропатчить, чтобы порожденный процесс удалял diff перед самым выходом. |
||||
- Debian'о-специфичные грабли - инитскрипты жестко привязаны к имени корневого раздела вида ``/dev/nbd?p?``, т.е. корень внутри lvm'а идет лесом. Возможно оно и к лучшему. |
||||
|
||||
TODO: четвертый пункт дополнить описанием, зачем вообще здесь нужен ``dhcp_inform``, пятый переписать по результатам тестирования патча. |
||||
|
||||
Ссылки |
||||
------- |
||||
|
||||
* [Network block device](http://en.wikipedia.org/wiki/Network_block_device) |
||||
* [HOWTO для archlinux'а](https://wiki.archlinux.org/index.php/Diskless_network_boot_NBD_root) |
||||
|
||||
[^fn1]: qemu. проигрывает VBox'у в простоте и удобстве, выигрывает в скорости и гибкости |
||||
|
||||
[^fn2]: осторожно, у него проблемы с дисками, подключенными как virtio |
||||
|
||||
[^fn3]: Разумеется оно и через диалап-модем загрузится, но загрузки дождетесь как раз к завтрашнему вечеру |
||||
|
||||
[^fn4]: debian'о-специфичные опции, у вас они могут отличаться, смотрите в своих инитскриптах |
||||
|
||||
[^fn5]: в дебиане это пишется в /etc/default/dhcpcd, OPTIONS=('-p' '-s'). |
||||
@ -0,0 +1,50 @@
|
||||
--- |
||||
title: Местные зеркала репозиториев |
||||
tags: archlinux, ubuntu, debian |
||||
--- |
||||
|
||||
Здесь собираются зеркала репозиториев различных linux-дистрибутивов. Расположение зеркал - Приморский край, главным образом - Владивосток. Добавление новых зеркал - приветствуется. |
||||
|
||||
--- |
||||
|
||||
Частные зеркала |
||||
---------------- |
||||
|
||||
Круглосуточная работа - не гарантируется, и зависит от владельца зеркала. |
||||
|
||||
Контакты: forum/crypton |
||||
Адрес: ftp:*w.almss.net/archlinux/ или ftp:*h.almss.net/archlinux/ |
||||
Дистрибутивы: |
||||
* Archlinux |
||||
Примечания: также доступен через rsync |
||||
|
||||
|
||||
Контакты: forum/AdUser |
||||
Адрес: http://aduser.info/repo/ |
||||
Дистрибутивы: |
||||
* Debian (+multimedia +fusioninventory +security +notesalexp +local) |
||||
* Ubuntu (только LTS) (+i2p) |
||||
|
||||
Зеркала ISP и организаций |
||||
--------------------------- |
||||
|
||||
Владелец: Подряд |
||||
Адрес: http://mirror.podryad.tv (RIP, 2014-10-16) |
||||
|
||||
Владелец: ДВО РАН |
||||
Адрес: ftp://ftp.dvo.ru/pub/ |
||||
Дистрибутивы: |
||||
* OpenBSD |
||||
* OpenSUSE |
||||
* Gentoo |
||||
* Slackware |
||||
Примечания: также, там лежит много редких образов, например Knoppix, OpenSolaris, SL, texlive |
||||
|
||||
Владелец: ВГУЭС |
||||
Адрес: http://repo.vvsu.ru |
||||
Дистрибутивы: |
||||
* Debian (+dotdeb) |
||||
* Ubuntu |
||||
|
||||
Владелец: Vladlink |
||||
Адрес: http://mirror.vladlink.lan (RIP, 2015-10-10) |
||||
@ -0,0 +1,31 @@
|
||||
--- |
||||
title: Обновление сайта |
||||
tags: linuxdv |
||||
--- |
||||
|
||||
Буду краток. В августе истекает срок действия старого домена linuxdv.ru, продлить который мы не можем. Если интересны детали - спросите **SCIF**'а, он популярно всё объяснит. |
||||
|
||||
Поскольку никто больше особо не горит желанием заниматься сайтом и форумом[^fn1], в игру вступаю я. |
||||
|
||||
--- |
||||
|
||||
Основные отличия: |
||||
|
||||
* старые статьи почищены (верстка, битые ссылки, опечатки и прочая орфография) |
||||
* движок обновлен до актуальной версии |
||||
* залиты все сохранившиеся у меня фотографии с прошедших эвентов, а также материалы к темам |
||||
* основной домен - linuxdv.org |
||||
* дополнительно сайт доступен по [этому](http://[fc89:68a4:1b14:a320:7d2e:ae1b:f250:dce7]) ipv6-адресу в [cjdns](https://ru.wikipedia.org/wiki/Cjdns) |
||||
* вместо статичного списка статей предлагается формат коллективного блога + отдельные страницы для больших тем (пример - проект по редактированию торрентов) |
||||
|
||||
Глюки и баги: |
||||
|
||||
* сломана сквозная авторизация с форумом (слишком кривая схема работы + легаси) |
||||
* не работает почта и уведомления (вообще) |
||||
* дата создания, а следовательно и сортировка статей - сбилась в кучу |
||||
* авторизацию на форуме иногда плющит |
||||
|
||||
Всё это решаемо, но не сразу. |
||||
|
||||
[^fn1]: а кое-кто выражал сомнение в нужности последнего |
||||
[^fn2]: впрочем, это уже вторая подобная итерация, предыдущая была 2009-12-03 |
||||
@ -0,0 +1,78 @@
|
||||
--- |
||||
title: Оверлейные сети, общая информация |
||||
tags: репост, security, i2p, tor, cjdns |
||||
--- |
||||
|
||||
Ниже перечислены свободные и открытые проекты оверлейных сетей, с кратким описанием, основыми недостатками и перспективами развития. В статье рассматриваются только сети, подходящие для потоковой передачи произвольного трафика. |
||||
|
||||
tor |
||||
--- |
||||
|
||||
Наиболее распространённая сейчас сеть. |
||||
|
||||
По сути - это socks-прокси, с произвольным маршрутом, но фиксированным количеством хопов (3). Изначальное предназначение - обход цензуры. Реализован на C, потребление ресурсов - умеренное, задержки невысокие (~5с на загрузку странички внутреннего сайта). |
||||
|
||||
Есть несколько: [1](https://blog.torproject.org/blog/tor-security-advisory-relay-early-traffic-confirmation-attack), [2](https://www.torproject.org/docs/faq.html.en#AttacksOnOnionRouting) подтверждённых и осуществимых атак на сабж. Вкратце: атака на exit-node, timing-атака, и последняя по времени - badrelay - направлена на внутренние сайты. |
||||
|
||||
Местный dns работает по следующим правилам - ``http://*.onion`` - внутренние сайты, всё остальное - внешка. Роутер публикует адрес сайта на "ближайшем" роутере с выставленным флагом "Dir", т.е. "каталог" (от "directory"). "Каталоги" периодически обмениваются информацией между собой. Адрес сайта выглядит примерно как "hemtrhbowstmbw.onion". Уникальность доменного имени гарантируется сгенерированным 1024-битным RSA ключом. |
||||
|
||||
Прогноз: будет использоваться ещё долго, при отсутствии критических уязвимостей. Все существующие атаки требуют значительного времени на деанонимизацию пользователя, если тот сам не сделает какую либо глупость. |
||||
|
||||
Сайт проекта: [здесь](http://torproject.org) |
||||
|
||||
i2p |
||||
--- |
||||
|
||||
В прошлом - форк freenet'а, ныне - самостоятельный проект. В отличие от tor'а - предназначен в первую очередь для размещения информации внутри сети, а не проксирования трафика во внешнюю. Выходов во внешний интернет - "outproxy" - всего несколько. Реализация - java, потребление ресурсов - высокое (минимум 200мб памяти, в среднем - 500). Задержки - до 40 секунд, первое соединение устанавливается с вероятностью 70-80%, последующие - значительно быстрее[^fn1]. |
||||
|
||||
Эмулирует набор прокси (socks, http, https). Количество хопов - от 0 до 8, (складывается из настроек клиентского (нашего) и серверного туннеля(удалённого)), может варьироваться при каждом соединении. Туннели перестраиваются каждые 10 минут. |
||||
|
||||
Основная проблема - java. Потребление ресурсов автоматически ставит крест на дешёвых dlink'ах, и прочих мыльницах за 20$. Впрочем, есть целых 2 проекта с попыткой переписать роутер на c++: [1](https://github.com/kytvi2p/i2pcpp), [2](https://github.com/PrivacySolutions/i2pd) |
||||
|
||||
Вторая по важности проблема - со стороны софта требуется или поддержка работы через прокси, или модификация исходников. Например, для торрентов есть 2 варианта - или встроенное приложение i2psnark, или старый и заброшенный форк transmission'а. |
||||
|
||||
Сам роутер - монструозен в плане навешанных возможностей (leechcraft видели?). Там тебе и встроенный вебсервер, и торрент, и почтовый клиент, и собственные децентрализованная служба сообщений и вебморда для управления роутером. |
||||
|
||||
DNS выглядит так: каждый роутер поддерживает список соответствий из b64 адреса (длинная многобайтная хреновина, он же - addresshelper), b32 адреса - укороченая версия helper'а вида ``[a-z]{52}.b32.i2p``[^fn2], и "человекочитаемых" доменных имён в корневой зоне ".i2p". При доступе к новому сайту, роутер сначала должен найти его addresshelper, что иногда занимает значительное время. Процесс можно ускорить, добавив несколько готовых списков ("подписок"), публикуемых некоторыми маршрутизаторами. |
||||
|
||||
Сейчас - сеть обеспечивает наибольшую анонимность из своих аналогов, но только при комплексном подходе к безопасности[^fn3]. |
||||
|
||||
Прогноз: будет быстро вытеснена, если появится менее ресурсоёмкая альтернатива. |
||||
|
||||
* [сайт проекта](http://geti2p.net/en/) |
||||
* Собранные [пакеты](http://ppa.launchpad.net/i2p-maintainers/i2p/) под debian/ubuntu. |
||||
|
||||
cjdns |
||||
----- |
||||
|
||||
На мой взгляд - самый перспективный проект в плане mesh-сетей. Реализован на C, потребляет мало, предусмотрена работа как поверх голого L2/ethernet, так и L3/udp. В отличие от проксей tor'а и i2p предоставляет tun-интерфейс с ipv6, это сразу даёт совместимость практически со всем не слишком старым софтом. |
||||
|
||||
!!! Сеть не анонимна. |
||||
|
||||
Интересен принцип поиска нужного хоста и внутренней маршрутизации. Вкратце он описан в их [whitepaper](https://github.com/cjdelisle/cjdns/blob/master/doc/Whitepaper.md)'е. Краткая суть такова - используется label-based routing, при проходе через роутер, последовательность label'ов сдвигается на размер label'а этого роутера. label - не фиксированного размера и соединены в route "встык". На практике, это означает, что конечный router не знает сколько **точно** хопов проходит пакет, но всю последовательность хопов можно восстановить при желании. |
||||
|
||||
Основной недостаток - создатели предполагают организацию "friend-to-friend", по типу фидо. Автоматическое обнаружение новых нод работает только если вы уже подключены к какой либо из них. [Обсуждение](http://cjdns.ru/forum/viewtopic.php?f=6&t=177) нужности "публичных пиров", ака "bootstrap". |
||||
|
||||
Второй недостаток - до сих пор не решены проблемы с местным dns'ом, нет точного представления, как он должен выглядеть. Есть несколько серверов, держащих неофициальную корневую зону `.hype`, но в долгосрочной перспективе - это опять централизация, со всеми вытекающими. Были попытки прикрутить к нему namecoin, но всеобщего одобрения идея не получила. |
||||
|
||||
Прогноз: положительный, при решении проблемы с dns'ом и механизмом обнаружения. Стабильный - в противном случае. Важно помнить, что это не прямая замена tor'у и i2p, поскольку анонимность весьма условная. |
||||
|
||||
* [github](https://github.com/cjdelisle/cjdns) |
||||
* [Русскоязычный сайт](http://cjdns.ru), [зеркало](http://cjdroute.net) |
||||
* [Карта](http://cjdroute.net/map/) узлов |
||||
* Собранные [пакеты](http://aduser.info/repo/debian-local/) под debian. |
||||
|
||||
netsukuku |
||||
---------- |
||||
|
||||
!! Упоминается в качестве исторической ретроспективы, сейчас проект мёртв. |
||||
|
||||
Идейный предок cjdns, но с другими принипами организации маршрутов. Основная идея - маршрутизация на основе фракталов. Близкорасположенные рядом ноды образуют "сеть" не больше определённого размера. Внутри сети маршруты строятся самими нодами, на основе данных о сегменте сети, между сетями - только через указание самой сети, лучший маршрут внутри транзитной сети выбирается ей самостоятельно. |
||||
|
||||
Первоначальная реализация - C, потом проект переписали на питон, от чего он и помер. Через несколько лет проект внезапно переписали ещё раз - на vala, но, как нетрудно догадаться, ему это не помогло. |
||||
|
||||
* [Википедия](https://en.wikipedia.org/wiki/Netsukuku) |
||||
|
||||
[^fn1]: пока живёт туннель, т.е. следующие 10 минут |
||||
[^fn2]: может быть получен из b64 |
||||
[^fn3]: Об этом - в следующей статье |
||||
@ -0,0 +1,113 @@
|
||||
--- |
||||
title: Firefox / Настройки приватности |
||||
tags: security, privacy, firefox |
||||
--- |
||||
|
||||
Утянуто с ЛОРа, дополнено своими заметками. Что требуется подкрутить в настройках самого браузера, чтобы он не стучал, аки дятел, куда попало. |
||||
|
||||
--- |
||||
|
||||
Запрещает поддержку протокола WebRTC, текущая реализация которого позволяет незаметно для пользователя получить список IP-адресов в его локальной сети (с помощью JavaScript), что повышает уникальность пользователя. [Пруф](http://habrahabr.ru/post/215071/) |
||||
|
||||
media.peerconnection.enabled = false |
||||
|
||||
Отключает передачу информации о посещаемых веб-сайтах Гуглу, база которого используется для предупреждений о мошеннических сайтах |
||||
|
||||
browser.safebrowsing.enabled = false |
||||
browser.safebrowsing.malware.enabled = false |
||||
browser.safebrowsing.downloads.enabled = false # >= 34 |
||||
|
||||
Отключает передачу текста, набираемого в окне поиска, поисковой системе без явного подтверждения со стороны пользователя. Лишаемся предложений от поисковой системы по мере набора запроса, но зато, если вы вдруг начали набирать запрос и передумали - он не отправится до нажатия Enter |
||||
|
||||
browser.search.suggest.enabled = false |
||||
|
||||
Отключает передачу браузером информации о времени начала и окончания загрузки страницы. Анализ этих данных позволяет определить факт использования прокси-сервера |
||||
|
||||
dom.enable_performance = false |
||||
|
||||
Запрещает предварительное разрешение имён DNS для всех ссылок на веб-странице (пока пользователь сам не нажмёт на ссылку). Это может привести к утечке DNS-трафика при работе через анонимизирующий прокси-сервер |
||||
|
||||
network.dns.disablePrefetch = true |
||||
|
||||
Отправлять DNS-запросы через прокси при использовании прокси. Иначе они пойдут напрямую и могут привести к раскрытию реального IP-адреса |
||||
|
||||
network.proxy.socks_remote_dns = true |
||||
|
||||
Отключить Seer (см. первый комментарий в топике для подробностей) |
||||
|
||||
network.seer.enabled = false |
||||
|
||||
Запрещает сайтам установку соединений на критически важные порты, занятые I2P и Tor |
||||
|
||||
network.security.ports.banned = 4444,9050,9051 |
||||
|
||||
Запрещает отслеживать состояние батареи и тем самым получать информацию, по которой можно идентифицировать пользователя |
||||
|
||||
dom.battery.enabled = false |
||||
|
||||
Запрещает определять параметры соединения с сетью (при этом передаётся тип соединения: LAN, Wifi, 3G и так далее) |
||||
|
||||
dom.network.enabled = false |
||||
|
||||
Запрещает сайтам обращение к локальной машине, что позволило бы им анализировать список открытых портов. [Подсмотрено](https://trac.torproject.org/projects/tor/ticket/10686) у разработчиков Tor Возможны проблемы при обращении на адреса типа ``http://127.0.0.1:631``, используемые для конфигурации принтеров через CUPS и прочих устройств |
||||
|
||||
network.proxy.no_proxies_on = (пустое значение) |
||||
|
||||
Тоже подсмотрено у Tor. Запрещает передачу сайтам подробной информации о графических возможностях системы |
||||
|
||||
webgl.disable-extensions = true |
||||
webgl.min_capability_mode = true |
||||
|
||||
Полное отключения кэширования. Анализируя время загрузки страницы, можно узнать, посещал ли пользователь этот сайт. Если посещал - часть файлов будет взята из кэша, что отразится на времени |
||||
|
||||
browser.cache.disk.capacity = 0 |
||||
browser.cache.disk.enable = false |
||||
browser.cache.disk.smart_size.enabled = false |
||||
browser.cache.disk_cache_ssl = false |
||||
browser.cache.memory.enable = false |
||||
browser.cache.offline.capacity = 0 |
||||
browser.cache.offline.enable = false |
||||
dom.indexedDB.enabled = false |
||||
media.cache_size = 0 |
||||
network.http.use-cache = false |
||||
|
||||
Отключает возможность сайтов хранить некоторые настройки (нечто похожее на куки). Однако, после отключения, пропадает возможность пользоваться кэшем Гугла (в поисковике исчезают соответствующие выпадающие меню). Проблема на стороне Гугла. |
||||
|
||||
dom.storage.enabled = false |
||||
|
||||
Маскировка браузера под версию 24 LTS и самую распространённую платформу. Не забываем обновлять по мере выхода очередных LTS |
||||
|
||||
general.appname.override = Netscape |
||||
general.appversion.override = 5.0 (Windows) |
||||
general.oscpu.override = Windows NT 6.1 |
||||
general.platform.override = Win32 |
||||
general.useragent.override = Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Firefox/24.0 |
||||
general.productSub.override = 20100101 |
||||
general.buildID.override = 20100101 |
||||
browser.startup.homepage_override.buildID = 20100101 |
||||
|
||||
Отключает автоматическое обновление браузера |
||||
|
||||
app.update.auto = false |
||||
app.update.enabled = false |
||||
app.update.mode = 0 |
||||
app.update.service.enabled = false |
||||
|
||||
Отключает автоматическое обновление поисковых плагинов |
||||
|
||||
browser.search.update = false |
||||
|
||||
Не отправлять данные о производительности в Mozilla |
||||
|
||||
datareporting.healthreport.service.enabled = false |
||||
datareporting.healthreport.uploadEnabled = false |
||||
datareporting.policy.dataSubmissionEnabled = false |
||||
|
||||
Отключить шифр RC4, считающийся слишком слабым: [1](https://tools.ietf.org/html/draft-popov-tls-prohibiting-rc4-01), [2](http://blogs.technet.com/b/srd/archive/2013/11/12/security-advisory-2868725-recommendation-to-disable-rc4.aspx): |
||||
|
||||
security.ssl3.ecdh_ecdsa_rc4_128_sha = false |
||||
security.ssl3.ecdhe_ecdsa_rc4_128_sha = false |
||||
security.ssl3.ecdh_rsa_rc4_128_sha = false |
||||
security.ssl3.ecdhe_rsa_rc4_128_sha = false |
||||
security.ssl3.rsa_rc4_128_md5 = false |
||||
security.ssl3.rsa_rc4_128_sha = false |
||||
@ -0,0 +1,40 @@
|
||||
--- |
||||
title: Firefox / Плагины |
||||
tags: firefox, security, privacy |
||||
--- |
||||
|
||||
В [предыдущей](/articles/2014/08/13/firefox_security_tuning/) статье я приводил примеры настроек, для повышения приватности. Но этого, как правило, недостаточно. Дополнительно требуется следить за загружаемым содержимым, которое может использоваться для отслеживания пользователя. Ниже **много** ссылок. |
||||
|
||||
--- |
||||
|
||||
Это может быть: |
||||
|
||||
* [cookie](https://ru.wikipedia.org/wiki/HTTP-Cookie) -- классика, массово используется с начала 2000х. Полное блокирование гарантированно вызовет проблемы с авторизацией на сайтах, и пользовательскими настройками. |
||||
* [referer](https://ru.wikipedia.org/wiki/Referrer) -- тоже классика, относительно безобидные данные. Полное блокирование может вызывать срабатывание [hotlink](https://ru.wikipedia.org/wiki/%D0%A5%D0%BE%D1%82%D0%BB%D0%B8%D0%BD%D0%BA)-protection. Рекомендуется изменение на корень сайта. |
||||
* [flash](https://ru.wikipedia.org/wiki/Adobe_Flash)-cookie -- не зависят от обычных http-cookie. Рекомендуется полное отключение flash или перевод его в режим [click-to-play](https://wiki.mozilla.org/Firefox/Click_To_Play) |
||||
* [html5-storage](http://dev.w3.org/html5/webstorage/) -- см. настройки браузера в предыдущей статье. |
||||
* [js](https://ru.wikipedia.org/wiki/Javascript) -- к сожалению, это неизбежное зло. Рекомендуется ограничить разрешённые скрипты поддоменом просматриваемого сайта и основными [CDN](https://ru.wikipedia.org/wiki/CDN)'ами. |
||||
|
||||
Итак, список плагинов, закрывающий большинство основных способов слежения за конечным пользователем. Must have: |
||||
|
||||
* [Request Policy](http://www.requestpolicy.com) -- ограничивает загрузку встраиваемого контента с "внешних" сайтов по отношению к просматриваемому. www.site.org -> static.site.org - будет разрешено, www.site.org -> bs.yandex.ru - будет заблокировано. Вырубает подавляющее большинство счётчиков, подключаемых со сторонних доменов в виде картинки или скрипта, без разницы. В настройках рекомендуется выбрать "Уровень классификации - основной домен", это по умолчанию разрешит поддомены сайта. |
||||
* [NoScript](http://noscript.net) -- раньше считался абсолютным "must have", сейчас его функции частично выполняет "Request Policy". Очень полезен для блокирования встроенных объектов (<embed ...>, <audio ...>, <video ...>), скриптов самого сайта, и даже (i)fram'ов. В настройках также рекомендуется разрешение скриптов для "домена второго уровня". |
||||
* [Cookie Monster](https://addons.mozilla.org/ru/firefox/addon/cookie-monster/) -- управление приемом и хранением cookie. В глобальных настройках: "блокировать сторонние cookie", "использовать имена доменов второго уровня". |
||||
* [RefControl](http://www.stardrifter.org/refcontrol/) -- управление отправляемыми referer'ами. Рекомендуется: "Посылать корень сайта" + "только 3ей стороны". |
||||
* [HttpsEverywhere](https://www.eff.org/https-everywhere) -- использовать https по умолчанию, если доступно. Не забывайте про банальное прослушивание трафика. Разрабатывается EFF -- некоммерческой огранизацией по защите прав человека в цифровом мире. |
||||
|
||||
Дополнительно: |
||||
|
||||
* <del>[AdBlock](http://adblockplus.org/ru/)</del>[^fn2], [Adblock Edge](https://bitbucket.org/adstomper/adblockedge), или [uBlock](http://www.opennet.ru/opennews/art.shtml?num=41500), для эстетов -- вырезает рекламу. Обычно после работы плагинов выше - вырезать уже нечего. |
||||
* [Element Hiding Helper for AdBlock](https://adblockplus.org/ru/elemhidehelper) -- дополнение к предыдущему, позволяет визуально выбрать блокируемый элемент на странице. |
||||
* [CertPatrol](http://patrol.psyced.org) -- предупреждает при изменении центра сертификации для https-сайтов. Может вызывать ложное срабатывание минимум в 3х случаях: перевод сайта под защиту от ddos'а и обратно (CA изменится примерно так: thawtee -> qrator), смена CDN'а для отдачи статики/скриптов/<...> и компании с несколькими CA (гугл). В будущих версиях в FF [обещали](https://wiki.mozilla.org/Security/Features/CA_pinning_functionality) реализовать certificate pinning в самом браузере. |
||||
* [Pure URL](https://addons.mozilla.org/firefox/addon/pure-url/) -- удаляет из ссылок источник из распространения. Пример: youtube.com/<...>?feature=youtube_gdata - ссылка на youtube из rss. |
||||
|
||||
Известные недобросовестные дополнения: |
||||
|
||||
* [Ghostery](http://forum.mozilla-russia.org/viewtopic.php?pid=566877#p566877) -- разрабатывается компанией, продающей данные рекламщикам. |
||||
* [Список](http://forum.mozilla-russia.org/viewtopic.php?id=58209) от forum.mozilla-russia.org |
||||
* [Новость](http://www.opennet.ru/opennews/art.shtml?num=38882) о скупке добросовестных дополнений и внедрении следящего кода. |
||||
|
||||
[^fn1]: [скатился](http://www.opennet.ru/opennews/art.shtml?num=41590) |
||||
[^fn2]: в СГ. Обратите внимание, в настройках есть галочка, разрешающая некоторую рекламу. ВКЛЮЧАЮЩАЯСЯ каждый раз при обновлении |
||||
@ -0,0 +1,152 @@
|
||||
--- |
||||
title: WebDAV и syncevolution |
||||
tags: webdav |
||||
--- |
||||
|
||||
Понадобилось тут помочь с настройкой синхронизации контактов в телефоне, где нет поддержки webdav'а и его вариаций. |
||||
|
||||
Ниже вы можете наблюдать развесистое дерево конфигов, необходимое для простой двухсторонней синхронизации типа "точка-точка". Всё это счастье располагается в ``~/.config/syncevolution/`` |
||||
|
||||
--- |
||||
|
||||
`syncevolution |
||||
├── owncloud |
||||
│ ├── peers |
||||
│ │ └── owncloud |
||||
│ │ ├── config.ini |
||||
│ │ └── sources |
||||
│ │ ├── addressbook |
||||
│ │ │ └── config.ini |
||||
│ │ ├── calendar |
||||
│ │ │ └── config.ini |
||||
│ │ ├── memo |
||||
│ │ │ └── config.ini |
||||
│ │ └── todo |
||||
│ │ └── config.ini |
||||
│ └── sources |
||||
│ ├── addressbook |
||||
│ │ └── config.ini |
||||
│ ├── calendar |
||||
│ │ └── config.ini |
||||
│ ├── memo |
||||
│ │ └── config.ini |
||||
│ └── todo |
||||
│ └── config.ini |
||||
└── owncloud-target |
||||
├── config.ini |
||||
├── peers |
||||
│ └── target-config |
||||
│ ├── config.ini |
||||
│ └── sources |
||||
│ ├── addressbook |
||||
│ │ └── config.ini |
||||
│ ├── calendar |
||||
│ │ └── config.ini |
||||
│ ├── memo |
||||
│ │ └── config.ini |
||||
│ └── todo |
||||
│ └── config.ini |
||||
└── sources |
||||
├── addressbook |
||||
│ └── config.ini |
||||
├── calendar |
||||
│ └── config.ini |
||||
├── memo |
||||
│ └── config.ini |
||||
└── todo |
||||
└── config.ini |
||||
|
||||
27 directories, 19 files |
||||
|
||||
Вводные: |
||||
|
||||
* owncloud, это, внезапно, наш локальный источник данных |
||||
* owncloud-target - это удалённый источник |
||||
* memo и todo - не используется, поскольку локальный источник не может их выгружать, оставлены в листинге для примера. |
||||
* как я понял, конфиг не особо рассчитан на правку руками, и может быть переписан программой в любой момент |
||||
* предполагается, что под owncloud выделен отдельный hostname и включен https |
||||
|
||||
Содержимое файлов, с комментариями. Все пути указываются относительно ``~/.config/``. Во все места, где используются переменные, должны быть вписаны нужные значения, сам syncevolution переменные не понимает! |
||||
|
||||
######## Локальный источник |
||||
|
||||
# ./syncevolution/owncloud/sources/addressbook/config.ini |
||||
# смотрите внимательно комментарии в конфиге выше этой директивы, |
||||
# при неверном выборе выдаётся крайне невразумительная диагностика |
||||
backend = addressbook |
||||
# смотреть через `syncevolution --print-databases` |
||||
database = qtcontacts:org.nemomobile.contacts.sqlite: |
||||
|
||||
# ./syncevolution/owncloud/sources/calendar/config.ini |
||||
# аналогично пункту выше |
||||
backend = calendar |
||||
# смотреть через `syncevolution --print-databases` |
||||
database = uid:70f9eee1-866e-4606-912c-2b1c94c084d1 |
||||
|
||||
# ./syncevolution/owncloud/peers/owncloud/sources/addressbook/config.ini |
||||
# в первый раз - ставится merge, потом переключается на two-way |
||||
# merge никогда ничего не удаляет! |
||||
sync = two-way |
||||
|
||||
# ./syncevolution/owncloud/peers/owncloud/sources/calendar/config.ini |
||||
# аналогично пункту выше |
||||
sync = two-way |
||||
|
||||
# ./syncevolution/owncloud/peers/owncloud/sources/memo/config.ini |
||||
# важно - отключить, иначе выдаст ошибку синхронизации |
||||
# и засоряет лог |
||||
sync = disabled |
||||
|
||||
# ./syncevolution/owncloud/peers/owncloud/sources/todo/config.ini |
||||
# аналогично пункту выше |
||||
sync = disabled |
||||
|
||||
# ./syncevolution/owncloud/peers/owncloud/config.ini |
||||
# самый главный конфиг |
||||
syncURL = local://@owncloud-target |
||||
printChanges = 0 |
||||
PeerIsClient = 1 |
||||
# чисто косметическая настройка - название пира |
||||
PeerName = owncloud |
||||
# показывать ли этот источник в gui |
||||
ConsumerReady = 1 |
||||
|
||||
######## Удалённый источник |
||||
|
||||
# ./syncevolution/owncloud-target/sources/addressbook/config.ini |
||||
# ВАЖНО! если указан просто addreddbook или что-то подобное |
||||
# оно таки пытается использовать сеть, из-за того, что указано http://* |
||||
# но ломится при этом на localhost! |
||||
# также, "ADDR" - название адресной книги owncloud'а, см вебинтерфейс |
||||
backend = CardDAV |
||||
database = https://$HOSTNAME/remote.php/carddav/addressbooks/$USER/$ADDR |
||||
|
||||
# ./syncevolution/owncloud-target/sources/calendar/config.ini |
||||
# $CAL - то же самое, что и выше, см вебинтерфейс |
||||
backend = CalDAV |
||||
database = https://$HOSTNAME/remote.php/caldav/calendars/$USER/$CAL |
||||
|
||||
# ./syncevolution/owncloud-target/peers/target-config/sources/addressbook/config.ini |
||||
# merge - в первый раз, two-way - второй и последующие |
||||
sync = two-way |
||||
|
||||
# ./syncevolution/owncloud-target/peers/target-config/sources/calendar/config.ini |
||||
# аналогично |
||||
sync = two-way |
||||
|
||||
# ./syncevolution/owncloud-target/peers/target-config/config.ini |
||||
syncURL = https://$HOSTNAME/remote.php/ |
||||
username = $USER |
||||
password = $PASS # пароль от owncloud'а |
||||
printChanges = 0 |
||||
dumpData = 0 |
||||
useProxy = 0 |
||||
PeerName = owncloud |
||||
SSLVerifyServer = 0 # выставить в случае самоподписного сертификата |
||||
SSLVerifyHost = 0 |
||||
ConsumerReady = 0 |
||||
peerType = WebDAV |
||||
|
||||
# ./syncevolution/owncloud-target/config.ini |
||||
# должен выставится сам при первом запуске, не трогать |
||||
deviceId = syncevolution-6ed8351d-76bb-4ee9-9c25-063849780848 |
||||
@ -0,0 +1,184 @@
|
||||
--- |
||||
title: Базовая настройка openldap |
||||
tags: ldap |
||||
--- |
||||
|
||||
Disclaimer: Я ни в коем не считаю ldap шедевром инженерной/архитектурной мысли, просто так исторически сложилось, что поддержка авторизации через него есть практически везде[^fn1] |
||||
|
||||
--- |
||||
|
||||
Установка / Debian |
||||
------------------- |
||||
|
||||
# apt-get install slapd |
||||
|
||||
Лезет стандартное окошко настройки, которое просит установить пароль админа. Рекомендую его сразу поставить правильным, потому что поменять его - много лишних действий. |
||||
|
||||
Дальше начинается чёрная магия. |
||||
|
||||
Схема дерева |
||||
------------- |
||||
|
||||
Будем делать дерево вот по такой простенькой схеме: |
||||
|
||||
dc=org |
||||
`-> dc=company |
||||
`+-> ou=users |
||||
| `+-> uid=user1 |
||||
| `-> uid=user2 |
||||
`-> ou=groups |
||||
`+-> cn=group1 |
||||
`-> cn=group2 |
||||
|
||||
Для юзера, образующий[^fn2] элемент - inetOrgPerson, для группы - groupOfUniqueNames. |
||||
|
||||
Настройка slapd |
||||
---------------- |
||||
|
||||
Нужно создать саму базу, корень в ней, основные ou'шки и пользователя admin для дальнейшей работы. |
||||
|
||||
openldap после 2.4.27 поставляется с динамическим конфигом. Что бы там не говорили разработчики, править его **намного сложнее**. |
||||
|
||||
Перед тем как создавать свою базу, предлагаю сначала удалить типовую, созданную при установке. Как её удалить уже после создания нашей - см ниже. |
||||
|
||||
* остановить slapd: `service slapd stop` |
||||
* перейти в `/etc/ldap/slapd.d/cn=config`, найти там файлик вида `olcDatabase={X}hdb.ldif` |
||||
* убедиться, что он именно тот, что нужно: `olcSuffix: dc=nodomain` |
||||
* если он последний по порядку: переместить его куда-нибудь, например в /tmp |
||||
* если он НЕ последний - см ниже |
||||
* проверить конфиг через `slaptest`, в случае успеха - запустить `slapd` обратно |
||||
|
||||
Сначала нужно определить порядковый номер для новой базы. Смотрим в `/etc/ldap/slapd.d/cn=config/` на предмет файлов ``olcDatabase*``. Находим последнее по порядку значение в {N}, добавляем к нему единицу. |
||||
|
||||
$ export RDN="dc=company,dc=org" # поменять на правильный |
||||
$ export N=2 # номер базы |
||||
$ export ADMIN="cn=admin,$RDN" # юзер для правки базы |
||||
$ PASS=$(slappasswd -h '{SSHA}') |
||||
New password: |
||||
Re-enter new password: |
||||
$ |
||||
$ cat > 01-create-db.ldif <<EOF |
||||
dn: olcDatabase={$N}hdb,cn=config |
||||
objectClass: olcDatabaseConfig |
||||
objectClass: olcHdbConfig |
||||
olcDatabase: {$N}hdb |
||||
olcDbDirectory: /var/lib/ldap |
||||
olcSuffix: $RDN |
||||
olcAccess: {0}to attrs=userPassword,shadowLastChange |
||||
by dn="$ADMIN" write |
||||
by anonymous auth |
||||
by self write |
||||
by * none |
||||
olcAccess: {1}to dn.base="" by * read |
||||
olcAccess: {2}to * by dn="$ADMIN" write by * read |
||||
olcLastMod: TRUE |
||||
olcRootDN: $ADMIN |
||||
olcRootPW: $PASS |
||||
olcDbCheckpoint: 512 30 |
||||
olcDbConfig: set_cachesize 0 2097152 0 |
||||
olcDbConfig: set_lk_max_objects 1500 |
||||
olcDbConfig: set_lk_max_locks 1500 |
||||
olcDbConfig: set_lk_max_lockers 1500 |
||||
olcDbIndex: objectClass eq |
||||
EOF |
||||
$ ldapadd -Y EXTERNAL -H ldapi:/// -f 01-create-db.ldif |
||||
|
||||
Предполагается, что slapd запущен с ``-h ldap://127.0.0.1:389/ ldapi:///``, т.е. слушает на loopback'е и разрешены обращения через локальный сокет. |
||||
|
||||
Создаём корень базы. Обратите внимание, авторизация меняется с `-Y EXTERNAL` на обычный ``-D $ADMIN -W`` |
||||
|
||||
$ cat > 02-create-rdn.ldif <<EOF |
||||
dn: $RDN |
||||
objectClass: top |
||||
objectClass: dcObject |
||||
objectclass: organization |
||||
o: company.org |
||||
dc: company |
||||
description: - |
||||
EOF |
||||
$ ldapadd -D "$ADMIN" -W -H ldapi:/// -f 02-create-rdn.ldif |
||||
|
||||
Создаём основные ou'шки: |
||||
|
||||
$ cat > 03-create-ou.ldif <<EOF |
||||
dn: ou=users,$RDN |
||||
objectClass: organizationalUnit |
||||
ou: users |
||||
|
||||
dn: ou=groups,$RDN |
||||
objectClass: organizationalUnit |
||||
ou: groups |
||||
EOF |
||||
$ ldapadd -D "$ADMIN" -W -H ldapi:/// -f 03-create-ou.ldif |
||||
|
||||
Создаём юзера, из под которого будем править базу: |
||||
|
||||
$ cat > 04-create-admin.ldif <<EOF |
||||
dn: $ADMIN |
||||
objectClass: simpleSecurityObject |
||||
objectClass: organizationalRole |
||||
cn: admin |
||||
description: LDAP administrator |
||||
userPassword: $PASS |
||||
EOF |
||||
$ ldapadd -D "$ADMIN" -W -H ldapi:/// -f 04-create-admin.ldif |
||||
|
||||
Этого должно быть достаточно. Проверяем работу: |
||||
|
||||
$ ldapsearch -LL -D $ADMIN -b $RDN -W 'dn' |
||||
Enter LDAP Password: |
||||
version: 1 |
||||
|
||||
dn: dc=company,dc=org |
||||
dn: ou=users,dc=company,dc=org |
||||
dn: ou=groups,dc=company,dc=org |
||||
dn: cn=admin,dc=company,dc=org |
||||
|
||||
Работа с базой |
||||
--------------- |
||||
|
||||
TODO: LDIF'ы типовых операций с базой. |
||||
|
||||
Дополнительно / Багфиксы |
||||
------------------------- |
||||
|
||||
Добавляем прав обычному юзеру[^fn3]. Обращаю внимание: перед "by" - ДВА пробела. это связано с тем, что при разборе продолжения линии парсером - первый пробел отбрасывается. |
||||
|
||||
$ cat > tmp.ldif <<EOF |
||||
dn: olcDatabase={$N}hdb,cn=config |
||||
changetype: modify |
||||
add: olcAccess |
||||
olcAccess: to * |
||||
by self write |
||||
by * read |
||||
by anonymous none |
||||
EOF |
||||
$ ldapadd -Y EXTERNAL -H ldapi:/// -f tmp.ldif |
||||
|
||||
Багфикс №2 - добавляем индекс для ``(uid=*)`` |
||||
|
||||
$ cat > tmp.ldif <<EOF |
||||
dn: olcDatabase={$N}hdb,cn=config |
||||
changetype: modify |
||||
add: olcDbIndex |
||||
olcDbIndex: uid eq |
||||
EOF |
||||
$ ldapadd -Y EXTERNAL -H ldapi:/// -f tmp.ldif |
||||
|
||||
Дополнительно / Удаление типовой базы |
||||
-------------------------------------- |
||||
|
||||
Задание со звёздочкой. Если мы прошляпили момент и хотим удалить типовую базу **после** создания своей - последовательность действий такая: |
||||
|
||||
* Останавливаем slapd |
||||
* делаем бэкапы ``/etc/ldap`` |
||||
* идём в ``/etc/ldap/slapd.d/cn=config/``, убираем оттуда файлик olcDatabase, отвечающий за тестовую базу. |
||||
* исправляем имена файлов, чтобы число в {} было последовательным, начиная с нуля. |
||||
* исправляем то же число в {} внутри переименованных файлов |
||||
* исправляем чексумму в заголовке файла (нужно посчитать CRC32 для файла, пропуская первые 2 строки с заголовком, и вписать её в заголовок). Например так: `tail -n +3 olcDatabase={3}hdb.ldif | rhash --crc32 -` |
||||
* осеняем себя пентаграммой, запускаем slaptest, читаем вывод, исправляем |
||||
* запускаем обратно slapd |
||||
|
||||
[^fn1]: Спасибо AD и лично товарищу БГ за наше счастливое детство, чтоб они были здоровы, @%$& |
||||
[^fn2]: structural |
||||
[^fn3]: оставлено для примера, можно было сразу сделать при создании базы |
||||
@ -0,0 +1,130 @@
|
||||
--- |
||||
title: postfix и спамеры |
||||
tags: mail, postfix |
||||
--- |
||||
|
||||
В этой заметке собраны практические наработки по противодействию спаму для систем, использующих postfix в качестве MTA. |
||||
|
||||
Штатные средства |
||||
----------------- |
||||
|
||||
Первое и главное, на что нужно смотреть в конфиге по-умолчанию - это для кого и от кого принимается почта. Основные опции, которые **нужно** посмотреть: |
||||
|
||||
- ``mydestination`` -- домен или конкретное имя этого хоста. Ничего лишнего. Если вы используете виртуальные домены - оставьте только localhost. |
||||
- ``mynetworks[_style]`` -- ни в коем случае не 0.0.0.0/0, юзеры из этих сетей получают больше прав "по умолчанию", в частности доступ к использованию пересылки почты на внешние адреса. |
||||
- ``relay_domains`` -- пересылать почту для этих доменов, по умолчанию - то же самое что и mydestination |
||||
- ``virtual_mailbox_domains`` -- то же самое что и mydestination, но для виртуальных доменов. см. ``VIRTUAL_README`` в документации, чтобы понять чем они отличаются от "обычных". |
||||
|
||||
Полный список опций с их описанием можно посмотреть в `postconf(5)`. |
||||
|
||||
Далее, начинаем рубить спамеров ещё "на подлёте": |
||||
|
||||
HELO/EHLO |
||||
---------- |
||||
|
||||
smtpd_helo_required = yes |
||||
smtpd_helo_restrictions = permit_mynetworks, |
||||
permit_sasl_authenticated, |
||||
reject_non_fqdn_helo_hostname, |
||||
reject_unknown_helo_hostname, |
||||
permit |
||||
|
||||
Ограничения: |
||||
|
||||
* ``reject_non_fqdn_helo_hostname`` -- требовать, чтобы в HELO/EHLO было что-то похожее на hostname |
||||
* ``reject_unknown_helo_hostname`` -- ...и этот хостнейм должен ресолвится по dns'у в ipv4/v6 адрес |
||||
|
||||
Первое помогает от совсем тупых ботов, второе - частично от vps'ок с ломанным wordpress'ом. |
||||
|
||||
Адрес клиента, IPv4/IPv6 |
||||
------------------------- |
||||
|
||||
smtpd_client_restrictions = permit_mynetworks, |
||||
permit_sasl_authenticated, |
||||
reject_unauth_pipelining, |
||||
check_client_access hash:/etc/postfix/relay_access, |
||||
reject_unknown_client_hostname, |
||||
check_reverse_client_hostname_access pcre:/etc/postfix/reverse_hostname_access.pcre, |
||||
reject_multi_recipient_bounce, |
||||
permit |
||||
|
||||
Ограничения: |
||||
|
||||
* ``reject_unauth_pipelining`` -- сбрасывать сессию, если клиент пытается отправлять команды не дождавшись ответа на предыдущую команду |
||||
* ``reject_unknown_client_hostname`` -- сбрасывать сессию, если не совпадают записи IP -> DNS/PTR или DNS/A -> IP для того хостнейма, что указан в EHLO |
||||
см также. ``reject_unknown_reverse_client_hostname``, более слабую альтернативу этой проверки. |
||||
* ``reject_multi_recipient_bounce`` -- сбрасывать сессию, если не указан отправитель и указано несколько получателей. |
||||
* ``check_reverse_client_hostname_access`` -- позволяет дать отлуп заведомо левым хостам на основе ненастроенной PTR записи |
||||
|
||||
Помогает от биомассы с завирусованным виндузом, дырявых CMS на VPS'ках и просто кулхацкеров на диалапе. Примерное содержимое файлика: |
||||
|
||||
/.*(dynamic|broadband|\.dyn\.|\.ddns|\.vps\.).*/i 421 Dynamic hostname. Fix it and try again. |
||||
/.*(\.adsl|\.cdma\.|\.pptp|\.pppoe|\.cable).*/ 421 Dynamic hostname. Fix it and try again. |
||||
/.*(\d+[-.]){4}.*/ 421 Dynamic hostname. Fix it and try again. |
||||
|
||||
Исключения: |
||||
|
||||
* ``check_client_access`` -- позволяет вводить исключения для произвольных хостов. |
||||
|
||||
Адрес отправителя |
||||
------------------ |
||||
|
||||
smtpd_sender_restrictions = reject_non_fqdn_sender, |
||||
permit_auth_destination, |
||||
reject_unknown_sender_domain, |
||||
permit |
||||
|
||||
Ограничения: |
||||
|
||||
* ``reject_non_fqdn_sender`` -- в `MAIL FROM:` должно быть что-то похожее на email |
||||
* ``reject_unknown_sender_domain`` -- проверить через dns, что домен отправителя действительно существует |
||||
|
||||
Также, можете задействовать это: |
||||
|
||||
* ``reject_unverified_sender`` -- сбросить сессию, если обратное письмо отправителю заведомо не будет доставлено |
||||
|
||||
Это достаточно хардкорная опция, и должна применяться ограниченно. Суть такова: наш сервер соединяется с доменом отправителя и пытается отправить ему письмо, сбрасывая отправку в последний момент. Можно легко нарваться на тот же кривонастроенный fail2ban, и почта к этому домену перестанет ходить вовсе. Кроме того, эта опция вносит ощутимую задержку в доставку письма - до 20 секунд. |
||||
|
||||
Адрес получателя |
||||
----------------- |
||||
|
||||
smtpd_recipient_restrictions = reject_non_fqdn_recipient, |
||||
permit_sasl_authenticated, |
||||
check_client_access hash:/etc/postfix/relay_access, |
||||
reject_unauth_destination, |
||||
permit_mynetworks, |
||||
check_policy_service unix:private/policy, |
||||
permit_auth_destination, |
||||
sleep 5, |
||||
reject |
||||
|
||||
* ``reject_non_fqdn_recipient`` -- в `RCPT TO:` должно быть что-то похожее на email |
||||
* ``reject_unauth_destination`` -- "у нас нет такого юзера"/"это не наш домен" |
||||
* ``check_policy_service`` -- проверять SPF, если он есть у домена отправителя |
||||
* задержка в конце - добавлена для противодействию перебору адресов |
||||
|
||||
Внешние средства |
||||
----------------- |
||||
|
||||
Средства самого постфикса - это хорошо, но явно недостаточно. Я могу выделить 2 категории внешних средств, работающих со входящей почтой. |
||||
|
||||
Первая из них - средства, работающие **до** принятия письма к доставке. (Перечислены только основные и широко используемые) |
||||
|
||||
* fail2ban -- бан особо назойливых ботов, срабатывание настраивается на множественные сбои авторизации, "relay denied" и "no such recipient" |
||||
* dnsbl -- проверка по dns'у ip-адресов клиента. Опция достаточно спорная, листы могут просто не успевать обновляться. |
||||
* SPF -- сейчас уже "must have". Требует достаточно мало ресурсов, очень эффективна для доменов отправителя с политикой "-all", в крайнем случае "~all" поможет спамфильтру. *Важно:* следует использовать только reject'ы от этой проверки. См [wide-mask vulnerability](https://en.wikipedia.org/wiki/Sender_Policy_Framework#Wide-mask_vulnerability) |
||||
* DKIM -- в какой-то мере аналог SPF, но применяется для проверки отправителя/получателя вместо ip-адресов. Тоже - использовать только reject'ы. |
||||
* postscreen -- специализированный фаервол для postfix'а, расширяет возможности встроенных проверок |
||||
|
||||
Вторая категория - средства, работающие над фильтрацией нежелательной почты, уже принятой к доставке. |
||||
|
||||
* весь спектр байесовских спам-фильтров (dspam, spamasassin, и что полегче: bogofilter, crm114, и т.д.) |
||||
* антивирусы |
||||
* DCC, razor и прочие контент-блэклисты. |
||||
* обратная связь от юзера со спамфильтром |
||||
|
||||
На последнем пункте стоит остановиться отдельно. Использование такой связи не должно быть сложнее "переслать это письмо"/"переместить в Спам", иначе оно просто не будет использоваться юзерами. Первый вариант, с пересылкой - реализуется на postfix'е отдельным транспортом или условием в procmail'е, второй - через dovecot или что вашем конкретном случае отдаёт юзеру его почту. |
||||
|
||||
Раскладывание почты по INBOX/Spam реализуется на procmail'е или том же dovecot'е (плагин lda), после прогона по всем спамфильтрам/антивирусам. |
||||
|
||||
Отдельно подчёркиваю, что средства второй категории не должны слать ничего наружу, и крайне неохотно - админу почтовой системы. Первый случай может использоваться для спама через bounce, второй - для DOS атаки. |
||||
@ -0,0 +1,130 @@
|
||||
--- |
||||
title: Небольшой проектик JFF на perl+mojo |
||||
tags: xbmc, perl, mojo |
||||
--- |
||||
|
||||
Сиё творение родилось из простенькой, казалось бы, задачи: прицепить подрядовские вебкамеры к медиацентру. |
||||
|
||||
Что хотелось видеть изначально: плейлист с перечнем камер со ссылками вида ``http://.*\.jpeg``. Открываешь его, тыкаешь в нужную камеру м смотришь обстановку на дороге. В крайнем случае - пачку плейлистов, ровно с одним пунктом. Как показывает опыт, xbmc просто до жопы хочет обязательно постоить превьюшку к каждому пункту плейлиста, и начинает их дёргать все сразу, что неприемлемо и в данном случае - не по джентельменски. Из-за дикого количества запросов на сервер подряда, нас могут просто рубануть по ip или useragent'у. |
||||
|
||||
--- |
||||
|
||||
Грабли с превьюшками - это полбеды. Как выяснилось в дальнейшем, xbmc прекрасно понимает http, и пришедший по нему jpeg. НО! обрабатывает их не как картинку, а как видео из одного кадра. Повезёт, если увидишь как там что-то мелькнуло в 1/25ю секунды[^fn1]. |
||||
|
||||
Поэтому, возникла гениальная идея - быстренько забацать аналог udpxy, который: |
||||
|
||||
- можно насиловать запросами сколько угодно и с какой угодно частотой, |
||||
- может отдавать не обязательно jpeg. |
||||
|
||||
Из требований - возможно меньше зависимостей, кроме perl'а. |
||||
|
||||
Кодинг |
||||
------- |
||||
|
||||
В репозиториях debian'а есть и perl и [mojolicious](https://metacpan.org/pod/Mojolicious), поэтому установку я расписывать не буду, перейдём сразу к коду. |
||||
|
||||
$ mojo generate app Livecam |
||||
|
||||
Структура проекта: |
||||
|
||||
$ tree -A -S -n livecam |
||||
livecam/ |
||||
├── cache # кэш списка каналов и изображений с камер |
||||
├── lib |
||||
│ ├── Livecam |
||||
│ │ └── Main.pm # контроллер |
||||
│ └── Livecam.pm # роутер |
||||
├── public |
||||
├── script |
||||
│ └── livecam # скрипт запуска |
||||
├── t # здесь должны быть тесты, но по факту - не используется |
||||
│ └── basic.t |
||||
└── templates # не используется, у нас все ответы - plain http |
||||
└── layouts |
||||
└── default.html.ep |
||||
|
||||
В роутере нужно дописать 2 пути и повесить Mojo::UserAgent как ресурс приложения, чтобы не инициализировать его каждый раз. |
||||
|
||||
$r->get('/playlist') -> to('main#playlist'); |
||||
$r->get('/livecam') -> to('main#livecam'); |
||||
|
||||
$self->app->attr(ua => sub { |
||||
require Mojo::UserAgent; |
||||
my $ua = Mojo::UserAgent->new; |
||||
# поставить любой, похожий на настоящий |
||||
$ua->name(qq{Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20140925}); |
||||
return $ua; |
||||
}); |
||||
|
||||
В контроллере кода побольше. Перечень функций с их назначением [^fn2]: |
||||
|
||||
# private, работа со списком камер |
||||
_pls_cache_path |
||||
_pls_cache_save |
||||
_pls_cache_load |
||||
# private, работа с изображениями камер |
||||
_cam_cache_path |
||||
_cam_cache_save |
||||
_cam_cache_load |
||||
# и 2 метода, вызываемых из роутера, которые мы рассмотрим подробнее |
||||
playlist |
||||
livecam |
||||
|
||||
В любой непонятной ситуации - [смотрите код](https://www.linuxdv.org/git/?p=livecam.git;a=summary), там его совсем мало. |
||||
|
||||
playlist() |
||||
---------- |
||||
|
||||
Назначение - получить полный список камер с сайта подряда (и закешировать его), отдать его в виде плейлиста m3u. |
||||
|
||||
Камеры раскиданы по 4 страницам, поэтому получим каждую и пройдёмся по ним парсером. Здесь нам поможет Mojo::DOM, совершенно замечательная штука, этакое jquery для perl'а (селекторы и манипуляция элементами, без ajax'а, которым занимается уже Mojo::UserAgent с Mojo::IOLoop). |
||||
|
||||
Итак, структура html'я каждой камеры довольно проста: три div'а, враппер, имя камеры и ссылка с превью. |
||||
|
||||
# перебор камер на странице |
||||
$self->app->ua->get($url)->res->dom('div.cam-preview')->each(sub {<...>}); |
||||
# ...и пример вытаскивания данных внутри обработчика в each(); |
||||
# из такого: <a href="<...>" class="<...>">Title</a> |
||||
my $title = $_->at('div.title a')->text; |
||||
|
||||
Всё остальное здесь не представляет особого интереса. |
||||
|
||||
livecam() |
||||
--------- |
||||
|
||||
Назначение - получить изображение с камеры, отдать перекодированное и ограничить частоту запроса к внешнему серверу за счёт кеширования вывода. |
||||
|
||||
Изначально, я хотел использовать для вывода gif, но в итоге отказался (+зависимость от gd2/im::m/g::m и всё равно - генерация заголовка gif'а руками). В итоге остановился на mjpeg over http. В отличие от просто mjpeg, с точки зрения браузера это выглядит так: |
||||
|
||||
* в заголовках посылается 'Content-Type: multipart/x-mixed-replace;boundary=--Frame' |
||||
* далее, пока страница не закрыта/держится соединение, периодически посылаются порции данных такого вида: |
||||
|
||||
--Frame\r\n |
||||
Content-Type: image/jpg\r\n |
||||
Content-Length: $size\r\n |
||||
\r\n |
||||
<binary jpeg data>\r\n |
||||
\r\n |
||||
|
||||
С точки зрения mojo, это реализуется так: |
||||
|
||||
* пишется обработчик с такой логикой: |
||||
* достать из кэша/получить извне кадр с внешней камеры с таким-то id |
||||
* сформировать "кадр" из примера выше, отдать его клиенту |
||||
* повесить обработчик на повторное выполнение каждые N секунд |
||||
* дёрнуть обработчик в первый раз, чтобы клиент не ждал до срабатывания периодического таймера |
||||
* висеть, пока таймер периодически кормит клиента кадрами |
||||
* при отвале клиента - аккуратно снять таймер, закрыть соединение |
||||
|
||||
Всё, теперь мы можем дёргать наш сервер хоть 50 раз в секунду, запросы наружу пойдут только по мере устаревания картинки в кеше. |
||||
|
||||
Эпилог |
||||
------ |
||||
|
||||
И всё таки она верт^W^W оно не работает. Потому что в xbmc не настолько продвинутый http-клиент. Картинку кажет, достаточно долго, но вот обновлять - хрен. Зато в браузере работает только так. Кроме того, обнаружился неприятный баг - плейлист самопроизвольно удаляется при закрытии через 'stop'. |
||||
|
||||
Напишу в их багзиллу, пусть думают. |
||||
|
||||
[^fn1]: 25fps - берётся по умолчанию |
||||
|
||||
[^fn2]: их назначение примерно понятно из названий, но тем не менее |
||||
@ -0,0 +1,24 @@
|
||||
--- |
||||
title: Необходимые вещи |
||||
tags: software |
||||
--- |
||||
|
||||
По аналогии с [suckless-tools](http://suckless.org/philosophy), у меня накопился свой список "маленького, но незаменимого" софта[^fn1]. Делюсь: |
||||
|
||||
--- |
||||
|
||||
* at -- Планировщик. Иногда бывает полезно повесить какое-то разовое задание на определённое время. Пример - докачка чего-то толстого из сети, и выключение компа примерно тогда, когда оно должно завершиться. Ещё сюда же входит batch -- для того спеифического случая, когда нужно выполнить много ресурсоёмких (cpu) задач, за возможно более короткое время. Пример - кодирование разных видеофайлов. Все сразу пускать нельзя, дисковая обидится, и первых результатов хочется возможно быстрее. См. также task-spooler |
||||
* [burp](http://burp.grke.net) -- Очень удобная система бэкапов. Минимум зависимостей, гибкие настройки, возможность создания бэкапов "по возможности" (timed backup). |
||||
* [ctags](http://ctags.sourceforge.net) (+vim) -- Подсветка синтаксиса. Писать скрипты намного приятнее, когда вывод раскрашивается, скобки подсвечиваются, а содержимое кавычек выделяется другим цветом. |
||||
* debfoster -- Чистка системы после экспериментов. Аккуратно разбирает граф зависимостей "сверху", показывая "кто что держит". Самую засранную систему можно привести в первоначальный вид за полчаса (хотя против установки через слака-вей - нет приёма, да). |
||||
* [htop](http://htop.sourceforge.net) -- top, но с интегрированным tree-view, знающим про отличия thread/fork, и тот факт, что cpuload бывает не только user. |
||||
* [links](http://links.twibright.com) -- из консольных браузеров - самый вменяемый движок рендеринга, верстка практически не едет (привет w3m!). |
||||
* localepurge -- Чистка неиспользуемых локалей, могущих жрать до гигабайта места. Очень полезно для минимальных систем. |
||||
* [ncdu](http://dev.yorhel.nl/ncdu/) -- Отвечает на вопрос "где всё место в /var, блжад??" и ему подобные. Очень удобна для чистки логов и мусора на файлопомойке. |
||||
* [pv](http://www.ivarch.com/programs/pv.shtml) -- Тот кто пользовался dd хотя бы пару раз - думал о возможности прикрутить к нему progressbar. Их есть у меня! Эта утилитка показывает размер и скорость прокачиваемых через пайп данных. В сочетании с netcat/[tarpipe](https://en.wikipedia.org/wiki/Tar_%28computing%29#Tarpipe) - вещь очень полезная для перекидывания данных с минимальным оверхедом, в том числе по сети. |
||||
* [task-spooler](http://vicerveza.homeunix.net/~viric/soft/ts/) -- менеджер очереди. В отличие от at+batch не полагается на avgload, а тупо выполняет их по очереди/в несколько потоков. Очередью можно управлять, добавляя/снимая слоты, двигая задания в очереди. |
||||
* [runit](http://smarden.org/runit/) -- Supervisor. Эта штука, наблюдающая за процессами, перезапуская их при необходимости. К ней легко довешивается сохранение логов (с авторотацией), если приложение может их выдавать на stdout/stderr. Может частично заменять cron (задача вида "запустить скрипт через X минут после завершения предыдущего запуска" в классическом кроне не решается, а здесь пожалуйста - sleep N в начале или конце ./run - и вуаля). См также [s6](http://skarnet.org/software/s6/index.html). |
||||
* [tmux](http://tmux.sourceforge.net) -- Консольный оконный менеджер. Если [screen](http://savannah.gnu.org/projects/screen) - это "запустить/отцепить/отключиться", то здесь почти можно жить. С плагином [tmux-ressurect](http://www.opennet.ru/opennews/art.shtml?num=40522) - вообще шикарно. |
||||
* [tudu](http://cauterized.net/~meskio/tudu/) -- Список дел. Есть tree-view, приоритеты, прогресс выполнения, время дедлайна, описание задачи. См также [taskwarrior](http://taskwarrior.org). |
||||
|
||||
[^fn1]: Сюда не включены широкоизвестные утилиты, типа rsync'а |
||||
@ -0,0 +1,406 @@
|
||||
--- |
||||
title: В кирпич и обратно |
||||
tags: android, репост |
||||
--- |
||||
|
||||
...или танцы вокруг одного девайса с андроидом с целью чистки от всякого разного и последующего обустройства по своему желанию. |
||||
|
||||
В качестве подопытного кролика на сей раз выступает китаец 'Perfeo 7143'[^fn1]. |
||||
|
||||
--- |
||||
|
||||
Дисклеймер |
||||
---------- |
||||
|
||||
Эта статья **ни в коем случае не является** готовым руководством к действию. ССЗБ, заявившие что-то в духе "я скопипастил всё как в статье и получил кирпич" - будут посылаться без лишних разговоров в направлении, которое зависит только от богатства фантазии автора. |
||||
|
||||
В статье также попадаются колоритные и сильные выражения русского языка. С этим я ничего делать не намерен, читается интереснее и живее, а благородных девиц я прошу вернуться обратно в монастырь. |
||||
|
||||
Зачем? |
||||
------ |
||||
|
||||
Короткий ответ: потому что мы можем. |
||||
|
||||
Развёрнутый же ответ подразумевает выяснение политических взглядов оппонента, его отношению к копирайту, seo, продаже его личных данных и данных его родственников, [аргументу](https://www.pgpru.com/biblioteka/statji/nothingtohide) "мне нечего скрывать", и тому подобных вещей. Долго, нудно, достаточно заковыристо и строго индивидуально. |
||||
|
||||
Конкретные цели: время жизни девайса близкое к максимально возможному, список программ, помещающийся на один экран, и некая степень приватности данных. Нет, я не хочу делиться ими ни с кем. Ecto gammat! |
||||
|
||||
Как? |
||||
----- |
||||
|
||||
Распространённое мнение о жручести андроид-девайсов - на самом деле полуправда. Если пользоваться коробочной версией и повключать все внешние средства связи - естественно батарейка будет улетать в момент. Не последнюю роль в этом играет предустановленный софт. Поэтому - в первую очередь нужно его проредить от совсем уж говнософта, который не даёт телефону спать. А во вторую - от того, чем мы пользоваться не собираемся. |
||||
|
||||
Всё это "добро" как правило находится на системном разделе и так просто его удалить не получится. Некоторые вендоры предусматривают процедуру отключения "защиты от дурака"[^fn2]. Другим приходится "помогать" в излечении от излишней заботы о пользователе. |
||||
|
||||
Чтобы таки получить полный контроль над устройством, нам нужен как минимум доступ суперпользователя (root). А как максимум - разлочка загрузчика (bootloader). Второе позволяет ставить сторонние прошивки и ядра. |
||||
|
||||
Для данного девайса я решил ограничиться первым пунктом, поскольку других прошивок под него нет, а собирать её самому - значит потратить порядочно времени с сомнительным результатом. Не мой профиль, проще говоря. |
||||
|
||||
Бинарник su и управление доступом |
||||
--------------------------------- |
||||
|
||||
В android'е, su - это нечто большее, чем "спросить пароль, выдать доступ". Здесь оно занимается ещё и логами (в sqlite), и ещё черте чем. Далее, каждая программа норовит впихнуть свой собственный бинарник, который уникален и неповторим. |
||||
|
||||
* [superuser](http://4pda.ru/forum/index.php?showtopic=170206) (старый), версии 3.X.X |
||||
|
||||
Иконка - зелёная голова-полусфера андроида, с повязкой на одном глазу. ``/system/xbin/su --version`` сообщает нам что-то вроде "3.0.3.2" |
||||
|
||||
На моём девайсе - не заработал. Ошибка достаточно расплывчатая: |
||||
|
||||
WARNING: generic atexit() called from legacy shared library |
||||
Permission denied |
||||
|
||||
* [superuser](http://4pda.ru/forum/index.php?showtopic=438224) (новый), версии 1.X.X.X |
||||
|
||||
Иконка - голубой квадрат с белым '#' на переднем плане. !!! **opensource** ``/system/xbin/su --version`` сообщает нам что-то вроде "16 com.koushikdutta.superuser" |
||||
|
||||
* [supersu](http://4pda.ru/forum/index.php?showtopic=318487) |
||||
|
||||
Иконка - жёлтый "брыльянт" с коричневым '#' на переднем плане (в старых версиях). В новых - что-то стилизированное под супермена[^fn3]. |
||||
|
||||
Пользоваться не приходилось, поэтому ничего не скажу. Но судя по наличию pro-версии - те ещё фрукты-авокады. |
||||
|
||||
Немного о бестиарии рутовалок |
||||
----------------------------- |
||||
|
||||
Небольшой обзор способов рутования андроидов, выпущенных несознательными вендорами[^fn4]. |
||||
|
||||
* ломалка компьютерная |
||||
|
||||
Как правило виндовая программа, в комплекте с базой телефонов и набором эксплоитов. Исходники - как правило отсутствуют, эффективность - от полного 0 до 90%. Под полным нулём понимается банальный троян, даже без попыток что-то сделать с телефоном. Как правило, такие викинги долго не живут, но при выходе очередной "новой, пока неломаемой версии" могут забрасываться на форумы в рассчёте на жадного полуграмотного лоха. |
||||
|
||||
Выделяется подвид "облачных", могущих сливать информацию напрямую в интернет. Притом, как ожидаемую - "модель устройства, окружение, результат операции", так и приватную. :-) |
||||
|
||||
Размер - от 5 до 150мб, в зависимости от комплектации и требования онлайна. Последствия для девайса - непрогнозируемы, при закрытых исходниках. Может и только рут получить, может и рекламы в довесок навешать, может и попробовать прошить что-то кривое, с последующим окирпичиванием. |
||||
|
||||
Предствители: kingroot |
||||
|
||||
* ломалка "стелефонная" |
||||
|
||||
Принцип тот же, что и выше, но оформлено в виде apk. Эффективность - от того же нуля до 60%, из-за ограничений на размер, что может выливаться в отсутствие любой эвристики, сокращённым набором эксплоитов и т.д. |
||||
|
||||
Пример: baiduroot |
||||
|
||||
В этом случае на девайс **как правило** ставятся всякие довески, из серии "ускоритель интернета на 300%". Зачастую, интерфейс - на китайском, если повезёт - найдёте серию скринов, с детальным описанием на какие кнопки тыкать и в какой последовательности[^fn5]. |
||||
|
||||
* эксплоит в чистом виде |
||||
|
||||
Некий бинарник, эксплуатирующий уязвимость в ядре или системном окружении. Загружается на телефон и выполняется. Иногда содержит свой урезанный шелл. |
||||
|
||||
Размер - как правило маленький, последствия для девайса: как правило безобидные, от кернелпаника/сегфолта ещё никто не умирал. Возможна установка трояна/руткита "в довесок". |
||||
|
||||
Пример представителей этого семейства: zergrush, towelroot |
||||
|
||||
* использование инженерной особенности |
||||
|
||||
Для взлома используются штатные средства системы. Не используется "левых" бинарников, только adb под линукс, который можно собрать и руками. |
||||
|
||||
Самый "чистый" способ из перечисленных, встречается редко. Последствия для девайса - зависят от кривизны рук, МНУ применяющего и понимания собственных действий. |
||||
|
||||
Представители: doomlord |
||||
|
||||
Краткая справка по adb |
||||
---------------------- |
||||
|
||||
Общая последовательность действий такова: |
||||
|
||||
* достаём/компиляем бинарник adb |
||||
* разрешаем отладку в настройках |
||||
* втыкаем девайс в комп |
||||
* запускаем adb в виде сервера, через который и пойдёт в дальнейшем вся работа (``./adb wait-for-device``) |
||||
|
||||
Грабли первые: права на файл устройства в /dev/. Чинится а) выяснением, где конкретно висит устройство (lsusb), б/1) выставлением прав на него, или б/2) добавлением себя в нужную группу (не рекомендуется для разовой операции) |
||||
|
||||
Грабли вторые: adb не может понять, что вот это устойство - таки сцуко андроид. Актуально для мелко- и среднесерийной китайчатины. Чинится так: |
||||
|
||||
Bus 004 Device 002: ID 04b4:0033 Cypress Semiconductor Corp. Mouse |
||||
Bus 004 Device 003: ID 04d9:1603 Holtek Semiconductor, Inc. Keyboard |
||||
<...> |
||||
Bus 008 Device 002: ID 1f3a:1002 |
||||
# ^^ -- ага, вот эти ребята. обратите внимание на отсутствие описания |
||||
|
||||
# смотри, сцуко, вот оно! |
||||
mkdir -p ~/.android/ |
||||
echo 0x1f3a >> ~/.android/adb_usb.ini |
||||
|
||||
* работаем с устройством ``./adb (shell|push|pull|remount|reboot) <...>`` |
||||
* прибиваем демона ``./adb kill-server`` |
||||
* отсоединяем девайс |
||||
|
||||
alltogether |
||||
------------ |
||||
|
||||
# приготовления |
||||
./adb wait-for-device |
||||
./adb remount |
||||
# сносим всё предустанавливаемое ПО |
||||
./adb shell 'ls /system/preinstall' |
||||
./adb shell 'rm /system/preinstall/*.apk' |
||||
# чистим конюшни в системных приложениях |
||||
./adb shell 'ls /system/app' |
||||
./adb shell 'rm ...' # удаление одной или больше apk, см ниже, чем это грозит |
||||
# Superuser / gui |
||||
./adb push Superuser_1_0_3_0.apk /system/app/Superuser.apk |
||||
# этот бинарник вытащен из Superuser'а (не промахнитесь с архитектурой) |
||||
# P.S. я подозреваю, что этот шаг можно и пропустить, но не проверял |
||||
./adb push sh /system/xbin/su |
||||
./adb shell 'chmod 04755 /system/xbin/su' |
||||
./adb shell 'chown root.shell /system/xbin/su' |
||||
# busybox (опционально) |
||||
./adb push busybox /system/bin/busybox |
||||
./adb shell 'chmod 00755 /system/bin/busybox' |
||||
./adb shell 'chown root.shell /system/bin/busybox' |
||||
./adb shell '/system/bin/busybox --install -s /system/bin/' |
||||
# |
||||
./adb reboot |
||||
./adb kill-server |
||||
|
||||
Удалить нельзя оставить |
||||
------------------------ |
||||
|
||||
Ниже - список "до", "после" и "почему". |
||||
|
||||
7143-HD.apk 7143-HD.apk # инструкция к девайсу |
||||
AdobeFlashPlayer.apk < # понятно |
||||
AdobeReader.apk < # понятно, есть более вменяемые читалки pdf'а |
||||
ApplicationsProvider.apk ApplicationsProvider.apk |
||||
BackupRestoreConfirmation.apk BackupRestoreConfirmation.apk |
||||
BasicDreams.apk < # перделка |
||||
Browser.apk < # огрызок, ff рулит |
||||
Calculator.apk Calculator.apk |
||||
Calendar.apk Calendar.apk |
||||
CalendarProvider.apk CalendarProvider.apk |
||||
CertInstaller.apk CertInstaller.apk |
||||
ChromeBookmarksSyncAdapter.apk < # нафиг гуглосервисы |
||||
ConfigUpdater.apk ConfigUpdater.apk |
||||
Contacts.apk Contacts.apk |
||||
ContactsProvider.apk ContactsProvider.apk |
||||
DefaultContainerService.apk DefaultContainerService.apk |
||||
DeskClock.apk DeskClock.apk |
||||
DownloadProvider.apk DownloadProvider.apk |
||||
DownloadProviderUi.apk DownloadProviderUi.apk |
||||
DrmProvider.apk < # нафиг гуглосервисы |
||||
Email.apk < # огрызок, нужна будет почта - поставлю k9-mail |
||||
Exchange2.apk < # MS-crap |
||||
FaceLock.apk < # на 0.3M камере, распознавание лиц, ага |
||||
FileExplore.apk FileExplore.apk # огрызок, но нужен при первой настройке |
||||
FusedLocation.apk FusedLocation.apk # ни в коем случае, см примечание [1] ниже |
||||
Galaxy4.apk Galaxy4.apk # судя по всему - тоже обои, не дочистил |
||||
Gallery2.apk Gallery2.apk |
||||
GmsCore.apk < # нафиг гуглосервисы |
||||
GoogleBackupTransport.apk < # нафиг гуглосервисы |
||||
GoogleCalendarSyncAdapter.apk < # нафиг гуглосервисы |
||||
GoogleContactsSyncAdapter.apk < # нафиг гуглосервисы |
||||
GoogleFeedback.apk < # нафиг гуглосервисы |
||||
GoogleLoginService.apk < # нафиг гуглосервисы |
||||
Google_maps.apk < # нафиг гуглосервисы |
||||
GooglePartnerSetup.apk < # нафиг гуглосервисы |
||||
GoogleServicesFramework.apk < # нафиг гуглосервисы |
||||
GoogleTTS.apk < # нафиг гуглосервисы |
||||
HoloSpiralWallpaper.apk < # перделка |
||||
HTMLViewer.apk HTMLViewer.apk # нужен, см. примечание [2] |
||||
InetService.apk InetService.apk |
||||
InetUpdate.apk < # сам обновлю когда надумаю, пнх |
||||
InputDevices.apk InputDevices.apk |
||||
KeyChain.apk KeyChain.apk |
||||
LatinImeDictionaryPack.apk LatinImeDictionaryPack.apk |
||||
LatinImeGoogle.apk LatinImeGoogle.apk # ни в коем случае: клавиатура |
||||
Launcher2.apk Launcher2.apk # ни в коем случае: "рабочий стол" |
||||
LiveWallpapers.apk < # жрёт батарейку |
||||
LiveWallpapersPicker.apk < # раз нет обоев - тоже не нужен |
||||
MagicSmokeWallpapers.apk < # жрёт батарейку |
||||
MediaProvider.apk MediaProvider.apk |
||||
MediaUploader.apk < # куда, блеать?! |
||||
Music2.apk < # огрызок |
||||
MusicFX.apk < # сканирует карту на любой чих, пиздец батарейке |
||||
NetworkLocation.apk NetworkLocation.apk |
||||
NoiseField.apk < # перделка |
||||
OneTimeInitializer.apk OneTimeInitializer.apk |
||||
PackageInstaller.apk PackageInstaller.apk |
||||
PhaseBeam.apk < # перделка |
||||
Phone.apk Phone.apk |
||||
Phonesky.apk < # нафиг гуглосервисы |
||||
PhotoTable.apk PhotoTable.apk |
||||
Settings.apk Settings.apk |
||||
SettingsProvider.apk SettingsProvider.apk |
||||
SetupWizard.apk SetupWizard.apk |
||||
SharedStorageBackup.apk SharedStorageBackup.apk |
||||
Skype.apk < # MS-crap |
||||
SoftWinnerService.apk < # vendor-crap |
||||
SoundRecorder.apk SoundRecorder.apk |
||||
SpeechRecorder.apk SpeechRecorder.apk |
||||
SystemUI.apk SystemUI.apk |
||||
Talk.apk < # нафиг гуглосервисы |
||||
Talkback.apk < # нафиг гуглосервисы |
||||
TelephonyProvider.apk TelephonyProvider.apk |
||||
UserDictionaryProvider.apk UserDictionaryProvider.apk |
||||
VisualizationWallpapers.apk VisualizationWallpapers.apk |
||||
VoiceSearchStub.apk < # нафиг гуглосервисы |
||||
VpnDialogs.apk VpnDialogs.apk |
||||
WAPPushManager.apk WAPPushManager.apk |
||||
Web-RF.apk < # яндекс-crap |
||||
|
||||
* [1] во всех версиях 4.X, кроме 4.2 - эта фигня занимается определением приблизительного местоположения устройства. НО! в 4.2 - это ремаппер путей типа: /mnt/extsd -> /sdcard. Короче, удалите - получите бесконечный ребут. Я вот на эти грабли благополучно наступил. :-) |
||||
* [2] видел [новость](http://www.opennet.ru/opennews/art.shtml?num=41447) об уязвимости в похожем компоненте, в ключе «поскольку %дарасы-вендоры не обновляют прошивки старых моделей, эта уязвимость останется навсегда» |
||||
|
||||
Зомби |
||||
------ |
||||
|
||||
Итак, после манипуляций из предыдущего пункта, я получил полуживой девайс. Самое время прочитать инструкцию "READ THIS FIRST" и немного пораскинуть мозгами. |
||||
|
||||
# ./files/adb get-state |
||||
device |
||||
|
||||
Ага, отлично, жив, но до конца не загружается. |
||||
|
||||
# ./adb logcat |
||||
|
||||
Видим упоминания 'fused', соображаем, что что-то пошло не так, и припоминаем файл 'FusedLocation.apk'. |
||||
|
||||
Поскольку удаления приложений проводились итеративно, есть бэкапы **части** этих apk'шек. (бэкапилось через adb pull + bash, и на каком-то этапе мне стало лениво копипастить имена в bash'евский 'for'). |
||||
|
||||
Сходил на сайт "вендора", нашёл одну-единственную прошивку для этой модели, выложенную на яндекс-диск(!). Немедленно скачал и заныкал в надёжное место на своём диске. |
||||
|
||||
Теперь у нас есть выбор - попробовать её прошить, разобрать или поискать нужные/совместимые файлики по интернету. |
||||
|
||||
От первого варианта я отказался сразу - неспортивно и в случае неудачи - запорем весь девайс полностью. Кроме того, я сильно не уверен, что это прошивка от "той" модели. Ну бывает, чо. Раз уж додумались положить её на яндекс-диск, может и такое быть. |
||||
|
||||
От третьего варианта - тоже, по итогам получасовой разведки ситуации на 4pda. Характеристика, данная выше - оказалась удивительно точной, именно "мелкосерийная". |
||||
|
||||
Значит будем играть в дохтура, а точнее - в патологоанатома. |
||||
|
||||
Разбираем прошивку |
||||
------------------- |
||||
|
||||
Первая возникшая мысль - подцепить прошивку как блочное устройство и поискать на ней сигнатуры разделов fat/ext[234]. Вдруг не стали муд ...рствовать в этот раз. |
||||
|
||||
# losetup -f 7143.img |
||||
# losetup -a |
||||
# fdisk -l /dev/loop0 |
||||
|
||||
...mbr-разделов нету. Ну ладно, у нас же всё-таки arm, там скорее всего и не должно быть, попробуем testdisk. |
||||
|
||||
Disk /dev/loop0 - 524 MB / 500 MiB - CHS 1025099 1 1 |
||||
Partition Start End Size in sectors |
||||
>P FAT16 2902 265045 262144 |
||||
|
||||
...что-то нашёл, посмотрим что именно. |
||||
|
||||
P FAT16 2902 265045 262144 |
||||
Directory / |
||||
. |
||||
>drwxr-xr-x 0 0 0 1-Jan-1980 00:00 bat |
||||
-rwxr-xr-x 0 0 57656 1-Jan-1980 00:00 bootlogo.bmp |
||||
-rwxr-xr-x 0 0 344813 1-Jan-1980 00:00 font24.sft |
||||
-rwxr-xr-x 0 0 357443 1-Jan-1980 00:00 font32.sft |
||||
-rwxr-xr-x 0 0 512 1-Jan-1980 00:00 magic.bin |
||||
-rwxr-xr-x 0 0 37680 1-Jan-1980 00:00 script.bin |
||||
-rwxr-xr-x 0 0 37680 1-Jan-1980 00:00 script0.bin |
||||
|
||||
Ага, что-то есть, но явно мало. Прошивка-то > 400мб, а тут - жалкие килобайты. Значит одно из 2х - или testdisk лажает, или таки всё как обычно - луковица. |
||||
|
||||
Лезем в интернет, читать о том как здесь правильно готовить прошивку: [1](http://www.techknow.me/forum/index.php?topic=1679.0). |
||||
|
||||
В процессе находим вот [этот](https://github.com/Ithamar/awutils) проектик, компиляем его и натравливаем на прошивку. На выходе получается такой список файлов: |
||||
|
||||
COMMON _SYS_CONFIG100000.hdr COMMON _SYS_CONFIG100000 |
||||
COMMON _SYS_CONFIG_BIN00.hdr COMMON _SYS_CONFIG_BIN00 |
||||
COMMON _SPLIT_0000000000.hdr COMMON _SPLIT_0000000000 |
||||
COMMON _SYS_CONFIG000000.hdr COMMON _SYS_CONFIG000000 |
||||
BOOT _BOOT0_0000000000.hdr BOOT _BOOT0_0000000000 |
||||
12345678_1234567890BOOT_0.hdr 12345678_1234567890BOOT_0 |
||||
12345678_UBOOT_0000000000.hdr 12345678_UBOOT_0000000000 |
||||
FES _FES_1-0000000000.hdr FES _FES_1-0000000000 |
||||
PXTOOLSB_XXXXXXXXXXXXXXXX.hdr PXTOOLSB_XXXXXXXXXXXXXXXX |
||||
UPFLYTLS_XXXXXXXXXXXXXXXX.hdr UPFLYTLS_XXXXXXXXXXXXXXXX |
||||
UPFLTL32_XXXXXXXXXXXXXXXX.hdr UPFLTL32_XXXXXXXXXXXXXXXX |
||||
12345678_1234567890CARDTL.hdr 12345678_1234567890CARDTL |
||||
12345678_1234567890SCRIPT.hdr 12345678_1234567890SCRIPT |
||||
12345678_1234567890___MBR.hdr 12345678_1234567890___MBR |
||||
12345678_1234567890DLINFO.hdr 12345678_1234567890DLINFO |
||||
RFSFAT16_BOOTLOADER_FEX00.hdr RFSFAT16_BOOTLOADER_FEX00 |
||||
RFSFAT16_VBOOTLOADER_FEX0.hdr RFSFAT16_VBOOTLOADER_FEX0 |
||||
RFSFAT16_ENV_FEX000000000.hdr RFSFAT16_ENV_FEX000000000 |
||||
RFSFAT16_VENV_FEX00000000.hdr RFSFAT16_VENV_FEX00000000 |
||||
RFSFAT16_BOOT_FEX00000000.hdr RFSFAT16_BOOT_FEX00000000 |
||||
RFSFAT16_VBOOT_FEX0000000.hdr RFSFAT16_VBOOT_FEX0000000 |
||||
RFSFAT16_SYSTEM_FEX000000.hdr RFSFAT16_SYSTEM_FEX000000 |
||||
RFSFAT16_VSYSTEM_FEX00000.hdr RFSFAT16_VSYSTEM_FEX00000 |
||||
RFSFAT16_RECOVERY_FEX0000.hdr RFSFAT16_RECOVERY_FEX0000 |
||||
RFSFAT16_VRECOVERY_FEX000.hdr RFSFAT16_VRECOVERY_FEX000 |
||||
RFSFAT16_DISKFS_FEX000000.hdr RFSFAT16_DISKFS_FEX000000 |
||||
|
||||
...уже что-то. Обозначению 'RFSFAT16' - не верьте, оно пиз###ит, на самом деле там особым образом™[^fn6] упакованная ext4. Чтобы его сконвертировать в нормальный образ, нам понадобятся исходники [отсюда](https://android.googlesource.com/platform/system/extras/) И дописанные каким-то добрым человеком: [здесь](http://forum.xda-developers.com/galaxy-s2/general/ref-unpacking-repacking-stock-rom-img-t1081239/post31089100#post31089100). |
||||
|
||||
$ simg2img RFSFAT16_SYSTEM_FEX000000 > test.bin |
||||
# losetup -f test.bin |
||||
# losetup -a |
||||
# mount -r /dev/loop1 /mnt/src |
||||
|
||||
...отлично, достаём все[^fn7] файлы из /system/app/. И закидываем наиболее подозрительные обратно на устройство. |
||||
|
||||
# ./files/adb wait-for-device |
||||
* daemon not running. starting it now on port 5037 * |
||||
* daemon started successfully * |
||||
# ./files/adb push ./FusedLocation.apk /system/app/FusedLocation.apk |
||||
failed to copy 'FusedLocation.apk' to '/system/app/FusedLocation.apk': Read-only file system |
||||
# ./files/adb remount |
||||
remount succeeded |
||||
# ./files/adb push ./FusedLocation.apk /system/app/FusedLocation.apk |
||||
174 KB/s (9232 bytes in 0.051s) |
||||
# ./files/adb reboot |
||||
|
||||
...после чего девайс загружается полностью. Легко отделались, вобщем-то. |
||||
|
||||
Идём дальше |
||||
------------ |
||||
|
||||
Это всё лирика, но по пути к первоначальной цели "сделать девайс маложрущим и юзабельным", мы дали достаточно большой крюк. Как говорил дедушка Ленин, в "пеrвую очередь, товаrищи, захватывайте телегrаф и почту!" |
||||
|
||||
* DroidWall |
||||
* [F-Droid](https://en.wikipedia.org/wiki/F-Droid) |
||||
|
||||
И через F-Droid ставится всё остальное[^fn8]: |
||||
|
||||
* Barcode scanner |
||||
* CalDav sync |
||||
* CoolReader |
||||
* cSipSimple |
||||
* Document Viewer |
||||
* ES FileManager |
||||
* Firefox |
||||
* jTalk |
||||
* notes |
||||
* wake-on-lan |
||||
* XBMC remote |
||||
|
||||
В настройках чистим "администраторов устройства" (ничего быть не должно, но мало ли), выключаем геолокацию и фоновые данные. |
||||
|
||||
После этого, девайс готов к базовому использованию. |
||||
|
||||
Если захотелось повторить |
||||
-------------------------- |
||||
|
||||
Если вы будете выбирать себе планшет, и смотреть этот, перечислю то, чем он мне НЕ понравился. Возможно, сумею разубедить. |
||||
|
||||
На поддержку от производителя я бы рассчитывать не стал. |
||||
|
||||
* Во-первых, нужно ещё найти сервисный, который за это чудо-юдо возьмётся. |
||||
* Во-вторых, они скорее всего тупо отправят его "на замену", это от 2х недель до 2х месяцев ожидания. |
||||
* В-третьих, через год вы можете обнаружить, что такой фирмы уже нет в природе. |
||||
|
||||
Это, вобщем-то, справедливо для всех "китайцев". Чисто технические недостатки: |
||||
|
||||
* включение/громкость сделаны "под левую руку". |
||||
* нет отдельного входа для зарядки. Сжечь/расшатать/оторвать usb - достаточно просто. |
||||
* глянцевый, сука, задник. Залапывается просто в момент. |
||||
* нет стерео |
||||
|
||||
[^fn1]: не является рекламой, в конце статьи честно перечислены его косяки |
||||
[^fn2]: хотя правильнее это будет назвать "защитой своих интересов и карманов" |
||||
[^fn3]: фи, какая пошлость, в самом деле |
||||
[^fn4]: у которых отсутствует штатная процедура это сделать |
||||
[^fn5]: думаю не нужно напоминать, что в случае "что-то пошло не так" - будете учиться забивать нужные иероглифы в гуглтранслейт |
||||
[^fn6]: чтоб эти велосипедисты горели в аду |
||||
[^fn7]: на всякий случай |
||||
[^fn8]: ИМХО, ясно дело |
||||
@ -0,0 +1,12 @@
|
||||
--- |
||||
title: Смена сертификатов |
||||
tags: linuxdv |
||||
--- |
||||
|
||||
Обновлены сертификаты сайта и остальных сервисов из-за перехода на SHA-2. См. [эту](/pages/services/security_notice/) страничку. |
||||
|
||||
Ещё по теме: |
||||
|
||||
* [общие инструкции по апгрейду](https://shaaaaaaaaaaaaa.com) (на буржуинском) |
||||
* [Поддержка в firefox](http://www.opennet.ru/opennews/art.shtml?num=40661) |
||||
* [Поддержка в chrome](http://www.opennet.ru/opennews/art.shtml?num=41263) |
||||
@ -0,0 +1,67 @@
|
||||
--- |
||||
title: Минималистичная почтовая система |
||||
tags: репост, mail, software |
||||
--- |
||||
|
||||
Задача: на некоторых хостах нужна отправка почты, но самый минимум. |
||||
|
||||
Например, если там в раз сутки отправляется 2 письма (отчёты logwatch, tiger) и ещё сколько-то с cron'а - особого смысла держать там MTA - нет. Для таких случаев я использую связку esmtp+procmail. |
||||
|
||||
--- |
||||
|
||||
Плюсы: в процессах не висит ничего лишнего. Безобразно просто в настройке. Не требует обслуживания. Минусы: нет retry ни в каком виде. Если в момент отправки недоступен smarthost - почта пропадёт. |
||||
|
||||
Вот такой минимальный конфиг будет складывать локальную почту в системные mailbox'ы, а остальное - слать через smarthost. А на smarthost'е оно уже разруливается как надо. |
||||
|
||||
``/etc/esmtprc``: |
||||
|
||||
hostname=mail.home.lan:25 |
||||
mda="/usr/bin/procmail -d %T" |
||||
|
||||
И, чтоб два раза не вставать: если хост работает долго, в ящике могут накапливаться тонны писем. |
||||
|
||||
Вот такой скриптик разгребает ящик раз в месяц и скидывает в архив всё, что не относится к текущему месяцу. |
||||
|
||||
#!/bin/sh |
||||
set -e |
||||
|
||||
MBOX="/var/spool/mail/$USER" |
||||
ARCH="$HOME/mail-archive" |
||||
# чёрная магия. определение предыдущего месяца |
||||
NAME=$(date --date="$(date +%Y-%m-15) -1 month" +%Y-%m) |
||||
DATE=$(date +%Y-%m-01) |
||||
|
||||
mkdir -p "$ARCH" |
||||
|
||||
if [ -f "$ARCH/$NAME.archive.gz" ]; then |
||||
echo "archive for prev month already exists, abort" |
||||
exit 1 |
||||
fi |
||||
|
||||
# http://adc-archmbox.sourceforge.net |
||||
archmbox --archive --date "$DATE" \ |
||||
--archive-path "$ARCH" --archive-name "$NAME" \ |
||||
--extension archive --compress --totals "$MBOX" |
||||
|
||||
exit 0 |
||||
|
||||
Положить куда-нибудь в ``/usr/local``, дать права и засунуть вызов в cron на первое число каждого месяца. В результате в почту будет прилетать вот такой отчётик: |
||||
|
||||
Mailbox '/var/spool/mail/alex': 238 messages (7.66 MB) |
||||
Archived: 238 messages (7.66 MB) |
||||
|
||||
Archive mailbox: /home/alex/mail-archive/2015-11.archive |
||||
|
||||
Overall summary |
||||
================================================== |
||||
Parsed mailboxes: 1 |
||||
Skipped mailboxes: 0 |
||||
Mailboxes in use: 0 |
||||
Invalid mailboxes: 0 |
||||
Non existent mailboxes: 0 |
||||
Empty mailboxes: 0 |
||||
Parsed messages: 238 |
||||
Total used space (MB): 7.66 |
||||
Archived messages: 238 |
||||
Total saved space (MB): 7.66 |
||||
================================================== |
||||
@ -0,0 +1,7 @@
|
||||
--- |
||||
title: Линуксовка, Линуксцентр |
||||
--- |
||||
|
||||
Темы: |
||||
|
||||
* iptables -- AdUser --  |
||||
Binary file not shown.
Binary file not shown.
|
After Width: | Height: | Size: 189 KiB |
|
After Width: | Height: | Size: 17 KiB |
@ -0,0 +1,13 @@
|
||||
--- |
||||
title: Линуксовка, Линуксцентр |
||||
--- |
||||
|
||||
Темы |
||||
---- |
||||
|
||||
* загрузка по сети на примере выч. кластера -- ``michail_ul`` -- [материалы](doklad.pdf) |
||||
|
||||
Фотографии |
||||
---------- |
||||
|
||||
[](imag0146.jpg) |
||||
Binary file not shown.
|
After Width: | Height: | Size: 488 KiB |
|
After Width: | Height: | Size: 40 KiB |
|
After Width: | Height: | Size: 482 KiB |
|
After Width: | Height: | Size: 43 KiB |
|
After Width: | Height: | Size: 481 KiB |
|
After Width: | Height: | Size: 37 KiB |
|
After Width: | Height: | Size: 471 KiB |
|
After Width: | Height: | Size: 39 KiB |
|
After Width: | Height: | Size: 518 KiB |
|
After Width: | Height: | Size: 44 KiB |
@ -0,0 +1,18 @@
|
||||
--- |
||||
title: Линуксовка 2011.05.14, кафе "Класс" |
||||
--- |
||||
|
||||
Темы |
||||
---- |
||||
|
||||
* Дисковое шифрование -- AdUser -- [материалы](crypt.tar.bz2) |
||||
* Работа с датчиками arduino -- leen |
||||
|
||||
Фотографии |
||||
---------- |
||||
|
||||
[](dsc07821.jpg) |
||||
[](dsc07824.jpg) |
||||
[](dsc07825.jpg) |
||||
[](dsc07829.jpg) |
||||
[](dsc07830.jpg) |
||||
|
After Width: | Height: | Size: 320 KiB |
|
After Width: | Height: | Size: 19 KiB |
|
After Width: | Height: | Size: 296 KiB |
|
After Width: | Height: | Size: 20 KiB |
|
After Width: | Height: | Size: 258 KiB |
|
After Width: | Height: | Size: 16 KiB |
|
After Width: | Height: | Size: 244 KiB |
|
After Width: | Height: | Size: 16 KiB |
|
After Width: | Height: | Size: 318 KiB |
|
After Width: | Height: | Size: 21 KiB |
|
After Width: | Height: | Size: 279 KiB |
|
After Width: | Height: | Size: 20 KiB |
|
After Width: | Height: | Size: 312 KiB |
|
After Width: | Height: | Size: 18 KiB |
|
After Width: | Height: | Size: 305 KiB |
|
After Width: | Height: | Size: 18 KiB |
|
After Width: | Height: | Size: 268 KiB |
|
After Width: | Height: | Size: 17 KiB |
@ -0,0 +1,22 @@
|
||||
--- |
||||
title: Линуксовка, день сисадмина |
||||
--- |
||||
|
||||
Темы |
||||
---- |
||||
|
||||
* Загрузка по сети -- AdUser -- TODO: материалы |
||||
|
||||
Фотографии |
||||
----------- |
||||
|
||||
[](imag0148.jpg) |
||||
[](imag0149.jpg) |
||||
[](imag0150.jpg) |
||||
[](imag0151.jpg) |
||||
[](imag0153.jpg) |
||||
|
||||
[](img_20110730_184603.jpg) |
||||
[](img_20110730_184611.jpg) |
||||
[](img_20110730_184616.jpg) |
||||
[](img_20110730_184633.jpg) |
||||
@ -0,0 +1,8 @@
|
||||
--- |
||||
title: Линуксовка, СШ №80 |
||||
--- |
||||
|
||||
Темы |
||||
---- |
||||
|
||||
* Почтовые системы на базе unix -- AdUser -- [материалы](unix_mail_system.tar.gz) |
||||
Binary file not shown.
@ -0,0 +1,29 @@
|
||||
--- |
||||
title: Линуксовка, СШ №80 |
||||
--- |
||||
|
||||
Темы |
||||
---- |
||||
|
||||
* переход на линукс, общие сведения -- AdUser -- [материалы](unix-relations.tar.gz), [тезисы](/articles/2012/11/24/linux_distro_postinstall/) |
||||
|
||||
Фотографии |
||||
---------- |
||||
|
||||
[](p1020299.jpg) |
||||
[](p1020300.jpg) |
||||
[](p1020301.jpg) |
||||
[](p1020303.jpg) |
||||
[](p1020304.jpg) |
||||
[](p1020305.jpg) |
||||
[](p1020306.jpg) |
||||
[](p1020307.jpg) |
||||
[](p1020308.jpg) |
||||
[](p1020309.jpg) |
||||
[](p1020311.jpg) |
||||
[](p1020312.jpg) |
||||
[](p1020313.jpg) |
||||
[](p1020314.jpg) |
||||
[](p1020315.jpg) |
||||
[](p1020317.jpg) |
||||
[](p1020319.jpg) |
||||
|
After Width: | Height: | Size: 470 KiB |
|
After Width: | Height: | Size: 32 KiB |
|
After Width: | Height: | Size: 596 KiB |
|
After Width: | Height: | Size: 39 KiB |
|
After Width: | Height: | Size: 631 KiB |
|
After Width: | Height: | Size: 40 KiB |
|
After Width: | Height: | Size: 604 KiB |
|
After Width: | Height: | Size: 40 KiB |
|
After Width: | Height: | Size: 734 KiB |
|
After Width: | Height: | Size: 43 KiB |
|
After Width: | Height: | Size: 658 KiB |
|
After Width: | Height: | Size: 41 KiB |
|
After Width: | Height: | Size: 611 KiB |
|
After Width: | Height: | Size: 39 KiB |
|
After Width: | Height: | Size: 613 KiB |
Some files were not shown because too many files have changed in this diff Show More
Loading…
Reference in new issue