Немножко про тюниг GC в Java

Для начала немножко хороших статеек:

http://www.oracle.com/technetwork/java/hotspotfaq-138619.html#gc_pause
http://www.petefreitag.com/articles/gctuning/

А все потому что было приложение, которое тормозило. А тормозило потому что много новых объектов создавалось и бросалось. И никак это пофиксить было нельзя. Но чуть увеличенные Xms и Xmx и смена GC на CMS решили практически все.

Используем git для работы с SVN

Во-первых, почему? Ну, просто эта методика весьма удобна для работы с opensource-проектами, так как даже если вы решите написать патч или наковырять собственную ветку, вам не придется плясать вокруг создания и синхронизации репозитория SVN для своих нужд - в git это все будет "из коробки". Ну и популярность git нынче растет, и вам наверняка не хочется отставать от тренда. Если еще и учесть то, насколько распределенный и легко ветвящийся git удобен, вопросов "почему", остается мало.

В git есть git-svn - интерфейс для работы с SVN, который позволит забирать весь SVN-репозиторий с историей изменений и затем даже коммитить в него.

Возьмем самый циничный пример - заберем исходные коды одного из сторонних модулей для asterisk (более мелкого проекта с svn найти быстро не смог) :)

git svn clone http://www.makhutov.org/svn/chan_datacard/trunk/ chan_datacard

Это создаст локальный git-репозиторий в текущем каталоге, подключится к SVN-репозиторию и заберет его со всеми ревизиями.
Теперь вы можете работать с ним как с обычным git-репозиторием. Делать diff-ы. Гулять по истории версий. Ответвляться от нужной ревизии и поддерживать свою собственную ветку своих патчей. Да-да. Вы можете коммитить в этот git-репозиторий. А потом, в случае чего, можно отправить изменения и в svn:

git svn dcommit

Ах, эти глупые заморочки с лицензиями

Не знаю, чем руководствуются некоторые компании, но мне кажется, что излишние сложности в лицензировании Trial-версий продуктов никак не помогают их продвижению.
Вчера мне захотелось поглядеть, поковырять, изучить в чистой виртуалочке дома ISPManager. Есть такая хостинговая панель, некоторые говорят, адекватная.
Идем на сайт производителя - качаем инсталлер. Инсталлер, на деле - shell-скрипт, первым делом определяет, есть ли у тебя лицензия для продукта, затем скачивает его, распаковывает и пытается запустить.
Регистрируемся, делаем лицензию. После 3-4 попытки понимаем, что инсталлер проверяет лицензию очень просто - если ваш публичный IP и введенный при регистрации адрес IP совпали, значит лицензия есть. Т.е. если у вас публичный IP динамический, вам надо успеть создать лицензию и установить продукт, иначе вы в пролете. Это первая сложность.
Вторая заключается в том, что, видимо, сама система проверки лицензии на уже установленной копии требует наличия этого "лицензированного" адреса прямо на самой машине, где оно работает. То есть, виртуалка с приватным IP за NAT уже в пролете. (И да, оно действительно утверждало, что лицензия неверная). В общем, через полчаса борьбы с этим зверем я решил что разбираться и ковыряться не буду. А ведь если понравилось бы, я бы может порекомендовал кому-нибудь эту штуку, установил, настроил, а компания ispsystem имела бы профит. Но, похоже что он ей не очень нужен.

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

Как я тупняки и глюки Firefox полечил

Признаться, профиль у Firefox был довольно-таки древний. Я помню, что не трогал его уже порядка 2-3 лет, хотя иногда делал vacuum, FF обновлялся, еще начиная с 3-й версии.

У меня не работала правильно авторизация на Хабре. То есть как-бы работала, но после входа появлялась чистая страничка с надписью ОК. Саппорт сказал что виноваты расширения. Я отключил их все. Это не помогло.
У меня глючил веб-интерфейс iLO, а точнее его Java-апплет. Я пробовал отключать расширения и менять виртуальные машины Java. Это не помогало.
Но вот переименовать .mozilla и позволить ему создать новый профиль - очень даже. Кроме того, оно как-то стало работать по-космически шустро, намного лучше чем раньше.
Единственный геморрой - настроить его снова так же, как он был настроен. Но это постепенно удастся.

Кроссплатформенный путь для проверки порта TCP

Много раз видел, как новички мучаются, пытаясь для этого установить nmap. Или мучаются еще больше, пытаясь установить его на Windows. Но в обеих системах есть утилита telnet, которая прекрасно позволяет проверить, можно ли установить соедиенение с tcp-портом или нет.

Вот такой вывод обычно подсказывает, что соединение установить можно:
$ telnet localhost 80
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.

А вот такой - что нельзя. И скорее всего потому что порт не прослушивается каким-либо приложением (либо незаметно закрыт фаерволом с REJECT --with tcp-reset)
$ telnet localhost 81
Trying 127.0.0.1...
telnet: Unable to connect to remote host: Connection refused

Многие очень расстраиваются, если telnet после установки соединения не выходит.
Для того чтобы выйти из telnet в этом случае, нужно нажать то что называется Escape character - telnet нам его подсказывает - это Ctrl + ]. После этого вы увидите приглашение встроенной оболочки telnet (если не видно, попробуйте нажать enter), в котором можно просто набрать quit.

Еще один хинт - если вы вдруг куда-то (например, на другую систему) все-таки ходите через telnet и запустили telnet там, то ^] сработает для вашего локального telnet, но не для того, что запущен удаленно. Это решаемо. Выходим в оболочку локального telnet - ^] и меняем escape character на новый:
^]

telnet> set escape ^B

После этого ^] уже будет срабатывать для удаленного telnet-клиента (что логично).

В свеженьких Windows 7 telnet почему-то из установки по-умолчанию выпилили, так что придется ее сначала установить через панель управления. Это добавит геморроя для техподдержки, Microsoft, так держать :)

HTTP сервер на python

Очень полезен, чтобы отдать 1-2 файлика по http и не настраивать настоящий большой вебсервер :)
$ python -m SimpleHTTPServer
Serving HTTP on 0.0.0.0 port 8000 ...

Корневым каталогом вебсервера становится текущий каталог. Лог выводится в stdout.

Игнорировать псевдоним в bash?

Если у вас есть некий псевдоним, например,

$ alias aptitude='sudo aptitude'

То, оказывается, а я даже не знал, можно его проигнорировать, написав перед псевдонимом обратный слеш:

$ \aptitude

Хотя, конечно, можно было бы сделать это и с помощью указания полного пути:

$ /usr/bin/aptitude

Но все-таки вариант со слешем короче.

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

Настройка клиента amanda для бекапа через ssh

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

emerge --sync, eix-update

Многие начинающие пользователи Gentoo Linux уже знают про eix - утилиту для поиска ebuilds в portage. Они все как один запускают eix-update сразу послее установки, но забывают, что информацию в базе надо обновлять после каждого emerge --sync, ибо она автоматически не обновится.
Можно, конечно, делать эти операции по-отдельности, но eix приходит с утилитой eix-sync, которая выполнит и emerge --sync и eix-update автоматически.

Ограничения ssh через authorized_keys

Почти все знают, что с помощью ~/.ssh/authorized_keys можно разрешить пользователю с определенным RSA/DSA ключем логиниться через ssh. Но мало кто знает, что там же можно ограничить возможности ssh для пользователя. :)

если строчку с ключем, которая обычно выглядит так:
ssh-rsa многобукав user@hostname
поправить на
command="/bin/date" ssh-rsa многабукав ...
То при логине с этим ключем автоматически запустится /bin/date и произойдет logout из системы. Другую команду пользователь запустить не сможет (удобно, если ваш скрипт ходит зачем-то на этот хост - для ограничения его возможностей на всякий пожарный).
from="192.168.1.1" - ключ сработает, только если пользователь пришел с хоста 192.168.1.1, иначе спросит пароль. Умеет маски.
no-port-forwarding - запретит случайно использовать опцию -L для проброса портов.
permitopen="google.com:80" - ограничивает возможности ssh -L только форвардингом порта на google.com:80

Опции можно разделять запятыми:
from="backup.example.com",no-port-forwarding,no-X11-forwarding ssh-rsa AAAAA3Nza.... LiPK== user@backup.example.com

Подробности сего действа можно вычитать в man sshd, секция "AUTHORIZED_KEYS FILE FORMAT". Там есть еще пара опций.