Поиск по этому блогу

понедельник, 28 декабря 2009 г.

Chrome и представление даты в u64

Информация для размышления по теме.

Заметка №1:
function DateTimeToChromeTime(Time: TDateTime): int64;
var
LocalFileTime: TFileTime;
SystemTime: TSystemTime;
begin
DateTimeToSystemTime(Time, SystemTime);
SystemTimeToFileTime(SystemTime, LocalFileTime);
Result := LocalFileTime.dwHighDateTime;
Result := Result * $100000000;
Result := Result + LocalFileTime.dwLowDateTime;
Result := Result div 10;
end;


Заметка №2:
static inline u64 get_rtc(void)
{
unsigned int hi, lo, hi2;

do {
asm volatile("mfrtcu %0; mfrtcl %1; mfrtcu %2"
: "=r" (hi), "=r" (lo), "=r" (hi2));
} while (hi2 != hi);
return (u64)hi * 1000000000 + lo;
}

суббота, 19 декабря 2009 г.

Потоковое видео средствами ffserver & ffmpeg

Статья взята с habrahabr.ru, ещё не пробовал делать то, что тут написано...


Для организации трансляции нам потребуется:

  • Linux
  • FFmpeg (включает в себя ffserver)
Теория
FFmpeg — это набор свободных библиотек с открытым исходным кодом, которые позволяют записывать, конвертировать и передавать цифровое аудио и видео в различных форматах. Он включает libavcodec, библиотеку кодирования и декодирования аудио и видео и libavformat, библиотеку мультиплексирования и демультиплексирования в медиаконтейнер. Название происходит от названия экспертной группы MPEG и «FF», означающего «fast forward».

© Wikipedia

ffserver идёт в комплекте с ffmpeg и выполняет роль медиа-сервера — получает видеопоток от ffmpeg, который может быть запущен на другой машине, и раздаёт его счастливым пользователям.
Каждый получаемый поток называется Feed’ом (далее будет просто фид). Таких потоков может быть несколько, так же как и отдаваемых (выходных).
FFmpeg у нас будет захватывать видео с веб-камеры или читать из файла.

Практика


Сначала настроим ffserver, чей конфиг лежит в /etc/ffserver.conf:
  1. Port 8090
  2. BindAddress 0.0.0.0
  3. MaxClients 100
  4. MaxBandwidth 20000
  5. NoDaemon
  6. # Фид, надо запомнить feed.ffm, он нам потребуется при запуске ffmpeg
  7. File /tmp/feed.ffm
  8. FileMaxSize 3M
  9. # Ранее объявленный фид
  10. Feed feed.ffm
  11. Format flv
  12. VideoCodec flv
  13. VideoFrameRate 30
  14. VideoBufferSize 80000
  15. VideoBitRate 200
  16. # Качество видео от 1 до 31, 1 == отлично 31 == фи!
  17. VideoQMin 1
  18. VideoQMax 5
  19. # Разрешение, везде должно быть одинаково!
  20. VideoSize 352x288
  21. PreRoll 1
  22. # Если у вас есть микрофон, или вы транслируете видео со звуком, закомментируйте эту строчку
  23. Noaudio
  24. # Флешка test.swf для просмотра трансляции
  25. Feed feed.ffm
  26. # Будет запускаться в Adobe Flash Player
  27. Format swf
  28. VideoCodec flv
  29. VideoFrameRate 30
  30. VideoBufferSize 50000
  31. VideoBitRate 100
  32. VideoQMin 1
  33. VideoQMax 5
  34. # Разрешение, везде должно быть одинаково!
  35. VideoSize 352x288
  36. PreRoll
  37. # Если у вас есть микрофон, или вы транслируете видео со звуком, закомментируйте эту строчку
  38. Noaudio
Пускаем ffserver:
$ ffserver

Пускаем ffmpeg:
$ ffmpeg -s 352x288 -r 30 -f video4linux2 -i /dev/video0 http://localhost:8090/feed.ffm
-s разрешение, указанное в конфиге ffserver, -r количество кадров/секунду, -f формат, -i путь к камере (или к видео-файлу), http://localhost:PORT/FEED это адрес, где ffserver будет ждать наш поток

PS: если выдаст ошибку, то можно попробовать формат v4l (-f video4linux)

Открываем в браузере http://localhost:8090/test.swf и широко улыбаемся:)

Для отправки видео поменяем параметр -i на путь к файлу, уберём -f (ffmpeg сам определит формат файла):
$ ffmpeg -s 352x288 -r 30 -i ~/big_buck_bunny.ogg http://localhost:8090/feed.ffm

Ну а что бы вставить нашу флешку в html-страницу используем следующий код:
src="http://localhost:8090/test.swf" width="550" height="400"></embed>


Q: А можно ли экран потоково отдавать, Х11 должен же иметь какой-то девайс в /dev?
A: Да, можно.
ffmpeg -f x11grab -r 30 -s 352x288 -i :0.0 localhost:8090/feed.ffm
Если будете менять разрешение, то и в конфиге ffserver не забудьте.

Chromium OS

Решил пройтись по инструкции сборки и установки Chromium OS, тут опишу пошагово то, что сейчас собираюсь делать. А вот заработает ли всё это добро и на каком этапе я решу остановиться - это уже второй вопрос ;)

Как обычно всё, что я буду делать - будет под Debian GNU/Linux.

Для начала скачаем исходники, где и как - внимательно читаем инструкцию. Надо сказать, что в debian'овской сборке git'а не нашёлся gclient, а потому пришлось скачать исходники wget'ом и распаковать:
olden@og:~$ mkdir chromiumos
olden@og:~$ cd chromiumos/
olden@og:~/chromiumos$ wget \
http://build.chromium.org/buildbot/archives/chromiumos-0.4.22.8.tar.gz
olden@og:~/chromiumos$ tar xzf chromiumos-0.4.22.8.tar.gz
olden@og:~/chromiumos$ ln -s chromiumos-0.4.22.8/src/ src
О полученной иерархии структуры каталогов можно почитать в документе "Структура директорий".

Переходим в созданной иерархии к исходникам:
olden@og:~/chromiumos$ cd ~/chromiumos/src/scripts
Не забываем установить пакет debootstrap:
olden@og:~/chromiumos/src/scripts$ aptitude -y install debootstrap
Создаём репозиторий Chromium OS:
olden@og:~/chromiumos/src/scripts$ ./make_local_repo.sh
Этот процесс займёт некоторое время...
Дождались? Отлично. Поехали дальше.
Создаём окружение сборки:
olden@og:~/chromiumos/src/scripts$ ./make_chroot.sh
Опять придётся подождать...
Раз, два, три, четыре, пять. Начинаем собирать. Так как в Debian'е в git'е нет gclient'а, а платформа у нас x86 то ничто не мешает воспользоваться вторым методом из указанной выше инструкции:
olden@og:~/chromiumos/src/scripts$ mkdir -p ~/chromiumos/src/build/x86/local_assets
olden@og:~/chromiumos/src/scripts$ cd ~/chromiumos/src/build/x86/local_assets
olden@og:~/chromiumos/src/build/x86/local_assets$ wget \
http://build.chromium.org/buildbot/archives/chromium-chromiumos-r32516.zip \
-O chrome-chromeos.zip
olden@og:~/chromiumos/src/build/x86/local_assets$ cd ~/chromiumos/src/scripts
Ну вот... Всё ближе и ближе подходим к финалу.
Собираем Chromium OS!
Входим в chroot окружение:
olden@og:~/chromiumos/src/scripts$ ./enter_chroot.sh
Mounting chroot environment.
(chroot)olden@og:~/trunk/src/scripts$
Включаем наш аккаунт в сборку, дабы не морочить себе голову с заведением пользователей:
(chroot)olden@og:~/trunk/src/scripts$ ( cd ../platform/pam_google && ./enable_localaccount.sh olden )
Enabling local account.  Remove chromeos_pam_localaccount.h to disable.
Имхо можно так завести нескольких пользователей, но так как у меня только один пользователь, то проверить это не представляется возможным, но всё в наших руках! :)
(chroot)olden@og:~/trunk/src/scripts$ ./set_shared_user_password.sh
Enter password for shared user account: shareduserpassword
Shared user password set in /home/olden/trunk/src/scripts/shared_user_passwd.txt
Собираем пакеты и ядро:
(chroot)olden@og:~/trunk/src/scripts$ ./build_platform_packages.sh
(chroot)olden@og:~/trunk/src/scripts$ ./build_kernel.sh
Это займёт время не на одну чашку кофе...
Ну и самый ответственный момент,- создаём образы:
(chroot)olden@og:~/trunk/src/scripts$ ./build_image.sh
После чего можно приступать к созданию носителей, откуда собираемся загружать нашу Chromium OS.
Но об этом я расскажу в следуюющей заметке...
If you created or changed a DOS partition, /dev/foo7, say, then use dd(1)
to zero the first 512 bytes:  dd if=/dev/zero of=/dev/foo7 bs=512 count=1
(See fdisk(8).)
Done.  Image created in /home/olden/trunk/src/build/images/999.999.35309.183057-a1
To copy to USB keyfob, outside the chroot, do something like:
./image_to_usb.sh --from=~/chromeos/src/build/images/999.999.35309.183057-a1 --to=/dev/sdb
To convert to VMWare image, outside the chroot, do something like:
./image_to_vmware.sh --from=~/chromeos/src/build/images/999.999.35309.183057-a1

вторник, 15 декабря 2009 г.

Upgrading Debian From i386 To amd64

Upgrading Debian From 32-bit To 64-bit

*****WARNING*****

This procedure is, in every possible respect, a bad idea. If it eats your firstborn, please don't come crying to me.
You probably don't need a complete backup of your data to do this safely, but you DO, without question, need boot media that has lots of things on it, like dpkg, for when you fry your system. The expected result of this procedure is a machine on which nothing works, where "nothing" includes "ls".
Seriously; the official documentation specifically declares this procedure to be impossible, which should give you some idea of how bad an idea this is.
*****WARNING*****

Target Audience

Sysadmins that have a 32-bit system that they'd really like to be 64-bit without re-doing all their configuration.
This really is for professional-level sysadmins; I don't suggest that anyone who hasn't seen a Debian box through a few manual broken-apt recoveries with dpkg, and libc upgrades, and kernel upgrades, even consider this.
Smart admins do all the config with cfengine, so this isn't an issue, but I didn't know that when I made this machine. :D

Preparation

Kernel

To make this work, you MUST have a 64-bit kernel installed. Seriously; you can't imagine how badly you'll fuck your system if you follow these steps without a 64-bit kernel.
If "uname -a" doesn't end with "x86_64 GNU/Linux", stop RIGHT NOW and fix it.
If you don't know how to upgrade your kernel, stop reading this. It's not for you.

Statically-Linked Shell And Stuff

To assist possible recovery issues, I strongly suggest apt-getting busybox and running it as a shell ("/bin/busybox ash") in a separate window. Make sure ls and cp and so on work even with PATH=''

List Your Packages

Run dpkg --get-selections and save it to a safe place. You'll want to know what you had installed when apt-get starts trying to make shit up.

Manual Package Downloads

Since both apt-get and dpkg think you're on an i386 machine, 64-bit kernel or no, you're going to have to get yourself some packages.

32-bit Compatibility Libraries

Unless the idea of every binary on your system suddenly ceasing to function sounds like your idea of a good time, you're going to need the 32-bit compatibility libraries for amd64, and you're going to need them before you upgrade libc. Start with the ia32-libs package (i.e. http://packages.debian.org/testing/libs/ia32-libs, but replace "testing" with your actual version) and download the amd64 version of it and ALL its dependencies.
You should now have a directory that looks like this:
ia32-libs_1.19_amd64.deb lib32asound2_1.0.14a-1_amd64.deb lib32gcc1_4.2-20070609-1_amd64.deb lib32ncurses5_5.6-3_amd64.deb lib32stdc++6_4.2-20070609-1_amd64.deb lib32z1_1.2.3-15_amd64.deb libc6-i386_2.5-9_amd64.deb lsb-release_3.1-23.1_all.deb 

dpkg, apt-get, and friends

Grab amd64 versions of dpkg, apt-get, and all their dependencies. You may not end up installing them all manually, but having them around can't hurt. Also grap apt-listchanges and apt-utils.
apt_0.6.46.4-0.1_amd64.deb binutils_2.17cvs20070426-8_amd64.deb bzip2_1.0.3-6_amd64.deb coreutils_5.97-5.3_amd64.deb cpio_2.7-3_amd64.deb debianutils_2.21_amd64.deb dpkg_1.14.4_amd64.deb ed_0.2-20_amd64.deb gcc-4.2-base_4.2-20070609-1_amd64.deb libacl1_2.2.42-1_amd64.deb libasound2_1.0.14a-1_amd64.deb libattr1_2.4.32-1.1_amd64.deb libbz2-1.0_1.0.3-6_amd64.deb libc6_2.5-9_amd64.deb libdb4.4_4.4.20-8_amd64.deb libgcc1_4.2-20070609-1_amd64.deb libgdbm3_1.8.3-3_amd64.deb libgpmg1_1.19.6-25_amd64.deb libncurses5_5.6-3_amd64.deb libreadline5_5.2-3_amd64.deb libselinux1_2.0.15-2_amd64.deb libsepol1_2.0.3-1_amd64.deb libstdc++6_4.2-20070609-1_amd64.deb make_3.81-3_amd64.deb ncurses-bin_5.6-3_amd64.deb patch_2.5.9-4_amd64.deb perl-base_5.8.8-7_amd64.deb perl_5.8.8-7_amd64.deb sed_4.1.5-2_amd64.deb 

The Actual Installation

Please note that order is very important. Read everything before starting. If this order doesn't seem eminently sensible to you, you may want to stop here.

32-bit Compatibility Libraries Install

First is the install of the 32-bit compat libc. This is the fun step:
dpkg --force-depends --force-architecture --force-overwrite -i libc6-i386_2.5-9_amd64.deb 
Yes, you really do need all those. When you're done, /lib/ld-linux.so.2 should be a symlink into /emul/ia32-linux, like this:
lrwxrwxrwx 1 root root 34 Jun 26 08:57 /lib/ld-linux.so.2 -> /emul/ia32-linux/lib/ld-linux.so.2* 
If it's not (it wasn't for me) run:
ln -sf /emul/ia32-linux/lib/ld-linux.so.2 /lib/ld-linux.so.2 
Check that it worked; there should be lots of stuff in /emul/ia32-linux, and:
$ ls -l /usr/lib32 /lib32                         lrwxrwxrwx 1 root root 20 Jun 26 08:56 /lib32 -> /emul/ia32-linux/lib/ lrwxrwxrwx 1 root root 24 Jun 26 08:56 /usr/lib32 -> /emul/ia32-linux/usr/lib/ 
Run "dpkg --force-architecture -i" for all of the other 32-bit compat libs until they're all installed. Should be uneventful.

64-bit libc Install

While this should be uneventful, I mention it separately because if you're going to fuck your system, this is where it'll happen. Run:
dpkg --force-architecture -i libc6_2.5-9_amd64.deb 

dpkg, apt-get, And Friends Install

If you can still "ls" and such in a non-static shell, congratulations. Now "dpkg --force-architecture -i" the packages for apt-get, dpkg, apt-listchanges, and apt-utils. Then keep trying to run each of apt-get, dpkg, apt-listchanges and apt-extracttemplates until they actually run without erroring.
For apt-listchanges, I had to install (in this order):
python2.4-minimal python2.4 python-apt zlib1g libdb-4.4 
That last isn't necessary for getting it to just run, but it was necessary to stop "apt-get -f install" from barfing.
At this point, "dpkg --print-architecture" should say amd64, as should most of "dpkg-architecture" if you have that installed, and "apt-get update" (which you should run) should download a bunch of files to /var/lib/apt/lists that have "amd64" in the name. That's good.

Upsetting apt-get

Run "apt-get update" followed by "apt-get -f install". Keep adding packages until "apt-get -f install" doesn't give you any library or ELFCLASS errors.
Having done so, things will probably still be upset, and you may need to do manual dpkg things. Steps I had to take to make "apt-get -f install" run to completion:
dpkg -i /var/cache/apt/archives/libperl5.8_5.8.8-7_amd64.deb 
Note that apt-get will Make Shit Up during this process. For example, it tried to give me exim4-daemon-light, which I never had installed (I use exim4-daemon-heavy). This is what the dpkg selections list is for. Hence:
apt-get -f install exim4 exim4-daemon-heavy apache2-mpm-prefork console-tools libconsole 
Then there was funkiness because someone broke tex's dependencies. :P

Ugrading Everything Else

Here's the fun part: catching all the things that haven't been gotten yet. First, make a list of remaining i386 packages:
for package in $(grep '[^e]install' dpkg_get_selections.out | awk '{ print $1 }') do     dpkg -s $package | grep -q 'Architecture: i386' && echo $package done >update 
Then open up yourself a copy of the update file (so you can fix the many problems that will occur) and run:
apt-get --reinstall install $(cat update | tr '\012' ' ') 
Keep editing and running until it works.
If you thought the last step downloaded a lot of packages, you may be surprised by the results of this step.
After all of that's done, you might want to check your currently installed packages for further badness:
for package in $(dpkg -l |  grep '^i' | awk '{ print $2 }') do     dpkg -s $package | grep -q 'Architecture: i386' && echo $package done >update2 
With this list, though, you almost certainly want to remove most or all of them: if they weren't installed as a dependency of the other stuff, you almost certainly don't care. Trim local stuff out (like kernel packages) and run:
dpkg -r $(cat update2 | tr '\012' ' ') 
That should pretty much do it.

Сам я не пробовал так апгрейдится... пока не пробовал... за ненадобностью. Но взял "на заметку". Оригинал статьи находится тут http://teddyb.org/~rlpowell/hobbies/debian_arch_up/.

понедельник, 14 декабря 2009 г.

MySQL: Восстановление пароля root

Останавливаем сервер MySQL:
# /usr/local/etc/rc.d/mysql-server.sh stop
Stopping mysql.
Waiting for PIDS: 83119, 83119.

Запускаем mysqld с параметром –skip-grant-tables, указав стартовать от имени пользователя mysql (или от другого непривелигерованного пользователя, но не от root’а.
Теперь запускаем mysql и делаем:
\u mysql
Правим таблицу user, очищая поле с паролем для root@localhost. Всё, пароля для root'а больше нет. Не забываем сказать flush privileges и перезапустить сервер mysql. Далее заходим под пользователем root@localhost и устанавливаем ему такой пароль какой нам необходим.

Как собрать бинарный deb пакет: подробное HowTo

Сегодня я расскажу на абстрактном примере как правильно создать *.deb пакет для Ubuntu/Debian. Пакет мы будем делать бинарный. Пакеты, компилирующие бинарники из исходников здесь не рассматриваются: осилив изложенные ниже знания, в дальнейшем по готовым примерам можно понять суть и действовать по аналогии :)

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

В качестве бонуса в конце статьи будет пример быстрого создания собственного локального репозитория: установка пакетов из репозитория позволяет автоматически отслеживать зависимости, и конечно же! — устанавливать всё одной консольной командой на нескольких машинах :)

Для тех, кто не хочет вдаваться в мощную систему установки софта в Linux, рекомендую посетить сайт проги CheckInstall: она автоматически создаёт deb-пакет из команды «make install» ;) А мы вместе с любопытными —

Источники


Информация надёргана из многих мест, но вот два основных:

В статье подробно изложены основы создания пакетов, достаточные для получения достаточно мощного управления установкой приложений. Более продвинутые фичи опущены, но предложены прямые ссылки на документацию для интересующихся.
Статья не является копией или переводом какой-либо документации: это — коллекция знаний, валявшихся в виде заметок, а теперь оформленная в виде статьи. Для ясности везде есть примеры, разъяснения на пальцах, найденные мной удобные фичи и некоторые типичные ошибки, которые можно совершить по незнанию.

Подготовка



Зачем это всё?

Да, CheckInstall умеет создавать рабочий пакет, но он не поддерживает все вкусности, на которые способны deb пакеты :) А именно:
  • Скрипты, выполняющиеся до, после и вместо установки пакета :)
  • Автоматическое управление конфигурационными файлами: пакет не позволит затереть старые конфиги новыми без спроса
  • Работа с шаблонами: возможность задавать пользователю вопросы при установке (!!!)
  • Изменение файлов других пакетов


Что потребуется

Конечно, для создания полноценного пакета хватит архиваторов tar, gz, ar, но можно исключить лишнюю возню, и воспользоваться инструментами, созданными для облегчения жизни :)
Ставим:
$ sudo apt-get install dpkg debconf debhelper lintian

Что мы будем делать

Для примера будет рассмотрен некий скрипт /usr/bin/super.sh. Не важно что внутри, главное — как он появится на правильном месте :)

Подготовка папки

В домашнем каталоге (или где удобно) создаём папку, в которой будут лежать все файлы будущего пакета: mkdir ~/supersh. Далее будем называть её корень пакета.
В корне пакета создаём папку «debian». Эта папка содержит управляющую генерацией пакета информацию, и не копируется на диск при установке пакета.
Также корневая папка пакета содержит будущий «корень диска»: при установке пакета все файлы (кроме папки «debian») распаковываются в корень /. поэтому наш скрипт должен лежать по такому пути, относительно корня пакета: «usr/bin/super.sh»
Белым по чёрному:
mkdir -p ~/supersh/debian # управляющая папка
mkdir -p ~/supersh/usr/bin # путь к скрипту
cp super.sh ~/supersh/usr/bin/ # копируем наш скрипт в нужное место

В итоге имеем:
supersh/debian/
supersh/usr/
supersh/usr/bin/
supersh/usr/bin/super.sh


Создание пакета: debian/*


Как я уже сказал, папка debian содержит файлы, используемые при установке. Здесь я опишу (с примерами) каждый файл.
Для создания полноценного пакета достаточно контрольного файла «control», все остальные используются либо для прикрепления текстовой информации (changelog, лицензия), либо для управления расширенными возможностями установки приложений.
Из описанных ниже файлов в папке debian/* выбираем необходимые, и заполняем согласно инструкции :)
В наше примере реально используется только обязательный debian/control.

debian/control: Основная информация

control — центральный файл пакета, описывающего все основные свойства. Файл — текстовый, состоящий из пар «Атрибут: значение». Можно использовать комментарии: символ "#" в начале строки (возможность была добавлена в версии dpkg >= 1.10.11, надеяться на комментарии не стоит :).
В таблице приведены все поля, определённые для контрольного файла. Обязательные поля выделены жирным: без них пакет не будет считаться составленным верно.
Атрибут Описание Примеры
— основные —
Package: Имя пакета: [a-zA-Z0-9-] — только латиница, цифры, и дефис. Имя используется при установке: apt-get install Package: supersh
Version: Версия пакета (и проги внутри). Используется для определения «обновлять ли».
Формат принят такой: <версия_программы>-<версия_пакета>.
Рекомендую всегда указывать версию пакета: при изменении структуры пакета цифра увеличивается на единичку.
Допустимые символы достаточно вольные: можно использовать дату и буквы. Примеры смотрите сегодня в своём репозитории :)
Version: 1.0-1
Version: 2009.12.12-1
Provides Имя приложения (возможно, виртуальное), регистрируемое в системе в результате установки этого пакета.
Используется редко: в основном, если нужно изменить имя пакета, или если более одного пакета предлагают одинаковый функционал. Например, пакеты Apache и nginx предоставляют возможность демона httpd: Provides: httpd
Вы наверняка сталкивались с ошибкой при попытке установки: «is a virtual package». Это оно и есть :)
Provides: supersh
Maintainer Имя и почта мэйнтейнера пакета: человека, который «дебианизировал» приложение.
Формат произвольный, но принято имя
Maintainer: o_O Tync
Architecture Архитектура процессора, для которой предназначен пакет.
Допустимые значения: i386, amd64, all, source
all используется для скриптов: они же портативные, верно? :)
source используется для компилируемых пакетов с исходниками
Architecture: all
Section Определяет задачу, для которой приложение обычно используется (группа приложений).
Возможные значения: admin, base, comm, contrib, devel, doc, editors, electronics, embedded, games, gnome, graphics, hamradio, interpreters, kde, libs, libdevel, mail, math, misc, net, news, non-free, oldlibs, otherosfs, perl, python, science, shells, sound, tex, text, utils, web, x11
Section: misc
Description Описание пакета.
Описание состоит из двух частей: короткое описание (70 символов) на той же строке, и длинное описание на последующих строках, начинающихся с пробела.
В расширенном описании все переводы строки игнорируются. Для вставки \n используется одиночная точка.
Description: Short.
␣Long
␣goes here.
␣.
␣New line.
— связи и зависимости —
Depends Список пакетов через запятую, которые требуются для установки этого пакета.
После имени пакета можно в круглых скобках указать ограничение на версию, используя операторы: <<, =, >>, <=, >=. Если оператор не указан — используется >=
Depends: dpkg, libz (>= 1.2.3), jpeg (= 6b), png (<>
Pre-Depends Список пакетов, которые требуются в процессе установки этого пакета.
Эти зависимости могут потребоваться для скриптов установки пакета: например, пакет flash-installer требует wget
Можно использовать ограничения на версию (см. Depends).
Pre-Depends: wget (>= 1.0)
Conflicts Список пакетов, которые не могут быть установлены одновременно с этим.
Установка не удастся, если хоть один из перечисленных пакетов уже будет установлен.
Conflicts: crapscript
Replaces Список пакетов, файлы которых модифицируются этим пакетом.
Требуется в случае создания «пакета-патча», изменяющего что-либо: в противном случае при замене файлов чужого пакета возникнет ошибка при установке. У меня, например, такой пакет патчит UT2004 и убирает звук наводящейся ракетницы :)
Replaces: ut2004
Recommends Список пакетов, рекомендуемых к установке
Эти пакеты не обязательны, но обычно используются вместе с текущим
Recommends: superplatform
Suggests Список пакетов, предлагаемых к установке.
Эти пакеты не обязательны, но с ними прога работает ещё лучше :) По идее, менеджер пакетов должен предлагать установить их.
Suggests: supersh-modules
Build-Depends (Только для Architecture: source)
Список пакетов, требуемых для компиляции исходников.
То же, что и Depends, но логически отделено.
Build-Depends: cmake
— экстра —
Installed-Size Размер файлов пакета в килобайтах.
Просто цифра, округлённая до ближайшего целого. Используется менеджером пакетов для определения суммарного требуемого объёма на диске.
Installed-Size: 3
Priority Приоритет пакета: насколько он важен в системе
Возможные значения: extra, optional, standard, important, required (такие пакеты не удаляются вообще!).
Priority: optional
Esssential Если установить этот атрибут в значение «yes», пакет нельзя будет удалить. Esssential: yes
Origin Строка: откуда получены программы в пакете. Обычно используется URL сайта автора, почта или имя. Origin: brain
X-Source Полная ссылка на *.tar.gz архив с исходниками X-Source: .../*.tgz

Да, вот такие солидные возможности у контрольного файла :)
А в нашем примере он выглядит так:
Package: supersh
Version: 1.0-1
Section: misc
Architecture: all
Depends: bash, sed (>= 3.02-8)
Maintainer: o_O Tync
Description: Super Shell script
␣A super example script.
␣.
␣It does nothing :)


debian/copyright: © / лицензия

Текст лицензии. Файл не обязателен, но лучше подчеркнуть своё авторство ;)

debian/changelog: история изменений

Changelog в специальном формате: используется dpkg для получения номера версии, ревизии, дистрибутива и важности пакета. Лучше посмотреть в официальной документации ;) а я лишь приведу пример:
supersh (1.0-1) stable; urgency=medium

* Testing.

-- o_O Tync Sun, 13 Dec 2009 00:11:46 +0300


debian/rules: правила компиляции

Используется для управления компиляцией пакета: это когда Architeture: source :)
См. официальную документацию

debian/conffiles: список файлов конфигурации

Обычно пакеты содержат болванки конфигурационных файлов, например, размещаемых в /etc. Очевидно, что если конфиг в пакете обновляется, пользователь потеряет свой отредактированный конфиг. Эта проблема легко решается использованием папок типа «config.d», содержимое которых включается в основной конфиг, заменяя собой повторяющиеся опции.
Файл «debian/conffiles» позволяет решить проблему иначе: он содержит список файлов конфигурации (по одному на строке). Если в текущей версии пакета один из этих файлов обновляется, то пользователь получает предупреждение о конфликте версий конфигов, и может выбрать: удалить, заменить, или сделать merge.
С этой ситуацией наверняка сталкивался каждый линуксоид, копавшийся в конфигах :) А ноги растут отсюда.
На каждой строке должен быть полный абсолютный путь до каждого конфига. Например:
/etc/supersh/init.conf
/etc/supersh/actions.conf


debian/dirs: список папок для создания

Список абсолютных путей к папкам, которые требуются программе, но по каким-либо причинам не создаются. По одной на строке. Например:
/var/log/supersh
/var/lib/supersh

Удобно использовать для создания нескольких пустых папок.

debian/menu: создание пунктов меню

Хитрый файл для создания пунктов меню. У меня он так и не заработал :) Складывается ощущение, что его содержимое используется либо в необычных оконных менеджерах, либо в каком-то консольном меню… или же использовалось ранее и было забыто :)
Пример:
?package(supersh):needs="text" section="Applications/Programming" title="Super Shell script" command="/usr/bin/super.sh"
TODO: узнать зачем нужно. Об этом написано в man5 menufile, честно говоря я не вникал :)

debian/md5sums: контрольные суммы файлов

Используется для проверки целостности пакета. Важный файл.
Заполняется так (cwd=корень пакета):
$ md5deep -r usr > debian/md5sums

debian/watch: мониторинг сайта, откуда была скачана прога

Функция полезна, если Вы мэйнтейните от нескольких десятков пакетов, и уследить за всеми обновлениями сложно.
Файл содержит инструкции для программ uscan и uupdate. Используя эту возможность, можно следить за сайтом, откуда были получены исходники пакета, и обеспечивать контроль качества дистрибутива в целом.
Пример:
# Site Directory Pattern Version script
ftp.obsession.se /gentoo gentoo-(.*)\.tar\.gz debian uupdate

Лучше почитайте официальную документацию, такие мощные вещи нечастно требуются простым смертным :)

Скриптинг


Мы подошли к самому интересному: встраиванию скриптов в deb пакеты. Скрипты позволяют управлять установкой, переустановкой и удалением пакета, выполняя действия, которые нельзя сделать простым копированием файлов в правильные места. Это может быть скачивание дополнительных файлов (как это делает flash-installer), изменение существующих, а также — вывод интерактивных (GUI или ncurses) диалогов, позволяющих пользователю сконфигурировать пакет под себя: например, mysql спрашивает какой установить пароль для root.
Все скрипты выполняются от пользователя root (а как же ещё :). Также они получают аргументы (которые обрабатывать не обязательно), конкретизирующие на каком именно этапе находится установка. Подробнее об этом здесь.

debian/(preinst|postinst|config|prerm|postrm): скрипты установки

Всего можно создать до пяти скриптов в одном пакете:
Скрипт Назначение
debian/preinst Выполняется перед установкой пакета: он может подготовить что-либо для успешной установки
debian/postinst Выполняется сразу после установки пакета: он настраивает установленный пакет так, чтоб он был готов к работе
debian/prerm Выполняется непосредственно перед удалением пакета: обычно этот скрипт подчищает установочные пути пакета так, чтоб ничего лишнего не завалялось :)
debian/postrm Выполняется сразу после удаления пакета: вычищает остатки
debian/config Выполняется после установки пакета на стадии конфигурирования: это — единственный скрипт, в котором разрешено вести диалог с пользователем. Это делается при помощи dh_input и файла debian/templates

Обратите внимание, что ошибки, возникающие в этих скриптах никак не логируются: ничего интереснее кода возврата скрипта нигде не сохраняется, и логирование необходимо делать вручную! Пользователи одного моего пакета терпели неудачу при установке на Linux Mint, и не было даже возможности попросить у них лог ошибок (которого нету) чтобы выдебагать причину :)
Рекомендую использовать в начале каждого скрипта следующую болванку: она будет сохранять в syslog все возникающие ошибки.
#!/bin/bash
set -e # fail on any error
set -u # treat unset variables as errors

# ======[ Trap Errors ]======#
set -E # let shell functions inherit ERR trap

# Trap non-normal exit signals:
# 1/HUP, 2/INT, 3/QUIT, 15/TERM, ERR
trap err_handler 1 2 3 15 ERR
function err_handler {
local exit_status=${1:-$?}
logger -s -p "syslog.err" -t "ootync.deb" "[${package}] *.deb script '$0' error code $exit_status (line $BASH_LINENO: '$BASH_COMMAND')"
exit $exit_status
}

... Ваш код установочного скрипта ...

exit 0

WARNING: болванка пока не тестировалась широко, проверьте лишний раз! На невозможность отладки наткнулся совсем недавно :)

debian/templates: шаблоны для диалогов

Как уже было сказано, в скрипте debian/config можно задавать пользователю вопросы: ввести строку, выбрать один из вариантов, поставить галочку,… Этим занимается «библиотека» bash функций debhelper пакета debconf, умеющая кроме этого ещё массу полезных вещей. Здесь их не рассматриваю :)
Файл debian/templates содержит данные, используемые при выводе диалоговых окон (GUI или ncurses). Файл содержит блоки, разделённые пустой строкой. Каждый блок определяет ресурсы, используемые в одном конкретном диалоговом окне.
Шапка для всех типов диалогов стандартная:
Template: supersh/template-name
Type: string
Default: Default-value
Description: Dialog-title
␣Dialog-text

Template — уникальный (в пределах одного пакета) идентификатор шаблона. Если в скрипте нужно вызвать определённый диалог — используется именно это имя.
Type — тип шаблона. Определены такие типы: string, password, boolean, select, multiselect, text, note, error.
Default-value — значение по умолчанию: пользователь может просто согласиться с ним.
Description — как и в контрольном файле, состоит из двух полей: короткое описание, и длинный текст. Первое — это заголовок «окна», второе — более развёрнутое описание того, что требуется от пользователя. Рекомендуется не использовать слов вроде «введите», а сразу суть: «Приветствие скрипта», «Точка монтирования»,…

Тип Описание шаблона
string Приглашение на ввод текстовой строки
password Приглашение на ввод пароля.
Для этого типа шаблона нет значения Default по понятным причинам :)
boolean Галочка :) Имеет строковое значение «true» или «false»
select Возможность выбора одного из нескольких вариантов.
Варианты предлагаются в дополнительном атрибуте шаблона:
Choices: yes, no, maybe
multiselect Возможность выбора нескольких вариантов галочками.
Варианты предлагаются в дополнительном атрибуте шаблона:
Choices: sex, drugs, rock-n-roll
text Выводит на экран текст: некоторая не очень важная информация
note Выводит на экран текст: важная информация
error Выводит на экран текст: очень важная информация, критическая.

Для шаблонов text, note, error также нет значения Default, так как они лишь отображают информацию :)
Поиграемся с следующим шаблоном:
Template: supersh/greeting
Type: string
Description: Welcome message
␣The message you wish the script to welcome you with.
Default: Greetings, my master!


Основы использования debconf и debhelper

Это лишь работоспособные наброски. В оригинале почитать о шаблонах и работе с ними можно здесь: man 7 debconf-devel :)
Чтобы использовать шаблоны в своём скрипте настройки debian/config, необходимо сначала подключить функции debhelper:
. /usr/share/debconf/confmodule
Эти функции доступны в пакете debconf, не забудьте включить его в зависимости!
Примитивный пример использования:
#!/bin/bash -e

. /usr/share/debconf/confmodule

# Запрос
db_input medium "supersh/greeting" || true # инициализация
db_go || true # вывод запроса на экран

# Обработка ответа
db_get "supersh/greeting" # Получение значения в переменную $RET
greeting="$RET"
echo "$greeting" > /etc/supersh/greeting.txt

Здесь уже кроется неприятная засада: обратите внимание, что функции db_input передаётся приоритет диалога medium. Для debconf можно установить минимальный приоритет: диалоги с приоритетом ниже которого не отображаются, а берётся значение по умолчанию (Default шаблона)! Чтобы этого ТОЧНО не случилось — используем приоритет critical :) Кроме того, при установке из GUI порог вывода вопросов выше, и многие из них не отображаются вообще.
Возможные приоритеты: low — всегда используется default, medium — дефаулт обычно вполне подходит, high — дефаулт нежелателен, critical — внимание пользователя жизненно важно.
|| true используется чтобы скрипт не помер из-за ключика "-e" переданного bash.
В этом скрипте тоже рекомендуется использовать ту болванку для отлова ошибок, иначе с распространяемым пакетом могут возникнуть проблемы при отладке :)
Все тонкости использования debconf (функции, способы, параметры, коды ошибок) описаны в достаточно многословном мане: man debconf-devel.

Собираем пакет! :)


Ура! Все нужные файлы созданы, лежат по нужным папочкам. Теперь пора собирать пакет :)
Первое, что нужно сделать — это рекурсивно выставить всем файлам в корне пакета пользователя и группу root:root (или другие, если потребуется):
$ sudo chown -R root:root .
Проверьте права доступа на все файлы! При установке пакета права будет сохранены. В нашем примере, скрипт должен иметь бит выполнимости.
Потом выходим на папку назад, чтоб было видно корневую папку пакета, и пакет создаётся лёгким пинком сам:
$ dpkg-deb --build supersh
Созданный пакет необходимо переименовать, чтобы он соответствовал порядку именования *.deb пакетов: <имя пакета>_<версия>_<архитектура>.deb
$ mv supersh.deb supersh_1.0-1_all.deb
Всё, пакет готов!

Автоматическая проверка пакета

Существует утилита lintian, позволяющая проверить пакет и выявить типичные ошибки в его структуре. Делается это так:
$ lintian supersh_1.0-1_all.deb

Установка пакета

$ sudo dpkg -i supersh_1.0-1_all.deb

Создаём собственный репозиторий пакетов


Теперь у нас есть собственный пакет. Когда их будет несколько, и тем более — с зависимостями, окажется, что намного удобнее быстренько поднять собственный локальный микро-репозиторий, и включить его в список источников менеджера пакетов :) Здесь я опишу быстрый HowTo «как создать свой репозиторий». Идею будет легко развить, почитывая соответствующую документацию :)
Сперва установим помощника:
$ sudo apt-get install reprepro

Описание будущего репозитория

Центр репозитория — его описание. Главное в нём — список компонент репозитория. Мы создадим компоненты «soft» и «games».
Выберите папку для будущего репозитория. Все действия производятся из её корня.
Создаём файл conf/distributions следующего содержания:
Description: my local repository
Origin: Ubuntu
Suite: testing
AlsoAcceptFor: unstable experimental
Codename: karmic
Version: 5.0
Architectures: i386 amd64 source
Components: soft games
UDebComponents: soft games

В нашем деле создания простого репозитория все поля не играют принципиальной роли, и используются лишь для визуального определения «что есть что» :)

Создание репозитория

Репозиторий описан! Теперь сгенерируем болванку на основе описания. Команды выполняются в корне репозитория:
$ reprepro export
$ reprepro createsymlinks

И добавим готовый репозиторий в /etc/apt/sources.list:
deb file:///path/to/repo/ karmic soft games
Этот репозиторий можно также расшарить при помощи веб-сервера.

Управление пакетами в репозитории

В корень репозитория кладём *.deb файлы для добавления, и добавляем их в компоненту soft дистрибутива karmic:
reprepro -C soft includedeb karmic *.deb
теперь пакеты доступны из менеджера пакетов :)
Удаление пакетов:
reprepro -C soft remove karmic supersh

Финиш


В статье рассмотрены материалы по созданию deb пакетов. Акцент сделан на моментах, для которых в сети нет достаточно наглядного описания. Надеюсь, что моя попытка изложить просто и понятно не провалилась :)
Домашнее задание :)) — вполне неплохо документированные вещи, которые легко найти в man'ах и статьях:
  • Создание source пакетов, компилирующих исходники: на примере Zabbix об этом отлично рассказал хабраюзер mahoro в своей статье
  • Debconf, debhelper в конфигурационных скриптах: читаем маны по debconf-devel и debhelper. Они также позволяют создать скелет пакета командой dh_make.
  • Продвинутые способы создания документации в пакетах: файлы debian/docs, debian/manpage.*
  • Создание init скриптов
  • Управление заданиями cron
  • Подписывание репозитория ключём gpg


UPD: ICD2 подсказывает, что есть GUIшная прога для создания пакетов: GiftWrap.

Cheers! :)

P.S. В статье наверняка встречаются неточности и ошибки. Давайте причешем её вместе! :)


Оригинал статьи читать тут habrahabr.ru

1. в ... болванках скриптов не хватает проверки на то, какое действие собственно происходит. В случае с postinst-скриптом это вроде ничего, но в prerm это уже совсем не лишнее. Правильные шаблоны есть в dh_make.
2. В майском номере Linux Format была подобная статья:
Кому интересно:
pic.ipicture.ru/uploads/091213/1gN9WxSV1F.jpg
pic.ipicture.ru/uploads/091213/6ccT4iL9Zu.jpg

пятница, 11 декабря 2009 г.

Запуск виртуальной машины в VirtualBox без GUI

VirtualBoxИногда возникает необходимость запустить виртуальную машину на хосте без иксов. Я расскажу о том как это сделать, имея доступ к хостовой системе только по ssh + rdp (Remote Desktop Protocol). процесс я буду описывать для OC Ubuntu 9.10 в качестве хоста.

Начнем с установки VirtualBox.

Предварительно нужно установить пакет dkms (Dynamic Kernel Module Support Framework):

sudo apt-get install dkms

На сайте VirtualBox-а предлагается 2 варианта: прописать источник пакетов (deb download.virtualbox.org/virtualbox/debian karmic non-free) в /etc/apt/sources.list либо скачать и установить deb-пакет. Когда я прописал источник и сделал sudo apt-get install virtualbox-3.1 у меня потянулась куча пакетов из зависимостей (в том числе и каких-то для GUI интерфейса). Поэтому лучше скачать deb-пакет. Качаем, устанавливаем:

sudo dpkg -i virtualbox-3.1_3.1.0-55467_Ubuntu_karmic_i386.deb

возможно тут также потребуются зависимости (какие-то библиотеки для парсинга xml, в котором хранятся конфиги, но их значительно меньше чем в первом случае). Если установка не завершилась из-за зависимостей, можно просто сделать

sudo apt-get -f install

при этом установятся зависимости и VirtualBox

ок. VirtualBox поставили. Начнем создавать guest-машины.

создаем саму машину:

VBoxManage createvm --name ubuntu --ostype Ubuntu --register
(name — имя машины, ostype — тип системы. полный список всех типов можно узнать командой VBoxManage list ostypes)

настраиваем

VBoxManage modifyvm ubuntu --memory 512 --floppy disabled --audio none --nic1 bridged --bridgeadapter1 eth0 --vram 4 --accelerate3d off --boot1 disk --acpi on --cableconnected1 on --usb off --vrdp on --vrdpport 3390

тут с большего все понятно. в качестве типа сети можно указать также NAT (--nic1 nat). также включаем rdp

создаем hdd диск для виртуальной машины:

VBoxManage createhd --filename /home/user/vbox/ubuntu.vdi --size 20000 --register

добавляем контроллер IDE в нашу машину

VBoxManage storagectl ubuntu --name "IDE Controller" --add ide

цепляем на IDE0 созданный ранее hdd

VBoxManage storageattach ubuntu --storagectl "IDE Controller" --port 0 --device 0 --type hdd --medium /home/user/vbox/ubuntu.vdi

на IDE1 цепляем установочный образ

VBoxManage storageattach ubuntu --storagectl "IDE Controller" --port 1 --device 0 --type dvddrive --medium /home/user/vbox/iso/ubuntu-9.10-alternate-i386.iso

говорим машине грузиться с диска

VBoxManage modifyvm ubuntu --boot1 dvd

запускаем машину

nohup VBoxHeadless --startvm ubuntu &

для того чтобы поставить базовую систему воспользуемся rdp-клиентом (у меня KDE, в стандартную поставку входит KRDC). коннектимся на хостовую машину на порт, который указали в настройках (--vrdpport 3390), ставим систему, делаем sudo apt-get install openssh-server. теперь на виртуальную машину можно попасть по ssh

останавливаем виртуальную машину

VBoxManage controlvm ubuntu acpipowerbutton
через acpi

или более жестко

VBoxManage controlvm ubuntu poweroff

говорим грузится с hdd

VBoxManage modifyvm ubuntu --boot1 disk

можно также отцепить установочный диск

VBoxManage storageattach ubuntu --storagectl "IDE Controller" --port 1 --device 0 --medium none

и снова запускаем

nohup VBoxHeadless --startvm ubuntu &

еще полезные команды:

VBoxManage list runningvms
просмотр всех запущенных машин

VBoxManage showvminfo ubuntu
просмотр информации о виртуальной машине

таким образом на одной машине с минимально установленной системой можно поднимать несколько виртуальных для различных целей и экспериментов.


Источник данной статьи habrahabr.ru

пятница, 4 декабря 2009 г.

Быстрый Flash в Ubuntu

Это просто калька поста с хабрахабра. Сам не проверял, но взял на заметку.


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



Итак:
1) Лучше всего, по наблюдениям, Flash работает в Ubuntu 9.04.
2) Естественно, нужно убедиться, что установлена последняя версия драйвера видеокарты. Ставим Flash плагин:
sudo apt-get install flashplugin-nonfree
3) Создаём папку /etc/adobe, а в ней — файл /etc/adobe/mms.cfg. В файл вписываем следующую строку:
OverrideGPUValidation=true
Это заставит Flash использовать аппаратное ускорение графики.
4) Правим /etc/init.d/ondemand — вписываем
for CPU_THRESHOLD in /sys/devices/system/cpu/cpu*/cpufreq/ondemand/up_threshold
do
[ -f $CPU_THRESHOLD ] || continue
echo -n 40 > $CPU_THRESHOLD
done

После аналогичного блока
for CPUFREQ in /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor
do
[ -f $CPUFREQ ] || continue
echo -n ondemand > $CPUFREQ
done

Это заставит ОС не понижать частоту процессора при загрузке большей, чем 40%.