Без технических знаний - никак, почти наверняка. Но если грамотно
ставить ТЗ, в том числе по настройке сервера, - таких вещей не должно всплывать.
Например, если Вам нужно, чтобы настроенный под определенное веб-приложение
сервер держал нагрузку XXX хитов или YYY одновременных пользователей
или ZZZ "любых попугаев, характеризующих нагрузку на сервер" в единицу
времени - ничто не мешает оговорить в ТЗ тестирование всего этого дела
какими-либо веб-бенчмаркерами, например, siege.
Что касается кучи сервисов - а мож-т они нужны были клиенту? Т.е. если
таки нужен FTP - воле-неволей порты открыть надо-ть. Хотя я не вижу ничего
плохого в том, чтобы держать почту+днс вне сервера для веб-проектов и оставить
открытыми только порт 80 и какой-нибудь еще для ssh ;).
А на 8080 уже был не левый прокси часом? :D
Заказ у "частника" принципиально ничем не отличается. Минусы - квалификацию
исполнителя придется оценивать Вам. Плюсы - более гибкий подход к клиентам,
что всегда характерно для небольших компаний предоставляющих услуги администрирования.
Мониторинг доступности сервисов и оборудования, обновление хостинговой среды, аудит
безопасности, доступных ресурсов на сервере, разрешение ситуаций "пожарного"
характера (на приемлемых для вас условиях по времени реакции на инцидент) - типа DoS,
отказа оборудования.
Дополнительно много чего можно добавить в индивидуальном порядке.
Если администратор не выполнил требований ТЗ разработчика по рекоммендуемым
настройкам сервера для его ПО. В ином случае - вина лежит по меньшей мере в
равной степени и на разработчике.
пункт 1 спорный. ну чем заметно поможет nginx на локально? разве
кешировать его заставили почтивсеподряд. ну, хз.
вам же написали: "configure arguments"
вот выясните в документации что они означают, сразу станет все понятно.
бинарник у вас в /usr/sbin/nginx
написали же "смотрим куда указывает ссылка exe".
ls -l /proc/<pid>/exe
PS:
кстати, у вас сборка из дистрибутива - лучше было бы собрать
нормальный rpm-пакет с новым nginx.
DenHost, нет, неверные - боюсь, вы не поняли ровным счетом ничего. Вам нужно собрать
nginx с опциями, указанными для прежней сборки. Как их узнать - рассказали выше.
Если у вас freebsd - ссылка exe называется file. Если linux - смотрите /proc под пользователем root - покажет все файлеки.
DenHost, вам дали пошаговую инструкцию. если сделаете сборку со старыми
опциями - конфигурационные файлы make install не перезапишет.
а чтение документации объяснит вам что означают опции, указанные при сборке,
какие умолчания и где находятся конфигурационные файлы.
pidof nginx
получаем <pid> процессов nginx. берем любой и
дальше идем в /proc/<pid>/ смотрим куда указывает ссылка exe - это и есть старый бинарник.
смотрим опции, с которыми он собирался:
/proc/<pid>/exe -V
дальше собираем, делаем make install и рестарт.
unlimbox, вопрос был к DenHost.
DenHost, уточните что за "папка". Если какая-нибудь /usr/local/nginx - там скорее всего
измененные конфиги лежат. Перезаписывать их теми, что устанавливаются по
умолчанию - нельзя. Тогда просто соберите nginx _с теми же опциями, что и
установленная раньше сборка_ и сделайте make install. Ну и тупо рестарт сделайте
сервису - обновление "на лету" пока не для Вас ;).
ЗЫ: unlimbox, в Debian давно 0.7.64 - куда уж новее?
DNS хостера на одном сервере? :)
Что за хостер, если не секрет?
