естественно, дело не ограничивается NAT firewalls,
onuchin.local может находиться и VPNe

Это замена vds, сдача в аренду фаервола или что? Или типа умный хостинг где у каждого юзера свой вебсервер на котором он может делать что хочет?

Похоже, e-mail не отображается в профиле для других пользователей. Я заинтересовался. Куда писать?

просмотрел еще раз, на предмет велосипедности моей идеи
http://en.wikipedia.org/wiki/Web_hosting
по-моему ничего подобного там нет. Может, ошибаюсь.

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

Мыло в твоем профиле видно только тебе и модераторам. Это ты для заинтересовавшихся модераторов писал?;)

email

>Мыло в твоем профиле видно только тебе и модераторам
впервые слышу об этом.

Valeri.Onoutchine@cern.ch

web hosting

Проблема с hosting site
состоит еще и в следующем:
0. это будет линуксовая мащина
1. user, который поимел на ней аккаунт не должен иметь никаких
прав на выполнение команд, только минимальный набор
(даже меньше, чем в BusyBoxe): cp, scp, rm , ls, cat ???
3. только провайдер имеет все права

> Это замена vds,

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

Моя идея - это переадресация через туннелирование,
т.е. запрос onuchin.hosting.com/dir/myscript.php
переадресуется по ssh tunnel к onuchin.local/dir/myscript.php

ssh tunnel позволят onuchin.local находиться вне общедоступной сети

- покупаем дешёвый vds (например, 5-10 евро в месяц)
- настраиваем ssh тоннель
- говорим апачу/ngnix/..., что server.local - это бэкэнд.

Настраивается очень быстро и просто. Стоит очень недорого.

Вообще, я думаю, описанная схема без проблем реализуется штатными средствами. Форвардинг портов у ssh плюс виртуальные хосты и mod_rewrite у апача, ну ещё грамотный restricted shell у юзеров. Да и автоматизировать процесс создания-настройки нового пользователя не так уж и сложно, имхо. Однако ничего подобного я лично пока не встречал, а идея-то интересная :)

сама идея была навеяна после
http://www.linux.org.ru/view-message.jsp?msgid=3057418
особенно полезна вот эта ссылка
http://www.linux.org.ru/view-message.jsp?msgid=3057418#3065844

у меня есть опыт написания apache module, последнее время
занимался сетями.

Это я к тому что, зачем огород городить? Всё уже придумано до нас.

>- покупаем дешёвый vds (например, 5-10 евро в месяц)
>- настраиваем ssh тоннель
>- говорим апачу/ngnix/..., что server.local - это бэкэнд.

мда по-видимому велосипед ...

> проект под кодовым названием xtovo (это город, где я родился)

Какой разряд?

vds

http://ru.wikipedia.org/wiki/VPS
на сколько я понял, там делается через Virtuozzo

ладно, все равно попытаюсь чего-нибудь (для домашнего пользования)
сотворить на уровне apache/ngnix + linux + ssl ++

Попробую написать module (наверное, даже всего один)
для web-hosting, который бы делал, действительно, rewrite ,
а потом передaвал через tunnel request backendу

> Какой разряд?

самбобезразрядный :) если правильно понял вопрос

> Моя идея - это переадресация через туннелирование,

так ты туннелями решил торговать? :). Туннелей щас выше крыши. Идея ну совсем не оригинальная, ssh -L + самый дешёвый vps и нет проблем.

Кстово? Я правильно понял? Город Кстово Горьковской области? Я тоже там родился!!!

По-моему такая штука уже написана, и называется mod_proxy

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

Вообще, по ощущениям, велосипед.
Схема напоминает зеркала и распределение нагрузки по разным серверам.

> не проще ли вообще тогда делать банальный редирект

сермяга в том, что юзеровская машина сидит за
корпоративным firewallом или как домашний комп в VPNe

типичная проблема, которая решается данным способом, описана у соседей
http://www.linux.org.ru/view-message.jsp?msgid=3079003&lastmod=1221227809996
Что угодно делай на своей домшней тачке - хоть "полный доступ к рутовому шеллу", хоть дырищу у себя (в безопасности) открой -
вся ответственность ложиться на юзера, а не на провайдера.

как писал Iakov Davydov, конечно, это всё можно соорудить через vds,
но поиграться стоит. Может, чего-нибудь неожданное вылезит ...

тов. Онучин, а чем вас не устраивает mod_proxy ?

пишем в гугле apache reverse proxy, попадаем на http://www.apachetutor.org/admin/reverseproxies

и читаем:

Reverse Proxies

A reverse proxy is a gateway for servers, and enables one web server to provide content from another transparently. As with a standard proxy, a reverse proxy may serve to improve performance of the web by caching; this is a simple way to mirror a website. **But the most common reason to run a reverse proxy is to enable controlled access from the Web at large to servers behind a firewall.**

как раз то что надо? если хотите большей безопасности можете между фронтендом и бэкендом провесить VPN.

> В связи с осенним "обострением гениальности", ночью осенила идея ...

Ну да, сентябрь уже, начинается :-)) дума вроде тоже уже собирается...

> Хочу запустить проект под кодовым названием xtovo (это город, где я родился)

региональный поцтреотизм это хорошо, но когда вы начинаете писать софт под unix, придется отринуть. xtovo - однозначно воспринимается как X11-фронтенд какого-то tovo. Потенциальные пользователи будут ждать ktovo и gtovo соответственно, думая что у xtovo интерфейс как у какого-нибудь xedit...

> пишем в гугле apache reverse proxy

про "reverse proxy" я, конечно, когда-то (~2002 года) знал,
но "забыл" :) Я и сам удивился, что идея-то простая ...

reverse proxy - это очень, очень близко, но всё равно, не совсем то,
о чем я написал.

"
A Reverse Proxy Scenario

Company example.com has a website at www.example.com, which has a public IP address and DNS entry, and can be accessed from anywhere on the Internet.

The company also has a couple of application servers which have private IP addresses and unregistered DNS entries, and are inside the firewall. The application servers are visible within the network - including the webserver, as "internal1.example.com" and "internal2.example.com"
"

В моём случае application servers are _NOT_ visible to webserver,
i.e. www.example.com (!!)

> В моём случае application servers are _NOT_ visible to webserver, i.e. www.example.com (!!)

А если их с фронт-енда не видно, как фронтенд с апп-серверов что-то получать будет?

"...проект под кодовым названием xtovo ..."

> xtovo - однозначно воспринимается как X11-фронтенд какого-то tovo

это правило для executable programms, но не для названия проекта.

"содержание" слова xtovo можно будет додумать, но несомненно, оно несёт
элемент "поцтреотизмa" и заканчвается моими инициалами

>А если их с фронт-енда не видно, как фронтенд с апп-серверов что-то
> получать будет?

через ssh канал. так же, как это описано в
http://souptonuts.sourceforge.net/sshtips.htm

необходмым условием возможности обмена/коммуникации
"фронтенд <-> апп-серверов" является активная ssh/Putty session
апп-сервер -> фронтенд

> необходмым условием возможности обмена/коммуникации "фронтенд <-> апп-серверов" является активная ssh/Putty session апп-сервер -> фронтенд

Ну так и включите порт-форвардинг. То есть

* апач фронтенда ходит на localhost:123456 * там висит ssh-труба уводящая на бекэнд * на бекэнде выход из трубы перенаправляется на localhost:80, где висит бэкендный апач.

единственная проблема может быть - как такая схема потянет большое количество постояно устанавливаемых/разрываемых соединений. то есть что на самом деле надо делать - это убедиться что mod_proxy умеет при обращениях к бэкенду делать reuse HTTP connections или как это там называется.

ну, понятно теперь (наконец-то:), что плясать надо от mod_proxy ...
Плезное обсуждение получилось, спасибо.

>> xtovo - однозначно воспринимается как X11-фронтенд какого-то tovo

> это правило для executable programms, но не для названия проекта.

$ find /usr/portage -name 'x*.ebuild' | cut -d/ -f4 | sort | tee /tmp/out1 | uniq | ( while read a; do echo -n $a; echo -n " " ; grep $a /tmp/out1 | wc -l ; done ) | grep [0-9][0-9][0-9]

x11-apps 104 x11-drivers 193 x11-misc 112 $

и для проектов тоже :-)

Что пилить, куда пилить, чем пилить - понятно.
Ладно, проект можно/нужно переименовать.
От ныне (и на веки) он будет называться "Р&К им. Оси Б." :)

Необходимо довести его до "комерческого предприятия" (достойного своего гордого названия)

1. наш потенциальный клиент - онанимная домохозяйка(ин) подсевшая
на оффтопике.
2. наша услуги (для начала) - Web Servers Hosting (WBS).
- клиент получает собственный веб-сервер, который доступен
из WWW, даже если клиентская машина не имеет собственного
IP адреса и находится за "бронированной" NAT firewall
или в VPN.
- обеспечиваем некую защиту нашему клиенту от посягательств
извне. по желанию - фильтрация трафика идущего к клиент
серверу (на предмет вирусов, троянов и пр.)
3. клиентский веб сервер - это модифицированный apache (поставляется
нами), который общается с нашим хостом, прозрачно для клиента, по
ssh туннелю.

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

На нашей веб странице клиент заполяет форму,
получает аккаунт и после этого (допустим имя клиента dom2)
веб сервер клиента будет доступен извне, как dom2.hosting.com.
Клиент также может хранить свои данные на нашем сайте по адресу:
hosting.com/~dom2/ Весь обмен/манипуляция данных между клиентом и
hosting.com прозводиться через веб интерфейс.

т.з. для "добровольцев":)
1. перепилить mod_proxy так, чтобы при добавлении нового юзера в
систему (линукс), все запросы, типа, dom2.hosting.com
перенаправлялись в ssh tunnel соответствующего юзера.
При этом, всё должно происходить динамически, т.е. без
переконфигурирования, перезагрузки апача.
2. написать клиентский апаче-модуль, который бы осуществлял
ssh туннелирование между клиентским веб-сервером и нашим хостингом.
Клиент не должен знать ни о каких ssh-forwarding, настройках Putty
и пр. При запуске клиентского веб-сервера должен появляться
диалог, по которому клиент логиниться по ssh к нашему хосту, тем
самым инициируя ssh tunnel.

> При запуске клиентского веб-сервера должен появляться диалог, по которому клиент логиниться по ssh к нашему хосту, тем самым инициируя ssh tunnel.

убило и разорвало. где появляться диалог должен? а если никто не залогинен еще а сервис уже стартует?

> где появляться диалог должен?

сразу после старта httpd, запускается диалог (на клиентской машине)
и предлагается залогиниться к hosting.com
Что не понятно? поясню

> сервис уже стартует

про какой сервис идёт речь?

в принципе, к клиентскому apache модулю можно/нужно добавить thread/subprocess, который бы проверял "наличие" туннеля к hosting.com
с автоматическим перелогиниванием в случае обрыва.

> запускается диалог (на клиентской машине)

я подразумевал, что клент сидит под офф-топиком,
под линуксом, будем пользовать сертификаты

Еще раз по самой идее этого проекта.
Хотелось бы иметь не только Web Servers Hosting System, 
но более продвинутую вещь. 
Я называю это "Web Operation System",
не надо воспринимать назвaние буквально, а как некую
аналогию. Поясню, что имею ввиду.

1. мы имеим hosting.com - аналог unix root directory, aka /
2. user1.hosting.com - аналог /user1
   user1.group.hosting.com - /group/user1 
   user2.group.hosting.com - /group/user2 
   ....
3. теперь аналог executable programms - 
   user1.hosting.com/path/my.php
   user2.group.hosting.com/path/my.py
   ...
   которые исполняются на соответствующих сайтах, 
   т.е. каждый из сайтов - это аналог "protected user memory space"
4. осталось дело за малым - ввести "права доступа".
   По аналогии введем access permissions - (read, execute) и в 
   дальнейшем write (возможность редактирования файлов через веб
   на удалённом юзеровском сервере)
   Опять же, по аналогии, введем ownership - world, group and owner

group - запрос к user.group.hosting.com/path/my.py
        разрешен если только он исходит от "group" сайта
owner - запрос к user.group.hosting.com/path/my.py
        разрешен если только он исходит от "group" сайта 
        и непосредственно от некоего юзера "user" - 
        по-видимому потребуется система дополнительной 
        authentication/authorization
world - запрос разрешен к ресурсу, исполнению скрипта для всех.

Понятно, что "разруливание" прав доступа
должно происходить на уровне hosting.com

Аналоги chown, chmod - будут реализованы через веб-интерфейс

to be continued ... :)

>> не проще ли вообще тогда делать банальный редирект

>сермяга в том, что юзеровская машина сидит за
>корпоративным firewallом или как домашний комп в VPNe

Может я неправильно понял задачу, но почему на серваке не поднять например openvpn и гонять трафик по тунелю?

> Может я неправильно понял задачу, но почему на серваке не поднять например openvpn и гонять трафик по тунелю?

А у него несколько бэкендов, то есть надо HTTP реквесты разбирать и раздавать разным бекендам, в зависимости от HTTP заголовка Host ....

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

Hi,
starting from this idea I
realized that we canhave than simple
WebServers Hosting System, but "Web Operation System"

1. we have hosting.com - analog to unix root directory /
2. user1.hosting.com - analog to /user1
   user1.group.hosting.com - /group/user1
   user2.group.hosting.com - /group/user2
   ....
3. "executable programms"
   user1.hosting.com/path/my.php
   user2.group.hosting.com/path/hsimple.C
   ...

   all scripts are executed on separate sites.
   It's analogous to "execution in protected user memory space"
4. remaining features to implement  -
   "file ownership" & "access permissions"
  
   In the same manner, let's introduce  "access permissions"
   read, execute,  later write (possibility to write/edit/delete
   files on remote user site)

  group - request to read/execute user.group.hosting.com/path/hsimpe.C
        is allowed only for those clients who came from "group" site
   owner - request to user.group.hosting.com/path/hsimpe.C
           allowed only for  "group" site
           and for client with name "user" -
           probably we'll need to introduce additional
           authentication/authorization mechanism
   world - read/execute user.group.hosting.com/path/hsimpe.C
           allowed for everybody

Obviously such mechanism must be implemented on hosting.com level.
chown, chmod - will be implemented as web scripts/interface.

Such system will allow to execute "carrot scripts" (I'm going
to resurrect carrot project under other name) safely

.. to be continued ... :)







-----Исходное сообщение-----
От: Valeri Onuchin
Отправлено: Сб, 9/13/2008 11:22
Кому: Fons Rademakers
Копия: Bertrand Bellenot; Axel Naumann
Тема: tunneling webserver

Hi,
I'm sitting behind a strict corporate NAT firewall.
I'd like to expose my local web server to the World Wide Web.
Recently I got an interesting idea about how to do it via ssh tunneling.
Notice, I know about reverse proxy (mod_proxy, ngnix etc.)
and possibility to do this by these utils. I also know about VDS etc. 

My goal - to create a Web Servers Hosting (WSH) System

I'll try to explain an idea:
1. assume, we have a public web apache server (hosting.com) exposed to the WWW.
2. our web server (hosting.com) is running linux
3. we have an user account (which is very restricted) e.g. onuchin
4. onuchin has his own web server (onuchin.local) somewhere
   behind remote NAT firewall or inside remote VPN and
   it's "invisible" (no IP, no name) to hosting.com.
5. onuchin can connect to hositng.com via ssh with tunneling
   between onuchin.local machine and hositng.com

The scenario:
-  a request like onuchin.hosting.com/dir/scipt.php
  is retranslated, retransmitted over ssh tunnel to onuchin's
  webserver (onuchin.local) and executed over there
  as onuchin.local/dir/script.php -> the result of this
  is sent over ssh tunnel back to hosting.com and exposed to the WWW.
- a request like virtual.onuchin.hosting.com/dir/scipt.php
  goes to virtual.onuchin.local (remote virtual hosting)


The task:
 1. (re)write mod_proxy in such way, so all requests to
    user.hosting.com will be transmitted to corresponding
    user's ssh tunnel, i.e.
    to user's remote machine -> user's web server.
 2. adding a new user to the system (hosting.com) should not
    require apache reconfiguring, restarting.
 3. write an apache_module for client's web-server  which
    supports ssh tunneling between client's web server and
    hosting.com in transparent way.
    The process of client loginning to hosting.com is "a part" of this module.
    That allows to have an automatic reloginning in case of disconnection
    between client's mashine and hosting.com.
 Everything must be transparent to user/client.
He/she knows nothing about ssh-forwarding, Putty-tunneling etc.

User can place his/her static HTML pages , images on hosting.com
available at hosting.com/~user/

Users management on hosting.com  be done via web interface.
It should be as simple as  possible.
Potential client (pedestrian) knows nothing about linux etc.

Of cause, hosting.com may provide any other services to the clients,
e.g. filtering content(security) which goes to the client's web-server etc.

One of the potential usages of such system is secure running of
ROOT/carrot/PHP scripts on client's web server.
All security problems are now client's concern - NOT web hosting provider.

What do you think about this idea?
Do I invent a wheel?

Regards. Valeriy

Долгое время я "сидел" на apache-devel,
Nick Kew  (автор  mod_proxy) знаю заочно.
Возможно,  стоит с ним связаться с обьяснением,
чего мы хотим (пусть сам "допилит" свой модуль:)

> Долгое время я "сидел" на apache-devel, Nick Kew (автор mod_proxy) знаю заочно. Возможно, стоит с ним связаться с обьяснением, чего мы хотим (пусть сам "допилит" свой модуль:)

я не понимаю, чего допиливать? тов Онучин, вы X11 соединения через SSH через трубу пускали? когда у вас на машине X-сервер а к нему с удаленной машины коннектятся всякие X11 приложения? при этом ни X-server ни эти приложения никак допилены для этого не были? Предлагаю таки настроить конфигурацию (ничего кодить при этом НЕ ПОТРЕБУЕТСЯ), запустить бенчмарки и посмотреть что начнет происходить.

Скорее всего начнется ппц с latencу и, при большом числе бэкендов, с CPU load на фронтенде. Причины этих эффектов будут 1) network latency между фронтендом и бэкендом 2) тяжесть установления ssh соединения для каждого реквеста 3) тяжесть при обслуживании большого количества ssh соединений.

Обнаружив сии эффекты экспериментальным путем, следует пойти... нет, еще не туда, а к тем кто делает какие-нибудь решения для больших распределенных server farms. и там, cкоперировавшись, дописать нужное.

Может я чего-то в этом мире не понимаю, но имхо странно подваливать к тому кого вы знаете заочно и требовать чтобы он что-то писал. Какой у него интерес? Надо найти тех, кто и так такое пишет (java-еры может? у них такая схема часто юзается- нормальный веб сервер раздает статику, а за динамикой ходит к java app server'у), или тех кто ищет популярности продукта (тогда вы их должны убедить что то, что надо вам, завтра будет надо всем), или уже заинтересовывать материально.

Проясни ситуацию. Вот я Маша Валенкова. У меня есть машина с виндовз хп за натом и три рецепта борща, которые я мечтаю разместить на дом.странице в интернетах. Что сделает для меня The Onuchin Corporation, чего не может dyndns? Можно ли грабить корованы?

> 2) тяжесть установления ssh соединения для каждого реквеста
ssh соединения - висит постоянно

>чего не может dyndns? Можно ли грабить корованы?

NAT отсекает все запросы к  "машина с виндовз хп за натом"
(из соображений безопасности).

> X11 соединения через SSH через трубу пускали

только этим и занимаюсь, что такое опция -Y - в курсе