Назад | Перейти на главную страницу

authbind, privbind или iptables REDIRECT (порт 80 на 8080)?

Я бы хотел запустить Glassfish v3 как непривилегированный пользователь в Linux (Debian), но сделать его доступным через порт 80. В настоящее время я делаю это с помощью iptables:

iptables -t nat -I PREROUTING -p tcp -d x.x.x.x --dport 80 -j REDIRECT --to-port 8080

Это работает, но мне интересно:

  1. Если это имеет какое-либо значительное влияние на производительность по сравнению с привязкой напрямую к порту 80
  2. Если бы я мог сделать аналогичную настройку, также работающую для HTTPS (или если она должна работать на 443)
  3. Если есть способ избежать привязки других пользователей к порту 8080 (в случае сбоя моего сервера) - возможно, каким-то образом заблокировать этот порт для других пользователей навсегда?

... или если я должен использовать вместо этого authbind / privbind? Проблема: я пока не мог заставить его работать с authbind или privbind.

Для authbind, Я отредактировал последнюю строку asadmin следующим образом:

exec authbind --deep "$JAVA" -Djava.net.preferIPv4Stack=true -jar ...

Для Privbind:

exec privbind -u glassfish "$JAVA" -Djava.net.preferIPv4Stack=true -jar ...

(Только) с этими настройками я могу успешно выполнить create-domain --domainport 80. Это доказывает, что authbind и privbind действительно работают. (версия скрипта authbind вызывается пользователем glassfish; версия privbind, конечно же, вызывается пользователем root). Однако в обоих случаях я получаю следующее исключение при запуске домена (start-domain):

[#|2010-03-20T13:25:21.925+0100|SEVERE|glassfishv3.0|javax.enterprise.system.core.com.sun.enterprise.v3.server|_ThreadID=11;_ThreadName=FelixStartLevel;|Shutting down v3 due to startup exception : Permission denied: 80=com.sun.enterprise.v3.services.impl.monitor.MonitorableSelectorHandler@1fc25e5|#]

Я еще не нашел для этого решения (после поиска в Интернете кажется, что это не так просто?) Но, может быть, решение с iptables достаточно хорошее - как вы думаете?

Спасибо,

Крис

Примечание:

Размещение Apache впереди в моем случае - не лучшее решение - я планирую использовать Comet, а Comet лучше работает без прокси.

Я все время использую NAT на производстве. Хотя он чаще используется для перевода между интрасетью и Интернетом, вполне приемлемо использовать его и таким образом. Я проделал то же самое для почти идентичной ситуации. При этом есть и другие варианты.

Серверы приложений и веб-серверы часто работают вместе, поэтому имеет смысл держать Java на 8080 и 8443 внутри. Чаще люди, вероятно, использовали бы Apache в качестве прокси для перевода определенных запросов на Java и обслуживания статического контента из экземпляра Apache. Я понимаю, что вы считаете это решение неприемлемым для вас, но об этом нужно сказать.

Если это не касается ваших вопросов, не стесняйтесь объяснять, и я буду повторять дальше.

Редактировать 1

Пожалуйста. NAT не повлияет на нормальную работу https, он будет работать нормально.

Я не могу представить, почему вы должны беспокоиться о привязке других непривилегированных пользователей к 8080. Есть ли что-то уникальное для вашей ситуации?

Ваша проблема с Privbind, вероятно, является результатом того, что HOME установлен на root. Либо я, либо тот, кто возьмет на себя ответственность за Privbind, попытаемся исправить это в следующей версии (теперь, когда будет следующая версия ...)

Посмотрите, решит ли проблему добавление "HOME = ~ glassfish" в начале командной строки (при условии, что оболочка, производная от Bourne) (если это все еще актуально: в конце концов, прошло четыре года с тех пор, как вопрос был задан ...)

Шахар