Httpd уже перезапускают “Адрес используемая” ошибка

Я предполагаю, что Вы уже экспортировали сертификат CA файлу, такой как "внутренний-ca.pem". Кроме того, я предполагаю, что это - Tomcat, кто инициирует соединение SSL с сервером IIS.

Вы банка должна использовать Java keytool для импорта сертификата в Java keystore, который используется механизмом Tomcat. keystore для сертификатов CA является $JAVA_HOME/jre/lib/security/cacerts. Таким образом для импорта нового внутреннего-ca.pem сертификата в этот keystore Вы использовали бы:

$JAVA_HOME/bin/keytool -importcert \
  -keystore $JAVA_HOME/jre/lib/security/cacerts \
  -file /path/to/internal-ca.pem  \
  -trustcacerts -alias internal-ca-1

Пароль по умолчанию для keystore: changeit

Проверьте, что Ваш сертификат находится в keystore:

$JAVA_HOME/bin/keytool -list \
  -keystore $JAVA_HOME/jre/lib/security/cacerts -v | less

Протестируйте соединение с сервером:

openssl s_client -CAfile /path/to/internal-ca.pem -connect server:port

Это должно дать Вам около конца его вывода:

Verify return code: 0 (ok)

Если Вы хотите протестировать доверие из Tomcat, необходимо будет записать некоторый тестовый код, чтобы сделать это. Извините, я не знаю Java.:-)

2
задан 15 December 2012 в 15:02
2 ответа

This is sometimes an indication the host is compromised or is running a misbehaving process. I say compromised because lots of malware forks into the background and ignores signals. However they do not normally close open file descriptors that were present at the fork.

This leads to a situation where the socket that was held open by apache was inherited by the malware which ignores signals to finish. This causes the 'unable to bind to address' issue.

Try issuing the command pgrep -l -u apache and see if any processes show up that are not apache.

1
ответ дан 3 December 2019 в 11:50

Сценарий init.d (вызываемый служебной командой) в зависимости от реализации не так умен, как вы думаете. То, что я вижу во многих из этих реализаций, заключается в том, что выполнение "start" убирает номер процесса исходного процесса httpd (то есть того, который выполняется как root). Затем, когда вы выполняете процесс 'stop', он просто убивает (с соответствующим номером сигнала) корневой процесс httpd.

Иногда подчиненные процессы становятся сиротами и не уничтожаются (потому что они могут быть сломаны и не отвечают в соответствии с сигналом родителей). Если это так, то порт все еще присоединен подчиненными процессами, и выполнение «перезапуска» или «старта» завершится ошибкой.

Что вам нужно сделать, так это выполнить команду " ps -aef | grep httpd | grep -v grep ", чтобы найти сломанные подчиненные процессы и уничтожить их напрямую (используя kill -9 pid # ). Может быть несколько сломанных процессов.

Один раз все неработающие процессы были заблокированы, тогда вы можете снова "запустить" сервер apache.

1
ответ дан 3 December 2019 в 11:50

Теги

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