плюсы:
- Проще сделать бекап сразу всех данных сайта. Один файл - один слепок состояния сайта. А файлы движка всегда можно взять из дистрибутива.
- Как ни странно, нагрузка может быть меньше, потому что базу легко реплицировать и рассредоточить нагрузку на группу серверов, а с файлами вас ожидает написание педальной синхронизации на php с соответствующего уровня ошибками.
- Супербезопасность: все скрипты и папки сайта "замораживаются" с помощью установки таких прав доступа, что файлы вообще нельзя модифицировать ни с помощью украденного пароля от ftp, ни логической уязвимостью в коде. Закачать файл веб-шелла просто некуда. И при этом сайт будет нормально работать. Конечно, украсть данные все еще будет можно, но при попытке сделать классический дефейс хакер будет весьма озадачен. ---------- Добавлено 17.08.2012 в 01:28 ----------
Не то чтобы лишним. Она проверяет права доступа. Если доступ в раздел закрыт, предполагается, что никакую информацию из этого раздела получить нельзя в том числе и картинки.
Если не каждый поддомен, то нужно хотя бы прописать "звездочку" - символ * . wildcard dns record.
ошибка вида The requested URL could not be retrieved показывает, что вы не обеспечили работу поддомена на уровне dns
кстати, я как-то пытался у fastvps.ru прописать её на dns-хостинге - не пошло.
как правильно поступить в этом случае ?
Ну вообще-то, при типичном способе "запароливания каталога через .htaccess" просто не возникает ситуации с ошибкой 403. Возникает ошибка 401.
Я предложил показать dmesg в этих двух случаях, чтобы сравнить что разного в процессе инициализации ядра. Ну и против dmidecode не возражал.
Что-то не очень там видно типы памяти и тд. Не всегда хорошо dmidecode это показывает.
скорее всего там и есть adm64, но без dmesg мы этого не узнаем.
Смиритесь. Вам не дано решить эту проблему.
mvolgin,
1. dmidecode это же не dmesg. не понятно как именно грузилось ядро, что включало, что выключало.
2. биос кто будет обновлять ? последняя версия от 2010-02-05, а у вас 06/10/2008.
3. за исключением одной пустой строки в конце, файлы идентичны. спутали что-то.
Разумеется, с такой невнимательностью все будет необъяснимо тормозить.
mvolgin, вас же специально попросили dmidecode показать. там информации побольше будет чем вы можете сообщить.
оба варианта вывода dmesg , с которым тормозит и с которым не тормозит, тоже небесполезны.
Вы же не хотите общий ответ вида "центос - надоевший тухляк"? Что конкретно устарело в centos вполне можно выяснить.
А я разве утверждал, что знаю готовое решение ? может и php, может и обработка на промежуточном nginx, может совместная работа .htaccess и php-скрипта в качестве обработчика ошибки 401. Надо экспериментировать и пробовать
Romka_Kharkov, строго говоря, требовалось обеспечить не N попыток, а ровно одну попытку.
Если сервер сможет при первом запросе где есть непустые и неправильные данные авторизации, выдать код 403, а не 401, то браузер больше не будет показывать окно для ввода.
Cделать это только с помощью .htaccess, пожалуй, сложновато будет.
Dr.SEOMAG, это я, не будучи администратором сервера, подсказал поисковикам IP на котором мог бы открываться forum.searchengines.ru. Но в данном случае они сделали так, что форум не открывается. На виртуальном хостинге скорее всего так же будет.
