воскресенье, 18 января 2015 г.

Kibana3 и Elasticsearch 1.4: Error Could not reach http://IP-АДРЕС-СЕРВЕРА:9200/_nodes. If you are using a proxy, ensure it is configured correctly

Осваиваю по тихоньку docker и при запукске в нем logstash+elasticsearch+kibana3 столкнулся с тем, что kibana3 ругается в браузере на до, что не может подключиться к:http://192.168.59.103:9200/_nodes.


Error Could not reach http://192.168.59.103:9200/_nodes. If you are using a proxy, ensure it is configured correctly
Лечится добавлением в elasticsearch.yml:

http.cors.allow-origin: "/.*/"
http.cors.enabled: true


https://gist.github.com/rmoff/379e6ce46eb128110f38

понедельник, 12 мая 2014 г.

Если AnyConnect говорит "The AnyConnect client service is not responding..." под Mac OSX 10.9.

Если AnyConnect говорит "The AnyConnect client service is not responding. A VPN connection cannot be established. Contact your system administrator" под Mac OSX 10.9 и пока не нажимаешьь "OK" данные в туннель передаются, то в случае если адрес получаете по dhcp на интерфейсе с которого стартует AnyConnect, проверьте не прописан ли руками dns сервер.
Если прописан, то удалите его (что бы dns сервер приходил по dhcp).

Два дня бился над этой бага-фичей и случайно обнаружил такую тонкость.
Версия AnyConnect клиента на которой проблема воспроизводится 3.1.05160.

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

Если на ssh подключение получаете Connection closed by, хотя ssh точно работает на удаленной стороне

ssh hostname
Connection closed by hostname

а при -v видно:
debug1: Local version string SSH-2.0-OpenSSH_6.6p1 Ubuntu-2ubuntu1
debug1: Remote protocol version 1.99, remote software version Cisco-1.25
debug1: no match: Cisco-1.25
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<3072 div="" sent="">
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP

то необходимо добавить в ~/.ssh/config:

KexAlgorithms=diffie-hellman-group14-sha1,diffie-hellman-group1-sha1


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

Адресная книга в kmail и ldap с self-signed сертификатом.

Что бы адресная книга kde могла исполользовать ldap сервер с self-signed сертификатом достаточно добавить "TLS_REQCERT allow" в ~/.ldaprc.


четверг, 19 декабря 2013 г.

avahi-daemon и .local домен.

Столкнулся сегодня с интересной проблемой:
если используется домен .local, то nslookup отлично отрабатывает, но если попытаться, например, пропинговать машину по fqdn в этом домене, то получаем ошибку "unknown host". Расследование показало, что во всем виноват avahi-daemon.
Что бы восстановить работу dns резолвинга для зоны .local в Debian Jessie:
➜ Downloads diff /etc/nsswitch.conf /etc/nsswitch.conf-orig
11c11
< hosts: files dns mdns4_minimal [NOTFOUND=return] mdns4
---
> hosts: files mdns4_minimal [NOTFOUND=return] dns mdns4
 

четверг, 10 ноября 2011 г.

Установка virtual pc в win7

Понадобилось мне сегодня установить одну программу, которая не работает под Windows 7 64bit. В качестве решения выбрал установку XP mode, благо у меня стоит Windows 7 Pro и поэтому могу официально установить virtual pc с образом Windows XP. Но не все оказалось так просто, установка virtual pc обрывалась на 96% и начинался откат назад. После нескольких неудачных попыток установки, начал гуглить и нашел решение проблемы (ссылка на форум с решением проблемы). Оказалость достаточно поправить регистр в ветке HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Network\MaxNumFilters значение с 8 (8 в десятичной системе) на 10 (16 в десятичной системе).

воскресенье, 23 октября 2011 г.

Проблемы с DNS resolving в 10.7 Lion

В четверг подключил кабельный интернет по технологии docsis (в Москве этим Акадо занимается, в Брно мой дом подключен к upc.cz). А за пару дней до этого обновил 10.7.1 до 10.7.2. Не знаю в 10.7.2 или еще раньше, но поломался dns resolving. Куча сайтов открывалось с огромными задержками. Использование nslookup показало, что очень долго происходит разрешение имен, а некоторый dns запросы вообще заканчивались не успешно. Поиски в гугле показали наличие проблем с Lion и dns. Но они другого характера были у людей, но все же в одном из постов на всякий случай поставили кеширующий dns сервер (dnsmasq). Я у себя его тоже поставил, и проблема исчезла. Все работает как надо.
Как ставить dnsmasq на Lion (я использую homebrew (http://mxcl.github.com/homebrew/)):
  1. ставим dnsmasq: brew install dnsmasq
  2. выполняем те команды, которые homebrew выведет на экран терминала
  3. на всякий случай говорим dnsmasq использовать не /etc/resolv.conf, а свой файл со списком dns сервером:
    1. cp /etc/resolv.conf /etc/resolv.dnsmasq.conf . В нем указываем пару публичный сервером (я использую 8.8.8.8 и 8.8.4.4)
    2. редактируем /usr/local/etc/dnsmasq.conf и добавляем туда строку "resolv-file=/etc/resolv.dnsmasq.conf"
  4. перезапускаем dnsmasq: для этого в Activity Monitor убиваем процесс dnsmasq, после чего он перезапускается автоматически.
  5. в System Preferences в сетевых настройках прописываем в качестве dns сервера адрес 127.0.0.1
UPD: Откатываю все назад, так как оказалось все проще. Оказывается все это время у меня был доступ к веб-инетрфейсу цисковского модема. Сегодня защел на него и проверил логи, а там куча сообщений о том что мой макбук флудит в сторону dns сервером, поэтому давайте заблочим их. Вырубил проверку флудинга и все заработало.