ssh на роутере Asus WL520GU открыть на WAN (с LAN доступ — ок)

вы ещё мою не видели :) но ничего. Консоль и помощь зала спасли и на старом релизе.

ssh на роутере Asus WL520GU открыть на WAN (с LAN доступ — ок)

Помогло, спасибо. Проголосовал за плюс в карму.

PS: Тем кто будет потом по топику себе настраивать, после iptables не забудьте ещё раз
flashfs save && flashfs commit && flashfs enable

ssh на роутере Asus WL520GU открыть на WAN (с LAN доступ — ок)

Выглядит хорошо. Похоже, действительно, надо обновить прошивку )

ssh на роутере Asus WL520GU открыть на WAN (с LAN доступ — ок)

На dd-wrt это выглядит действительно просто, но то что вы прислали это не то. Это доступ к веб-админке (которая сама на принтскрине) с внешней сети и порт по которому к ней будут обращаться. Настройки ssh там в другом месте. Но действительно там это всё проще.
Если не получится донастроить руками ssh, то прийдётся обновлять прошивку. Просто дать 1-2 команды из консоли проще и менее рискованно чем заливать новую прошивку.

ssh на роутере Asus WL520GU открыть на WAN (с LAN доступ — ок)

Может у меня прошивка старая, но у меня в Web UI нет ничего связанного с SSH. Но есть предлоложение что дело у меня даже не в ssh самом, а в файрволле. Попробую ещё, вот, решение от товарища, упомянутое выше

ssh на роутере Asus WL520GU открыть на WAN (с LAN доступ — ок)

Спасибо, вечером попробую

ssh на роутере Asus WL520GU открыть на WAN (с LAN доступ — ок)

выключать файрволл совсем тоже не хотелось бы. Предпочёл бы только этот порт, но попытки убедить роутер в этом через известные мне интерфейсы не привели к хорошим результатам

NHibernate vs хранимые процедуры

А профайлер — да, никто не отменял, я даже up на ответе Bick-a нажал :) Просто, как правило, как я писал — если ORM генерирует не такой запрос, как хотелось бы, иногда повлиять на это сильно не просто (по сравнению со случаем, когда пишешь запрос самостоятельно).

NHibernate vs хранимые процедуры

Тогда я не понимаю вопрос ТС-а: что значит «выборка всех порциями»?

Integrated R in Oracle 12c

Понятно. Статью по установке в 11-ку (это и другие видел). Думал что 12-ка всё же в себе содержит. Но, похоже, ошибался. Буду доставлять. Спасибо.

Создание теговой системы

А что жуткого? Структура правильная. Запрос чтобы получить список post_id, в которых есть запрошенные теги будет выглядеть проще:

SELECT pt.post_id 
  FROM post_tag pt,
       tag      t           
 WHERE t.tag_id = pt.tag_id
   AND t.tag IN ('tag_1','tag_3')
GROUP BY pt.post_id
HAVING COUNT(*) = 2; -- где 2 = количество тегов, по которому ищем.
-- написано в оракловой нотации - в других диалектах может чуть видоизменится

Более сложные пожелания, потребуют более сложных запросов, конечно, но ничего сверх-сложного.
В том что написал copist ничего страшного нету — он просто ещё дополнительно посчитал у выбранных статей сколько ещё «других» тегов проставлено и выбрал первыми те, у которых дополнительных тегов меньше.

Создание теговой системы

Ну… потому что это всё равно, что с кувалбой бегать за мухами, нет? Может, для мух взять мухобойку?
Из той же серии я предлагал продукты основанные на Lucene — но это скорее для индексации самих документов.
А чтобы проиндексировать уже структурированные данные, мне кажется обычной реляционки хватит выше крыши.
Просто прикинем, база у ТС — 100 Гб. Там хранятся статьи. Не знаю каких размеров — не признаётся ;) Предположим, средний рзамер статьи около 10Кб. Несложными арифметическими выражениями получается приблизительно 10 миллионов строк. Для обычного b-tree индекса это не так уж много, скажем честно. У нас в системах за день, бывало, больше загружалось данных.
Ок, скажем на каждую статью у него будет до 100 миллионов строк. Снова таки — не предел. В крайнем случае можно сделать партиционирование по hash(tag_id) и раскидать на несколько партиций. И то, не факт что понадобится.

Но, даже если человек захочет городить свой велосипед, или использовать nosql-базы, то я ему привёл пример как это несложно реализовать. Зачем ради поиска по ключу по структурированным данным прикручивать инструмент полнотекстового поиска? Так недолго и открытую версию поискового engine гугла прикрутить.

Создание теговой системы

А какой метод реализации полнотекстового поиска предлагаете использовать? Уверены что быстрее (и проще) будет? С учётом того, что человек спрашивает про базу всего то на 100Гб.

Создание теговой системы

PS: сорри, случайно вместо ответа на Ваш комментарий, начал ещё одну ветку.

NHibernate vs хранимые процедуры

Я, к сожалению, слабо знаком с внутренностями работы NHibernate (точнее, во что выльется, работа NHibernate). Если организует, наподобии, ADO.NET структуры данных на клиенте, и судя по вашему описания вопроса — на клиент скачает все миллионы строк, чтобы там за-join-ить, а потом отфильтровать по ID, то да — это 100% медленнее (сами подумайте — ресурсы хотя бы на скачивание данных на клиентскую сторону уже покроют вопросы :) ). Добавим то, что методы соединений и фильтрации у Оракла порядочно более эффективные, чем .NET-овские + предположительно в базе у вас есть соответсвующие индексы (а если нет, то при необходимости их можно будет создать). Итд итп. В общем я на 200% за то, чтобы работу СУБД делала сама СУБД, а не клиентское приложению. Слесарю — слесарево, кесарю — … гхм, это не из той песни.
Оставляю только призрачную вероятность того, что Hibernate способен обрамить ваши пожелания в разумно сформированный и хорошо написанный запрос и отправит его на выполнение базы, то производительность станет сравнимая… Но в автоматически написанный хороший запрос верится с трудом (разве что он совсем простой, и то… ). И если вам хоть немного не понравится то, что нагенерировано автоматически, в ORM намного сложнее что-то исправить (по сравнению со случаем, когда вы сами пишете запрос).
Подводя итог: если у вас стандарт — вызов хранимых процедур — туда вам и дорога. Правильно всё вы делаете, продолжайте :)

Создание теговой системы

MapReduce сейчас настолько на слуху, что его еспользуют в тему и не в тему :)
Что в вашей вселенной «огромное»? Миллиарды записей? Сотни миллиардов? Можно уточнить порядок? В целом сотни миллионов записей в связке спокойно выдержит реляционка с индексами. В худшем случае прийдётся добавить партиционирование. До десятков миллионов даже партиционировать не обязательно.

Ну и, ещё, рекомендую на Хабре поискать статью о том, как реализовывался сервис поисковых подсказок портала prom.ua. Хоть тема и немного другая, но суть, мне кажется, вам подойдёт. Они как раз беспокоились подобными вопросами (создание прямого и обратного индекса, уменьшение его размеров, ускорение работы этого инструмент), уход от прохода всех записей итд. Не думаю что мне стоит повторятся — даже если вам и не подойдёт их опыт, думаю на определённые мысли направит.

Как объяснить фирме, что их сайт содержит критическую уязвимость?

Ну, у меня дома интернет появился в 1995 (да, повезло, спасибо родителям, но, к концу 90-х это уже не было столь нереальным). В начало 2000 пришлась пора рассвета локальных сетей, в т.ч. предприятий, которые модно было подключать к интернету. Сети строились «как могли». Подключали — как получилось. Разбирались в этом единицы, а хотели — многие. И подключались. Не понимая рисков. Оставляя, банально, гостевые пароли. Аккаунты администрраторов и пользователей без паролей (или с класс, стандартные сетевые шары (помните ещё C$, D$ итд?). Ну это из простого что можно в двух словах в комментарии написать.

Как объяснить фирме, что их сайт содержит критическую уязвимость?

Мы вот так, бывало, и звонили (был случай — сеть открыта буквально настеж. На рабочий стол компьютера сети под неброским названием «TheBoss» даже зайти можно было), у которого на том же столе лежали финансовые документы. Пытались как раз связаться с этим самым «the boss» и объяснить ему проблему, предложить свои услуги, чтобы сказать где у них есть «дырки» размером с пропасть и, при желании, предложить услуги по закрытии хотя бы «парадного входа». Чуть не поимели большие проблемы. Помню тот случай хорошо.
PS: названия компаний и подробности оставляю обезличенными, думаю, по понятным причинам.

Как объяснить фирме, что их сайт содержит критическую уязвимость?

hermit931, хорошо если соответсвующий сотрудник — это ИТшный отдел. А если свою службу безопаснотси и юристов? Особенности нашего рынка. Мы в конце 90-х, начале 2000-х пытались делать то, что сейчас называли бы чем то типа ИТ-аудита начального уровня. Только «рынок» тогда вообще не понимал что мы им предлагали. Разные варианты пробовали, потому я понимаю автора… Но это очень «тонкий» вопрос. Часто действительно на грани того, чтобы тебя не приняли в лучшем случае в законный оборот. В худшем — 90-е были в то время «ещё вчера». А сколько компаний работало с практически «открытыми воротами»… когда вся внутренняя сеть безпарольно была открыта в сеть. Или не сильно напрягаясь можно было пробраться ко всем электронным документам контор. Но выйти на связь и предложить свои услыги всегд индивидуальный и сложный вопрос был. Сегдоняшние компании, всё-же, лучше понимают суть вопроса. Сейчас даже «домохозяйка» понимает что такое «потенциальная опасность взлома сети вашего предприятия».
А демонстрировать действительно опасно. И даже проверять без предварительного согласования. Можно получить неприятности.

Как объяснить фирме, что их сайт содержит критическую уязвимость?

Так написали именно как я сказал, или «с полным описанием проблемы»? На первом этапе не нужно большое и детальное описание проблемы. Вас, с большой вероятностью, там прост оне поняли. Я не знаю куда вы писали, но с большой вероятностью там сидит девочка, которая просто разбирает почту и поток ваших идей просто не поняла / не оценила. Нужно короткое, но привлекающее внимание информационное сообщение, чтобы она привлекла к рассмотрению соответсвующих специалистов. Потому я и написал как написал в изначальном сообщении. А уже со специалистами говорить о «полном описании проблемы».