По пути Java, Linux и Open Source

Как отсыпать совсем немножечко рута для Java и разрешить захватывать сетевые пакеты

2016-06-28T14:48:00.000+03:00

В различных дистрибутивах Linux такие программы, как tcpdump и wireshark, использующиеся для анализа сетевого трафика, обычно требуют прав суперпользователя для получения доступа к возможностям захвата пакетов. Точно также дело обстоит и с Java-программами, которые используют системную библиотеку libpcap. Причем в этом случае вам придется запустить с неограниченными правами саму виртуальную машину Java, которая уже в свою очередь будет исполнять ваш код. Я думаю, мало кто любит лишний раз сорить суперправами направо и налево, поэтому в Linux, начиная с ядра 2.2 появилась такая штука, как Linux Capabilites, которая позволяет наделить непривилегированные процессы только необходимыми возможностями суперпользователя. В данном случае, например, нас интересует только возможность перехвата и отправки сетевых пакетов. Для установки и просмотра Linux Capabilites необходимы программы setcap и getcap, соответственно. У меня в openSUSE эти утилиты находятся в пакете libcap-progs, а в Ubuntu в пакете libcap2-bin.

Установка возможности захвата и отправки сетевых пакетов и возможности изменения конфигурации интерфейсов выглядит так:

setcap cap_net_raw,cap_net_admin=eip /usr/local/lib64/jdk1.8.0_77/bin/java

Просмотр установленных возможностей:

getcap /usr/local/lib64/jdk1.8.0_77/bin/java
/usr/local/lib64/jdk1.8.0_77/bin/java = cap_net_admin,cap_net_raw+eip

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

java -version

java: error while loading shared libraries: libjli.so: cannot open shared object file: No such file or directory

Это происходит из-за того, что при наличии у непривилегированного процесса возможностей, которыми он вроде как обладать не должен, загрузчик динамических библиотек запрещает загрузку библиотек из недоверенных каталогов. Доверенными каталогами по умолчанию являются /lib и /usr/lib (а также /lib64 и /usr/lib64).

С помощью утилиты ldd посмотрим, какие динамические библиотеки использует java:

ldd /usr/local/lib64/jdk1.8.0_77/bin/java
        linux-vdso.so.1 (0x00007ffc91ffd000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fc3dc124000)
        libjli.so => /usr/local/lib64/jdk1.8.0_77/bin/../lib/amd64/jli/libjli.so (0x00007fc3dbf0d000)
        libdl.so.2 => /lib64/libdl.so.2 (0x00007fc3dbd09000)
        libc.so.6 => /lib64/libc.so.6 (0x00007fc3db961000)
        /lib64/ld-linux-x86-64.so.2 (0x00005584e041d000)

Как видно из вывода команды ldd, при запуске java не удалось загрузить как раз ту самую библиотеку, которая находится в недоверенном каталоге ../lib/amd64/jli/.

Это можно легко пофиксить, добавив файл с расширением .conf в каталог /etc/ld.so.conf.d, в котором перечислить все необходимые пути. В случае с java это всего лишь один каталог:

echo /usr/local/lib64/jdk1.8.0_77/lib/amd64/jli > /etc/ld.so.conf.d/java.conf

После изменения файлов в /etc/ld.so.conf.d может потребоваться перестроить кэш библиотек, для этого нужно выполнить:

ldconfig

Проверяем, что загрузчик видит нашу библиотеку:

ldconfig -v |grep jli
/usr/local/lib64/jdk1.8.0_77/lib/amd64/jli:
libjli.so -> libjli.so

Ну и на всякий случай, команда для удаления всех дополнительных возможностей у программы:

setcap -r /usr/local/lib64/jdk1.8.0_77/bin/java

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

Где отрыто

Как приструнить Wireshark
Небаг в багтрекере Java
Куришка: man capabilities

Установка Java Development Kit в Linux из архива tar.gz

2016-03-28T09:09:00.000+03:00

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

Если вам потребовался стандартный JDK от Oracle, вместо OpenJDK, который поставляется с современными свободными дистрибутивами Linux, то его можно скачать либо с дополнительных сторонних репозиториев для вашего дистрибутива, либо напрямую с сайта www.oracle.com. Если ставить Java из репозиториев для вашего дистрибутива, то скорее всего всё само настроется и заработает, и ни о чем беспокоится вам не придется, но если вы скачали JDK или JRE в виде архива tar.gz с сайта Oracle, придется совершить несколько дополнительных телодвижений.

На данный момент скачать JDK с сайта Oracle можно в двух видах: это RPM-пакет и вышеупомянутый архив tar.gz. Про то, на сколько удачно ставится JDK из RPM-пакета, мне сказать нечего - не пробовал. Я предпочитаю устанавливать JDK именно из архива, потому что так я получаю полное управление и понимание того, что и откуда у меня будет запускаться, а также универсальное решение, которое подойдет для всех дистрибутивов, а не только для RPM-based.

План действий

Скачать нужную версию JDK (архив tar.gz)
Распаковать архив
Настроить переменные окружения
Настроить update-alternatives

Куда распаковать?

Итак, скачали JDK. Распаковываем. Но куда? Вроде бы тупой вопрос, но я далеко не сразу пришёл к правильному для себя решению. Сейчас я все JDK распаковываю в каталог /usr/local/lib64 и там у меня одновременно живёт несколько версий JDK. Например, на данный момент, там у меня есть каталоги jdk1.7.0_79 и jdk1.8.0_77. В дополнение к этим каталогам, в /usr/local/lib64 у меня находится симлинк с именем jdk, который сегодня чаще всего указывает на каталог jdk1.8.0_77. К такой конфигурации я пришел, когда потребовалось периодически переключаться между различными версиями JDK, причем переключаться нужно было глобально во всей системе. Каким образом такая конфигурация помогает переключаться между версиями, станет понятно ниже.

Переменные окружения

Простой распаковки файлов JDK недостаточно для того, чтобы можно было нормально использовать установленный JDK по умолчанию в системе. Следующим шагом необходимо настроить переменные окружения. Для настройки глобальных переменных окружения в Linux используются специальные конфигурационные файлы, обычно это /etc/profile (в OpenSUSE предпочтительнее /etc/profile.local ).

Ниже приведен пример настройки моих переменных окружения для JDK:

JAVA_HOME=/usr/local/lib64/jdk
JRE_HOME=$JAVA_HOME/jre
PATH=$JAVA_HOME/bin:$PATH
export JAVA_HOME JRE_HOME PATH

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

Примечания:

В некоторых особых случая, возможно, понадобится добавить эти же строки в файл /etc/bashrc (в SUSE /etc/bash.bashrc.local), который читается bash'ем, если он запущен без параметра --login
В дистрибутивах SUSE для установки глобальных переменных окружения по умолчанию следует использовать файлы /etc/profile.local и /etc/bash.bashrc.local, потому что после апгрейда системы, файлы /etc/profile и /etc/bash.bashrc могут быть перезаписаны. Если таких файлов нет, то необходимо их создать. Также, вместо использования файла /etc/profile.local, в каталоге /etc/profile.d можно создать отдельный bash-скрипт, с командами для настройки окружения JDK. В этом случае, при создании скрипта, важно не пересечься с именами скриптов, которые могут быть созданы системой в этом же каталоге в будущем при установке каких-либо пакетов.
Я не знаю аналога /etc/profile.local в дистрибутивах Ubuntu, поэтому могу порекомендовать использовать каталог /etc/profile.d.
Переменная JRE_HOME может быть и не особо нужна, но я часто встречаю её в современных дистрибутивах, поэтому на всякий случай можно её установить - вдруг она понадобится какой-нибудь странной программе :)

После изменения файла /etc/profile (или других подобных файлов, см. примечания выше), необходимо перезайти в систему. В консоле можно проверить правильно ли установлены значения переменных:

$ set |grep  JAVA_HOME

JAVA_HOME=/usr/local/lib64/jdk

$  set |grep ^PATH

PATH=/usr/local/lib64/jdk/bin:/usr/local/bin:/usr/bin:/bin:/usr/bin/X11

Теперь проверяем версию Java:

$ java  -version

java  version "1.8.0_77"

В принципе это всё и уже по умолчанию в системе будет использоваться Oracle JDK вместо OpenJDK. Но в современных дистрибутивах лучше выполнить ещё одну настройку, о которой написано ниже.

Настройка update-alternatives

На самом деле, переменную PATH можно было и не менять. Сегодня в дистрибутивах Linux установка среды выполнения Java по умолчанию осуществляется с помощью утилиты update-alternatives. Кратко опишу принцип её работы на моем примере с java.

В каталоге альтернатив /etc/alternatives есть символическая ссылка java, которая указывает на настоящий файл java, расположенный где-то в файловой системе. В каталоге /usr/bin есть символическая ссылка, которая указывает на ссылку /etc/alternatives/java. Таким образом, для всех пользователей и программ, которые вызывают java на самом деле доступна ссылка /usr/bin/java которая ссылается на реальную программу java через ссылку /etc/alternatives/java. Утилита update-alternatives служит для переключения символической ссылки /etc/alternatives/java на различные версии java, установленные в системе, а все пользователи либо программы как использовали ссылку /usr/bin/java для вызова java, так и будут продолжать её использовать.

Посмотрим, какие установленные версии java доступны для /etc/alternatives/java в моем случае c помощью параметра --list, для этого программе update-alternatives также необходимо указать имя ссылки в каталоге /etc/alternatives:

# update-alternatives --list java

/usr/lib64/jvm/jre-1.7.0-openjdk/bin/java

/usr/lib64/jvm/jre-1.8.0-openjdk/bin/java

Используя параметр --config можно посмотреть доступные альтернативы для java, а потом выбрать нужную в интерактивном режиме:

# update-alternatives --config java

There are 2 choices for the alternative java (providing /usr/bin/java).

  Selection    Path                                       Priority   Status

------------------------------------------------------------

* 0            /usr/lib64/jvm/jre-1.8.0-openjdk/bin/java   1805      auto mode

  1            /usr/lib64/jvm/jre-1.7.0-openjdk/bin/java   1705      manual mode

  2            /usr/lib64/jvm/jre-1.8.0-openjdk/bin/java   1805      manual mode

Press enter to keep the current choice[*], or type selection number:

Приведу теперь простую и понятную схему ссылок, которая используется на данный момент в моей системе:

/usr/bin/java -> /etc/alternatives/java -> /usr/lib64/jvm/jre-1.8.0-openjdk/bin/java

Итак, как стало ясно, в моем случае доступно две альтернативы для java, это OpenJDK 1.7 и OpenJDK 1.8, и сейчас update-alternatives настроены на использование OpenJDK 1.8. Для того, чтобы добавить альтернативную версию java, необходимо использовать параметр --install и указать следующее:

Главную ссылку, которая будет ссылаться на символическую ссылку в /etc/alternatives (для моего случая это /bin/usr/java)
Имя ссылки в каталоге /etc/alternatives (в данном случае java)
Альтернативу для этой ссылки, т.е. местоположение самой программы ( /usr/local/lib64/jdk/bin/java)
Приоритет для этой альтернативы. Приоритет необходим для автоматического выбора альтернативы при включении automatic mode (будет выбрана альтернатива с наибольшим приоритетом).

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

# update-alternatives --install /usr/bin/java java /usr/local/lib64/jdk/bin/java 10000

update-alternatives: using /usr/local/lib64/jdk/bin/java to provide /usr/bin/java (java) in auto mode

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

Посмотрим, что доступно теперь:

# update-alternatives --list  java/usr/lib64/jvm/jre-1.7.0-openjdk/bin/java

/usr/lib64/jvm/jre-1.8.0-openjdk/bin/java

/usr/local/lib64/jdk/bin/java

После установки новой альтернативы видим, что в списке появилась альтернатива /usr/local/lib64/jdk/bin/java.

Теперь, если нам необходимо переключиться на какую-либо из доступных альтернатив, можно использовать параметр --config:

#  update-alternatives --config java

There are 3 choices for the alternative java (providing /usr/bin/java).

Selection    Path                                       Priority   Status
------------------------------------------------------------
* 0            /usr/local/lib64/jdk/bin/java               10000     auto mode
1            /usr/lib64/jvm/jre-1.7.0-openjdk/bin/java   1705      manual mode
2            /usr/lib64/jvm/jre-1.8.0-openjdk/bin/java   1805      manual mode
3            /usr/local/lib64/jdk/bin/java               10000     manual mode

Press enter to keep the current choice[*], or type selection number: 1
update-alternatives: using /usr/lib64/jvm/jre-1.7.0-openjdk/bin/java to provide /usr/bin/java (java) in manual mode

Ручное переключение на альтернативу отключило automatic mode. Теперь при добавлении еще одной версии java в альтернативы автоматического переключения не произойдет. Для включения automatic mode снова, нужно ввести 0 при использовании --config java.

Примечания:

Важно понимать, что с помощью update-alternatives настраивается только ссылка на исполняемый файл java, а переменная окружения JAVA_HOME остаётся неизменной. Т. к. многим программам может потребоваться корректно установленная переменная JAVA_HOME, то для интеграции Oracle JDK в систему, необходимо использовать комплексный подход, заключающийся в настройках переменных окружения и update-alternatives.
Да, update-alternatives можно использовать и для настройки альтернатив каталога с jdk, вместо приведенного в статье варианта ручного управления симлинком /usr/local/lib64/jdk, но по-моему, при добавлении новой версии jdk, гораздо проще поменять руками собственный симлинк, чем запоминать параметры команды update-alternatives для установки новой альтернативы.
При использовании --config, символ "*" показывает какая альтернатива сейчас используется.
Если вы руками измените значение ссылок /etc/alternatives/java или /usr/bin/java, то скорее всего при перезагрузке эти значения вернутся в состояние которое описано утилитой update-alternatives.
Каталог альтернатив /etc/alternatives является каталогом по умолчанию и может быть изменен командой update-alternatives --altdir.
Утилиту update-alternatives можно использовать также для создания своих собственных групп альтернатив.

После настройки update-alternatives можно удалить строку в файле /etc/profile, которая добавляет в переменную окружения PATH путь к директории $JAVA_HOME/bin, если, конечно, вам не нужны в глобальном пространстве другие программы из этого каталога (вроде javac и jvisualvm), и перезайти в систему. После этого вы будете использовать java из Oracle JDK по привычной ссылке /usr/bin/java.

USB redirection error в Spicy на openSUSE

2016-02-13T10:58:00.000+03:00

Столкнулся в openSUSE с тем, что в gtk-клиенте для spice не работает проброс USB-устройств внутрь гостевой системы. После выбора устройства для проброса появляется окно с просьбой ввести пароль суперпользователя. Вводим пароль, жмём OK и получаем сообщение вроде этого:

Could not redirect Kingston DataTraveler 3.0 [0951:1666] at 2-13: Error setting USB device node ACL: 'Error setting facl: Operation not permitted'

Оказывается, что в пакете spice-gtk вместе с клиентом spicy есть еще такая программка с длинным названием spice-client-glib-usb-acl-helper. При подключении USB-устройства через spicy эта программа, по всей видимости, проверяет и назначает файлу этого устройства дополнительные права через ACL. Проблема в том, что для этого не помешало бы быть root'ом, но не смотря на запрос пароля суперпользователя, spice-client-glib-usb-acl-helper выполняется с правами обычного пользователя из-под которого запущен spicy. Короче, где-то недокостылили. Самым простым решением этой проблемы является установка бита setuid на файл spice-client-glib-usb-acl-helper:

chmod u+s /usr/bin/spice-client-glib-usb-acl-helper

После этого действия USB-устройства начинают успешно пробрасываться.

Для удобства теперь можно также отключить запрос пароля суперпользователя. Делается это через polkit. В файле /usr/share/polkit-1/actions/org.spice-space.lowlevelusbaccess.policy надо отредактировать содержимое элемента defaults следующим образом:

Skype 4.3 без PulseAudio

2015-08-22T16:08:00.000+03:00

Как известно, Microsoft безжалостно выпилила поддержку ALSA из Skype 4.3. А я, в свою очередь, недавно пару вечеров старательно выпиливал этот PulseAudio из openSUSE 13.2, после того, как никакими молотками и "волшебными" русскими словами не смог заставить этот самый PulseAudio видеть порт line-in на старой карте видео-захвата. Кроме того, я попытался снять звук обычной звуковой картой и получил на записи великолепный белый шум, хотя ожидал услышать немного другое.

После "лечения" системы от PulseAudio осталась только одна проблема - неработающий Skype. В интернетах сразу нашел совет использовать эмулятор PulseAudio для ALSA - apulse. Нормальный такой рабочий костыль. Один из вариантов настройки apulse заключается в создании файла ~/.asoundrc. У меня он, например, такого содержания:

pcm.!default {
  type asym
    playback.pcm {
      type plug
      slave.pcm "hw:1,0"
    }
    capture.pcm {
      type plug
      slave.pcm "hw:3,0"
    }
}

Где "hw:1,0" и "hw:3,0" это ALSA-идентификаторы устройств воспроизведения и захвата звука, соответственно. Но такой подход оказался не очень удобным, потому что в компьютере у меня одновременно было 2 устройства воспроизведения и 3 устройства захвата звука. И если ID основного устройства для вывода звука оказывался всегда "hw:1,0", то нужное устройство захвата периодически оказывалось то с ID "hw:3,0", то "hw:2,0". Ну и, понятное дело, чтобы Skype начал получать звук с правильного устройства, надо было поменять его ID в файле .asoundrc и после этого перезапустить Skype через apulse:

apulse skype

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

Он основывается на том, что указать устройства для apulse можно с помощью установленных переменных окружения APULSE_PLAYBACK_DEVICE и APULSE_CAPTURE_DEVICE. А с помощью программ aplay и arecord можно легко выдернуть циферки, которые присвоены вашим звуковым устройствам.

Например, вот мой вывод команды aplay -l:

**** List of PLAYBACK Hardware Devices ****
card 0: HDMI [HDA Intel HDMI], device 3: HDMI 0 [HDMI 0]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: HDMI [HDA Intel HDMI], device 7: HDMI 1 [HDMI 1]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: HDMI [HDA Intel HDMI], device 8: HDMI 2 [HDMI 2]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 1: PCH [HDA Intel PCH], device 0: ALC1150 Analog [ALC1150 Analog]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 1: PCH [HDA Intel PCH], device 1: ALC1150 Digital [ALC1150 Digital]
  Subdevices: 1/1
  Subdevice #0: subdevice #0

Интересующее меня устройство вывода называется ALC1150 Analog. Команда play -l говорит что ему присвоены идентификаторы card 1 и device 0. Из этих сочетаний в моем случае надо сформировать имя "hw:1,0". В других дистрибутивах имя может строиться немного по-другому, например, "plughw:1,0".

Таким образом, всё что надо сделать это выдернуть циферки, назначенные устройствам воспроизведения и захвата, сформировать для них валидные ALSA-идентификаторы и записать их в соответствующие переменные окружения. Автоматизировать эту процедуру можно добавлением следующих строчек в ваш файл ~/.profile, который будет выполнятся при каждом входе в систему под вашим именем:

PLAY_DEV_NAME="ALC1150 Analog"
REC_DEV_NAME="U0x46d0x804"

PLAY_CARD=`aplay -l |grep "$PLAY_DEV_NAME" | grep -E -o "card +[0-9]+"`
PLAY_DEV=`aplay -l |grep "$PLAY_DEV_NAME" | grep -E -o "device +[0-9]+"`
APULSE_PLAYBACK_DEVICE="hw:${PLAY_CARD##card },${PLAY_DEV##device }"

REC_CARD=`arecord -l |grep "$REC_DEV_NAME" | grep -E -o "card +[0-9]+"`
REC_DEV=`arecord -l |grep "$REC_DEV_NAME" | grep -E -o "device +[0-9]+"`
APULSE_CAPTURE_DEVICE="hw:${REC_CARD##card },${REC_DEV##device }"

export APULSE_PLAYBACK_DEVICE APULSE_CAPTURE_DEVICE

Только нужно поменять значения переменных PLAY_DEV_NAME и REC_DEV_NAME на имена ваших устройств.

Eclipse Mars, GTK+ 3, Adwaita и маленький CSS-напильник

2015-06-29T05:03:00.000+03:00

С переходом на новый Eclipse Mars, я решил кое-что ещё поменять в своей жизни. Хотя правильнее сказать, что сам Eclipse предложил мне эти изменения, а я не стал сопротивляться. Как известно, Eclipse Mars теперь по умолчанию использует GTK+ версии 3. Для второй версии GTK+ у меня уже много лет стоит тема oxygen-gtk. Страшненькая, да... но уже привычная. Поэтому как-то даже мысли не возникало попробовать поменять её. А тут оказалось, что для GTK+ 3 у меня вообще эта тема не стоит, и используется тема по умолчанию, которая называется Adwaita. И что-то я так поглядел на неё, и в принципе мой глаз посчитал её чуть менее страшной и чуть более секси, чем oxygen-gtk. Осталось только решить несколько бросившихся сразу в глаза проблем.

Проблемы

Проблема 1. Какое-то неадекватно большое значение padding у большинства GUI-элементов.

Проблема 2. Странный tooltip для javadoc с белым шрифтом на чёрном фоне.

Проблема 3. Смазанные шрифты после скролинга некоторых окон (Project Explorer, Package Explorer, Outline). Особенно ярко проблема проявляется, если скролить колесом мыши.

Решение

В GTK+ 3 для описания тем больше не используются rc-файлы собственного формата. Теперь для стилизации применяются более понятные CSS-подобные файлы.

Проблемы 1 и 2 решаются созданием файла ~/.config/gtk-3.0/gtk.css со следующим содержанием:

* {
    padding: 1px;
}

GtkToolbar {
    padding: 2px;
}

GtkMenuBar {
    padding: 2px;
}

GtkMenuItem {
    padding: 2px 6px;
}

.tooltip {
    background-color: #CAE1FF;
    color: #333;
    text-shadow: none;
}

Кратко поясню. Сначала устанавливаем padding абсолютно для всех элементов равным 1px. Затем для элементов GtkToolbar, GtkMenuBar и GtkMenuItem делаем отступы чуть более разумными. CSS-класс tooltip вероятно прописан где-то в коде и назначен, как для всплывающего окна javadoc, так и для хинтов различных графических элементов. Свойство text-shadow необходимо, чтобы ликвидировать тень текста хинта, которая становится заметной и неуместной после изменения его фона и цвета текста:

Обратите внимание, что файл ~/.config/gtk-3.0/gtk.css будет действовать и переопределять стили для любой темы GTK+ 3, выбранной пользователем, у которого в домашнем каталоге есть этот файл, а не только для темы Adwaita.

Проблему 3 я решил довольно тупо, сняв флажок с Use mixed fonts and colors for labels в настройках внешнего вида (Window / Preferences / General / Appearance). Мне легче смириться с одноцветным черным лейблом, чем с таким поломанным шрифтом.

Тут я вынужден обновить сообщение и добавить, что после решения проблемы 3 появилась проблема 4 :) которая выглядет, как практически нечитаемый выбранный пункт во всплывающем окне автодополнения.

Эта неприятность также фиксится добавлением некоторых строчек в gtk.css:

GtkTreeView:selected {
    color: #FFF;
    background-color: #4A90D9;
}

Результаты

Ссылки

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

Когда терпение кончилось

Спустя некоторое время, должен признать, что это далеко не все глюки с UI, которые мне повстречались при использовании GTK+ 3 в Eclipse. И у меня больше нет сил подкручивать эти гайки. Я устал, я ухожу. Теперь перед запуском Eclipse у меня выполняется export SWT_GTK3=0, что заставляет Eclipse использовать GTK+ 2 по старинке.

Перенос существующей базы данных Redmine с SQLite на PostgreSQL

2015-06-10T06:59:00.002+03:00

Разглагольствовать не буду. Скажу лишь, что попробовал несколько различных способов, кроме ручного исправления дампа SQLite, ибо лень. Самым простым и жизнеспособным оказался метод с использованием программы Taps. Эта чудо-ruby-штука поднимает http-сервер с подключением к базе данных А и позволяет с помощью клиента выполнять обмен данными между этой базой А и какой-либо базой Б, даже если они управляются различными СУБД. Конечно, её возможности не безграничны, но для миграции базы данных Redmine их хватило.

Все ниже описанные действия выполнялись на openSUSE 13.2.

Кратко и по сути

1. Установить через RubyGems программу Taps:

gem install taps

2. Подготовить базу данных PostgreSQL для Redmine:

createuser -U postgres redmine
psql -U postgres
postgres=# ALTER USER redmine WITH PASSWORD 'redmine_password';
postgres=#\q
createdb -U postgres -O redmine redmine

3. Запустить сервер Taps с подключением к новой созданной в PostgreSQL базе для Redmine:

taps.ruby2.1 server postgres://redmine:redmine_password@localhost/redmine taps taps_password

4. Используя клиент Taps, запушить все данные из исходной базы SQLite в PostgreSQL:

taps.ruby2.1 push sqlite:///usr/local/redmine/db/redmine.db.sqlite3 http://taps:taps_password@localhost:5000

5. Не забыть изменить настройки подключения к БД в Redmine (redmine/config/database.yml):

production:
  adapter: postgresql
  database: redmine
  host: localhost
  username: redmine
  password: "redmine_password"

5. Перезапустить Redmine

Грабли

При запуске сервер валится приблизительно с такой портянкой:

/usr/lib/ruby/gems/2.1.0/gems/sinatra-1.0/lib/sinatra/base.rb:298:in `': uninitialized constant Tilt::CompileSite (NameError)
        from /usr/lib/ruby/gems/2.1.0/gems/sinatra-1.0/lib/sinatra/base.rb:297:in `'
        from /usr/lib/ruby/gems/2.1.0/gems/sinatra-1.0/lib/sinatra/base.rb:21:in `'
        from /usr/lib/ruby/2.1.0/rubygems/core_ext/kernel_require.rb:73:in `require'
        from /usr/lib/ruby/2.1.0/rubygems/core_ext/kernel_require.rb:73:in `require'
        from /usr/lib/ruby/gems/2.1.0/gems/taps-0.3.24/lib/taps/server.rb:1:in `'
        from /usr/lib/ruby/2.1.0/rubygems/core_ext/kernel_require.rb:73:in `require'
        from /usr/lib/ruby/2.1.0/rubygems/core_ext/kernel_require.rb:73:in `require'
        from /usr/lib/ruby/gems/2.1.0/gems/taps-0.3.24/lib/taps/cli.rb:61:in `server'
        from /usr/lib/ruby/gems/2.1.0/gems/taps-0.3.24/lib/taps/cli.rb:27:in `run'
        from /usr/lib/ruby/gems/2.1.0/gems/taps-0.3.24/bin/taps:6:in `'
        from /usr/bin/taps.ruby2.1:23:in `load'
        from /usr/bin/taps.ruby2.1:23:in `'

В этом случае необходимо проверить какие версии библиотеки Tilt у вас установлены:

zypper se -s tilt

Если среди установленных есть Tilt версии 2, то необходимо её снести и поставить 1.4. Как правило, zypper сам ставит версию 1.4 вместо удалённой 2.

Ещё

Уже после публикации этой статьи, я наткнулся ещё на одну чудо-ruby-штуку под названием YamlDb. Жалко, что она сразу мне не попалась, меньше бы времени потратил. И на Хабре давно уже есть статейка.

Автоматический запуск скриптов при подключении NetworkManager

2014-10-11T14:23:00.000+04:00

Я очень долго отказывался от использования NetworkManager (далее NM) и жил с традиционным и понятным ifup. Но теперь, пожалуй, пришло время приобщиться к цивилизации. Тем более, что NM стал уже не такой сурово глючный, как раньше, да и что там говорить, удобно на ноутбуке перещёлкиваться между проводом, WiFi и GSM-модемом.

Единственной преградой на пути к благам цивилизации для меня было то, что мне приходится использовать программу VTun для создания туннеля между домом и работой, через который я также хожу в глобальную сеть, а NM не поддерживает VTun из коробки. Конечно, всегда можно наваять пару скриптов, которые будут периодически смотреть поднятые интерфейсы, пинговать различные ip-адреса и заниматься прочими делами, чтобы понять в каком состоянии находится сеть. Но, как оказалось, можно решить эту задачу и более красивым способом с помощью NetworkManager Dispatcher Service. В systemd он обычно имеет имя NetworkManager-dispatcher.service.

NetworkManager Dispatcher Service это сервис, который при изменении состояния NM, дёргает скрипты из каталога /etc/NetworkManager/dispatcher.d и передает в них в качестве параметров командной строки имя сетевого интерфейса, у которого изменилось состояние, и новое значение этого самого состояния - up или down (vpn-up и vpn-down для VPN-соединений).

Типичный шаблон скрипта в каталоге /etc/NetworkManager/dispatcher.d может выглядеть, например, так:

#!/bin/bash

IF=$1      # имя сетевого интерфейса, с которым связано событие
STATUS=$2  # новое состояние сетевого интерфейса

if [ $IF = "eth0" ]; then
  case $STATUS in
    up)
      # команды выполняемые после установления соединения
      ;;
    down)
      # команды выполняемые после разрыва соединения
      ;;
  esac
fi

Для того, чтобы Dispatcher Service смог запустить ваш скрипт, ему должен быть назначен владелец root и у него должно быть право на выполнение этого скрипта.

Дома я хожу в интернет через роутер, который умеет раздавать этот самый интернет по проводам и по WiFi. Мне хотелось, чтобы у меня в NM было два соединения. Первое соединение обычное, которое выполняет подключение к роутеру и получает от него IP по DHCP, после чего у меня появляется доступ в интернет через провайдера. Второе соединение делает изначально всё тоже самое что и первое, но после подключения к роутеру осуществляет ещё запуск программы VTun для установки туннеля и добавляет несколько статических маршрутов, которые должны направлять пакеты на локальные адреса моего провайдера через реальный интерфейс, а не через туннель. Туннель используется как для доступа к машинам на работе, так и для хождения в интернет через рабочий канал.

Т. к. я хочу иметь два соединения в NM, повешанных на один сетевой интерфейс, и при запуске только одного из этих соединений должен также подниматься туннель, то скрипту необходимо знать имя активного соединения. Активные соединения можно посмотреть командой nmcli c show --active. Эта команда выводит список всех активных соединений в виде таблицы. Но мне нужно проверить активно ли одно конкретное соединение с указанным именем. Это можно сделать, передав выше указанной команде идентификатор интересующего меня соединения: nmcli c show --active id ID_СОЕДИНЕНИЯ. После выполнения этой команды для активного соединения будет выведено множество строк с различными параметрами этого соединения, а если выполнить эту команду для неактивного соединения, то вывод будет пустой. Я, честно говоря, не понял чем отличаются и отличаются ли вообще понятия ID соединения и NAME соединения в NetworkManager, но по моим наблюдениям они всегда совпадают.

Основываясь на вышесказанном, мой скрипт получился таким:

#!/bin/bash

IF=$1
STATUS=$2

VTUND_SCRIPT=/usr/local/etc/vtun/vtund.sh

REQUIRED_IF="eth0"
REQUIRED_CON="vtun"

if [ $IF = $REQUIRED_IF ]; then
  case $STATUS in
    up)
      # посчитать количество строк - если соединение неактивно, то их кол-во = 0
      (( `nmcli c show --active id $REQUIRED_CON | wc -l`  > 0 )) && VTUN_CONNECTION=true || VTUN_CONNECTION=false

      if [ $VTUN_CONNECTION = true ]; then
        $VTUND_SCRIPT &
      fi
      ;;
    down)
        killall vtund.sh
        killall vtund
      ;;
  esac
fi

В скрипте, при поднятии соединения на интерфейсе eth0, сначала проверяем не является ли активным соединение с именем vtun, которое я назначил в настройках NM соединению, отвечающему за поднятие туннеля, и привязал его явно к интерфейсу eth0:

Если на интерфейсе eth0 поднялось соединение с именем vtun, значит можно запускать скрипт для установки туннеля: "$VTUND_SCRIPT" &. Обратите внимание, что для вызова скрипта, запускающего программу vtun, я использую амперсанд, чтобы этот скрипт выполнялся в фоновом режиме. Это очень важный момент, потому что у Dispatcher Service есть таймаут для выполнения каждого скрипта из каталога /etc/NetworkManager/dispatcher.d и если какой-либо скрипт не успевает выполниться за время таймаута, Dispatcher Service просто грохает его. Ещё я заметил, что в некоторых дистрибутивах скрипты Dispatcher Service запускаются с очень бедным окружением, поэтому возможно придется прописывать полные пути до каких-либо программ, используемых в этих скриптах. Но в принципе, это нормально и вообще является правилом хорошего тона для подобных автоматически запускаемых скриптов. При опускании интерфейса eth0 убиваются скрипт vtund.sh и сам демон vtund.

Вот в принципе и всё о чем хотелось написать. Ещё немного почитать о Dispatcher Service можно здесь. Там есть пара примеров и более подробная информация о таймауте.

Баг с shortcut'ами в qt4

2014-04-04T13:43:00.000+04:00

Вдруг странным образом перестали работать сочетания клавиш в qt-программах. Например Ctrl+C, Ctrl+V, Ctrl+X в Dolphin или Ctrl+Alt+T в Yakuake. Скорее всего, к этому списку относятся все сочетания с участием Ctrl и Alt. Оказалось, что ковыряясь в настройках раскладки KDE после сноса бесполезного ibus, я переместил русский язык на первое место, тем самым сделав его раскладкой по умолчанию. Возвращение US-раскладки в зад, т.е. на первую строчку, всё чинит. Такая вот багулька.

Выбор года и месяца в GWT DatePicker с помощью ListBox

2013-10-29T14:01:00.001+04:00

Стандартный DatePicker в GWT очень неудобный. Для выбора нужного года и месяца пользователь вынужден кликать по соответствующим стрелочкам и перемещаться на один месяц вперед или на зад. Например, если пользователю необходимо выбрать свою дату рождения, скажем, 29 февраля 1980 года, а в календаре по умолчанию установлена текущая дата 25 октября 2013 года, то представьте сколько раз нужно будет кликнуть бедняге по стрелочке, чтобы добраться до дня своего рождения!

Стандартный DatePicker в GWT

Конечно, в качестве простого решения, можно просто дать пользователю возможность ввести дату самому в текстовое поле. И в общем-то нет, наверное, ничего плохого в таком решении. Но иногда просто хочется сделать немного более красиво. В этом смысле Datepicker из jQuery UI вполне себе красив и позволяет выбирать год и месяц с помощью выпадающих списков, что очень сокращает путь до необходимой даты.

jQuery Datepicker

На самом деле, такую же возможность очень несложно реализовать и в GWT DatePicker. Для этого нужно просто написать свою собственную реализацию абстрактного класса MonthSelector, который представляет из себя визуальный компонент, отвечающий за установку текущего года и месяца в DatePicker.

Немного теории

MonthSelector расширяет класс DatePickerComponent, у которого, в свою очередь, есть метод getModel(), возвращающий экземпляр класса CalendarModel. Как вы уже поняли, экземпляр CalendarModel является моделью календаря DatePicker'а и, получив его в своё распоряжение, мы получаем возможность управлять этим календарём. Пожалуй, самое интересное в модели для нас это методы setCurrentMonth и getCurrentMonth, которые позволяют установить текущий отображаемый месяц календаря и получить его, соответственно. Это в общем-то основное знание, которое необходимо для создания собственного MonthSelector, но есть ещё одна тонкость. Установить свой собственный MonthSelector в DatePicker можно только через protected-конструктор DatePicker'а. Поэтому нужно ещё расширить класс DatePicker и в своей реализации календаря установить свой свежеприготовленный MonthSelector, воспользовавшись этим защищённым конструктором. В данном конструкторе, кроме сохранения ссылки на экземпляр MonthSelector, происходит так же вызов метода monthSelector.setDatePicker(this), т. е. в наш новый MonthSelector передаётся ссылка на использующий его экземпляр DatePicker. Именно поэтому внутри нашего MonthSelector мы имеем доступ к модели DatePicker'а.

Ещё немного теории

Как было сказано выше, всё что нужно для управления содержимым DatePicker'а, это получить доступ к его модели CalendarModel. Теперь разберёмся, что нужно для того, чтобы DatePicker смог отобразить наш MonthSelector внутри себя. А нужно для этого совсем немного – состряпать визуальный компонент, представляющий MonthSelector, из каких-либо потомков класса Widget и передать его в унаследованный от класса Composite метод initWidget(Widget widget). Например, для нашего варианта MonthSelector будет состоять из двух ListBox'ов и контейнера для них – экземпляра класса Grid.

Практика

Итак, расширяем стандартный класс DatePicker и добавляем в него новые методы для настройки поведения. Предлагаю добавить два новых метода setFloatingYearsRange и setFixedYearsRange. Первый метод будет устанавливать плавающий диапазон годов, а второй фиксированный. Плавающий диапазон будет отличаться от фиксированного тем, что при выборе нового, года список будет перестраиваться заново, таким образом, что пользователь сможет выбрать любой год, но при этом, количество годов в выпадающем списке будет постоянным. Если мысль моя изложена не слишком ясно, проще посмотреть аналогичное поведение Datepicker из jQuery UI.

public class ListBoxDatePicker extends DatePicker {
     
    /**
    * Sets the floating range of years
    * 
    * @param negativeShift - shift to the left relative to 
    *                        the selected year; must be < 0.
    * @param positiveShift - shift to the right relative to 
    *                        the selected year; must be > 0.
    */
    public void setFloatingYearsRange(int negativeShift, int positiveShift) {}
        
    /**
    * Sets the fixed range of years
    * 
    * @param first - value of the first year in the list; 
    *                must be > 0 and <= last.
    * @param last  - value of the last year in the list; 
    *                must be > 0 and >= first.
    */
    public void setFixedYearsRange(int first, int last) {}

}

В качестве параметров метод setFloatingYearsRange принимает отрицательное и положительное смещения относительно выбранного года. Если методу передать параметры -3 и 5, то при выборе 2013 года, список будет содержать года от 2010 до 2018 включительно, а при изменении года на 2010 список будет перестроен и будет содержать уже года с 2007 по 2015.

В качестве параметров метод setFixedYearsRange принимает первый и последний год списка.

С классом ListBoxDatePicker пока всё и в будущем он станет не намного сложнее, т. к. весь основной код будет в классе, который расширяет MonthSelector. Вот он с полями, которые нам понадобятся.

public class ListBoxMonthSelector extends MonthSelector {

    private static enum YearsRangeType {Fixed, Floating};
    // current type of the years range
    private YearsRangeType yearsRangeType;

    private static final DateTimeFormat monthFormat = 
                             DateTimeFormat.getFormat("yyyy-MMM");
    private static final DateTimeFormat yearFormat = 
                             DateTimeFormat.getFormat("yyyy");

    private String[] monthNames; // list of month names
    private String[] years;      // list of years available for selection

    private final ListBox yearsBox = new ListBox(false);
    private final ListBox monthsBox = new ListBox(false);

    // current shifts for floating range
    private int negativeYearShift = -1, positiveYearShift = -1;

    private Grid grid;      
}

Кратко о полях

Т. к. наличие двух методов настройки нового DatePicker'а предполагают различное поведение (фиксированный диапазон годов и плавающий), то надо иметь признак для понимания того, на какое поведение в данный момент настроен календарь. При двух вариантах можно использовать переменную boolean, но мне более по душе enum, т.к. если завтра появится новый вариант поведения, его признак будет проще добавить. Итак, enum YearsRangeType {Fixed, Floating} служит для определения поведения календаря, а поле yearsRangeType хранит текущее поведение.

Поля класса monthFormat и yearFormat будут использоваться для форматирования значений списков годов и месяцев в строку и обратно.

Массивы строк monthNames и years, будут хранить значения месяцев и годов, на основе которых будут строиться выпадающие списки.

Экземпляры ListBox yearsBox и monthsBox это те выпадающие списки, которые будут отображаться в верхней части DatePicker'а для выбора года и месяца.

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

Поле grid это именно тот компонент, который будет отображаться в качестве MonthSelector в новом DatePicker'е. Он будет содержать в себе компоненты yearsBox и monthsBox.

Основные методы

Начнём сразу с самого главного метода в нашем новом MonthSelector'е.

protected void setYearsRange(int first, int last, YearsRangeType type){
    yearsRangeType = type;
    
    switch (type) {
    
    case Fixed:
        
        this.negativeYearShift = -1;
        this.positiveYearShift = -1;
        
        buildYears(first, last);

        break;
        
    case Floating:
        // various signs for left and right shifts 
        // are needed for additional verification
        if (first >= 0) throw 
            new IllegalArgumentException("First year shift value must be < 0");
        if (last <= 0) throw 
            new IllegalArgumentException("Last year shift value must be > 0");
        
        this.negativeYearShift = Math.abs(first);
        this.positiveYearShift = last;

        int currentYear = Integer.parseInt(getCurrentModelYear());
        buildYearsByShifts(currentYear, negativeYearShift, positiveYearShift);

        break;
    }

    updateYearsBox();
    setModelByListBoxes();
}

Этот метод осуществляет настройку ListBoxMonthSelector - устанавливает диапазон доступных для выбора годов в выпадающем списке и определяет поведение этого списка (фиксированный или плавающий). Именно этот метод будет вызываться ListBoxDatePicker'ом в методах setFloatingYearsRange и setFixedYearsRange. Заметьте, что первые два параметра зависят от третьего. Т. е. для YearsRangeType.Fixed данные параметры являются первым и последним годами в списке, а для Floating левым и правым смещением относительно базового года, соответственно. Вообще говоря, это плохая затея делать такое "два в одном", но т. к. метод setYearsRange мы закрыли от клиентов модификатором protected, то можно немножко и согрешить :)

Внутри метода, в зависимости от полученного YearsRangeType, происходит генерация массива (методы buildYears и buildYearsByShifts), содержащего список годов, которые должны быть отражены в соответствующем ListBox'е. После этого, с помощью метода updateYearsBox происходит построение ListBox'а по сгенерированному массиву и установка значения модели по выбранным значениям в ListBox'ах (метод setModelByListBoxes).

Метод setModelByListBoxes очень прост. Берём значения года и месяца из ListBox'ов и с помощью DateTimeFormat создаём экземпляр Date, который используем для установки текущего отображаемого месяца нашего календаря. После изменения модели необходимо вызвать метод refreshAll, чтобы DatePicker перерисовал календарь в соответствии с новым значением модели.

private void setModelByListBoxes() {
    String year = yearsBox.getItemText(yearsBox.getSelectedIndex());
    String month = monthsBox.getItemText(monthsBox.getSelectedIndex());

    getModel().setCurrentMonth(
            monthFormat.parse(year + "-" + month));
    refreshAll();
}

Если пользователь выберет новое значение в каком-то из наших списков, то нужно будет просто вызвать этот метод для изменения текущего отображаемого месяца DatePicker'а. Но, кроме пользователя, значение текущего месяца календаря может изменить класс-клиент, т. к. из экземпляра DatePicker'а доступен публичный метод setCurrentMonth, который вызывает одноименный метод модели и обновляет все свои компоненты, в том числе и MonthSelectror. Поэтому в дополнение к методу установки текущего месяца по значениям выпадающих списков, нам также нужен обратный метод, который выбирает соответствующие значения в ListBox'ах, если значение текущего месяца модели календаря изменилось программно.

private void setListBoxesByModel() {

    String currentMonth = monthFormat.
                            format(getModel().getCurrentMonth());
    
    String[] yearAndMonth = currentMonth.split("-");

    boolean yearSetted = false;
    boolean monthSetted = false;
    
    for (int i = 0; i < yearsBox.getItemCount(); i++) {
        if (yearsBox.getItemText(i).equals(yearAndMonth[0])) {
            yearsBox.setSelectedIndex(i);
            yearSetted = true;
            break;
        }
    }

    for (int i = 0; i < monthsBox.getItemCount(); i++) {
        if (monthsBox.getItemText(i).equalsIgnoreCase(yearAndMonth[1])) {
            monthsBox.setSelectedIndex(i);
            monthSetted = true;
            break;
        }
    }

    if(!yearSetted || !monthSetted)
        throw new RuntimeException("Can't set month " + currentMonth + 
                                   " in " + getClass().getName());
}

Для сравнения названий месяцев используется equalsIgnoreCase, т. к. я заметил, что для русской локали DateTimeFormat возвращает короткие названия месяцев (формат "MMM") с маленькой буквы, а названия в массиве monthNames и, соответственно, в списке monthsBox начинаются с заглавной буквы. Такими их возвращает метод monthsShortStandalone из интерфейса DateTimeFormatInfo, который мы будем использовать ниже для инициализации списка месяцев. В детали этого метода я пока не вникал.

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

Как я уже писал выше, клиенты могут изменить месяц календаря через публичный метод DatePicker'а. В этом методе после изменения модели происходит обновление всех компонентов DatePicker'а. Поэтому, для того что бы установить соответствующие значения в списках при изменении модели, нам надо переопределить метод refresh нашего ListBoxMonthSelector и установить в нем новые значения в ListBox'ах. Именно этот метод будет вызываться DatePicker'ом после обновления модели.

@Override
protected void refresh() {
    setListBoxesByModel();
}

Итак, я описал основные рабочие методы из которых должно стать ясно, как работать с моделю календаря из MonthSelector. Остальные служебные методы вроде buildYears и buildYearsByShifts я описывать не буду, а просто приведу в конце статьи полный код с комментариями на моём корявом индокитайском диалекте английского языка :) Код хранится на гитхабе, поэтому я стараюсь там держать околоанглийские комментарии, вдруг кому пригодится.

Разберемся теперь как и самое главное когда инициализировать компоненты нашего нового MonthSelector. Для удобства восприятия разделим инициализацию на три этапа: инициализация списка годов, инициализация списка месяцев и инициализация всего компонента в целом.

Инициализация списка годов

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

private void initYearsBox() {
    yearsBox.setVisibleItemCount(1);
    yearsBox.addChangeHandler(new ChangeHandler() {
        @Override
        public void onChange(ChangeEvent event) {
            if(yearsRangeType == YearsRangeType.Floating) {
                buildYearsByShifts(Integer.parseInt(getSelectedYear()), 
                                   negativeYearShift, positiveYearShift);
                updateYearsBox();
            }
            setModelByListBoxes();
        }
    });
}

Инициализация списка месяцев

Сначала получаем локализованные короткие названия месяцев. Кстати, для русской локали названия слегка странные, на мой взгляд. Например, "Февр." или "Нояб." вместо привычных "Фев" и "Ноя" без точки. После заполнения массива названий месяцев, так же как и в предыдущем методе, устанавливаем один отображаемый элемент для списка месяцев и создаем обработчик для события изменения выбранного месяца и в нём только обновляем модель календаря.

private void initMonthsBox() {
    // localized short month names
    monthNames = LocaleInfo.getCurrentLocale().
                    getDateTimeFormatInfo().monthsShortStandalone();
    for (String month : monthNames) {
        monthsBox.addItem(month);
    }
    
    monthsBox.setVisibleItemCount(1);
    monthsBox.addChangeHandler(new ChangeHandler() {
        @Override
        public void onChange(ChangeEvent event) {
            setModelByListBoxes();
        }
    });
}

Инициализация MonthSelector

Как уже, отмечалось, основой для визуальной части MonthSelector у нас будет компонент Grid. Создаём его размером 1 на 2 и помещаем в него компоненты список годов и список месяцев. Добавляем на всякий случай уникальное имя класса стиля и передаём созданный компонент в метод initWidget. После выполнения initWidget, DatePicker сможет отобразить внутри себя наш новый MonthSelector.

private void initMonthSelector(){
    grid = new Grid(1, 2);
    grid.setWidget(0, 0, yearsBox);
    grid.setWidget(0, 1, monthsBox);
    grid.setStyleName("ListBoxMonthSelector");

    initWidget(grid);
}

Необходимые методы инициализации созданы. Когда же их теперь вызвать? В принципе, в нашем случае эти три метода можно вызвать в конструкторе ListBoxMonthSelector, но лучше всего воспользоваться переопределённым методом setup, который будет автоматически вызван при создании экземпляра DatePicker. Преимущество использования данного метода для инициализации компонента перед конструктором заключается в том, что в момент выполнения setup, вам уже доступен экземпляр DatePicker'а и, соответственно, его модель, которые могут пригодиться для инициализации. Кроме инициализации компонентов, нам ещё нужно определить настройки по умолчанию для ListBoxMonthSelector. Сделаем это с помощью метода setYearsRange. И вот этот метод уже не может быть использован в конструкторе, т.к. внутри него происходит обращение к модели календаря, которая в конструкторе нам ещё не доступна.

@Override
protected void setup() {
    initYearsBox();
    initMonthsBox();
    initMonthSelector(); 
    setYearsRange(-7, 7, YearsRangeType.Floating);
}

По большому счёту, все необходимые шаги для создания собственного MonthSelector я описал. Теперь приведу полный код ListBoxMonthSelector.

И теперь полный код ListBoxDatePicker.

Обратите внимание, что каждый метод установки диапазона годов в ListBoxDatePicker заканчивается вызовом метода refresh для DefaultCalendarView. Этим мы сигнализируем, что модель календаря изменилась и заставляем обновить его представление.

Пример использования ListBoxDatePicker:

// Fixed range of years
ListBoxDatePicker datePicker1 = new ListBoxDatePicker();
datePicker1.setFixedYearsRange(2005, 2015);

// Floating range of years
ListBoxDatePicker datePicker2 = new ListBoxDatePicker();
datePicker2.setFloatingYearsRange(-5, 5);

А вот что получилось

Созданный календарь является просто примером и не претендует на большую стабильность, поэтому без тщательной проверки и доработки пользоваться им для публичных проектов не рекомендую :)

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

Небезопасно посылаем e-mail из bash'a используя сторонний smtp

2013-10-02T06:29:00.000+04:00

Как известно, все настоящие админы лентяи, в хорошем смысле этого слова. По этой причине они стараются автоматизировать всё что можно и что нельзя. Одним из главных инструментов тотальной админоавтоматизации является ужасно прекрасный (или прекрасно ужасный) bash. Огромная куча поэтично сложенных bash-скриптов постоянно трудится без обеда, что бы админ мог изучить что-то новое или просто почитать Хабр :) Но бывает так, что случается беда и столкнувшийся с ней скрипт обязан призвать админа для спасения организации. Призывом админа проще, конечно же, заниматься посредством e-mail. Только не всегда есть желание ставить и настраивать какой-нибудь postfix на каждой машине, которая должна оповещать админа о проблемах. Иногда просто хочется одной командой послать письмо, использовав уже настроенный smtp организации. Сделать это можно при помощи программки msmtp. Я применяю этот подход только для использования smtp, находящегося внутри локальной сети организации, т.к. он не очень правильный с точки зрения безопасности, но в качестве примера покажу, как можно отправлять письма используя гугловский smtp.

Пример:

#!/bin/bash

printf "Subject:%b\nFrom:%b\nTo:%b\n%b\n" \
       "From good admin" "someuser@gmail.com" "ded@moroz.ru" \
       "Hello Ded Moroz! I worked hard all year, and so I want to get a red bike for the New Year!"|\
msmtp -t --host=smtp.gmail.com \
      --port=587 \
      --user=someuser \
      --passwordeval="echo some_incredible_password" \
      --from=someuser@gmail.com \
      --tls=on \
      --tls-certcheck=off \
      --auth=on

Наверное, тут практически всё ясно и без слов, но немного поясню. Команда printf формирует само письмо, состоящее из заголовков Subject, From, To и тела письма, после чего вывод перенаправляется в команду msmtp, которая и отправляет письмо.

Параметры msmtp:
    -t - заставляет программу msmtp брать адреса назначения из заголовков To, Cc и Bcc
    --host - smtp-сервер, который надо использовать для отправки
    --port - порт smtp-сервера
    --user - пользователь
    --passwordeval - команда, которая выводит пароль на стандартный вывод
    --from - отправитель письма
    --tls - включает/выключает TLS/SSL шифрование
    --tls-certcheck - включает/выключает проверку сертификата
    --auth - включает/выключает аутентификацию

Заголовки Subject, From и To можно и не создавать, просто в таком случае письмо будет без темы и поля To, а в качестве From будет установлено значение параметра --from. Но так делать некрасиво :)

Параметр -t тоже можно не использовать, а вместо него в качестве последних параметров через пробел указать адреса, на которые нужно отправить письмо.

Если не указать параметр --passwordeval, то при запуске команды нужно будет ввести пароль руками.

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

#!/bin/bash

printf "%b\n" \
       "Hello Ded Moroz! I worked hard all year, and so I want to get a red bike for the New Year!"|\
msmtp --host=smtp.gmail.com \
      --port=587 \
      --user=someuser  \
      --from=someuser@gmail.com \
      --tls=on \
      --tls-certcheck=off \
      --auth=on \
      ded@moroz.ru \
      santa@klaus.com

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

Патчим драйвер NVIDIA 319.32 для ядра Linux 3.10

2013-08-01T06:13:00.004+04:00

Обновил себе ядро Linux до версии 3.10 и, как это всегда бывает в таких случаях, после перезагрузки нужно было пересобрать драйвер NVIDIA. Однако, оказалось, что последний драйвер NVIDIA (на этот момент версии 319.32) не поддерживает моё новое ядро. Вариантов в таком случае два: даунгрэйдить ядро до 3.9 или патчить драйвер NVIDIA (если есть чем патчить). Так уж сложилось, что даунгрэйдить я очень не люблю, а вот к добрым ребятушкам, которые в свободное время пописывают всякие патчи и улучшают наш тленный мирок, испытываю самые тёплые и нежные чувства. Конечно же, патч решающий мою проблему, был уже давно написан и выложен, за что автору большое спасибо. Осталось только разобраться, как его использовать. Разобрался. Делюсь.

Качаем патч, например, в домашний каталог. По умолчанию имя будет pastie-7942599.diff.

Распаковываем все внутренности скрипта с драйвером:

> NVIDIA-Linux-x86-319.32.run -x
Creating directory NVIDIA-Linux-x86-319.32
Verifying archive integrity... OK
Uncompressing NVIDIA Accelerated Graphics Driver for Linux-x86 319.32...

Переходим в созданный каталог:

> cd NVIDIA-Linux-x86-319.32

Патчим драйвер:

> patch -p1 < /home/user/pastie-7942599.diff
patching file kernel/nv-i2c.c
patching file kernel/nv-procfs.c
Hunk #4 succeeded at 161 with fuzz 1.

Выходим из каталога с драйвером:

> cd ..

Запаковываем наши пропатченные кишочки обратно:

> ./NVIDIA-Linux-x86-319.32/makeself.sh --target-os Linux --target-arch x86 NVIDIA-Linux-x86-319.32 NVIDIA-Linux-x86-319.32-patched-3.10.run "NVIDIA Accelerated Graphics Driver patched for Linux-x86 3.10 kernel" ./nvidia-installer

Устанавливаем пропатченный драйвер, как обычно:

> sh NVIDIA-Linux-x86-319.32-patched-3.10.run

У меня всё пропатчилось и собралось без проблем. Про качество работы пропатченного драйвера сказать пока что нечего, но иксы запустились, что уже прекрасно несомненно :)

Сборка jNetPcap из исходников в openSUSE 12.1

2012-11-15T06:57:00.002+04:00

Набрел тут на интересную java-обёртку для libpcap. Называется она jNetPcap. По описаниям и примерам выглядит достойно. Но главное, что в отличие от Jpcap, с которой я как-то давненько имел интимные отношения, jNetPcap продолжает развиваться.

Если кто не в курсе, кратко поясню, что libpcap это библиотека для захвата и анализа пакетов, проходящих через сетевые интерфейсы. Её, например, используют такие программы, как wireshark, tcpdump, nmap, ipcad и многие другие.

На сайте разработчиков, есть готовые сборки для Ubuntu, RedHat Enterprise, Fedora и Windows. Архив сборки содержит два интересующих меня файла jnetpcap.jar и libjnetpcap.so. Сборка для Fedora сомнительно, но гордо называется Linux (Generic). Сначала я попробовал именно её. При запуске примера она искала libpcap.so.0.9, но ничего не нашла, т.к. у меня стоит версия 1.3.0. В принципе, простой симлинк в /usr/lib libpcap.so.0.9 -> libpcap.so.1.3.0 решает проблему, и пример начинает работать, но что-то меня смущает такая большая разница в версиях libpcap. Поэтому пришлось собирать jNetPcap из исходников.

Сборка прошла не совсем гладко, поэтому оставлю тут для себя, а может и ещё для кого, заметку поэтому поводу.

Теперь кратко о проблемах:

При попытке собрать jnetpcap.jar (команда ant build-jar):

[taskdef] Could not load definitions from resource cpptasks.tasks. 
It could not be found.

[typedef] Could not load definitions from resource cpptasks.types.
It could not be found.

build.xml:119: taskdef class org.vafer.jdeb.ant.DebAntTask cannot be found 
using the classloader AntClassLoader[]

При попытке собрать libjnetpcap.so (команда ant comp-jni-linux):

[cc] /home/eqlbin/SRC/jnetpcap-src-1.3.0-1/src/c/jnetpcap.cpp:996:6: 
error: invalid suffix "xpackage" on integer constant

[cc] :0:1: error: "not" cannot be used as a macro name as it is an
operator in C++

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

Для сборки, помимо JDK, понадобятся такие естественные штуки, как gcc, gcc-c++, libpcap-devel, ant, ant-junit, ant-contrib. Возможно я что-то упустил, но это основное.

Поехали:

Качаем и распаковываем исходники jNetPcap в гипотетический каталог ~/jnetpcap-src
Качаем cpptasks для ant и кладём файл cpptasks.jar например в ~/jnetpcap-src/lib
Дальше, если у вас есть желание создать из всего хозяйства файл deb, то понадобится найти библиотеку jdeb.jar с соответствующими тасками для ant. Её можно найти уже собранную или же собрать самому. У меня такого желания не образовалось, поэтому я просто закомментировал строку в файле build.xml:
Теперь необходимо подправить build.xml, чтобы ant смог найти cpptasks.jar и jdeb.jar (если вы, используете jdeb и не закомментировали строку, как в п.3): Вот это: Надо привести к виду, вроде этого: Всё, конечно, зависит от того, как называются ваши jar-файлы и где они лежат... Короче, думаю, что и так тут всё ясно.
Добавить в файл Linux.properties строку compiler.LIBPCAP_VERSION = 100
Запустить ant clean comp-jni-linux build-jar
Забрать из ~/jnetpcap-src/build/lib вожделенные jnetpcap.jar и libjnetpcap.so (там еще у меня появился файл libjnetpcap.so.1.3.0, но судя по его размеру, это тот же libjnetpcap.so)

P.S. - Если build.xml кажется вам страшным и непонятным, почитайте это.

Автоматическое создание Runnable JAR в Eclipse и ресурсы

2012-04-28T10:08:00.001+04:00

Когда разрабатывается относительно небольшое десктопное приложение на Java, частенько возникает вполне, на мой взгляд, естественное желание запихать все классы, библиотеки и ресурсы в один исполняемый JAR-файл. В некоторых случаях именно такое решение является предпочтительным.

В Eclipse IDE это можно сделать очень легко и, кроме того, автоматизировать это действие, чтобы в дальнейшем делать сборку JAR одной кнопкой.

Сборка

Кликаем правой кнопкой по проекту, который надо упаковать в исполняемый JAR и нажимаем Export.

В окне выбираем Java -> Runnable JAR и жмём Next

Теперь настраиваем параметры создания JAR:

Конфигурация запуска (Launch configuration или Run configuration), которая отвечает за запуск проекта. Из неё во время сборки будет взята информация о Main class, CLASSPATH и всех необходимых библиотеках
Имя создаваемого JAR-файла
Далее надо указать, как следует поступить с подключенными библиотеками:

Распаковать содержимое библиотек и запаковать и вместе с вашими классами и ресурсами в один JAR
Не распаковывая положить все библиотеки в создаваемый JAR. В дополнение к этому Eclipse положит в build-катлог файл jar-in-jar-loader.zip, который содержит классы, позволяющие использовать эти "дважды упакованные" библиотеки вашему приложению (Classloader). Эти классы будут также упакованы в ваш JAR и, следовательно, для его выполнения после окончательной сборки архив jar-in-jar-loader.zip не нужен. Однако, для того чтобы можно было автоматизировать такую сборку, этот архив обязательно должен быть в build-каталоге, поэтому после первой "кнопочно-окошечной" сборки его удалять не стоит
Положить все необходимые библиотеки в каталог рядом с созданным JAR'ом

Можно указать где сохранить сгенерированный Ant-скрипт для этой сборки. В дальнейшем его можно будет использовать для автоматизации процесса создания исполняемого JAR-файла из проекта

При создании JAR, автоматом также будет создан файл MANIFEST.MF с правильными Class-Path и Main-Class, поэтому ваш архив можно будет запустить простой командой java -jar application.jar.

Если вы решите упаковывать все библиотеки в один JAR вместе с вашими классами, убедитесь, что лицензии библиотек это разрешают.

Автоматизация сборки

Как было сказано ранее, при создании JAR с помощью Eclipse, вы можете сохранить сгенерированный скрипт Ant, содержащий все необходимые действия.

В свойствах проекта (Project -> Properties) есть раздел Builders, в котором вы можете создавать дополнительные билдеры и в частности таким билдером может быть Ant, которому вы и подсовываете этот файл. После этого при каждом запуске проекта (Ctrl + F11), JAR будет собираться автоматически, если были изменения в исходном коде.

Такой вариант постоянной сборки JAR не особо удобен, т.к. может занимать некомфортное по продолжительности время. Вместо этого можно создать этот билдер в External Tools (Run -> External Tools -> External Tools Configurations) и запускать сборку JAR только, когда вам это действительно нужно.

Ну и, конечно же, никто не запрещает вам добавлять свои собственные цели и задачи в этот Ant-скрипт. Подробнее об Ant'е я писал тут.

Ресурсы

Кроме скомпилированных классов, в JAR также можно хранить и другие ресурсы приложения, например, текстовые файлы или картинки. Для этого нужно поместить ресурсы в пакет (или субпакет) с каким-нибудь классом и использовать методы Class.getResource(String name) или Class.getResourceAsStream(String name) для доступа к ресурсу. Параметр name это имя файла ресурса относительно каталога (пакета), в котором лежит класс.

Пример

У вас есть класс MyApp.class, который находится в пакете my.application. Вы можете поместить файлы изображений например в my.application.images и обращаться к ним из класса MyApp примерно так:

URL url = getClass().getResource("images/my_picture.png");        
Image image = Toolkit.getDefaultToolkit().getImage(url);

Или из любого другого класса:

URL url = MyApp.class.getResource("images/my_picture.png");        
Image image = Toolkit.getDefaultToolkit().getImage(url);

При использовании такого подхода, можно получать доступ как к незапакованным файлам ресурсов, так и к тем, которые запакованы в JAR вместе с классами.

Установка Magnolia Community Edition из WAR-файла

2012-04-11T06:17:00.000+04:00

Magnolia Community Edition на первый взгляд очень достойная современная WCMS с открытым исходным кодом. Для её познания есть довольно неплохая документация и wiki. Однако, есть у меня подозрения, что эта штука не относится к числу простых и легкоподнимаемых CMS. Но выглядит, повторюсь, очень достойно. Пока что просто установим её под Linux.

Установка Magnolia CMS

1. Скачать и распаковать Apache Tomcat в какой-либо каталог, который далее будет обозначаться [tomcat]

2. В каталоге [tomcat]/bin создать исполняемый файл setenv.sh, со строкой export CATALINA_OPTS="$CATALINA_OPTS -XX:MaxPermSize=256m -Xms128M -Xmx768M -Djava.awt.headless=true"

Файл setenv.sh будет автоматически выполнен при запуске tomcat и JVM будет запущена с аргументами, которые указаны в файле. Кратко о каждом:

-Xms128M и -Xmx768M устанавливают, соответственно, минимальный и максимальный размер кучи. Параметр -Xms128M не особо обязательный, если речь не идёт о повышении производительности, а вот без -Xmx768M установка Magnolia скорее всего будет падать с java.lang.OutOfMemoryError: Java heapspace.

-XX:MaxPermSize=256m увеличивает размер области памяти, которая называется Permanent Generation. Эта память не относится к куче, в ней хранятся классы, методы и другие полезные вещи. Если до установки Magnolia не увеличить эту область памяти, то установка будет валиться с java.lang.OutOfMemoryError: PermGen space.

-Djava.awt.headless=true пригодится, если Magnolia будет запускаться на сервер, на котором не запущены Иксы.

После завершения установки, выделяемую память, вероятно, можно немного уменьшить, но это надо проверять.

3. Скачать WAR-файл с Magnolia. На данный момент последний доступный это magnolia-bundled-webapp-4.5.2.war.

4. В каталог [tomcat]/webapps положить две копии этого файла под именами magnoliaAuthor.war и magnoliaPublic.war.

При запуске tomcat magnoliaAuthor будет автоматически сконфигурирована как приватная авторская часть CMS, а magnoliaPublic как публичная. Авторская часть, как и в любых других CMS, используется для подготовки публикаций, которые могут создаваться постепенно и во время создания быть недоступны публично. При этом сам автор может просматривать то, что у него получается в ходе работы над контентом. Как только работа над контентом завершена, автор публикует его и контент становится доступным через публичную часть CMS.

5. Запустить Tomcat ([tomcat]/bin/startup.sh) и подождать пока распакуются оба WAR'а.

6. В браузере сначала постучаться по адресу http://localhost:8080/magnoliaAuthor, нажать "Start install", дождаться завершения и нажать "Start up Magnolia". Потом тоже самое проделать для http://localhost:8080/magnoliaPublic.

На этом установка завершена. Для доступа к http://localhost:8080/magnoliaAuthor введите superuser в качестве логина и пароля.По адресу http://localhost:8080/magnoliaPublic по умолчанию будет доступен демонстрационный сайт, над которым можно поиздеваться через magnoliaAuthor.

Возможные проблемы

Если установка или работа Magnolia CMS вдет себя странно, то гляньте в логи Tomcat:

Если увидите в логах java.lang.OutOfMemoryError, то попробуйте ещё увеличить размеры Heap или Permanent Generation.
Если обнаружите исключения с припиской "Too many open files", то нужно увеличить лимит на количество открытых файлов в Linux

Общее количество файлов

Установить в файле /etc/sysctl.conf параметр fs.file-max = 400000, и для обновления параметра в системе выполняем sysctl -p

Проверить можно так: sysctl -a |grep fs.file-max

Количество файлов на пользователя

В файле /etc/security/limits.conf написать eqlbin hard nofile 50000 и eqlbin soft nofile 10000, только вместо eqlbin, естественно, ваш пользователь, ну или символ * для любого пользователя

Файл limits.conf читается при загрузке. Чтобы сразу установить новое значение лимита выполните: ulimit -n 50000 из под того пользователя, под которым запускается Tomcat. Если эта операция запрещена в вашем дистрибутиве для обычного пользователя, то проще установить значение в limits.conf и перезагрузиться

Проверить: ulimit -n

Список CMS на Java

2012-04-05T10:19:00.001+04:00

Давно хотел найти для себя какую-нибудь удобную CMS, а точнее WCMS, которая:

Создана на стеке Java-технологий
Open Source
Легко разворачивается
Имеет развитую и относительно простую систему шаблонов
Более или менее легко интегрируется с другими веб-приложениями
Проста в освоении для "нетехнических" людей, которые будут наполнять контент

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

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

Список я разделил на две части. В первом списке главные кандидаты. Это те CMS, с которыми я уже успел немного познакомиться: какие-то разворачивал и тыкал ранее, а какие-то просто внимательно изучал на официальных сайтах и они мне на первый взгляд понравились. Во втором списке системы, в которых я не особо уверен, потому что пока не уделил им достаточно внимания. Возможно, с течением времени эти списки будут пополняться или между ними будут происходить перестановки.

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

Итак, списки.

Главные претенденты:

Запасной состав:

Hippo (www.onehippo.org)
Daisy (www.daisycms.org)
Vosao (www.vosao.org)
eXo Platform (www.exoplatform.com)
InfoGlue (www.infoglue.org)
Enonic (www.enonic.com)
JadaSite (www.jadasite.com)
Fedora Commons (fedora-commons.org)
LogicalDOC (www.logicaldoc.com)
DSpace (www.dspace.org)
OpenKM (www.openkm.com)
Yanel (yanel.org)

Многие CMS из этих списков имеют версии Enterprise и Community, которые, соответственно, распространяются под разными лицензиями: закрытой и открытой. Также, некоторые кандидаты являются не только WCMS, а большими разухабистыми ECMS (как, например, Alfresco) с возможностями WCMS. А вот в запасной список наоборот могли закрасться те, которые вообще не умеют WCMS, а являются к примеру только DMS.

Точка доступа D-Link DAP-1150 RU которая не тонет

2012-03-14T04:40:00.002+04:00

"Посчастливилось" мне тут повозиться с этим редкостным г... ну тем в общем, что не тонет. Эта гадость в режиме AP Mode раздает по DHCP беспроводным клиентам в качестве шлюза по умолчанию и DNS свой собственный адрес. Естественно, в такой ситуации клиенты этой точки ограничены только работой в своей сети и никаких им интернетов. Вылечить это психическое расстройство удалось только заменой родной прошивки версии 2.0 на вот эту 2.11 beta. Хоть она и beta, но с ней DHCP заработал адекватно и кроме этого появился режим Wireless Client Mode. Сначала пробовал прошивать стабильной версией 2.10 (стабильной по мнению разработчиков). Прошилось легко, но толку никакого. Так что, товарищи, если вам "повезло" как мне, то рекомендую воспользоваться ссылочкой выше.

Плагин Google для Eclipse: обновления о которых не просят

2011-10-11T14:29:00.001+04:00

Обнаружил интересную особенность у плагина Google для Eclipse, позволяющего разрабатывать приложения с использованием GWT и App Engine.

После очередного перезапуска контейнера сервлетов Jetty, который используется плагином для запуска GWT приложений на локальном хосте, он как-то необычно призадумался на старте. Вывел мне на консоль "Initializing App Engine server" и замолчал. Понимаю, что тужится, но не понимаю с чего это вдруг. Подождал я его несколько минут и он выдавил на консоль что-то вроде этого:

INFO: Unable to access http://appengine.google.com/api/updatecheck?runtime=java&release=1.5.4×tamp=1315604504&api_versions=['1.0']

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

Первым делом я, конечно, полез в настройки Eclipse (Window -> Preferences -> Google) и убрал галку с пункта "Notify me about updates", но ничего не изменилось. Немного пошарив по интернету, я наткнулся на забавное описание метода allowedToCheckForUpdates() класса UpdateCheck в пакете com.google.appengine.tools.info. По названию пакета можно сделать некоторые выводы о том, для чего он нужен. Вот описание этого метода:

Returns true if the user wants to check for updates even when we don't need to. We assume that users will want this functionality, but they can opt out by creating an .appcfg_no_nag file in their home directory.

В общем, надо или не надо, этот метод все равно возвращает true, т.к. разработчики уверены что, если пользователь даже отключил проверку обновлений, то он всё равно хочет обновлений. Как-то так получается :) Однако, всё-таки можно эту проверку отключить, создав в домашнем каталоге пользователя, под которым запускается контейнер, файл .appcfg_no_nag. После того, как я это сделал, "задумчивость" контейнера на старте прошла, но tcpdump показывает, что он всё равно продолжает стучаться на appengine.google.com.

Основы использования системы сборки Apache Ant

2011-09-29T06:19:00.000+04:00

Когда ведется разработка программного продукта, он может состоять из множества исходных частей. Например, разработка может вестись несколькими людьми практически независимо друг от друга, а файлы с исходным кодом, за который они отвечают, могут находится в совершенно разных местах файловой системы и даже на разных машинах. Кроме файлов исходного кода, в проекте могут использоваться также и готовые библиотеки от сторонних разработчиков (например, файлы jar, dll или so), файлы конфигурации, различные картинки и иконки, звуковые файлы и куча всего остального. Все эти штуки могут так же изменяться в ходе разработки проекта другими людьми.

А теперь представьте, что из всего этого безобразия необходимо собрать всего один файл сжатого архива, который пользователь мог бы скачать с вашего сайта, распакавать и сразу же запустить ваш продукт. Вам нужно будет собрать вместе все файлы с исходным кодом Java и скомпилировать их, прогнать тесты, чтобы убедиться что проект никто не поломал, полученные class-файлы упаковать в JAR (или несколько JAR'ов), для которого ещё необходимо сгенерировать правильный манифест, содержащий CLASSPATH, имя главного класса, номер версии и т.п., затем собрать вместе все остальные файлы вроде библиотек, картинок и конфигов, распихать это все в правильные каталоги, сгенерировать документацию, создать из всего этого архив и залить его на ваш вэб-сервер, а всё произошедшее записать в лог и сохранить его в базе данных, которая хранит информацию о различных сборках. Делать всё это руками довольно уныло, да и не должен психически здоровый человек этим заниматься.

Системы сборки, такие как Apache Ant, были созданы для того, чтобы автоматизировать весь этот порой достаточно сложный и рутиный процесс по сборке проекта. Причем, в случае с Apache Ant проект не обязательно должен быть на Java, и не обязательно должен быть вообще программным обеспечением. Это может быть что угодно, хотя ориентирован он, конечно же, в первую очередь на Java. В данной статье я хочу на очень простом примере показать, как можно облегчить себе жизнь с помощью Apache Ant.

Минимальные знания об использовании Apache Ant

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

Файл build.xml содержит внутри себя корневой элемент project, наполнением которого являются элементы, относящиеся к одному из следующих понятий:

Цели (Targets)
Задачи (Tasks)
Ресурсы (Resources)
Свойства (Properties)

Задачи представляют из себя различные атомарные операции: компиляция исходных файлов Java, создание JAR, создание каталога, копирование файлов, вывод информации на экран и т.п.. Задачи могут использовать для своей работы отдельные ресурсы (например, файл) или коллекцию ресурсов (множество файлов). Цели, в свою очередь, состоят из одной или нескольких задач, поэтому цель можно рассматривать как функцию или процедуру в языках программирования. Целями могут быть: создание дерева каталогов, компиляция всего проекта, создание дистрибутива, удаление результатов предыдущей компиляции, и всё в таком духе.

Если термины "Цель" и "Задача" запутывают вас, то попробуйте размышлять как-нибудь так: "Для того чтобы достичь какую-либо цель, нужно выполнить определенные задачи". Например, чтобы достичь цель "Скомпилировать проект", необходимо выполнить задачи: "Создать каталог для скомпилированных файлов", "Запустить компилятор javac" и "Создать JAR".

Кроме целей, задач и ресурсов есть свойства. К свойствам можно относится как к переменным, а точнее константам. У свойства есть имя и значение в виде строки. Значение свойства устанавливается один раз и любая попытка изменить это значение игнорируется. Свойства обычно используются в атрибутах задач. Установка значения может происходить в самом файле build.xml или во внешнем properties-файле, что очень удобно и позволяет менять процесс сборки не изменяя build.xml.

Свойства

В файле build.xml значение свойства может быть установлено с помощью элемента property. Этот элемент может использоваться как внутри корневого элемента project, так и внутри target'ов:

Как уже было сказано, свойства могут быть определены и во внешнем файле properties. Записи свойств в этом файле могут выглядеть так:

myProp=myValue
my.text = Very useful text

Чтобы свойства, записанные в файле, стали доступны в сценарии сборки, нужно его подключить:

Для получения доступа к значению свойства используется конструкция ${myProp}. Следующий код выводит на экран значение свойства с именем myProp:

Ресурсы

Примером ресурсов могут быть, например, элементы file и url:

Думаю, что тут всё понятно без лишних слов.

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

В этом примере в fileset войдут все файлы java из каталога src и его подкаталогов, кроме файлов, в имени которых есть слово Test с учётом регистра.

Помимо описанных вариантов ресурсов, также существуют, так называемые, path-like структуры. Не знаю, стоит ли относить их к коллекциям ресурсов, но лучше места для них я не придумал, поэтому упомяну эти структуры тут. Из названия, думаю, понятно, что это элементы которые описывают такие вещи как пути (PATH). Их наполнением могут быть различные ресурсы и их коллекции.

Обратите внимание, что в данном примере так же используются свойства mylib.dir и extlib.dir, значением которых являются пути к каталогам с собственными и внешнимим библиотеками, соответственно.

В описанных path-like структурах, Ant будет автоматически использовать правильный символ сепаратора для разделения ресурсов, соответствующий операционной системе, на которой он выполняется.

Очень удобной возможностью в path-like структурах является возможность одной структуры ссылаться на другую, используя атрибуты id и refid:

Более подробно о ресурсах можно почитать тут.

Задачи

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

Часто используемые задачи
Задача (xml-тег)	Действие
javac	компиляция файлов с исходным кодом java
jar	создание java-архива
zip	создание zip-архива
mkdir	создание директории
copy	копирование файлов
delete	удаление файлов и директорий
exec	выполнение внешней команды
mail	отправка электронной почты
junit	запуск unit-тестов

Ниже приведу простейшие примеры использования задач.

Создание каталога:

Копирование файла:

Компиляция файлов с кодом java:

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

Полный список задач представлен здесь.

Цели

Итак, мы подошли к цели :) На целях строится весь сценарий сборки. Вы ставите цели и достигаете их с помощью выполнения задач и использования ресурсов. Зачем использовать цели, если все задачи можно писать прямо в корневом элементе project? А затем, что цели позволяют разделить сценарий сборки на отдельные законченные логические этапы, которые могут быть зависимыми друг от друга. Т.е. одна цель может быть помечена как зависимая от другой цели, и для её достижения необходимо, чтобы сначала была достигнута цель от которой она зависит.

В случае, если задачи расположены в корневом элементе project, то ant, проходя по файлу build.xml, последовательно их выполняет. При таком подходе вы можете определить для себя только один вариант выполнения сборки. При использовании целей можно указать ant'у какую цель необходимо достичь, а он уже сам проверит её зависимости и выполнит сначала цели от которых зависит главная.

В приведенном примере описаны вполне реальные цели, только вместо элементов echo в них должны быть более полезные задачи. В элементе project установлено значение атрибута default равное compile, которое означает, что по умолчанию ant будет выполнять цель compile, которая зависит от цели make.build.dirs, поэтому сначала будет выполнена цель make.build.dirs, а затем compile. Если же ant'у при запуске указать цель dist, которая зависит одновременно от двух целей compile и make.dist.dirs, то сначала будет выполнен этап описанный выше, затем make.dist.dirs, а уже потом dist:

make.build.dirs:
     [echo] creating directories for build...

compile:
     [echo] compiling...

make.dist.dirs:
     [echo] creating directories for distribute...

dist:
     [echo] creating a distribution...

Кроме этого в примере также есть цель clean, которая не зависит ни от какой другой цели, и также нет цели которая зависила бы от clean, поэтому данная цель может быть только явно вызвана ant'ом: ant clean.

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

В данном примере цель build.full будет выполняться только, если установлено значение совйства full, в противном же случае будет выполняться build.simple. Абсолютно неважно какое значение установлено в свойство full, это может быть и true, и false, и любая другая строка, даже пустая.

Пример сборки проекта с помощью Apache Ant

Теперь разберем относительно простой процесс сборки маленького проекта.

Для уверенности в том, что сценарий сборки, приведённый ниже, собирает действительно рабочий и самодостаточный проект, я написал очень маленькую программу, код которой я приводить не буду, потому что это в данном случае не нужно. Программа состоит из трёх файлов java: ValuesGenerator.java, Statistic.java и Main.java. В ValuesGenerator.java описан метод для генерации случайного набора данных, в Statistic.java методы для нахождения минимального, среднего и максимального значений массива, а в Main.java находится метод main(), в котором происходит вызов методов классов ValuesGenerator и Statistic. Класс Statistic использует для рассчета значений библиотеку Apache Commons Math, а вся работа программы пишется в лог-файл с помощью библиотеки log4j. Также в каталоге с проектом есть небольшой файл readme.txt с описанием программы.

Задача заключается в том, чтобы иметь возможность автоматически создавать zip-файл с дистрибутивом программы.

Сразу привожу содержание файла свойств и файла build.xml c подробными комментариями, а потом опишу некоторые моменты подробно.

Файл build.properties

# имя каталога с дополнительными библиотеками
lib.dir=lib
# каталог проекта
project.dir=project
# каталог с исходниками проекта
project.src.dir=${project.dir}/src
# каталог для сборки
build.dir=build
# имя для jar-файла
build.jar.name=myprogram.jar
# имя главного класса
build.jar.mainclass=eqlbin.tutorials.ant.Main
# имя проекта
dist.name=myprogram
# каталог для создания дистрибутива
dist.dir=distribution
# имя каталога с библиотеками в дистрибутиве
dist.lib.dir=lib

Файл build.xml

На первый взгляд листинг build.xml может показаться сложным и громоздким. На самом деле, если потратить немного времени и внимательно просмотреть весь код, почитав комментарии, всё должно стать понятно. Ну а громоздкое оно, потому что XML, от этого никуда не деться. Рассмотрим теперь поподробнее приведённый пример.

Цели make.build.dirs и make.dist.dirs вам должны быть уже предельно понятны. Они не делают ничего умного, а только создают каталоги. Единственное, что можно отметить, в данном случае совсем не обязательно было прописывать в них по две задачи mkdir, а можно было бы обойтись одной, т.к. mkdir может создавать целую цепочку каталогов сразу.

Цель compile содержит задания, необходимые для компиляции исходного кода. Перед вызовом компилятора происходит создание элемента path, в котором будут содержаться пути к файлам библиотек, используемых в нашей программе. Файлы определяются с помощью элемента fileset, помимо которого в path могли бы содержаться и другие элементы коллекции ресурсов, например, dirset, содержащий пути к каталогам со скомпилированными java-классами или другой элемент path. Т.к. созданный элемент path представляет из себя необходимый для компиляции CLASSPATH, ему устанавливается соответствующий атрибут id, для того чтобы позже можно было на это path сослаться. После создания path, его текстовое представление записывается в свойство с помощью элемента pathconvert и выводится на экран. Цель compile указана в элементе project, как цель по умолчанию, поэтому если ant'у не указывать цель для выполнения, он будет выполнять именно её. Данная цель зависит от выполнения только одной цели make.build.dirs.

Цель dist.lib.copy тоже простая и осуществляет копирование всех jar-файлов, необходимых для запуска программы в каталог дистрибутива. В качестве источника файлов используется созданный ранее path. Атрибут flatten="true" в элементе copy отсекает всю информацию о пути к копируемым файлам и оставляет только их имя. Если его не использовать или указать равным false, то при копировании ant будет создавать всё дерево каталогов в каталоге todir, а т.к. в path у нас используются абсолютные пути, которые начинаются с корня (т.е. с символа "/"), то копирование вообще не выполнется. Это важный момент, который иногда является источником ошибок.

Цель make.jar занимается упаковыванием всех скомпилированных java-классов в исполняемый JAR. Для того чтобы создать првильно выполняющийся JAR, необходимо в первую очередь наличие файлов скомпилированных классов и система каталогов в которой также должны находиться файлы используемых программой библиотек. По этой причине цель make.jar зависит от целей compile и dist.lib.copy. Также для создания исполнимого JAR'а необходимо сгенерировать специальный файл MANIFEST.MF, в котором должны быть указаны имя главного класса, содержащего метод main() и CLASSPATH, благодаря которому программа сможет найти все необходимые ей библиотеки. У нас, на момент выполнения цели make.jar, уже есть элемент path, содержащий все пути до файлов используемых библиотек. Проблема в том, что эти пути абсолютные и указывают на конкретное место. Нам для распространения нужно чтобы пути были относительными и указывали на положение файлов библиотек, которые были скопированы с помощью цели dist.lib.copy в каталог с программой. Кроме этого, символом разделителя путей в манифесте, должен быть пробел, а не ":" или ";". Поэтому, с помощью элемента pathconvert происходит преобразование значения CLASSPATH, использовавшегося для компиляции, в значение пригодное для записи в манифесте. Элемент chainedmapper определяет цепочку преобразований, которые необходимо произвести с элементом path. В этой цепочке находится два действия: flattenmapper и globmapper. Эти действия совершают удаление информации о пути к файлам определенным в path, оставляя только имя файла, и добавляют перед именами файлов относительный путь к каталогу, содержащему эти библиотеки в рамках дистрибутива. Полученный результат преобразования сохраняется в свойстве dist.classpath и выводится на экран. Затем элемент jar используется для создания java-архива. Внутри этого элемента описывается манифест и набор скомпилированных классов для упаковки. В манифесте указываются атрибуты, содержащие имя главного класса и преобразованный CLASSPATH, а также имя того, кто создал этот JAR.

Цель javadoc осуществляет генерацию документации javadoc. Её подробно я описывать не буду, просто привел для демонстрации.

Конечной целью является dist. Её легко понять просто посмотрев на код. В ней происходит копирование файла с описанием программы в каталог с дистрибутивом и создание zip-архива из этого каталога.

Цель clean также проста до безобразия и просто производит удаление результатов предыдущих сборок.

Заключение

Хотел написать небольшую статью об основах Ant, а получилось так много букв, что вряд ли кто-то будет читать это до конца :) Зато, вроде бы, получилось очень доступно и подробно. Не смотря на объём, статья не является чем-то большим, чем введение в Ant, но её более чем достаточно для начала работы с этим замечательным инструментом. Более подробно обо всех возможностях Ant можно узнать из документации на официальном сайте проекта.

Вычисление БПФ на GPU с использованием Java и CUDA

2011-08-14T10:08:00.008+04:00

В последнее время у меня на работе встала задача создания спектрограмм для довольно большого объема данных. Главным инструментом для этого является алгоритм Быстрого Преобразования Фурье. На сегодняшний день для Java написано уже множество библиотек, реализующих вычисление БПФ и другие математические инструменты, например, мне нравится Commons Math от Apache project. Но для того, чтобы обрабатывать большие объемы данных с помощью этой библиотеки за более или менее разумное время, нужна довольно мощная и недешевая машина, которой у меня нет. Поэтому я и обратил свой взор на технологию NVIDIA CUDA, которая позволяет очень шустро производить расчеты с плавающей точкой на чипе видеокарты. А, как известно, БПФ это очень даже плавающая точка :) Вдвойне приятно то, что хорошие люди уже давно написали Java-интерфейс JCuda для нативной библиотеки CUDA. И ещё больше я обрадовался, когда обнаружил, что библиотека CUDA имеет в своем составе модуль CUFFT, который предоставляет средства для расчета БПФ, использующие по полной программе возможности видеокарты для выполнения параллельных вычислений с плавающей точкой.

CUDA поддерживается видеокартами NVIDIA GeForce начиная с чипа G80, т.е. с восьмой серии. Машина, на которой я тестирую в данный момент связку Java + CUDA довольно старенькая и имеет на борту процессор AMD Athlon X2 4200+, видеокарту NVIDIA GeForce 8800 GTS 640 Mb, всего 2 Gb оперативной памяти и управляется операционной системой openSUSE 11.4.

Теперь немного о производительности видеокарт и центральных процессоров в цифрах. Мерой производительности вычислительных систем, которая показывает количество операций с плавающей точкой выполняемых за секунду является единица, называемая FLOPS. Ниже в таблицах можно увидеть на сколько различается теоретическая производительность современных видеокарт и современных процессоров при выполнении операций с плавающей точкой.

Процессоры
Модель	Гигафлопс
AMD Phenom II X6 1100T Black Edition 3.3 ГГц	60.1
Intel Core i7-975 XE 3.33 ГГц	53.28
Intel Core 2 Quad Q8300 2.5 ГГц	40
AMD AMD ATHLON II X4 645 3.1 ГГц	38.44
Intel Core 2 Duo 2.4 ГГц	19.2
AMD Athlon 64 X2 4200+ 2.2 ГГц	13.2

Видеокарты
Модель	Гигафлопс
GeForce GTX 590	2488.3
GeForce GTX 580	1581.056
GeForce GTX 480	1344.96
GeForce GTX 280	933.120
GeForce 9800 GTX	648
GeForce 8800 GTS 640mb	346

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

На данном этапе я пока не разбирался глубоко в возможностях CUDA и использовал только готовый модуль CUFFT и интерфейс к нему из JCuda. Т.е. в моем случае мне не приходилось писать свои собственные ядра (kernels) для CUDA. Что такое ядро CUDA? Это файл с расширением PTX, исходный код которого пишется на языке, являющимся по сути ограниченной версией языка C, а затем компилируется с помощью специального компилятора NVCC. Файл ядра CUDA содержит функции, которые должны выполняться на GPU. С помощью JCuda можно, грубо говоря, загружать такие ядра в вашу java-программу и вызывать функции, описанные в них.

Подготовка

Итак, для того чтобы использовать JCuda, сначала необходимо сделать следующее:

Скачать и установить "родные" проприетарные драйвера NVIDIA.
Скачать и установить CUDA Toolkit
Скачать и распаковать библиотеку JCuda
Добавить путь до jar-файлов JCuda в CLASSPATH или подключить её в вашей IDE как пользовательскую библиотеку
Установить путь до нативных библиотек JCuda (файлы *.so в linux или *.dll в windows) в переменной окружения LD_LIBRARY_PATH

Важные замечания

Сначала я установил Developer Drivers for Linux (260.19.26), ссылка на которые находится на той же странице, где и ссылка на CUDA Toolkit 3.2. Уж не знаю является ли установка именно этой версии драйверов обязательной, но после того, как я убедился, что CUDA работает, я установил последние на тот момент драйвера NVIDIA версии 280.13, которые при установке сообщили о том, что сносят драйвера 260.19.26, потому что сами всё умеют. CUDA при этом осталась работоспособной.
У меня 32-разрядная версия openSUSE, поэтому мне были нужны соответствующие версии CUDA и JCuda. Не особо запариваясь, я взял последнюю доступную собранную для Linux 32-bit версию JCuda 0.3.2a и соответствующую ей версию CUDA Toolkit 3.2. CUDA Toolkit 3.2 была доступна для версии openSUSE 11.2, но вполне себе благополучно встала на 11.4. Входе установки CUDA Toolkit, предложит выбрать путь установки и по завершению скажет о том, что нужно будет добавить в переменные окружения PATH и LD_LIBRARY_PATH. Сделайте это.
В Eclipse JCuda можно подключить как пользовательскую библиотеку: Window -> Preferences -> Java -> Build Path -> User Libraries, New, AddJARs... и добавить все файлы *.jar из каталога jcuda. После этого библиотеку можно добавить в проект.
Необходимо указать путь к нативным библиотекам JCuda. В Eclipse можно поступить двумя способами. Первый способ заключается в том, чтобы при добавлении библиотеки JCuda в User Libraries, для каждого jar-файла указать путь до каталога, в котором лежат нативные библиотеки JCuda (Native Library Location). Второй способ это создать каталог в проекте eclipse и скопировать в него все файлы нативных библиотек JCuda. В Run Configurations проекта добавить переменную окружения LD_LIBRARY_PATH и указать в ней путь до этого каталога. На скриншоте ниже второй способ показан наглядно.

От слов к делу

CUFFT базируется на очень популярной и эффективной библиотеке FFTW. Довольно интересная концепция этой библиотеки заключается в том, что прежде чем осуществить преобразование какого-либо массива данных, нужно сформировать так называемый план (plan). Такой подход позволяет не тратить время на пересчет конфигурации алгоритма преобразования при множественных однотипных преобразованиях. Чтобы создать план используя JCuda, сначала нужно создать объект cufftHandle, который представляет указатель на план, а потом, используя этот указатель, создать план с помощью какой-либо из функций: cufftPlan1d, cufftPlan2d или cufftPlan3d. Эти методы создают план для выполнения одномерного, двумерного и трехмерного БПФ соответственно. В моем случае необходимо осуществить одномерное (1D) преобразование вещественных чисел и на выходе получить также вещественные числа. В CUFFT есть несколько вариантов проведения БПФ:

CUFFT_C2C - преобразование комплексных чисел в комплексные (одинарная точность)
CUFFT_C2R - преобразование комплексных чисел в вещественные (одинарная точность)
CUFFT_D2Z - преобразование вещественных чисел в комплексные (двойная точность)
CUFFT_R2C - преобразование вещественных чисел в комплексные (одинарная точность)
CUFFT_Z2D - преобразование комплексных чисел в вещественные (двойная точность)
CUFFT_Z2Z - преобразование комплексных чисел в комплексные (двойная точность)

В Java тип с одинарной точностью это float, а с двойной - double. Массив комплексных чисел в CUFFT представляет чередующиеся реальные и мнимые части числа. Т.е. для представления одного комплексного числа требуется два элемента массива. Например, массив размером 10, может содержать 5 комплексных чисел.

Как видно выше, в CUFFT нет возможности подать на вход вещественные числа и на выходе получить тоже вещественные, поэтому можно использовать преобразования CUFFT_R2C или CUFFT_D2Z, а затем самостоятельно найти модули полученных комплексных чисел, это уже не такое дорогое действие как выполнение БПФ в плане времени.

Еще оговорюсь, что, к сожалению, моя GeForce 8800 GTS не поддерживает операции с двойной точностью, поэтому мне приходится использовать CUFFT_R2C, хотя хотелось бы CUFFT_D2Z, но это уже мелочи которые лечатся покупкой новой видеокарты.

Пример создания плана для одномерного БПФ вещественных чисел в комплексные:

cufftHandle plan = new cufftHandle();
JCufft.cufftPlan1d(plan, inputDataSize, cufftType.CUFFT_R2C, 1);

plan - указатель на план
inputDataSize - количество входных значений; если входные данные являются вещественными, то этот параметр равняется длине входного массива, а если входные данные это массив комплексных чисел, то значение параметра равно половине длины входного массива, т.к. одно комплексное число представлено двумя элементами массива
cufftType.CUFFT_R2C - тип преобразования
1 - количество подобных преобразований

После создания плана можно уже выполнять преобразование, но только с одинарной точностью, и данные в таком случае будут находиться в оперативной памяти, а не в памяти видеокарты:

// создание случайных входных данных размером 1024
float[] inputData = createRandomData(1024);
// массив для сохранения результатов преобразования
float[] fftResults = new float[inputData.length + 2];
// выполнение преобразования
JCufft.cufftExecR2C(plan, inputData, fftResults);

В этом коде можно заметить некоторую странность. Почему размер массива для сохранения результатов преобразования на 2 элемента больше, чем размер входных данных? Важно в этом разобраться. На входе мы имеем массив из N = 1024 вещественных чисел. А результатом у нас будут комплексные числа, т.е. по 2 элемента массива на одно число. Но в тоже время в документации CUFFT сказано, что результатом преобразования является массив без избыточных значений и его размер равен N/2 + 1. Вот тут для меня небольшая загадка. Почему +1? Зачем он нужен? На сколько я знаю, полезными результатами БПФ является массив размером равным ровно половине размера входного массива, т.е. N/2. Поэтому этот +1 элемент может является особенностью алгоритма, а может это пробел в моих знаниях :) Но это и не важно. Важно помнить то, что результатами преобразований CUFFT является массив который содержит N/2 + 1 значений. Но почему тогда в примере выше размер выходного массива равен не N/2 + 1, а N + 2? Это потому, что на выходе у нас комплексные числа, и для их представления, как было уже много раз упомянуто выше, необходимо два элемента массива. Если писать полностью, то правильно было бы вычислять размер выходного массива так: (inputData.length/2 + 1) * 2. Если раскрыть скобки, то мы и получим inputData.length + 2.

Для того, чтобы осуществлять преобразования с двойной точностью или еще увеличить производительность, необходимо скопировать массив входных данных в память видеокарты и после преобразования результаты скопировать обратно:

// создание случайных входных данных размером 1024
float[] inputData = createRandomData(1024);
// массив для сохранения результатов преобразования
float[] fftResults = new float[inputData.length + 2];
// указатель на устройство
Pointer deviceDataIn = new Pointer();
// выделение памяти на устройстве для входных данных
JCuda.cudaMalloc(deviceDataIn, inputData.length * 4);
// копирование данных из оперативной памяти в память видеокарты
JCuda.cudaMemcpy(deviceDataIn, Pointer.to(inputData), inputData.length * 4, 
          cudaMemcpyKind.cudaMemcpyHostToDevice);
     
Pointer deviceDataOut = new Pointer();
// выделение памяти на устройстве для результатов
JCuda.cudaMalloc(deviceDataOut, fftResults.length * 4);

// создание плана     
cufftHandle plan = new cufftHandle();
JCufft.cufftPlan1d(plan, inputData.length, cufftType.CUFFT_R2C, 1);

// преобразование
JCufft.cufftExecR2C(plan, deviceDataIn, deviceDataOut);

// копирование данных из памяти видеокарты в оперативную память     
JCuda.cudaMemcpy(Pointer.to(fftResults), deviceDataOut, fftResults.length * 4, 
             cudaMemcpyKind.cudaMemcpyDeviceToHost);

В данном примере метод JCuda.cudaMalloc(Pointer devPtr, long size) осуществляет выделение памяти размером size байт на видеокарте и возвращает на неё указатель в параметре devPtr. JCuda.cudaMemcpy(Pointer dst, Pointer src, long count, int cudaMemcpyKind_kind) осуществляет копирование данных между хостом и видеокартой, где dst - указатель на место назначения, src - указатель на источник, count - количество байт для копирования, cudaMemcpyKind_kind - направление копирования (например, cudaMemcpyKind.cudaMemcpyDeviceToHost для копирования данных с памяти видеокарты в оперативную память). С помощью Pointer.to(float[] values) создается указатель на массив значений.

После проведения преобразования необходимо уничтожить все указатели и планы:

JCufft.cufftDestroy(plan);
JCuda.cudaFree(deviceDataIn);
JCuda.cudaFree(deviceDataOut);

Пример программы

Теперь приведу пример рабочей программы, которая будет генерировать массив случайных значений размером 2 в 23 степени (кратность степени двойки необходима для библиотеки от Apache, для CUFFT это условие не обязательно) и производить БПФ этого массива с помощью Apache Commons Math и CUDA, замеряя при этом время выполнения каждого преобразования. В конце программа выведет первое, среднее и последнее значение для каждого из результатов преобразования, чтобы можно было убедиться в правильности расчетов. Для того, чтобы программа успешно выполнилась, необходимо увеличить размер кучи у JVM с помощью параметров командной строки -Xms512m -Xmx768m или же уменьшить размер генерируемого входного массива. В Eclipse указать параметры командной строки можно в Run Configurations во вкладке Arguments, раздел VM arguments.

import java.util.Date;
import java.util.Random;
import org.apache.commons.math.complex.Complex;
import org.apache.commons.math.transform.FastFourierTransformer;
import jcuda.Pointer;
import jcuda.jcufft.JCufft;
import jcuda.jcufft.cufftHandle;
import jcuda.jcufft.cufftType;
import jcuda.runtime.JCuda;
import jcuda.runtime.cudaMemcpyKind;

public class JCufftDemo {

 public static void main(String[] args) {

  double[] fftResults;  
  int dataSize = 1<<23;

  System.out.println("Генерация входных данных размером "+dataSize+" значений...\n");
  float[] inputData = createRandomData(dataSize);
  
  System.out.println("1D БПФ с использованием apache commons math...");
  fftResults = commonsTransform(floatDataToDoubleData(inputData.clone()));
  printSomeValues(fftResults);
  
  System.out.println();
  System.out.println("1D БПФ JCufft (данные в оперативной памяти)...");
  fftResults = jcudaTransformHostMemory(inputData.clone());
  printSomeValues(fftResults);
   
  System.out.println();
  System.out.println("1D БПФ JCufft (данные в памяти видеокарты)...");
  fftResults = jcudaTransformDeviceMemory(inputData.clone());
  printSomeValues(fftResults);
 }
 
 /**
  * Генерирует массив случайных чисел
  * 
  * @param dataSize - размер генерируемого массива
  * @return массив случайных чисел
  */
 public static float[] createRandomData(int dataSize){
        Random random = new Random();
        float data[] = new float[dataSize];
        
        for (int i = 0; i < dataSize; i++)
         data[i] = random.nextFloat();

        return data;
 }
 
 /**
  * Конвертирует массив значений типа float в массив значений double
  * 
  * @param data - массив который нужно конвертировать
  * @return - сконвертированный массив
  */
 public static double[] floatDataToDoubleData(float[] data){ 
  
  double[] doubleData = new double[data.length];  
  for(int i=0; i < data.length; i++) doubleData[i] = data[i];
  
  return doubleData;
 }
 
 /**
  * Выполняет БПФ массива значений с помощью CUDA, осуществляя
  * операции с данными в оперативной памяти
  * 
  * @param inputData - массив входных значений
  * @return массив с результатами БПФ
  */
 public static double[] jcudaTransformHostMemory(float[] inputData){
  float[] fftResults = new float[inputData.length + 2];
     // создание плана
     cufftHandle plan = new cufftHandle();
     JCufft.cufftPlan1d(plan, inputData.length, cufftType.CUFFT_R2C, 1);
     // выполнение БПФ
     long timeStart = new Date().getTime();
     JCufft.cufftExecR2C(plan, inputData, fftResults);
     System.out.println("Время преобразования: " + (new Date().getTime() - timeStart)/1000.0+" сек");
     // уничтожение плана
     JCufft.cufftDestroy(plan);

  return cudaComplexToDouble(fftResults);
 }
 
 /**
  * Выполняет БПФ массива значений с помощью CUDA, осуществляя
  * операции с данными в памяти видеокарты
  * 
  * @param inputData - массив входных значений
  * @return массив с результатами БПФ
  */
 public static double[] jcudaTransformDeviceMemory(float[] inputData){

     float[] fftResults = new float[inputData.length + 2];

     // указатель на устройство
     Pointer deviceDataIn = new Pointer();
     // выделение памяти на видеокарте для входных данных
     JCuda.cudaMalloc(deviceDataIn, inputData.length * 4);
     // копирование входных данных в память видеокарты
     JCuda.cudaMemcpy(deviceDataIn, Pointer.to(inputData), inputData.length * 4, 
          cudaMemcpyKind.cudaMemcpyHostToDevice);
     
     Pointer deviceDataOut = new Pointer();
     // выделение памяти на видеокарте для результатов преобразования
     JCuda.cudaMalloc(deviceDataOut, fftResults.length * 4);

     // создание плана
     cufftHandle plan = new cufftHandle();
     JCufft.cufftPlan1d(plan, inputData.length, cufftType.CUFFT_R2C, 1);

     // выполнение БПФ
     long timeStart = new Date().getTime();
     JCufft.cufftExecR2C(plan, deviceDataIn, deviceDataOut);
     System.out.println("Время преобразования: " + (new Date().getTime() - timeStart)/1000.+" сек");
     
     // копирование результатов из памяти видеокарты в оперативную память
     JCuda.cudaMemcpy(Pointer.to(fftResults), deviceDataOut, fftResults.length * 4, 
             cudaMemcpyKind.cudaMemcpyDeviceToHost);

     // освобождение ресурсов
     JCufft.cufftDestroy(plan);
     JCuda.cudaFree(deviceDataIn);
     JCuda.cudaFree(deviceDataOut);

  return cudaComplexToDouble(fftResults);
 }
 
 /**
  * Выполняет БПФ массива значений с помощью Apache Commons Math
  * 
  * @param inputData - массив входных значений
  * @return массив с результатами БПФ
  */
 public static double[] commonsTransform(double[] inputData){
  
  FastFourierTransformer fft = new FastFourierTransformer();
  long timeStart = new Date().getTime();
  Complex[] cmx = fft.transform(inputData);
  System.out.println("Время преобразования: " + (new Date().getTime() - timeStart)/1000.+" сек");

  double[] fftReults = new double[inputData.length/2 + 1];
  for(int i = 0; i < fftReults.length; i++){
   fftReults[i] = cmx[i].abs();
  }
  
  return fftReults;
 }
 
    /**
     * Метод осуществляет преобразование массива комплексных чисел в
     * массив, содержащий их модули
     * 
     * @param complexData - массив комплексных чисел
     * @return массив модулей комплексных чисел
     */
    public static double[] cudaComplexToDouble(float[] complexData){

     double[] result = new double[complexData.length/2];
     int j=0;
        for(int i=0; i < complexData.length-1; i++) {         
         result[j++] = Math.sqrt(complexData[i]*complexData[i] + complexData[i+1]*complexData[i+1]);
         i++;
        }

     return result;  
    }
    
    /**
     * Выводит на стандартный вывод первое, среднее 
     * и последнее значения массива
     * 
     * @param data - массив, значения которого необходимо вывести
     */
    public static void printSomeValues(double[] data){    
     System.out.println("[0]: "+data[0]);
     System.out.println("["+(data.length/2)+"]: "+data[data.length/2]);
     System.out.println("["+(data.length-1)+"]: "+data[data.length-1]);
    }
}

Результат выполнения программы:

Генерация входных данных размером 8388608 значений...

1D БПФ с использованием apache commons math...

Время преобразования: 92.851 сек

[0]: 4195107.645827353

[2097152]: 1411.8392665442454

[4194304]: 114.60465306043625

1D БПФ JCufft (данные в оперативной памяти)...

Время преобразования: 0.085 сек

[0]: 4195107.922955976

[2097152]: 1411.791370918522

[4194304]: 114.75

1D БПФ JCufft (данные в памяти видеокарты)...

Время преобразования: 0.0 сек

[0]: 4195107.922955976

[2097152]: 1411.791370918522

[4194304]: 114.75

Как видно из результатов выполнения программы, выполнение БПФ с помощью CUDA на несколько порядков быстрее, чем при использовании Apache Commons Math, а при использовании памяти видеокарты оно вообще происходит меньше миллисекунды, что, согласитесь, просто "сносит башню"! :) Но тут необходимо принять во внимание тот факт, что в программе измеряется только выполнение самого преобразования и не учитываются временные издержки на нахождение модуля комплексных данных, выделение памяти под массивы, копирование данных между видеокартой и хостом и т.п., а эти издержки имеют место быть. Поэтому если у вас есть задача в которой вам пригодилось бы использование CUFFT, то лучше сначала провести исследование стоит ли вам использовать память видеокарты или нет. Однако, если нужна двойная точность, то вариантов кроме как копировать данные на видеокарту и обратно нет. Кстати, по поводу двойной точности. В результате выполнения программы можно заметить, что результаты преобразование с помощью Apache Commons Math несколько отличаются от результатов CUFFT. Это происходит как раз из-за того, что в Commons используется двойная точность, а в CUFFT мне пришлось использовать одинарную по причине староватости видеокарты.

Баг kdesu в openSUSE 11.4

2011-07-23T15:18:00.001+04:00

Столкнулся в openSUSE 11.4 с тем, что мои замечательные скрипты выбора конфигурации сети, вдруг перестали нормально работать. Довольно быстро мне стало понятно, что сердце неприятности заключается в программе kdesu. Здравствуй, новый KDE! Суть проблемы была в том, что после ввода в диалоговом окне пароля суперпользователя ничего не происходило, а должен был запуститься скрипт с соответствующими правами. Я перекопал весь интернет и не нашел ничего лучше, чем удалить (а точнее просто переименовать на всякий случай) файл /usr/lib/kde4/libexec/kdesud. После этого всё вроде бы заработало, но теперь kdesu стал ругаться, что не может найти своего друга-демона и что это вроде как небезопасно. Ну и хрен с ним, пусть боится.

Instant Messenger'ы в Linux. Сборка qutIM 0.3 beta в openSUSE 11.4

2011-07-22T06:26:00.003+04:00

По моему сугубо личному мнению, в Linux, если рассматривать его как систему для десктопного использования, существует две бросающихся в глаза проблемы: отсутствие приятных в использовании мультимедиа проигрывателей и отсутствие таких же приятных Instant Messenger'ов. В этой статье я хочу поговорить о последних.

Не знаю кому как, но мне всем известные Kopete и Pidgin кажутся страшненькими и неудобными. Хочется что-то попроще, но симпатичное. Что-то вроде того, чем раньше был QIP, только многопротокольное. И достаточно давно я открыл для себя qutIM. Думаю, что сегодня у него уже достаточно много пользователей. Первая версия, которую я себе поставил была 0.1 (то ли альфа то ли бета). Когда я её увидел, то сразу понял, что это то, чего мне так не хватало для счастья. Конечно, глючило это создание прилично, но мне было всё равно, главное, что глаз радовало.

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

Несколько дней назад я решил попробовать 0.3 beta, и тут меня поджидало разочарование. Внешне всё сильно изменилось, и для меня не в лучшую сторону. Вдобавок появилось очень много новеньких глюков. Понятно, конечно, что это бета-версия, но дело даже не в глюках. Я по-прежнему готов с ними мириться. Такое чувство, что проект пошел в ту же сторону, где сидят Kopete и Pidgin. Я говорю, главным образом, о простоте и органичности интерфейса, а также о понятности настроек. Пока что я решил остаться на версии 0.2, но продолжу следить за проектом, вдруг снова станет лучше. А пока расскажу, как собрать 0.3b в openSUSE 11.4, и делается это довольно просто, что приятно.

Сначала ставим все необходимые для сборки пакеты:

zypper install cmake make gcc git libqt4 libqt4-devel xscreensaver libidn libidn-devel libpurple-devel libqca2 libqca2-devel cyrus-sasl cyrus-sasl-devel libQtWebKit4 libQtWebKit-devel 

Создаем себе какой-нибудь каталог и переходим в него, например:

mkdir ~/SRC

cd ~/SRC

Тащим исходники с git-репозитория:

git clone git://github.com/euroelessar/qutim.git

cd qutim

git submodule update --init --recursive

На вики qutIM сказано, что если при выполнении git submodule update --init --recursive возникают ошибки, то необходимо запустить команду еще раз. У меня ошибок не было.

Создаем каталог для билда и переходим в него, например:

mkdir ~/SRC/qutim-build

cd ~/SRC/qutim-build

Запускаем cmake:

cmake ~/SRC/qutim

Сначала я не установил пакет libQtWebKit-devel и cmake руганулся так:

CMake Error: The following variables are used in this project, but they are set to NOTFOUND.

Please set them or make sure they are set and tested correctly in the CMake files:

QT_QTDECLARATIVE_INCLUDE_DIR (ADVANCED)

used as include directory in directory /home/eqlbin/SRC/qutim/plugins/qmlchat

QT_QTWEBKIT_INCLUDE_DIR (ADVANCED)

used as include directory in directory /home/eqlbin/SRC/qutim/core/src/corelayers/kineticscroller

used as include directory in directory /home/eqlbin/SRC/qutim/core/src/corelayers/adiumchat/chatfactories/webkitchat

QT_QTXMLPATTERNS_INCLUDE_DIR (ADVANCED)

used as include directory in directory /home/eqlbin/SRC/qutim/plugins/yandexnarod

-- Configuring incomplete, errors occurred!

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

cmake -DQMLCHAT=0 -DYANDEXNAROD=0 ~/SRC/qutim

Если же cmake прошел удачно, то запускаем make:

make

Для установки необходимо выполнить make install с правами root:

make install

Теперь можно запустить qutIM из командной строки:

qutim

В заключении хочу сказать, что около года назад я начал следить ещё за одним довольно интересным проектом MDC. Это также мультипротокольный месенджер, который выглядит немного странно, на мой взгляд, но очень даже достойно. На официальном сайте есть статическая сборка, которая на openSUSE 11.4 запускается без проблем, хотя глюки в работе тоже случаются, конечно, куда же без них :)

Как узнать полный путь до запущенного bash-скрипта

2011-04-21T07:58:00.004+04:00

Иногда нужно знать, в каком каталоге находится запущенный скрипт. Ну, например, в этом же каталоге лежат другие скрипты, которые должны быть запущены текущим выполняющемся скриптом. Для того, чтобы он их запустил, ему было бы неплохо знать, где их искать, потому что вы могли запустить скрипт находясь в совершенно произвольной директории, или воспользоваться для запуска не самим файлом скрипта, а символической ссылкой, лежащей в другом каталоге, которая указывает на файл скрипта.

Можно, конечно, поступить просто и в самом скрипте в переменной жёстко прописать полный путь до каталога, в котором этот скрипт лежит. Получится что-то вроде этого:

#!/bin/bash

DIRECTORY="/home/user/my_scripts"
cd $DIRECTORY

# запуск "соседних" скриптов
./script1.sh
./script2.sh

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

Для красивого решения проблемы нужно знать всего три вещи:

Путь до выполняющегося скрипта можно узнать с помощью $0, но проблема в том, что он относительный, т.е. если вы запустите скрипт как ./script.sh, то и $0 будет содержать ./script.sh
Команда readlink с параметром -e решит сразу две проблемы: во-первых она вернет полный путь до файла скрипта, если вы воспользовались для запуска символической ссылкой (даже если это была цепочка симлинков), а во-вторых преобразует относительный путь, если такой получен с помощью $0, в абсолютный
Чтобы избавиться от имени файла скрипта в конце абсолютного пути, нужно воспользоваться командой dirname

Пример:

#!/bin/bash

# полный путь до скрипта
ABSOLUTE_FILENAME=`readlink -e "$0"`
# каталог в котором лежит скрипт
DIRECTORY=`dirname "$ABSOLUTE_FILENAME"`

# запуск "соседних" скриптов
$DIRECTORY/script1.sh
$DIRECTORY/script2.sh

Прикручиваем кнопки "Поделиться" от Яндекса к www.blogger.com

2011-04-04T08:07:00.004+04:00

Захотелось мне прикрутить к блогу эти самые кнопочки. Напишу пару слов о том, как я это сделал.

Сначала идём по адресу http://api.yandex.ru/share/, настраиваем вид блока "Поделиться" и выбираем сервисы, в которые хочется постить с его помощью. Получаем код, вроде этого:

Теперь заходим в Панель инструментов -> Дизайн -> Изменить HTML. Ставим галку рядом с "Расширить шаблоны виджета".

Между тегами <head> и </head> где-нибудь втыкаем первую строку из листинга выше. Короче эту:

Дальше надо выбрать место, где хочется разместить эти кнопки. Я решил вставить их под сообщением, ниже автора и времени создания сообщения. Если вас устраивает это место, то ищите в шаблоне строку <span class="post-icons"> и над ней вставляйте оставшуюся часть полученного кода:

Если вы сохраните шаблон и зайдёте на блог, то кнопочки должны будут появиться и будут даже работать, только не всегда правильно. Например, если отдельно открыть страницу с конкретным сообщением блога и там нажать на какую-либо из кнопок "поделиться", то всё отработает правильно. А вот если нажать на одну из этих кнопок под каким-либо сообщением на главной странице, то делёжка будет осуществляться не ссылкой на это сообщение, а ссылкой на главную страницу блога. Для того, чтобы такого безобразия не происходило, нужно элементу DIV добавить атрибуты data-yashareLink и data-yashareTitle, которые позволяют установить ссылку, которой нужно поделиться и заголовок сообщения, соответственно. Но для того, чтобы динамически получать ссылку и заголовок нужно использовать хитрые выражения, которые понимает движок блоггера.

Вот как это выглядит:

В процессе генерации страниц блога выражение expr:data-yashareLink='data:post.url' будет заменено блоггером на data-yashareLink='http://myblog.blogspot.com/путь_до_сообщения', а expr:yashareTitle='data:post.title' на yashareTitle='Заголовок_сообщения'.

Кстати, контейнером для кнопок может быть не обязательно элемент DIV, я использую SPAN. Вот код, который я добавил себе в шаблон:

Красивое использование косвенной адресации в bash-скриптах

2011-03-25T02:53:00.004+03:00

Косвенная адресация это когда, грубо говоря, одна переменная ссылается на какое-либо значение через другую переменную. Если говорить точнее и применительно к bash'у, то это когда одна переменная хранит имя другой переменной, которая в свою очередь содержит, например, какое-либо значение. С помощью косвенной адресации можно, используя первую переменную, сразу получить доступ к значению, которое содержит вторая переменная. Как это работает вроде бы ясно, но, возможно, не сразу понятна нужность всего этого.

Итак, допустим у нас есть переменная X, которая содержит строку "значение". Так же есть переменная Y, которая в качестве значения содержит имя переменной X. Красивость заключается в том, что с помощью прямой и косвенной адресации, используя переменную Y, можно получить соответственно имя и значение переменной X.

Простой пример:

X="значение"
Y=X
echo "$Y: ${!Y}"

В этом примере с помощью прямой адресации $Y мы получаем доступ к имени переменной X, а с помощью косвенной ${!Y} - к её значению. В старых версиях bash косвенная адресация могла использоваться только так eval Z=\$$Y, а начиная со 2 версии она стала выглядеть проще, хотя старый вариант так же может использоваться.

Теперь приведу более жизненный пример. У меня есть скрипт, который настраивает iptables. Косвенная адресация в нем используется для того, чтобы сделать проще изменение настроек скрипта и создать красивый вывод. Приведу пример поясняющий основную суть.

#!/bin/bash

# список сервисов и их портов
SSH=22
HTTP=80
HTTPS=443
SAMBA="137 138 139 445"

# локальные сервисы на которые разрешен доступ снаружи
INPUT_PORTS_ACCEPT="SSH SAMBA HTTP HTTPS"

echo "Удаленный доступ к сервисам хоста:"
# открываем доступ на разрешенные сервисы
for SERVICE_NAME in $INPUT_PORTS_ACCEPT
do
    # для каждого порта сервиса добавляем разрешающие правила в iptables
    PORTS=${!SERVICE_NAME} # устаревший вариант: eval PORTS=\$$SERVICE_NAME
    for PORT in $PORTS
    do
        iptables -t filter -A INPUT -i eth0 -p tcp --dport $PORT -j ACCEPT
        iptables -t filter -A INPUT -i eth0 -p udp --dport $PORT -j ACCEPT
    done

    # выводим имя и порты сервиса
    echo "$SERVICE_NAME: $PORTS --accept"
done

Вывод скрипта:

Удаленный доступ к сервисам хоста:

SSH: 22 --accept

SAMBA: 137 138 139 445 --accept

HTTP: 80 --accept

HTTPS: 443 --accept

Таким образом, для настройки скрипта в переменной INPUT_PORTS_ACCEPT нужно указывать не номера портов, а просто имена сервисов, и в выводе наглядно показано на какие локальные сервисы открыт доступ и какие порты им соответствуют. Красиво :)

JDOM: работа с XML на Java - проще простого

2011-03-11T06:35:00.005+03:00

JDOM – это максимально упрощенная open source Java-библиотека для создания, парсинга, изменения и сериализации XML-документов. В отличие от других подобных DOM APIs, JDOM ориентированна на язык Java, а не на спецификации XML, что очень упрощает код и облегчает его интуитивное понимание. При этом JDOM не является "велосипедом" и не содержит в себе свой собственный парсер, а использует уже существующие наработки – стандартные пакеты javax.xml и org.xml.sax. Если вам понадобилось работать с XML, то обратите сначала внимание именно на эту библиотеку, скорее всего вам она понравится.

Краткое описание модели библиотеки JDOM

Так же, как и сам XML, JDOM APIs являются древовидными. Для представления XML в библиотеке, главным образом, используются классы Document, Element и Attribute.

Документ XML в JDOM представляет из себя дерево, корнем которого является объект класса Document. Экземпляр Document является контейнером для всех остальных элементов и обязательно содержит один корневой элемент (экземпляр Element). Главной характеристикой объекта Element является его содержание (Content) и список атрибутов (Attribute). Класс Content является родительским для классов Element, Comment и Text (а так же для некоторых других), поэтому экземпляры перечисленных классов могут быть содержимым объекта Element. Объект Element есть ничто иное как XML-тег, у которого обязательно должно быть имя и могут быть атрибуты. Классы Comment и Text соответственно представляют комментарий и текст внутри тега. Экземпляры Attribute, Comment и Text не могут содержать внутри себя никаких элементов и по сути являются объектами, которые содержат только текстовые значения. Значение экземпляра Attribute может быть получено по имени в отличие от Comment и Text, у которых имени нет.

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

Представленный документ является списком глав подразделений компании. Документ для простоты содержит всего два руководителя (<head>). У каждого элемента <head> есть атрибут id, а в качестве содержания – комментарий, кратко описывающий руководителя и элементы <name> и <department>, которые в свою очередь содержат текст, представляющий имя руководителя и название подразделения соответственно.

Теперь посмотрим, как будет выглядеть сам XML.

<?xml version="1.0" encoding="UTF-8"?>
<Head_list>
  <head id="1">
    <!--Head of IT department-->
    <name>Petrov P.</name>
    <department>IT</department>
  </head>
  <head id="2">
    <!--Head of Sales-->
    <name>Sidorov S.</name>
    <department>Sales</department>
  </head>
</Head_list>

Создание XML-документа

Для того чтобы создать XML-документ в общем случае необходимо выполнить следующие этапы:

Создать экземпляр Document
Создать корневой Element и добавить его в экземпляр Document
Создать и заполнить, начиная с корневого элемента, необходимое дерево с помощью экземпляров Element, Attribute, Comment и т.д.
Если необходимо, вывести (например в файл) созданный документ как поток байт с помощью класса XMLOutputter.

Пример метода, который создаёт описанное выше XML-дерево и выводит его на стандартный вывод, а так же в файл Heads.xml.

private static void createXMLDocument(){
      
        // Создаем документ
        Document xmlDoc = new Document();
        // Создаем корневой элемент
        Element root = new Element("Head_list");
        // Добавляем корневой элемент в документ
        xmlDoc.setRootElement(root);
        
        // Создаем элемент head и добавляем ему атрибут
        Element head1 = new Element("head");
        head1.setAttribute("id", "1");
        // Добавляем комментарий в контент элемента head
        head1.addContent(new Comment("Head of IT department"));

        // Создаем элемент name и добавляем в него текст
        Element name1 = new Element("name");
        name1.addContent("Petrov P.");
          
        // Добавляем элемент name в элемент head
        head1.addContent(name1);
          
        // Создаем элемент department
        Element department1 = new Element("department");
        department1.addContent("IT");
        head1.addContent(department1);
          
        // Добавляем элемент head в корневой элемент
        root.addContent(head1);
      
        // Еще один элемент head создадим более кратко
        root.addContent(new Element("head").setAttribute("id","2")
                        .addContent(new Comment("Head of Sales"))
                            .addContent(new Element("name").addContent("Sidorov S."))
                            .addContent(new Element("department").addContent("Sales"))
                         );
       
        try {
            // Получаем "красивый" формат для вывода XML
            // с переводами на новую строку и отступами
            Format fmt = Format.getPrettyFormat();  

            // Выводим созданный XML как поток байт на стандартный
            // вывод и в файл, используя подготовленный формат
            XMLOutputter serializer = new XMLOutputter(fmt);
            serializer.output(xmlDoc, System.out);
            serializer.output(xmlDoc, new FileOutputStream(new File("Heads.xml")));
        }
        catch (IOException e) {
            System.err.println(e);
        }
  }

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

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

Форматом вывода можно управлять с помощью класса org.jdom.output.Format. Например, можно установить отступ, символ новой строки, кодировку вывода, указать как следует выводить пустые элементы (<empty/> или <empty></empty>), установить автоматическое удаление лишних пробельных символов и т.д..

Разбор XML-файла

Работа с существующим XML-файлом состоит из следующих этапов:

Создание экземпляра класса org.jdom.input.SAXBuilder, который умеет строить JDOM-дерево из файлов, потоков, URL и т.д.
Вызов метода build() экземпляра SAXBuilder с указанием файла или другого источника.
Навигация по дереву и манипулирование элементами, если это необходимо.

С первыми двумя пунктами все предельно ясно, а вот навигация по дереву может осуществляться множеством способов.

Для того, чтобы пробежаться по всем элементам дерева (экземпляры Element), можно воспользоваться методом getChildren(), что бы получить список List всех дочерних экземпляров корневого Element, а затем для каждого дочернего элемента так же вызвать getChildren() и т.д.

Пример использования getChildren()

public static void listChildren(Element element) {
    System.out.println(element.getName());
    List children = element.getChildren();
    Iterator iterator = children.iterator();
    while (iterator.hasNext()) {
      Element child = (Element) iterator.next();
      listChildren(child);
    } 
}

Можно поступить по-другому – использовать методы getContent() и getDescendants(), передавая им фильтры для того что бы ограничить выборку.

Метод getContent() возвращает список List вложенных элементов, причем поиск осуществляется только на глубине 1 уровня. Таким образом, с помощью getContent() можно получить дочерние элементы объекта у которого вызывается данный метод, но нельзя получить дочерние элементы его дочерних элементов.

Метод getDescendants() возвращает Iterator по всем найденным элементам, но в отличие от getContent() поиск ведется на всех уровнях вложенности элементов.

Как я уже сказал, для ограничения выборки дочерних элементов в обоих методах можно использовать фильтры. Фильтры это классы, которые реализуют интерфейс org.jdom.filter.Filter. В библиотеке JDOM есть два готовых класса фильтра, реализующих этот интерфейс: org.jdom.filter.ContentFilter и org.jdom.filter.ElementFilter. Используя фильтр ElementFilter, можно осуществлять поиск объектов Element ограничивая его именем элемента и/или пространством имен (Namespace), а с помощью ContentFilter можно ограничивать поиск определенным "видом" элемента, например, получить все комментарии и текст, которые содержит элемент или только текст и в таком духе. В тоже время интерфейс Filter очень прост и требует реализации лишь одного метода matches(java.lang.Object obj), который возвращает true в случае если элемент obj соответствует заданным параметрам фильтра, поэтому довольно легко можно создавать свои изощеренные фильтры.

Теперь приведу пример метода, который парсит созданный ранее XML-файл.

private static void readXMLDocument() {
      SAXBuilder parser = new SAXBuilder();
      Document xmlDoc;
      
      try {
        xmlDoc = parser.build(new File("Heads.xml"));

        System.out.println("Heads:");
        
        // Получаем список всех элементов head, которые 
        // содержит корневой элемент 
        List elements = xmlDoc.getRootElement()
                            .getContent(new ElementFilter("head"));      
        
        // Для каждого элемента head получаем значение атрибута
        // id и текст вложенных элементов name и department
        Iterator iterator = elements.iterator();
        while(iterator.hasNext()){          
            Element head = (Element)iterator.next();
            String id = head.getAttributeValue("id");           
            String name = head.getChildText("name");
            String department = head.getChildText("department");
         
            System.out.println(id+": "+name+" - "+department);
        }
        
        System.out.println("Comments:");
        
        // Получаем все комментарии в документе и выводим для 
        // каждого его значение и имя элемента, который содержит
        // этот комментарий
        iterator = xmlDoc.getDescendants(new ContentFilter(ContentFilter.COMMENT));
        while(iterator.hasNext()){    
            Content comment = (Content)iterator.next();
            System.out.println(comment.getParentElement().getName()+": "+ comment.getValue());
        }
      } catch (JDOMException e) {
        e.printStackTrace();
      } catch (IOException e) {
        e.printStackTrace();
      }
  }

После выполнения метода на консоль будет выведено следующее:

Heads:

1: Петров - IT

2: Sidorov S. - Sales

Comments:

head: Head of IT department

head: Head of Sales

Изменение дерева осуществляется с помощью различных методов вроде removeChild(), removeChildren(), removeContent(), addContent(), setContent(), removeAttribute(), setAttribute(), setName(), setText() и т.д. и т.п., думаю что это и так понятно.

Более подробную информацию о JDOM можно найти на официальном сайте, а так же в главах 14 и 15 свободно доступной книги о работе с XML на Java (всё на английском).