Не, куда там, я тоже не сплю. А, кстати, вот kostin ранее говорил, что, возможно, кроме этого процесса было ещё парочку (тоже перловских), но их — бахнули сгоряча.
Не, это вряд ли. Юзера webtin я же сам когда-то добавлял по ходу дела. Плюс видно, что скрипт работает 173 часа, а это меньше на несколько дней, чем аптайм сервера (т.е. при старте сервера этот скрипт не поднимался).
dsd_corp, вы, к моему сожалению в текущей ситуации, совершенно правы. Анализируется только та часть текста, что расположена после закрытия последней ссылки. Например, если единственное правильное вхождение огурца окружить ссылками (ссылка до и ссылка после него), то слово совсем не заматчится. Эх.
Ну, да. Это я понимаю. И культовый ответ на вопрос про html и регулярки мне тоже известен :-) Но если уж оно совсем нерешаемо регулярками, то интересно было бы разобраться, что именно тут непреодолимого.
Выражаясь вашим языком — я сейчас как раз учусь плавать, притом я даже не мечтаю стать олимпийским чемпионом, но хочу сам переплывать хотя бы озеро или пруд. В пруд я пока и полез (со своим доморощенным vps, на котором висит пара полупустых бложиков). В океан, не умея плавать, я лезть не осмелился (если океан — это продакшн-сервер). Для океана я пока использую, правда, не персонального инструктора (как вы советуете), а спортивную секцию (виртуальные хостинги).
Количество попыток коннекта — я уже ограничил, как можно увидеть в статусе ufw в тексте вопроса.
А вам говорю спасибо за советы про смену стандартного порта и logwatch. Пойду с последним знакомиться.
Если не найду конструктивного решения, то, видимо, придётся. Восстановить конфиги и контент БД и веб-сервера — вопрос решаемый за час. Но хочется, конечно, более изящного решения и контроля за ситуацией. роме того, волнует как именно проникли: доказательств того, что пароль утёк из FTP-клиента — пока нет. И потом: как именно получили рута? Всё это, как минимум, интересно.
Мне нужно знать пиковую загрузку, для этого есть профилировщики, да и сайты можно испытывать по одному. Надо именно текущую нагрузку на одном сервере получать по разным сайтам.
Это задача наверняка имеет решение, ведь как-то с этим справляются, например, провайдеры виртуального хостинга. Хотя у них, подозреваю, сайты разнесены по отдельным пользователям.
Боюсь, munin на моём сервере для того же apache будет собирать только общую статистику, не показывая сколько отъедает каждый сайт ресурсов. Ведь даже прописывая в /etc/munin/munin.conf разные домены, я всё равно статистику собираю с одного и того же munin-node.
У меня проблема не в том, чтобы выявить и наказать виновного: я не виртуальным хостингом занимаюсь. Хочется просто видеть как сервер в себя чувствует в целом и кто из сайтов вносит самый тяжелый вклад в затруднённое дыхание именно сейчас. Профилировать каждый сайт в отдельности и в изолированной среде я могу, хочется иметь срез на общем боевом сервере под текущей нагрузкой.
Увы, но, в итоге, примерно так и пришлось делать. Это временный костыль до тех пор, пока нельзя будет сменить архитектуру.
Немного улучшил алгоритм лишь тем, что завёл массив с теми номерами цитат, которых по уже проведённым испытаниям не было в хранилище. И брал, соответственно, случайные элементы НЕ из него.
Приоритет зон для РФ: ru, su, com, net, org, pro. Поисковикам — плевать. Приоритеты исходя из людских предпочтений.
Домены — лучше, когда короче и когда пишется русскоязычным человеком однозначно.
Ключевики в домене поисковиками видятся, но я бы рекомендовал лучше короткий для людей, чем длинный для поисковиков.