Category Archives: Tools
Научился сегодня по-простому делать профили а-ля мавно. Рецепт таков:
1) Создаём файл defaults.gradle. В нём будут лежать значения свойств по умолчанию, например:
allprojects { ext { // Solr connection host = 'localhost' port = '8983' username = '' password = '' } } project(':crawler') { // SQL Server connection project.ext["jdbc.url"]='jdbc:jtds:sqlserver://...' project.ext["jdbc.username"] = 'user' project.ext["jdbc.password"] = 'passasdf' project.ext["jdbc.driverClassName"]='net.sourceforge.jtds.jdbcx.JtdsDataSource' } |
2) Для каждого профиля создаём файл с именем profile-${profile}.gradle, например, файл profile-stage.gradle:
allprojects { ext { host = '234.23.42.3' port = '6001' username = '' password = '' } } |
3) В основной скрипт сборки build.gradle в начало добавляем следующий код:
apply from: "defaults.gradle" if (hasProperty('profile')) { apply from: "profile-${profile}.gradle" } |
Таким образом, defaults.gradle будет применяться всегда, а скрипт, специфичный для конкретного профиля – только если указывается свойство profile.
4) Запустить сборку с указанием профиля:
gradlew -Pprofile=stage :crawler:build
Если вы только что собрали что-то с одним профилем, а потом решили пересобрать для другого, убедитесь, что gradle прознал о том, что что-то надо пересобрать. Например, если вы используете Ant Filtering, то градло не поймёт, что ресурсы надо пересобрать – нужно явно выполнить clean.
Сегодня Тимур мне рассказал, что для градла есть удобнейшая штука – враппер. Например, вы используете gradle с версией X (икс). И ваш скрипт сборки точно будет работать на этой версии. Будет ли он работать на других версиях – вопрос. Программист, скачавший ваш репозиторий с кодом и скриптами сборки, вынужден будет установить у себя такую же версию градла. Неудобно. Но градло спешит на помощь ! Можно добавить в build.gradle следующее:
task wrapper(type: Wrapper) { gradleVersion = '2.0' // Желаемая версия } |
и после этого выполнить команду gradle wrapper, которая сгенерирует следующие файлы:
gradlew gradlew.bat gradle/wrapper/ gradle-wrapper.jar gradle-wrapper.properties |
Эти файлы нужно закоммитить (да-да, джарник тоже, но он крошечный). И теперь чтобы собрать проект, достаточно вместо gradle использовать gradlew:
gradlew build |
Враппер сам скачает нужную версию градла, поместит её в .gradle-кеш и использует её для сборки. Таким образом, пользователю, скачавшему ваш репозиторий, вообще ничего не нужно делать, кроме запуска bat-файла (или shell-скрипта в не-Windows системах) ! Вот такой вот best practice. Разве не блистательно ?
Узнал о приложении Secure Shell – ssh-клиенте и эмуляторе терминала, работающем в броузере. Меня удивило, что эта штука, написанная на js, действительно работает – неужели протокол ssh с шифрованием действительно был реализован на javascript? Или он проксирует данные через внешний сервер, передавая туда сочетания клавиш, а обратно получая команды для эмулятора терминала в plain text ? При этой мысли по спине пробежал холодок. Я только что подключался к одному серверу и ввёл там правильный пароль. Если догадка верна, то мой пароль мог легко попасть к злоумышленникам. В общем, пришлось поковырять поглубже, чтобы выяснить, как всё работает.
После изучения FAQ, исходников и файлов, поставляемых с расширением, выяснено было следующее:
-
Это приложение написано в рамках проекта
Chromium OS, и его исходники открыты. -
Оно действительно написано на js, но реализации ssh в нём нет, но есть нативный плагин, встроенный в расширение при помощи технологии
Native Client. В нём-то и лежит реализация ssh-протокола, а доступ к нему осуществляется через джаваскриптовое API, предоставляемое броузеромGoogle Chrome. -
Но механизм проксирования также присутствует ! Называется он
Relay Server, и иногда работает. Из документации непонятно, при каких ситуациях используется именно этот режим. Написано что по умолчанию используется native client, но можно и специально заставить использовать relay, указав его опции в строкеRelay options. Почему-то списка доступных настроек найти не удалось. По исходникам тоже непонятно, в каком случае используется native client, а в каком – relay server. Исходные коды гуглового relay сервера закрыты, в комментариях написано, что “Вы можете написать такой сервер сами, вам достаточно зареверсинжинирить такой-то js-файл”. -
Есть джавский relay-сервер в открытых источниках: https://github.com/zyclonite/nassh-relay/
Демосервер, на нём можно проверить работу https://relay.wsn.at/
Заодно мы узнаём опции, которые нужно добавить в строку relay options:
--proxy-host=relay.wsn.at --proxy-port=443 --use-ssl
Решил проверить этот сервер, не вводя там правильного пароля – всё заработало, но строка Loading Native Client всё равно смущает. Попробовал удалитьssh_client_nl_x86_64.nexe, после этой операции Secure Shell не хотел подключаться, хотя опции для релея были. -
Вот ещё один relay-server, здесь уже на пейтоне: https://github.com/raptium/hashi
Выглядит очень лаконично, по сравнению с джавской реализацией. Заодно узнаём ещё один способ задания relay-server:
To connect via the relay server, use USER@SSH_SERVER[:SSH_PORT]@RELAY_SERVER as the destination in the secure shell. -
Native Client – очень интересная фигня. Файлы nexe, поставляемые с расширением, разные для разных процессорных платформ, но одинаковые для операционных систем. То есть
ssh_client_nl_x86_64.nexeможет успешно использоваться и на Windows, и на Linux, и на Mac OS X, главное чтобы система была 64-битная. Это обстоятельство меня смутило, т.к. проводя первичный осмотр в Total Commander, я обнаружил, что эти файлы начинаются с ELF, а значит, что это либо работает только на линуксах, либо где-то дальше в файле лежат нативные файлы в других форматах –PE,dylib. Такой типа самопальныйfat executable. Но всё оказалось ещё интереснее. Выяснилось, что гугл в этом месте не хранит нативный готовый код, а какой-то байткод, получаемый на выходе nacl-toolchain. В сети упоминался байткод LLVM, но тут пока неясно, в чём отличие pexe от nexe. pexe не зависит от платформы, nexe-зависит. Интересно, чем они отличаются внутри. С этим пока разобраться не удалось.
Дополнительный прикол заключаются в том, что эти бинарники безопасны, хотя и содержат нативный код. Дело в том, что они могут быть собраны только с теми библиотеками, которые портированы вnacl-ports. А верификатор броузера при загрузке этого кода проверяет, не содержит ли он потенциально небезопасных инструкций – к таким, например, относятсяsyscallиint.
Общий вывод
Secure Shell скорее всего безопасен для применения, но точно не ясно, при каких случаях может включаться механизм проксирующих серверов, который небезопасен по своей сути. При paranoid_mode = ON лучше либо не пользоваться этой тулзой, либо до конца разобраться в логике включения релеев.
0