| |
| |
| 3.15, Аноним (15), 01:04, 15/08/2026 [^] [^^] [^^^] [ответить]
| +/– |
Можно подумать, что ты хоть раз расследовал на гигабайтах логов.
Есть смысл временно включать, чтобы проверить почему падает отдельная служба, но держать на постоянке и никогда туда не смотреть... ну ты сам себе буратино.
| | |
| |
| 4.19, Аноним (2), 01:21, 15/08/2026 [^] [^^] [^^^] [ответить]
| +/– | |
Гигабайты там и не нужны. Хватает 100 строчек выхлопа тогоже ядра, чтобы понять, почему вся система отъехала.
К слову, актуально даже на десктопе с теме же амдешными, кривыми GPU дровами.
| | |
|
| 3.16, Аноним (16), 01:06, 15/08/2026 [^] [^^] [^^^] [ответить]
| +/– | |
> Удачи потом в расследовании инцидентов.
Может он эти инциденты и создает? "В расследовании главное не выйти на самого себя!"
| | |
|
|
| |
| |
| 3.12, Аноним (16), 00:59, 15/08/2026 [^] [^^] [^^^] [ответить]
| –1 +/– | |
> А как пели: бинарный формат, это не партянки, всё быстро...
А оно и правда - быстро. Скажем я могу более-менее в реальном времени парсить "все сообщения от sshd". Префильтр и индексированный доступ - обеспечит сам journald. И сообщение таки - можно атомарно читануть от и до.
В текстовом же случае...
1) Вы вообще сами будете искать где граница между сообщениями. Мало того что это пригрузит проц - так вы еще и облажаться рискуете, когда атакующий в какой-нибудь юзернейм или что там 0x0d, 0x0a, 0x0 или что там воткнет - парсинг текста сорвется - и вы получите неполные или поддельные записи логов под контролем атакующего вообще. Что может быть использовано для обхода банов, крафтинга банов совершенно непричастным айпишникам и проч.
2) Парсинг гигз логов - нифига не быстро. А без этого - как вы вообще получите знание "сколько запросов с этого IP было за последние 5 минут"? Вот то то и оно - трекать такие вещи с текстовиками - потребует опять же юзать бинарные бд для всяких индексов - и вообще enterprise-grade soultion. Который настолько монструозен что будет у полутора коопрв. А доморощенные админы будут сиять голым окороком - доказывая что и так сойдет!
| | |
|
|
| 1.4, Аноним (4), 00:35, 15/08/2026 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
А я думал это норма, что что все эти лог журналы насилуют твой ссд, чтобы потом форензик экспертам было легче копаться в твоих штанах.
| | |
| |
| 2.8, Аноним (-), 00:52, 15/08/2026 [^] [^^] [^^^] [ответить]
| +/– |
> А я думал это норма, что что все эти лог журналы насилуют твой ссд,
> чтобы потом форензик экспертам было легче копаться в твоих штанах.
Да не парься ты так - форенсики с твоего SSD и с якобы-in-place файлухи вынут кучу данных с твоего SSD. Потому что флеш память не умеет in place перезаписи, внезапно. А стирание медленное и крупноблочное. Так что контроллер - всяко почти наверняка CoW сделает. И если читануть NAND напрямую без его услуг по пропуску лишнего...
Кстати, "secure" erase с явным протиранием нулями региона - тоже так не сработает. Оно протрет нолями ДРУГОЙ регион SSD. Вот явный запрос TRIM конкретного региона - еще может какую-то пользу принести. Только это блочный уровень, ФС сами по себе без явного прокостыливания такими вещами не оперируют.
| | |
|
| 1.5, Аноним (-), 00:48, 15/08/2026 [ответить] [﹢﹢﹢] [ · · · ]
| –2 +/– |
> В данном случае разработчики systemd продемонстрировали
> типичный для корпоративного Open Source подход
В данном случае опеннетчики продемонстрировали типичный подход: много критиканить других и мало делать самим. А ваши текстовые логи - это прекрасно. Кроме того момента что даже просто банить околореалтаймно ботов по ним адское мучение. И либо дичайше жрет проц на парсинг гигабайтов - либо требует навороченных энтерпрайзных систем с индексами, и там вопрос амплификации, нагрузки и проч вообще - не раскрыт.
А каких-то реально сравнимых решений получить? Что вы, не дождетесь!
| | |
| |
| 2.9, Аноним (9), 00:53, 15/08/2026 [^] [^^] [^^^] [ответить]
| +1 +/– |
Так может лучше задействовать для бана ботов нормальную базу данных, а не эти ошмётки? А текстовые логи оставить только для отладки.
| | |
| |
| 3.13, Аноним (16), 01:03, 15/08/2026 [^] [^^] [^^^] [ответить]
| +/– |
> Так может лучше задействовать для бана ботов нормальную базу данных, а не эти ошмётки?
> А текстовые логи оставить только для отладки.
Ваша проблема в том что у вас в итоге только:
- Голый зад - и нифига кроме рассказов как все это "не надо".
- Невь...й enterprise grade которому для обслуги надо тиму фултайм админов в комплекте. Потому что ваша нормальная база данных - обслуживаемая. И надо - того кто умеет в DBA. Бесплатно работать DBA почему-то не любят.
А mid-range и просто возможность забанить надоевших ботиков с своего сервера без огромных напрягов и затрат? В вашей картине мира такое не предусмотрено вообще. А у поттера так можно было. И это причина по которой мир в целом предпочел - его. А вы можете свои базы данных админить, если вам это надо.
| | |
|
|
| 1.10, Аноним (6), 00:55, 15/08/2026 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
> типичный для корпоративного Open Source подход: критический недочёт в инфраструктурном компоненте игнорировался годами
Вся суть архитектуры системды.
| | |
| |
| 2.17, Аноним (16), 01:17, 15/08/2026 [^] [^^] [^^^] [ответить]
| +/– |
>> типичный для корпоративного Open Source подход: критический недочёт в инфраструктурном
>> компоненте игнорировался годами
> Вся суть архитектуры системды.
А альтернативы то какие? Сидеть с голым задом или огроменные энтерпрайзные монстры? Тоже мне дузовные метания мадам грицацуевой.
| | |
|
|
