Идея в том, что у API в принципе нет метода (по крайней мере доступного для фронтенда) чтобы сделать то, что фронтенду не нужно (напр, получить всех юзеров или дропнуть таблицу). Поэтому обращаться некуда.
Сделать доступ к записи пользователя только после его аутентификации - возможно? А лимитировать "дать не более 100 записей из табл. customers" за день ?
По производительности: у меня сейчас идея как раз в том, чтобы только маленькую часть данных (самую конфиденциальную) так надежно защищать, поэтому, даже если логин будет происходит не 0.01s а 10s - это все равно терпимо. А 90-99% данных могут быть по прежнему в базе, пусть даже утекают - их утечка мало что даст.
database firewalls прямо звучит как надо :-) Еще вопрос: а что-то опен-сорсное, бесплатное есть в этой сфере? По первому впечатлению, Imperva - это что-то для компаний типа боинга или кока-колы, за миллионы долларов.
Проблема в том, что я наверняка не знаю, что у меня жрет ресурсы. Сервер (VPS) при не очень высокой нагрузке более-менее нагружен. И у меня есть подозрение, что это связано с логированием (возможно, это и есть стадия "логи начали влиять на производительность"), но я в нем не уверен (возможно, другие части приложения грузят базу, и база тормозит не потому что загружена логами, а по иной причине).
Можно ли как-то посмотреть/сравнить сколько ресурсов отжирает работа с каждой таблицей?
Погляжу, спасибо, но предварительно эта идея кажется оверкиллом. Логи в моем случае очень маленькая и не очень важная часть приложения, и разворачивать целый стек ПО для этой задачи - "ну такое"...
Примерно как для шелл скрипта вся схема логирования - это код: echo `date` message >> $LOG
Тут, мне кажется, проблема не с CORS а с OPTIONS. Запрос на OPTIONS возможно не доходит от вебсервера до этого куска кода. Под каким вебсервером крутится это приложение? Может быть такое, что код исполняется только для методов GET/POST но не для OPTIONS?
RoffDaniel, bad ownership or modes for chroot directory component "/var/kov-mc/"
Вот и ответ. Надо медитировать на тему владельца-группы и прав доступа /var/kov-mc/
В целом, я с вами согласен, это все разумно. Но вот в моем случае, похоже, не подойдет:
1. Stress тест
Приложение сейчас хостится на VPSках. Соответственно, тут две стороны - с одной, на дешевой VPS в предел производительности мы точно можем упереться довольно легко. С другой - всегда есть решение в виде простого апгрейда тарифа на более мощную VPS. (Но мне, технически, конечно хотелось бы заранее знать, что архитектура у меня такая, что масштабироваться будет легко, даже когда дальше уже некуда апгрейдиться). А вот stress-тест сделать на облачной базе - можно ли? Или выйдет достаточно дорого (ведь нужно ее забить огромными объемами) ?
2. Read Only запросы
Увы, приложение по большей части собирает данные. Конечно, иногда и отдает тоже, но в обычном случае, наверное, на 100-1000 read есть один write, а у меня наоборот.
Хотя кто потом будет читать этот вопрос, для них это, возможно, будет правильными советами, сам так считаю.
Согласен с вами, про идею. Поэтому и не планирую продавать ее, вряд ли кто-то купит.
Деньги - это мотивация, да. Но не единственная. Мое имя есть в исходных кодах ядра ОС Linux, участие в других известных проектах и это серьезно помогает при поиске заказчиков. Участие в интересном проекте - всегда плюс. Помните, был такой проект, Chatroulette. Сколько он принес денег? Да вроде нисколько. Но он интересный и он создал имя (раз даже NY Times написали и в South Park спародировали). Молодой программист который после ВУЗа уже может сказать "я был основным программистом для этого интересного проекта" - получает серьезное преимущество.
Почему вы считаете, что цель должна быть обязательно измеряемой, чтобы человек заинтересовался? Это в постановке задачи, задача должна быть обязательно измеряемой (чтоб было понятно, достигли цели или нет), и как вариант, измерять можно через аудиторию проекта, но как proof-of-concept, доказательство, что человек действительно освоил технологии - достаточно проекта с 1 пользователем. Это уже имеет ценность ведь. (Хотя миллион - конечно лучше).
А вот насчет бумажки - презентации, да, отличная идея, лучше чем каждому сумбурно ее пересказывать, забывая иногда некоторые важные моменты.
В принципе - да. Если программист не камень, который нужно через силу тащить и пинать, то его юношеский энтузиазм иногда нужно поднаправить только. Ну, например, объяснить, что вот тут данные надо не напрямую передавать, а через openssl тоннель, что для хранения таких данных лучше не SQL базу, а No-SQL итд. По себе знаю, что очень часто какой-то важный совет состоит из одного слова, которое надо загуглить или провикипедировать и сразу наступает озарение и меняется видение проекта.
Фактически - это же получается просто общение с коллегами на общую интересную тему, а не работа, вот как мы сейчас бесплатно общаемся свое время - просто из интереса. Поотвечать на письма иногда и может раз в 1-2 недели попить кофе-пиво обсуждая это вживую - почему бы и нет?
Ну и отчасти мотивация в этой смене задач, смена деятельности, поиграться в это - с малыми рисками посмотреть, насколько можно минимизировать свое время контроля проектом. Вдруг да получится? А если и нет - ну невелика беда, можно заново проект начать или просто похоронить его.
Даже копейки жалко (это своего рода забава для фанатов, а не инвестиции), и не то отношение к проекту. Я бы скорее предпочел молодых энтузиастов, которым не нужно денег, у которых есть энтузиазм, но при этом они могут срывать сроки и иметь долгий learning curve, для фанатского проекта это не проблема.
Александр Маджугин, мне понравилась эта идея (хотя и через задницу, но вполне рабочая же!). Только, надо, наверное, не bash а busybox, потому что bash не сможет даже ps запустить, если памяти нет, а в busybox они встроены все. Хотя, блин, malloc() то все равно вызывают - может и упасть, наверное.
Дмитрий Александров, я понимаю что вы хотите донести. И я спрашиваю про другой (гораздо более сложный) путь, не потому что простой, прямой и короткий путь мне не нравится, а именно наоборот - именно потому что он мне полностью понятен, зачем мне отвлекать тут людей вопросами, на которые я знаю ответ? Это не ситуация или/или. Сервер уже ребутнули, логи начали копать, итд. (как бы, простуду вылечили до следующего раза традиционными понятными средствами)
Просто эта проблема (моя частная, локальная и понятная) меня натолкнула на мысль о более глобальной мировой проблеме, с которой все изредка сталкиваются (невозможность удаленно зайти на сервер) и вот эта ситуация технически у меня вызывает больше интереса и желания понять ее :-). (хочется понять, есть ли универсальная вакцина от этой простуды)
Да в другом дело. С сервером (с частной проблемой) уже решилось все. (перегрузили и зашли).
Суть моего вопроса про ОБЩУЮ ситуацию - как сделать когда у меня или у вас или у кого-то еще будет какая-то задача, которая отжирает память - как сделать чтобы SSH работал? Предотвратить OOM в мировом масштабе - задача заведомо невыполнимая. А вот сделать так, чтобы по SSH можно было зайти даже когда на сервере OOM - это вполне решаемо. (и мне немного странно, что до сих пор это никем в мире не сделано).
Как один из вариантов - вот cgroups выше предложили. А у меня была мысль, может быть как-то можно пре-аллоцировать мегабайт 10-50 для SSH, чтобы рут всегда мог зайти и запустить ps, kill итд
