Это совершенно не выглядит как мечта. Это выглядит как огромнейший костыль, который толком ничего не решает. А ещё, это выглядит как нейрослоп.
Что у нас уже есть и что нам предлагают? А есть у нас протокол IPv6, который прекрасно работает в самом ядре интернета и у провайдеров, которые его осилили. Этот протокол может делать всё, что умеет IPv4. Этот протокол совместим с IPv4 и вполне может транспортировать пакеты IPv4 внутри себя. Если у вас есть на устройстве протокол IPv6, то вы можете организовать доступ к любым ресурсам. Для этого нужен модифицированный костыль, который повсеместно применяется для IPv4, даже многоуровневый (NAT). DNS уже давно адаптирован для IPv6. DHCPv6 уже давно существует и при этом не является обязательным условием для автоконфигурирования сети (всё работает и без него, но вы можете его использовать для более сложной конфигурации). Все современные операционные системы поддерживают протокол IPv6, а если есть какие-то проблемы, то это проблемы конкретного софта, а не самой операционной системы. Все мобильные ОС умеют работать в сетях с исключительно IPv6-адресацией и из коробки имеют необходимый костыль — CLAT, для работы с IPv4 сервисами, которые не удаётся обмануть с помощью NAT64+DNS64. Большая часть сервисов работает без CLAT. Из того, что не работает без CLAT, я нашёл толко торрент клиенты и Steam. Точнее, торренты работают, но число пиров на IPv6 значительно меньше, чем IPv4 и часто невозможно скачать некоторые раздачи без доступа к IPv4 пирам. CLAT в настольных ОС из коробки есть только macOS, для Linux есть несколько решений, в будущей версии NetworkManager 1.58 тоже будет поддержка (можно попробовать уже сейчас установить версию 1.57). Для Windows 11 соответствующий патч проходит тестирование.
Производителям маршрутизаторов не нужно изобретать велосипед, так как уже есть, как минимум, OpenSource операционная система OpenWrt, которая поддерживает IPv6 из коробки, настроена по умолчанию безопасно (нужно только задать пароль для входа в интерфейс) и которую производители могут адаптировать под своё железо.
Чего не хватает в IPv6? То, что если вы пользуетесь только IPv4, то вам недоступны ресурсы IPv6. Есть костыльные решения, которые позволяют организовать доступ, но вы становитесь зависимым от туннельного брокера.
Что же нам предлагают по этому документу? Сегментировать интернет. Сделать кучу разных сегментов, которые напрямую друг с другом не связаны. Те устройства, что будут оставаться в сети IPv4 также не будут иметь доступа в сеть IPv8. Для доступа к IPv8 тоже нужен будет аналогичный костыль, как и для доступа к IPv6. Только подобный костыль для доступа к IPv6 уже есть, можно сказать есть даже несколько видов костылей. Т.е. единственная вещь, за что можно поругать IPv6 характерна и для IPv8. Для IPv8 нужно будет изобретать что-то новое, этим кто-то должен будет заниматься. IPv8 частично решает проблему нехватки адресов, но оставляет старые костыли в виде NAT для устройств пользователя, как минимум. Сквозную прозрачность хороним сразу. Более того, связь между устройствами из разных сегментов сети будет идти через устройства с довольно сложной логикой трансляции адресов. Это как NAT, только ещё более сложный. И эти устройства должны быть установлены в самое «ядро» интернета, где идут огромные потоки данных. Сомнительно, что современные технологии позволят обеспечить скорость передачи пакетов, которая сейчас есть в IPv4 и IPv6.
IPv6 создавался с прицелом на устранение выявленных недостатков IPv4, ведь при расширении адресного пространства протокол становился уже несовместим с IPv4 напрямую, поэтому и смысла нести дальше с собой все недостатки IPv4 не было. И именно поэтому протокол так отличается от IPv4 в лучшую сторону, хоть и требует некоторого времени на знакомство и выкидывания из головы «IPv4 головного мозга». IPv8 продолжает тянуть за собой все косяки IPv4 дальше.
Я не вижу никакого смысла во внедрении IPv8, даже если напишут то, чего сейчас не хватает даже для того, чтобы его попробовать. Внедрение IPv8 - это шаг назад. Индустрия уже сделала шаг в сторону внедрения IPv6 и на текущий момент любой провайдер при желании может включить IPv6 на своей сети. «Вой», что железки IPv6 не понимают… где вы нашли современное железо, которое не поддерживает IPv6? Вы до сих пор используете коммутаторы и маршрутизаторы из нулевых годов? Можно я не буду вашим клиентом. Лично мне не хочется, чтобы надёжность сети зависела от явно устаревшего железа, которое к тому же имеет довольно низкую, по современным меркам производительность.
Насколько я знаком с IPv6? Мне интересен этот протокол. В настоящее время я использую его в своей домашней сети. У меня есть устройства, которые работают исключительно на IPv6, в том числе сотовые телефоны у членов семьи и мой личный ноутбук с ОС Linux. Особого смысла так настраивать сеть нет, но лично мне интересно было настроить именно IPv6-only сеть, а не дуалстэк. И, как показала практика, это рабочее решение.
Звучит приятно, но есть одно но. На этот адрес будет литься весь трафик IPv4. Если это будет какой-то публичный шлюз, то по сути туда пойдёт весь IPv4 трафик интернета. Что делать, чтобы не перегружать узел? Использовать не один, а несколько. Но тут мы упираемся в префикс 64:ff9b::/96. Его могут использовать провайдеры на своей сети. В таком случае достаточно клиенту предоставить DNS64, или просто на клиенте указать DNS64 от Google или Cloudflare, и весь его трафик IPv4 польётся на NAT64 шлюз провайдера. Примерно также, как льётся IPv4 трафик сейчас на CGNAT провайдера. Только CGNAT с каждым годом всё больше и больше загружен, а нагрузка на NAT64 будет падать по мере внедрения на интернет сервисах IPv6.
В принципе, провайдеры тоже могут маршрутизировать 64:ff9b::/96 на вышестоящего оператора, который будет на своей сети иметь NAT64.
То, что в IPv6 сквозная прозрачность вовсе не означает что узел А может общаться с узлом Б! И современные маршрутизаторы по умолчанию настроены так, чтобы не пускать кого попало в периметр локальной сети. И им никакой NAT не нужен, чтобы это сделать для IPv6.
Читер. Я также могу сделать со своим DNS64+NAT64 и спокойно сидеть в своей IPv6only сети с доступом ко всем сервисам интернета без ограничений по версии протокола. Только это не отменяет того, что vk недоступен по IPv6.
По сути из 128 бит для выделения клиентам используется только 64. Но и даже эти 64 нарушают рекомендации и тогда для адреса клиента остаётся уже 56 бит. А если следовать полностью рекомендациям RIPE NCC, то для адресации клиента вообще остаётся всего 48 бит. Все остальные биты адреса уходят клиентам. Благодаря таком распределению адресов клиентам никогда не понадобится NAT, а в его сети будет нормально работать автоконфигурация. Но даже при таком раскладе каждому человеку на земле достанется как минимум по 200 сетей /48 только в одном диапазоне 2000::/3.
В IPv6 согласно bcom-690 провайдеры должны выдавать клиентам стабильный префикс /48, ну или /56, если они хотят разделить бизнес и домашних пользователей. Выдача динамического префикса по сути нарушение этих рекомендаций. Тот же Ростелеком их нарушает.
Мне от интересно как они умудрились в клиенте для Android сломать IPv6. Если ваш провайдер даёт вам DNS64+NAT64, то у вас ни один прокси не заведётся. Всему виной записи типа AAAA. Телеграм видит эту запись, пытается соединиться, но у него не получается. Это единственное приложение, которое не может работать с IPv6, которое я знаю. А я уже довольно продолжительное время использую режим IPv6only на своём телефоне и компьютере на Linux. Большей части приложений хватает DNS64+NAT64. Остальные несколько программ можно заставить работать с помощью CLAT, который на Android из коробки начиная с Android 4.3. Справедливости ради, нужно сказать, что прокси таки можно заставить работать. Но для этого нужно доменное имя заменить на IPv4 адрес, на который ссылается это доменное имя. И благодаря CLAT, прокси заработает.
Было бы неплохо эмулировать клиента. Так, например, можно подписаться на чат класса своего ребёнка и пробрасывать через телеграм бота сообщения в группу телеграм для всех родителей.
По какой-то причине Telegram на Android видит AAAA записи и не может по этим адресам подключиться. После неудачных попыток он просто пишет, что сервер недоступен. Если просто вписать IPv4 адрес, то прокси начинает работать. также не работают прокси если указать IPv6 адрес. Проблема только в Android клиенте Telegram. Декстопные версии и Telegram X такой проблеме не подвержены.
Кстати, проблема может вылезать на Мегафон и МТС, т.к. у них есть IPv6 и у них есть NAT64+DNS64. Они формируют фейковые AAAA записи с указанием на свой шлюз NAT64.
nslookup, dig, host. Если есть AAAA запись содержащая IPv6 адрес, то могут быть проблемы.
Бороться с этим не надо, нужно чтобы Telegram починили. Но если есть AAAA записи, например, если у вас Мегафон (там работает DNS64, на МТС не проверял, у других сотовых нет такого), то можно просто вместо имени домена вписать IPv4 адрес. Мера временная. Адрес сервера может смениться. Но это уже вручную придётся отслеживать. По хорошему нужно патчить Android клиент Telegram. На десктопе всё работает.
Альтернативный вариант - поставить Telegram X от того же разработчика. Но мне он показался неудобным. Зато с прокси работал нормально.
Визуально заработало, но раньше оно тоже работало, но отваливалось. Ну и так и не исправили проблему с IPv6. Он вообще не работает, а если у домена есть AAAA запись, то прокси вообще никакой работать не будет.
Не видел, чтобы Хабр был недоступен. Но пос е 22 часов при входе на него очень часто отображались ошибки 502 и 504. А это значит сам Хабр был доступен, но лежал бэкенд за nginx.
С лагом в одну секунду, что при реалтаймовой отладке чего-нибудь раздражает
Ради интереса открыл journalctl -f на своём компьютере и попробовал обратиться к веб-серверу nginx локальному. За одно туда много пишет отладочной информации php-fpm, всё-таки у меня сервер стоит для разработки. Время от нажатия кнопки обновить в браузере и вывод логов занимает доли секунды. Точнее, чтобы узнать сколько, нужно что-то аппаратное, потому что глазом видно, что это происходит почти мгновенно.
Вероятно на продакшене может быть задержка, Но она связана, скорее всего, с повышением эффективности логирования. Если нагрузка большая и логов много, логично накапливать их в оперативной памяти, а потом сбрасывать на диск всем куском, чем дёргать диск на каждый чих.
Вышеупомянутый перенос логов nginx из текстовых файлов в journald для меня выглядит самоубийством
Рекомендую всё-таки ознакомиться с возможностями journalctl. Там есть и свой grep, и фильтр по датам, и поиск по метаданным, и аналог tail -f.... Лично мне больше понравилось. Плюс не нужно быть root, чтобы логи смотреть. Достаточно дать пользователю необходимые права. А также вместо путей /var/log… можно пользоваться просто тегами или именами сервисов (опять таки, надо смотреть что удобнее в каждом конкретном случае). Мне тоже, по началу, казалось сложно, но сейчас наоборот - ведение логов в текстовых файлах кажется дичью.
Скорее всего где-то вы ошиблись. Внимательно посмотрите на то, что там пишется. Может быть какой-то сервис сильно много чего-то пишет. В любом случае, если у вас journald, то там есть ограничение на максимальный объём файлов журнала. В случае переполнения, старые логи просто начнут удаляться и дополнительного места на диске уже не потребуется. Я бы просто запустил journalctl -f и посмотрел чего у меня там летит такого, что постоянно забивает логи. Возможно у какого-то сервиса не выключена отладка или что-то сбоит.
Могу сказать только в защиту nginx. Он по умолчанию пишет сообщения самостоятельно. Но это легко меняется в настройках и он отлично пишет в journald. Особенно удобно, когда логи nginx можно просматривать совместно с логами php-fpm через journalctl. Сразу видно какой запрос пришёл, какую отладочную информацию выдал php-fpm и какие проблемы возникли при обработке запроса PHP. В java, наверно, тоже можно сделать что-то подобное.
Это не вредительство, это обычное поведение файловой системы linux. Оно в корне отличается от того, что происходит в Windows. Пока что-то держит файл, файл после rm физически не удаляется и продолжает работать. При этом для тех, кто файл не держал, файл фактически считается удалённым. В Windows же при попытке удалить файл, пока его кто-то держит, вываливается ошибка.
Всех этих мучений, что описаны в статье, можно было бы избежать, если бы сервис не писал файлы логов самостоятельно, а доверил это какому-либо сервису по ведению логов. Там все особенности файловой системы linux уже учтены.
А я как-то привык писать логи в journald. Он, и логи в сжатом виде хранит (с поиском по ним), и о ротации заботится, и чтобы диск не забивался логами (ограничение на максимальный размер). А ещё du себя очень странно ведёт на дисках с btrfs. У самой утилиты обслуживания btrfs есть свой btrfs filesystem du.
У нас на работе не были PDF, которые были удобнее для печати. Нам слали docx, что по сути тот же самый PDF, но его можно передалать для чтения. Но в документах не это важное. Всё было оформлено по стандратам. Введение, зачем документ, сам документ канцелярским языком, заключение, список кокращений и прочая хрень. Т.е. там документа на 1 страницу обычного печатного текста, а, по факту, там листов 20-30. Видимо какого-то родственника наняли, чтобы эти документы делать. И документы были вроде того, как инженер должен заходить в хату. Не в смысле тюремного. Как в дом зайти к абоненту. Куча текста, информации полезной никакой.
Это совершенно не выглядит как мечта. Это выглядит как огромнейший костыль, который толком ничего не решает. А ещё, это выглядит как нейрослоп.
Что у нас уже есть и что нам предлагают? А есть у нас протокол IPv6, который прекрасно работает в самом ядре интернета и у провайдеров, которые его осилили. Этот протокол может делать всё, что умеет IPv4. Этот протокол совместим с IPv4 и вполне может транспортировать пакеты IPv4 внутри себя. Если у вас есть на устройстве протокол IPv6, то вы можете организовать доступ к любым ресурсам. Для этого нужен модифицированный костыль, который повсеместно применяется для IPv4, даже многоуровневый (NAT). DNS уже давно адаптирован для IPv6. DHCPv6 уже давно существует и при этом не является обязательным условием для автоконфигурирования сети (всё работает и без него, но вы можете его использовать для более сложной конфигурации). Все современные операционные системы поддерживают протокол IPv6, а если есть какие-то проблемы, то это проблемы конкретного софта, а не самой операционной системы. Все мобильные ОС умеют работать в сетях с исключительно IPv6-адресацией и из коробки имеют необходимый костыль — CLAT, для работы с IPv4 сервисами, которые не удаётся обмануть с помощью NAT64+DNS64. Большая часть сервисов работает без CLAT. Из того, что не работает без CLAT, я нашёл толко торрент клиенты и Steam. Точнее, торренты работают, но число пиров на IPv6 значительно меньше, чем IPv4 и часто невозможно скачать некоторые раздачи без доступа к IPv4 пирам. CLAT в настольных ОС из коробки есть только macOS, для Linux есть несколько решений, в будущей версии NetworkManager 1.58 тоже будет поддержка (можно попробовать уже сейчас установить версию 1.57). Для Windows 11 соответствующий патч проходит тестирование.
Производителям маршрутизаторов не нужно изобретать велосипед, так как уже есть, как минимум, OpenSource операционная система OpenWrt, которая поддерживает IPv6 из коробки, настроена по умолчанию безопасно (нужно только задать пароль для входа в интерфейс) и которую производители могут адаптировать под своё железо.
Чего не хватает в IPv6? То, что если вы пользуетесь только IPv4, то вам недоступны ресурсы IPv6. Есть костыльные решения, которые позволяют организовать доступ, но вы становитесь зависимым от туннельного брокера.
Что же нам предлагают по этому документу? Сегментировать интернет. Сделать кучу разных сегментов, которые напрямую друг с другом не связаны. Те устройства, что будут оставаться в сети IPv4 также не будут иметь доступа в сеть IPv8. Для доступа к IPv8 тоже нужен будет аналогичный костыль, как и для доступа к IPv6. Только подобный костыль для доступа к IPv6 уже есть, можно сказать есть даже несколько видов костылей. Т.е. единственная вещь, за что можно поругать IPv6 характерна и для IPv8. Для IPv8 нужно будет изобретать что-то новое, этим кто-то должен будет заниматься. IPv8 частично решает проблему нехватки адресов, но оставляет старые костыли в виде NAT для устройств пользователя, как минимум. Сквозную прозрачность хороним сразу. Более того, связь между устройствами из разных сегментов сети будет идти через устройства с довольно сложной логикой трансляции адресов. Это как NAT, только ещё более сложный. И эти устройства должны быть установлены в самое «ядро» интернета, где идут огромные потоки данных. Сомнительно, что современные технологии позволят обеспечить скорость передачи пакетов, которая сейчас есть в IPv4 и IPv6.
IPv6 создавался с прицелом на устранение выявленных недостатков IPv4, ведь при расширении адресного пространства протокол становился уже несовместим с IPv4 напрямую, поэтому и смысла нести дальше с собой все недостатки IPv4 не было. И именно поэтому протокол так отличается от IPv4 в лучшую сторону, хоть и требует некоторого времени на знакомство и выкидывания из головы «IPv4 головного мозга». IPv8 продолжает тянуть за собой все косяки IPv4 дальше.
Я не вижу никакого смысла во внедрении IPv8, даже если напишут то, чего сейчас не хватает даже для того, чтобы его попробовать. Внедрение IPv8 - это шаг назад. Индустрия уже сделала шаг в сторону внедрения IPv6 и на текущий момент любой провайдер при желании может включить IPv6 на своей сети. «Вой», что железки IPv6 не понимают… где вы нашли современное железо, которое не поддерживает IPv6? Вы до сих пор используете коммутаторы и маршрутизаторы из нулевых годов? Можно я не буду вашим клиентом. Лично мне не хочется, чтобы надёжность сети зависела от явно устаревшего железа, которое к тому же имеет довольно низкую, по современным меркам производительность.
Насколько я знаком с IPv6? Мне интересен этот протокол. В настоящее время я использую его в своей домашней сети. У меня есть устройства, которые работают исключительно на IPv6, в том числе сотовые телефоны у членов семьи и мой личный ноутбук с ОС Linux. Особого смысла так настраивать сеть нет, но лично мне интересно было настроить именно IPv6-only сеть, а не дуалстэк. И, как показала практика, это рабочее решение.
Звучит приятно, но есть одно но. На этот адрес будет литься весь трафик IPv4. Если это будет какой-то публичный шлюз, то по сути туда пойдёт весь IPv4 трафик интернета. Что делать, чтобы не перегружать узел? Использовать не один, а несколько. Но тут мы упираемся в префикс 64:ff9b::/96. Его могут использовать провайдеры на своей сети. В таком случае достаточно клиенту предоставить DNS64, или просто на клиенте указать DNS64 от Google или Cloudflare, и весь его трафик IPv4 польётся на NAT64 шлюз провайдера. Примерно также, как льётся IPv4 трафик сейчас на CGNAT провайдера. Только CGNAT с каждым годом всё больше и больше загружен, а нагрузка на NAT64 будет падать по мере внедрения на интернет сервисах IPv6.
В принципе, провайдеры тоже могут маршрутизировать 64:ff9b::/96 на вышестоящего оператора, который будет на своей сети иметь NAT64.
А ещё с IPv8 можно легко построить чебурнет. Просто оставляешь нужные ASN. Профит.
То, что в IPv6 сквозная прозрачность вовсе не означает что узел А может общаться с узлом Б! И современные маршрутизаторы по умолчанию настроены так, чтобы не пускать кого попало в периметр локальной сети. И им никакой NAT не нужен, чтобы это сделать для IPv6.
Читер. Я также могу сделать со своим DNS64+NAT64 и спокойно сидеть в своей IPv6only сети с доступом ко всем сервисам интернета без ограничений по версии протокола. Только это не отменяет того, что vk недоступен по IPv6.
По сути из 128 бит для выделения клиентам используется только 64. Но и даже эти 64 нарушают рекомендации и тогда для адреса клиента остаётся уже 56 бит. А если следовать полностью рекомендациям RIPE NCC, то для адресации клиента вообще остаётся всего 48 бит. Все остальные биты адреса уходят клиентам. Благодаря таком распределению адресов клиентам никогда не понадобится NAT, а в его сети будет нормально работать автоконфигурация. Но даже при таком раскладе каждому человеку на земле достанется как минимум по 200 сетей /48 только в одном диапазоне 2000::/3.
В IPv6 согласно bcom-690 провайдеры должны выдавать клиентам стабильный префикс /48, ну или /56, если они хотят разделить бизнес и домашних пользователей. Выдача динамического префикса по сути нарушение этих рекомендаций. Тот же Ростелеком их нарушает.
Мне от интересно как они умудрились в клиенте для Android сломать IPv6. Если ваш провайдер даёт вам DNS64+NAT64, то у вас ни один прокси не заведётся. Всему виной записи типа AAAA. Телеграм видит эту запись, пытается соединиться, но у него не получается. Это единственное приложение, которое не может работать с IPv6, которое я знаю. А я уже довольно продолжительное время использую режим IPv6only на своём телефоне и компьютере на Linux. Большей части приложений хватает DNS64+NAT64. Остальные несколько программ можно заставить работать с помощью CLAT, который на Android из коробки начиная с Android 4.3. Справедливости ради, нужно сказать, что прокси таки можно заставить работать. Но для этого нужно доменное имя заменить на IPv4 адрес, на который ссылается это доменное имя. И благодаря CLAT, прокси заработает.
Было бы неплохо эмулировать клиента. Так, например, можно подписаться на чат класса своего ребёнка и пробрасывать через телеграм бота сообщения в группу телеграм для всех родителей.
По какой-то причине Telegram на Android видит AAAA записи и не может по этим адресам подключиться. После неудачных попыток он просто пишет, что сервер недоступен. Если просто вписать IPv4 адрес, то прокси начинает работать. также не работают прокси если указать IPv6 адрес. Проблема только в Android клиенте Telegram. Декстопные версии и Telegram X такой проблеме не подвержены.
Кстати, проблема может вылезать на Мегафон и МТС, т.к. у них есть IPv6 и у них есть NAT64+DNS64. Они формируют фейковые AAAA записи с указанием на свой шлюз NAT64.
nslookup, dig, host. Если есть AAAA запись содержащая IPv6 адрес, то могут быть проблемы.
Бороться с этим не надо, нужно чтобы Telegram починили. Но если есть AAAA записи, например, если у вас Мегафон (там работает DNS64, на МТС не проверял, у других сотовых нет такого), то можно просто вместо имени домена вписать IPv4 адрес. Мера временная. Адрес сервера может смениться. Но это уже вручную придётся отслеживать. По хорошему нужно патчить Android клиент Telegram. На десктопе всё работает.
Альтернативный вариант - поставить Telegram X от того же разработчика. Но мне он показался неудобным. Зато с прокси работал нормально.
Визуально заработало, но раньше оно тоже работало, но отваливалось. Ну и так и не исправили проблему с IPv6. Он вообще не работает, а если у домена есть AAAA запись, то прокси вообще никакой работать не будет.
Не видел, чтобы Хабр был недоступен. Но пос е 22 часов при входе на него очень часто отображались ошибки 502 и 504. А это значит сам Хабр был доступен, но лежал бэкенд за nginx.
Ради интереса открыл journalctl -f на своём компьютере и попробовал обратиться к веб-серверу nginx локальному. За одно туда много пишет отладочной информации php-fpm, всё-таки у меня сервер стоит для разработки. Время от нажатия кнопки обновить в браузере и вывод логов занимает доли секунды. Точнее, чтобы узнать сколько, нужно что-то аппаратное, потому что глазом видно, что это происходит почти мгновенно.
Вероятно на продакшене может быть задержка, Но она связана, скорее всего, с повышением эффективности логирования. Если нагрузка большая и логов много, логично накапливать их в оперативной памяти, а потом сбрасывать на диск всем куском, чем дёргать диск на каждый чих.
Рекомендую всё-таки ознакомиться с возможностями journalctl. Там есть и свой grep, и фильтр по датам, и поиск по метаданным, и аналог
tail -f.... Лично мне больше понравилось. Плюс не нужно быть root, чтобы логи смотреть. Достаточно дать пользователю необходимые права. А также вместо путей /var/log… можно пользоваться просто тегами или именами сервисов (опять таки, надо смотреть что удобнее в каждом конкретном случае). Мне тоже, по началу, казалось сложно, но сейчас наоборот - ведение логов в текстовых файлах кажется дичью.Скорее всего где-то вы ошиблись. Внимательно посмотрите на то, что там пишется. Может быть какой-то сервис сильно много чего-то пишет. В любом случае, если у вас journald, то там есть ограничение на максимальный объём файлов журнала. В случае переполнения, старые логи просто начнут удаляться и дополнительного места на диске уже не потребуется. Я бы просто запустил
journalctl -fи посмотрел чего у меня там летит такого, что постоянно забивает логи. Возможно у какого-то сервиса не выключена отладка или что-то сбоит.Могу сказать только в защиту nginx. Он по умолчанию пишет сообщения самостоятельно. Но это легко меняется в настройках и он отлично пишет в journald. Особенно удобно, когда логи nginx можно просматривать совместно с логами php-fpm через journalctl. Сразу видно какой запрос пришёл, какую отладочную информацию выдал php-fpm и какие проблемы возникли при обработке запроса PHP. В java, наверно, тоже можно сделать что-то подобное.
Это не вредительство, это обычное поведение файловой системы linux. Оно в корне отличается от того, что происходит в Windows. Пока что-то держит файл, файл после rm физически не удаляется и продолжает работать. При этом для тех, кто файл не держал, файл фактически считается удалённым. В Windows же при попытке удалить файл, пока его кто-то держит, вываливается ошибка.
Всех этих мучений, что описаны в статье, можно было бы избежать, если бы сервис не писал файлы логов самостоятельно, а доверил это какому-либо сервису по ведению логов. Там все особенности файловой системы linux уже учтены.
А я как-то привык писать логи в journald. Он, и логи в сжатом виде хранит (с поиском по ним), и о ротации заботится, и чтобы диск не забивался логами (ограничение на максимальный размер). А ещё du себя очень странно ведёт на дисках с btrfs. У самой утилиты обслуживания btrfs есть свой
btrfs filesystem du.У нас на работе не были PDF, которые были удобнее для печати. Нам слали docx, что по сути тот же самый PDF, но его можно передалать для чтения. Но в документах не это важное. Всё было оформлено по стандратам. Введение, зачем документ, сам документ канцелярским языком, заключение, список кокращений и прочая хрень. Т.е. там документа на 1 страницу обычного печатного текста, а, по факту, там листов 20-30. Видимо какого-то родственника наняли, чтобы эти документы делать. И документы были вроде того, как инженер должен заходить в хату. Не в смысле тюремного. Как в дом зайти к абоненту. Куча текста, информации полезной никакой.