baas

baas
Рейтинг
171
Регистрация
17.09.2012
Должность
ИТ
Интересы
Пиво варение.

location /catalog/Joy/joy_em_6_1t/ {

rewrite ^(.*)$ /catalog/Joy/joy_em_1x1t/ redirect;

}

Не работает почему то редирект.

Rebz:
хотелось бы автоматизированный подход :)
Устранение уязвимостей без доступа к серверу нереально, тем более что в уведомлении об уязвимости чаще всего пишут что надо пропатчиться до новой версии - эти рекомендации также будут входить в уведомление.

Мало толку будит от ваших уведомлений.

Rebz:
Да, конечно, будет и бесплатный вариант. Платный - скорее дополнительные и полезные фичи. Самый базовый функционал - бесплатно.

Платный вариант можете сделать устранением этих уязвимостей!

Rebz:
это не очень универсально, зато очень затратно :) вот, люди готовы до 500 руб платить в месяц, и то таких очень немного. Не окупится)

Ну, 500 р в месяц нормально, даже много.

1 и более тысяч это перебор.

Большой клиент не заинтересуется вами, ибо у него есть свой безопасник, админ, прогеры и т.д., а вот для начального уровеня думаю полезно будит.

Но у начального уровня даже и 500 рублей не будит на эти услуги, первое время делать на бесплатной основе, что бы народу собрать.

ну а потом как пойдут, начать можно со 100 рублей.

Rebz:
можно подробнее? Речь об обновлении CMS?

Давайте рассмотрим другой вариант. Есть, к примеру, WordPress, к нему есть куча плагинов, в них часто ищут уязвимости. Так вот, в сервисе вы указываете свои установленные плагины и по ним получаете информацию об уязвимостях прямо на почту. Такой агрегатор ок?

Хмм, а гарантии какие?

Вы код весь досканально проверяете/тестируете, или чисто по версиям модулей/движка ищите уязвимости?

Rebz:
спасибо за вопрос.
вообще изначально думал только про серверные уязвимости, но в целом можно будет чекать и неизвестные CMS, вопрос в целесообразности.
Уязвимости по заданной CMS будут чекаться из открытых источников. Какая вероятность, что такая CMS будет упоминаться? В целом, можно сделать, проблем не вижу.

Информирование об уязвимостях уже есть.

http://www.securitylab.ru/vulnerability/

http://www.opennet.ru/mp/security/

и т.д.

Опрос не логичный!

Где выбор пункта? , (мне это не нужно, такой сервис уже есть!)

Смотрите лог медленных запросов, 99% вероятности, что прогер не использует where в выборках базы!

Запросы базы оптимизируйте, все что больше 1й секунды выполняется - это плохо!

Хорошо было бы включить кэшировние в базе.

не может найти скрипт который ты просишь его запустить.

Показывай конфиг nginx.conf и конфиг виртуал хсота.

Цены на аренду серверов и до подорожания были ЖУТКИЕ! А сейчас стали просто ФАНТАСТИЧЕСКО жуткие!

greg_cdr@i.ua:
На производительность мускуля могут оказывать влияние железо, ОС и т.д.

Но как правило, узкое место - перегрузка проца и подсистем ввода/вывода (оптимизацию запросов к базе, пока что не берем во внимание)

Насчет проца - нужно смотреть на версию базы, где лучше реализована работа с ядрами. Почему только Mysql? Может есть смысл посмотреть в сторону Percona, Maria DB. Эти решения работают и поддеррживают практически весь стандартный функционал мускуля "с коробки".
Вы можете взять проц с кучей ядер, а релизация текущей версии мускуля, к примеру, может не работать эффективно с таким количеством ядер.

SSD для базы всегда лучше, чем обычные винты :)

Выбор операционой системы + файловой системы, тоже немаловажный аспект.

Опять такие - файловую систему нужно выбирать в идеале, в зависимости от типа движков ваших таблиц. Что-то лучше для InnoDB, что-то для MyIsam лучше и т.д.

Хмм, и какая фс лучше подойдет к innodb?

Всего: 852