Вопросы Теги

Упаковка об/мин конфликтующие библиотеки

Можно создать VirtualHosts в Apache и затем использовать ProxyPass для subdomain1.mydomain.com, чтобы инвертировать прокси в IIS и иметь VirtualHost по умолчанию, которые инвертируют прокси в VM Linux.

Вы хотели бы конфигурацию, которая была чем-то вроде этого:

<Virtualhost *:80>

    ServerName subdomain1.mydomain.com

    ....
    # Reverse proxy into IIS
    ProxyRequests off
    ProxyPass / http://ip.of.IIS.machine/
    ProxyPassReverse / http://ip.of.IIS.machine/
</VirtualHost>

<VirtualHost _default_:80>
    ....
    ProxyRequests off
    ProxyPass / http://ip.of.linux.machine/
    ProxyPassReverse / http://ip.of.linux.machine/        
</VirtualHost>

Те конфигурации пропускают большую часть конфигурации, но важные биты - то, что первые соответствия определения VirtualHost на subdomain1.mydomain.com, и это затем делает обратный прокси в машину IIS. Второе определение соответствует всему остальному и обратным прокси в машину Linux.

Отметьте, я не протестировал вышеупомянутое, как оно записано, но я определенно получил апачские настройки с несколькими virtualhosts, где один vritualhost является обратным прокси в другую машину, таким образом, основная теория прекрасна.

2
задан 24 March 2014 в 15:13
1 ответ

Поразмыслив над этим некоторое время, я думаю, что более правильный подход - использовать «пространства имен» виртуальных ресурсов RPM. Например: 

Provides:  resource               # 'resource' is available to the whole system
Provides:  namespace(resource)    # 'resource' is specifically available only to "namespace"

RPM в конечном итоге выглядят следующим образом: 

grunk-libs.rpm
  Provides:  libgrunk.so.1()(%{_arch})       # System library.  unchanged

foo.rpm
  Requires:  /bin/sh
  Requires:  libc.so.6()(%{_arch})
  Requires:  foo(libgrunk.so.1()(%{_arch}))  # Note special foo(...) namespace

foo-grunklibs.rpm
  Provides:  foo(libgrunk.so.1()(%{_arch}))  # Note special foo(...) namespace

Таким образом, зависимость foo от специальной сборки libgrunk не может быть удовлетворена обычным grunk -libs RPM, но должен удовлетворяться специфичной для foo сборкой этой библиотеки.

Мое доказательство концепции выглядит следующим образом: 

Name:     foo
...
Source99: find-namespaced-requires     # Here's the magic

%define    _use_internal_dependency_generator 0
%define    __find_requires %{SOURCE99} foo /bin/sh glibc

Где сценарий find-namespaced-requires обертывает стандартный RPM % {_ rpmconfigdir} / find-requires и фильтрует его вывод. Его первый аргумент - это используемое пространство имен ( "foo (...)" ), а последующие аргументы - это зависимости или RPM, обеспечивающие зависимости, которые должны не быть пространством имен. В этом примере я хочу, чтобы foo требовал / bin / sh основной системы, а также обычные libc, libdl, libm и т. Д. Из glibc , но все остальные зависимости должны приниматься чтобы быть конкретным для foo .

Это можно было бы сделать немного более понятным и универсальным, заключив большую часть вышеперечисленного в RPM во время сборки и сказав что-то вроде: 

Name:          foo
BuildRequires: special-deps-macros

%define _namespace            foo      # defaults to %{name} ?
%define _generic_dependencies ...      # defaults to /bin/sh glibc libselinux ?
0
ответ дан 3 December 2019 в 15:13

Теги

Похожие вопросы