http://nginx.org/ru/download.html
Русским языком написано в т.ч. что разработчики считают "стабильной версией". Вам на какой язык перевести?
Кол. В школу с родителям!
Однопользовательский режим - это init 1. Или загрузка ядра с соответствующим ключиком для init - single.
Но беспарольный загрузчик - тоже дырка (которая позволит в т.ч. и init=/bin/sh). Так что, поставим Андрейке вместо: 1+.
Не получится. пароль root попросит.
Зато получится с внешнего CD загрузиться. Если BIOS не настроен соответствующим образом и не запаролен.
А еще можно батарейку выдрать из биоса. Потому - шифруйте дисковые разделы, особенно Ваши с фотографии с любимыми кошечеками (или что-там у Вас компрометирующего).
Тогда скажите им об этом прямо.
Это не технический вопрос - это вопрос доверия. Куда более Вас компетентным технически людям - не составит труда сохранить доступ к серверу, буде один раз они его получили.
Вопрос такой - они, в принципе, хоть как-то отвечают за работоспособность сервисов, работу сайтов? Если да - им нужен доступ. Если делают только разовые работы по Вашей просьбе - не нужен. И пусть тогда они просто проинструктируют Вас как закрыть им доступ.
Разумное - это сколько?
У них для клиентов вообще бесплатная установка: http://shopcms.ru/install_post.html Или с этим какие-то проблемы?
Или memory_limit в PHP. По настройкам PHP - тоже в лог апача.
Кто-то у кого-то доку содрал.
Шутите. 256 штук апачей эдак по 20Mb каждый - это под 5Gb. Естественно, у Вас все дохнет еще раньше.
Вы так ничего и не поняли. Телепатии нету и детальные инструкции под данные типа "процессор используется на 150% больше положенного по тарифу" - никто Вам давать не будет.
Как уже написали - начать стоит с оптимизации mysql и включения кеширования в PHP. В качестве более суровых мер - кеширование на nginx.
Вот и замените как рекоммендует masterhost. Ваши 256 апачей в пике будут только память жрать. Плюс, установите nginx перед апачем.
Будут. Но насколько "значимы" - сказать заранее трудно. Не думайте, что это "вылечит" кривой движок сайта, например. Нужно смотреть, что является действительно узким местом и исправлять это. Может неоптимизированные запросы к базе, может стоить кеширование в PHP включить, и т.п.
Ну тогда XXX - новый айпи, YYY - "так же подсеть". Как запишете изменения в файл - сделайте
ifup eth0:0
Вас не затруднит в командной строке на сервере набрать
man interfaces
Если затруднит, то исходя из уже пиведенных в треде фактов - наймите специалиста обслуживать сервера. Иначе доломаете все нахрен.
Грейлистинг - как раз на сервере получателя. Штука может кому-то и отвратительная, зато отбивает у очередных пыонеров желание "напрямую коннектиться через сокеты" (без полноценного почтового сервера и т.п.).
Судя по моей статистике - много серверов с грейлистингом запоминают IP. Т.е. если раньше Вы успешно достучались до принимающего сервера - он далее не будет мурыжить подобными задержками.
iface eth0:0 inet static
address XXX
netmask YYY
могут понадобиться дополнительные опции, типа gateway (в зависимости от выданной новому IP маски)
И что он делает? Очевидный вопрос, правда? Неочевидно предложение вместо этого гадать на кофейной гуще:
Если подтвердится предположение о wa из-за mysql - попробуйте организовать кеширование на nginx.
