git+ssh через https прокси

В продолжение предидущей темы о работе git из-за прокси.

Собственно, предидущая тема рассчитана на взятие и обновления исходного кода из репозитория (git clone/pull). Отдачу дельты она не подразумевает (git push).
Однако в жизни разработчика наступает момент, когда необходимо что-либо поместить на сервер.

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


И тут на помощь нам приходит corkscrew. На Fedora она есть в репозиториях.

1. Устанавливаем corkscrew (yum install corkscrew)
2. Добавляем в $HOME/.ssh/config следующие строчки

Host github.com
    User git
    HostName ssh.github.com
    Port 443
    ProxyCommand corkscrew 127.0.0.1 9090 %h %p

У меня используется cntlm прокси, поэтому адрес 127.0.0.1 и порт 9090. Если у кого не так, нужно заменить эти значения на те, которые используются в вашей сети.

Теперь git push должен работать из-за прокси.
Если нужен другой сервер с ssh (не github.com), его также нужно добавить в $HOME/.ssh/config


.

Как использовать git из за HTTP прокси с Linux машины

Оригинал статьи на Английском здесь

Собственно суть проблемы.

Все началось с того что я решил вытянуть на работе boost-cmake с gitorious, но так как там большие блобы, то клонирование по http:// протоколу через корпаративный прокси заканчивалось ошибкой 500, где-нибудь в районе 25-30%. Описание проблемы, похоже на приведенное здесь.

Утверждалось, что по git:// схеме такого быть не должно.

1. Собственно предложенный вариант - туннель git протокола через HTTP CONNECT. Данная схема используется для https:// соединений на порт 443. Так как все корпаративные прокси поддерживают данную возможность, то необходимо попросить админа разрешить метод HTTP CONNECT на порт 9418, который используется git.

2. Далее нужна утилита socat - устанавливаем ее со своего Linux репозитория (yum install socat).

3. Создайте исполняемый скрипт с именем gitproxy (или выберите имя на ваше усмотрение) где-нибудь в месте из переменной PATH (например ~/bin):

#!/bin/sh 
# Use socat to proxy git through an HTTP CONNECT firewall. 
# Useful if you are trying to clone git:// from inside a company. 
# Requires that the proxy allows CONNECT to port 9418. 
# 
# Save this file as gitproxy somewhere in your path (e.g., ~/bin) and then run 
#   chmod +x gitproxy 
#   git config --global core.gitproxy gitproxy 
# 
# More details at http://tinyurl.com/8xvpny 
 
# Configuration. Common proxy ports are 3128, 8123, 8000. 
_proxy=proxy.yourcompany.com 
_proxyport=3128 
 
exec socat STDIO PROXY:$_proxy:$1:$2,proxyport=$_proxyport

view rawgitproxy-socatThis Gist brought to you by GitHub.

4. Конфигурируем git на использование данного скрипта (git config --global core.gitproxy gitproxy или имя выбранное вами на шаге 3)

Собственно и все. Теперь git:// URL-ы тоже работают.

Оказалось, действительно, на данном протоколе все работает стабильнее।

Обновил:
- 04.02.2011 - исправил досадную опечатку в пункте 4 (спасибо Yalexand)

размер имеет значение...

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

Поковырялись в ELDK, немножко сократили за счет реорганизации инсталляции, но все равно не хватает.

Возникла мысль выкинуть C++ рантаймовую либу.
Для этого необходимо переписать парочку модулей на C.

Начал смотреть библиотеки для C.

Интересными для исследования показались:

• A Simple Generic Library for C (http://sglib.sourceforge.net/)
• C Algorithms (http://c-algorithms.sourceforge.net/)
• c-generic-library (http://code.google.com/p/c-generic-library/)

Может еще кто что подскажет? :-)

рекурсивные обработки файлов в *ux

Не то чтобы новое - даже наоборот старое.
Добавил дабы кому пригодилось ;)
Да и сам чтобы не забыл

Возьмем за пример конвертацию файлов на языка C в *ux формат по всем поддиректориям.

Вы можете поменять на свою операцию - например удаление :)

Итак, я знаю примерно 3 способа

1. #dos2unix -k `find . -name "*.c"`
2. #find . -name "*.c" -exec dos2unix -k '{}' \;
3. #find . -name "*.c" -print | xargs dos2unix -k

Я предпочитаю длинный вариант - уже и не помню почему.
Видимо что первое показали - то и использую.

opensuse 11.1 // wlan

Вчера столкнулся с проблемой - после приема очередного обновления перестал работать wlan.

Не то что как бы совсем не работать - network manager видит беспроводную сетку и соединяется к ней. Адресочек автоматом (dhcp) выставляется - просто не видит компьютер глобальную паутинку и все тут.

Решил проблемку следующим образом:

#sudo /sbin/ifrenew-dhcp wlan0

выдало другой адресок и стало все работать.

Embedded Linux // /dev/random

Сброка Openssl не работала с GoAhead - сервер прекращал соединение на https с ошибкой вида - сервер неожиданно разорвал соединение.

Поиск в гугле дал совет - посмотрите - все ли хорошо с /dev/random

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

Проблема 1 - его там вообще нет.

Лечим по простому

mknod -m 644 /dev/random c 1 8
mknod -m 644 /dev/urandom c 1 9
chown root:root /dev/random /dev/urandom

Проблема 2 - чтение cat из /dev/random зависает.

В Faq по Eldk читаем решение для проблемы зависания

Суть проблемы:

В обычном PC линуксе драйвера клавиатуры и мыши наполняют драйвер случайных чисел (/dev/random) необходимой ӕнтропией. Во встроенном линуксе таких драйверов может не быть (в моем случае их просто нет).

Как обходной маневр используем

# cd /dev
# rm -f random
# ln -s urandom random

Проверяем работу сервера с OpenSSL.

Linux // Настройка GoAhead Web Server для работы c OpenSSL

На самом деле прошу не смеяться - может кому-то данный опыт тоже пригодиться.
И сохранит 4 часа непрерывного ковыряния в Гуле и коде (да, он опенсоурсный, но почитайте лицензию прежде чем использовать).

"Да нах он нужен! Ведь есть восхитительнейшие Apache или еще что-нибудь" - скажете вы и, по своему, будете правы. Однако, спешу напомнить, что жизнь непростая штука и вы не всегда играете по своим правилам. Короче, в сторону лирику...

Задача примерна такая - есть маломощное вычислительное устройство и на нем уже крутиться данный сервер. Надо криптануть трафик от и до с помощью SSL.

Все опции по криптовальным пакетам есть в
<место куда вы распаковали исходники>/LINUX/Makefile

И надо сказать даже у апача столько нет ;-)
- бесплатная OpenSSL
- платная BSAFE от RSA
- платная NanoSSL от Mocana

Понятно, что одним из рассматриваемых вариантов становиться OpenSSL (нет еще не победитель, но как бы уже доступен на попробовать).

Что собственно делаем для сборки GoAhead Web server (далее GAWS).

Кросскомпилером собираем OpenSSL (отдельная история - если кто захочет могу рассказать отдельно). Есть правда надежда что он у вас уже собранный. Я делаю допущение что он у вас уже есть :-) C каким-нибудь тулкитом для встроенного линукса.

Редактируем вышеуказанный Makefile следующим образом (согласно английским комментариям в файле)

SSLPATCHFILE = ../websSSL.o

# Here I put top location of openssl
# it could be anywhere for example point to location of target platform
OPENSSL_ROOT=/opt/eldk//usr

SSLINC = $(OPENSSL_ROOT)/include/openssl
# here could be either
# static libs in following form
# $(OPENSSL_ROOT)/lib/libssl.a $(OPENSSL_ROOT)/lib/libcrypto.a
# or
# dynamic in following form
# -L$(OPENSSL_ROOT)/lib -lssl -lcrypto
# or both forms for example I'we was forced to add 1 satatic from krb5 set ;-)
SSLLIB = -L$(OPENSSL_ROOT)/lib -lssl -lcrypto
SSLSW = -DWEBS_SSL_SUPPORT -I$(SSLINC) -DOPENSSL


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

Все собралось. Получили исполнимый файл. Нужны сертификаты.

Процедура такова - реальный сертификат нам на тестировании не нужен.
Посему делаем самодельные.

Сервер будет их искать в (там где у него жестко прописано - см. исходный код в файле websSSL.c - можете, кстати, и поменять)

1) там где он стартанул - должен быть файл server.pem
2) там где он стартанул - должна быть директория certs с двумя файлами в ней cacert.pem & cakey.pem

делаем их так

1) Генерим ключ и x509 сертификат

$openssl req -x509 -newkey rsa:2048 -days 1024 \
-keyout server-key.pem -out server-cert.pem

Вас опросит по английски заполнить поля вашего сертификата
Не забудте на вопрос
Common Name (eg, YOUR name) []:localhost
указать имя вашего хоста - в моем примере - localhost

2) Снимаем пароль с ключа, который вы введете на первом шаге на один из вопросов

$openssl rsa -in server-key.pem -out server-key-nopassword.pem

3) Склеиваем два файла в один (он будет лежать откуда стартует исполнимый файл)

$cat server-key-nopassword.pem server-cert.pem > server.pem

4) Ну и собственно перемещаем или копируем их каждого на свое место

server.pem      -> /server.pem
server-cert.pem -> /certs/cacert.pem
server-key.pem  -> /certs/cakey.pem

Проверяем работоспособность.

Если вдруг не заработает - берите дебаггер и вперед.

Удачи.

SuSEa 10.3 в виртуалке на Vista

Сегодня успешноводрузил Сюзи в виртуальную машину на ноутбук.
Чтоже, первые впечатления весьма положительны - работает быстро и "гладко".
Собственно, это сообщение публикую из Сюзи.
Доволен, как ребенок :-)
Итог, в моем домашнем "зоопарке": FreeBSD 7, SuSE Linux 10.3.
На подходе Solaris x86.