Маразм крепчал, еноты пели…
Третьего дня столкнулся в сети с утверждением, что согласно нашему Законодательству РКН считает IP-адреса персональными данными. Аргументация железобетонная:
▫️ IP-адрес связан с конкретным устройством и, в совокупности с другими данными, позволяет однозначно определить человека.
▫️ Статические адреса однозначно идентифицируют пользователя, динамические — рассматриваются как ПДн при возможности идентификации провайдером.
А позвольте спросить, каким образом я могу связать статический IP с конкретным физическим лицом без идентификации провайдером? Или где-то уже публично опубликован подобный реестр?
Ок, хорошо, но исходя из этой логики ПДн следует признать государственный регистрационный знак автомобиля. Но увы, номер персональными данными не является, примерно по тем же самым основаниям:
▫️ Он присваивается автомобилю, а не человеку и относится к техническим данным транспортного средства.
▫️ Узнать владельца по номеру можно только законными способами (запрос в ГИБДД), так как эта информация защищена законом.
Ну так покажите мне, где я, как физическое лицо, могу получить в персональное использование IP-адрес, которое будет присвоено лично мне, а не является техническими данными моего сетевого оборудования?
И как я могу узнать владельца IP-адреса кроме как оформив законным образом и на законных основаниях запрос к оператору связи?
А ведь номерной знак «связан с конкретным устройством», является статическим и «однозначно идентифицирует пользователя».
Сдается мне, что инициаторы данной инициативы в принципе не представляют, что такое IP-адреса, как и для чего они используются.
При этом в Законодательстве нет пояснений, какие именно адреса являются ПДн, а какие не являются. Является ли персональными данными адрес 192.168.0.1? Или 10.8.0.100?
А согласно Закона оператором персональных данных является тот, кто собирает, хранит, копирует, распространяет и использует эти самые данные.
Вот тут и разверзается пропасть куда-то на самое дно, потому как теперь оператором ПДн является любой гражданин подключившийся к сети Интернет.
Ваше устройство ведет логи? Значит вы собираете и храните. Но даже отключив логи мы получим собирание, хранение и использование в DNS-кеше или таблицах маршрутизации. И если логи и кеш мы еще можем выключить, то без таблиц маршрутизации никуда.
Но это только цветочки, ягодки впереди. Отправив ответный пакет, вы распространяете эти самые персональные данные, в открытом виде и, возможно, трансгранично. За что вас полагается жестоко покарать.
Тем более, что вы передали их (в заголовках пакета) третьему лицу (шлюзу своего провайдера), которому владелец IP-адреса мог и не выдать разрешения на обработку его ПДн, равно как и вам на передачу его третьим лицам.
В общем всю глубину дна вы поняли. Потому как в нынешнем виде это не только про сайты, а вообще про любое сетевое устройство.
И не только. Вот опубликовал я у себя на сайте инструкцию, где в качестве примера указал адреса 192.168.0.100 и 192.168.1.101 – все, я попал, потому что я распространил публично чьи-то персональные данные.
А завтра, в период очередного весенне-осеннего обострения шизоид Вася сделает нотариально заверенный скриншот, что его компьютер имеет адрес 192.168.0.100 и потребует от всех удалить из публичного пространства этот адрес.
И будет в своем праве, а тот, кто шизоида проигнорирует рискует попасть на совсем не детские штрафы и гражданские иски.
В этой теме радует только одно – необязательность применения всех этих ***, ну вы поняли, норм. Ибо сами не поняли они, чего нахреновертили.
Но была бы статья, а люди найдутся. Поэтому ходим – да оглядываемся, полезная привычка, как ни крути.
Третьего дня столкнулся в сети с утверждением, что согласно нашему Законодательству РКН считает IP-адреса персональными данными. Аргументация железобетонная:
▫️ IP-адрес связан с конкретным устройством и, в совокупности с другими данными, позволяет однозначно определить человека.
▫️ Статические адреса однозначно идентифицируют пользователя, динамические — рассматриваются как ПДн при возможности идентификации провайдером.
А позвольте спросить, каким образом я могу связать статический IP с конкретным физическим лицом без идентификации провайдером? Или где-то уже публично опубликован подобный реестр?
Ок, хорошо, но исходя из этой логики ПДн следует признать государственный регистрационный знак автомобиля. Но увы, номер персональными данными не является, примерно по тем же самым основаниям:
▫️ Он присваивается автомобилю, а не человеку и относится к техническим данным транспортного средства.
▫️ Узнать владельца по номеру можно только законными способами (запрос в ГИБДД), так как эта информация защищена законом.
Ну так покажите мне, где я, как физическое лицо, могу получить в персональное использование IP-адрес, которое будет присвоено лично мне, а не является техническими данными моего сетевого оборудования?
И как я могу узнать владельца IP-адреса кроме как оформив законным образом и на законных основаниях запрос к оператору связи?
А ведь номерной знак «связан с конкретным устройством», является статическим и «однозначно идентифицирует пользователя».
Сдается мне, что инициаторы данной инициативы в принципе не представляют, что такое IP-адреса, как и для чего они используются.
При этом в Законодательстве нет пояснений, какие именно адреса являются ПДн, а какие не являются. Является ли персональными данными адрес 192.168.0.1? Или 10.8.0.100?
А согласно Закона оператором персональных данных является тот, кто собирает, хранит, копирует, распространяет и использует эти самые данные.
Вот тут и разверзается пропасть куда-то на самое дно, потому как теперь оператором ПДн является любой гражданин подключившийся к сети Интернет.
Ваше устройство ведет логи? Значит вы собираете и храните. Но даже отключив логи мы получим собирание, хранение и использование в DNS-кеше или таблицах маршрутизации. И если логи и кеш мы еще можем выключить, то без таблиц маршрутизации никуда.
Но это только цветочки, ягодки впереди. Отправив ответный пакет, вы распространяете эти самые персональные данные, в открытом виде и, возможно, трансгранично. За что вас полагается жестоко покарать.
Тем более, что вы передали их (в заголовках пакета) третьему лицу (шлюзу своего провайдера), которому владелец IP-адреса мог и не выдать разрешения на обработку его ПДн, равно как и вам на передачу его третьим лицам.
В общем всю глубину дна вы поняли. Потому как в нынешнем виде это не только про сайты, а вообще про любое сетевое устройство.
И не только. Вот опубликовал я у себя на сайте инструкцию, где в качестве примера указал адреса 192.168.0.100 и 192.168.1.101 – все, я попал, потому что я распространил публично чьи-то персональные данные.
А завтра, в период очередного весенне-осеннего обострения шизоид Вася сделает нотариально заверенный скриншот, что его компьютер имеет адрес 192.168.0.100 и потребует от всех удалить из публичного пространства этот адрес.
И будет в своем праве, а тот, кто шизоида проигнорирует рискует попасть на совсем не детские штрафы и гражданские иски.
В этой теме радует только одно – необязательность применения всех этих ***, ну вы поняли, норм. Ибо сами не поняли они, чего нахреновертили.
Но была бы статья, а люди найдутся. Поэтому ходим – да оглядываемся, полезная привычка, как ни крути.
👍57👀13❤5🥱3🤮2
Первые впечатления от Ubuntu 26.04 LTS
Выдалось немного свободного времени, и мы решили посмотреть на новую Ubuntu 26.04 LTS, которая готовится к выпуску в этом месяце. Смотреть можно смело, так как пакетная база дистрибутива на данный момент заморожена и идет только устранение ошибок, без добавления новой функциональности.
При этом сам релиз также можно считать завершающей стадией публичного тестирования, так как автоматическое обновление прошлых версий станет доступно только после выпуска 26.04.1.
Что принципиально нового в этом выпуске? Ядро 7.0, полный отказ от X11 в пользу Wayland и GNOME 50. Хотя ничего революционного в ядре 7.0 нет, просто Линус Торвальдс всегда переходит на новую ветку после 19 релиза старого ядра.
А вот новый GNOME в связке с Wayland – это действительно значимое событие, в честь которого системные требования по ОЗУ повысили до минимальных 6 ГБ, что автоматически отсекает системы начального уровня.
Так ли это на самом деле? Давайте посмотрим. На первый взгляд все не так уж и плохо, после загрузки система показывает умеренное потребление в 1,75 ГБ, не то, чтобы мало, но и не так уж и много, возможно разработчики просто решили перестраховаться.
Ну давайте попробуем чего-нибудь поделать, да и вообще осмотримся. Сама система в минимальной установке ведет себя неплохо, графический интерфейс приятный, в фирменном стиле, работает плавно, не лагает.
Предустановленных программ минимум, поэтому сильно не развернешься, поэтому будем использовать то, что есть, открыли браузер с одной страничкой – потребление выросло до 2,7 ГБ, ну тут никто не сомневался, браузер сегодня основной потребитель памяти.
Потом мы открыли магазин, пару окон файлового менеджера, сделали скриншот и просмотрели его, потом добавили к этому всему терминал – и вплотную приблизились к отметке 4 ГБ, а немного позже и перевалили за нее.
Ну что тут можно сказать, GNOME 50 на Wayland выглядит и работает замечательно, но за все нужно платить. На системах с 4 ГБ ОЗУ эта связка практически неработоспособна, так как памяти вам хватит только на базовые потребности системы (а мы ничего тяжелого, кроме браузера с двумя вкладками еще не запускали).
Поэтому менее чем 8 ГБ для комфортной работы мы даже не рассматриваем и считаем минимальные требования в 6 ГБ вполне обоснованными. Но будем честны, сегодня 8 ГБ – это компьютеры начального уровня, минимальный порог.
Что-то более-менее нормальное, но еще бюджетного сегмента – это от 16 ГБ, меньше просто нет смысла. Поэтому мотивация разработчиков понятна, зачем ужиматься и ограничивать себя в флагманской линейке системы, когда это никому не нужно?
Владельцев старых ПК мы в расчет не берем, так как старые ПК и новые ОС – это вещи радикально противоположные. Хотя и для них есть варианты с менее требовательными графическими оболочками, та же LXQt будет отлично себя чувствовать с 4 ГБ.
Но если вы хотите чтобы система выглядела максимально современно и радовала глаз визуальными эффектами – то готовьте ваши гигабайты, чудес не бывает.
Выдалось немного свободного времени, и мы решили посмотреть на новую Ubuntu 26.04 LTS, которая готовится к выпуску в этом месяце. Смотреть можно смело, так как пакетная база дистрибутива на данный момент заморожена и идет только устранение ошибок, без добавления новой функциональности.
При этом сам релиз также можно считать завершающей стадией публичного тестирования, так как автоматическое обновление прошлых версий станет доступно только после выпуска 26.04.1.
Что принципиально нового в этом выпуске? Ядро 7.0, полный отказ от X11 в пользу Wayland и GNOME 50. Хотя ничего революционного в ядре 7.0 нет, просто Линус Торвальдс всегда переходит на новую ветку после 19 релиза старого ядра.
А вот новый GNOME в связке с Wayland – это действительно значимое событие, в честь которого системные требования по ОЗУ повысили до минимальных 6 ГБ, что автоматически отсекает системы начального уровня.
Так ли это на самом деле? Давайте посмотрим. На первый взгляд все не так уж и плохо, после загрузки система показывает умеренное потребление в 1,75 ГБ, не то, чтобы мало, но и не так уж и много, возможно разработчики просто решили перестраховаться.
Ну давайте попробуем чего-нибудь поделать, да и вообще осмотримся. Сама система в минимальной установке ведет себя неплохо, графический интерфейс приятный, в фирменном стиле, работает плавно, не лагает.
Предустановленных программ минимум, поэтому сильно не развернешься, поэтому будем использовать то, что есть, открыли браузер с одной страничкой – потребление выросло до 2,7 ГБ, ну тут никто не сомневался, браузер сегодня основной потребитель памяти.
Потом мы открыли магазин, пару окон файлового менеджера, сделали скриншот и просмотрели его, потом добавили к этому всему терминал – и вплотную приблизились к отметке 4 ГБ, а немного позже и перевалили за нее.
Ну что тут можно сказать, GNOME 50 на Wayland выглядит и работает замечательно, но за все нужно платить. На системах с 4 ГБ ОЗУ эта связка практически неработоспособна, так как памяти вам хватит только на базовые потребности системы (а мы ничего тяжелого, кроме браузера с двумя вкладками еще не запускали).
Поэтому менее чем 8 ГБ для комфортной работы мы даже не рассматриваем и считаем минимальные требования в 6 ГБ вполне обоснованными. Но будем честны, сегодня 8 ГБ – это компьютеры начального уровня, минимальный порог.
Что-то более-менее нормальное, но еще бюджетного сегмента – это от 16 ГБ, меньше просто нет смысла. Поэтому мотивация разработчиков понятна, зачем ужиматься и ограничивать себя в флагманской линейке системы, когда это никому не нужно?
Владельцев старых ПК мы в расчет не берем, так как старые ПК и новые ОС – это вещи радикально противоположные. Хотя и для них есть варианты с менее требовательными графическими оболочками, та же LXQt будет отлично себя чувствовать с 4 ГБ.
Но если вы хотите чтобы система выглядела максимально современно и радовала глаз визуальными эффектами – то готовьте ваши гигабайты, чудес не бывает.
👍31🤷♂8🤡5❤3🤮3
Уже было, но вопросы как были, так и остаются, поэтому повторим.
Почему именно systemd?
Практически после каждой нашей заметки о возможностях systemd в комментариях появляются читатели, которые пишут, что мол, а не проще ли это сделать … и далее идет перечисление простых утилит или скриптов.
С одной стороны, они могут показаться в чем-то правы. Зачем нужны все эти юниты, когда можно просто дернуть утилиту, получить результат и обернуть все это в скрипт.
Но это очень узкий и односторонний взгляд. Современные системы очень сложны и требуют стандартизации и унификации средств администрирования.
Вы можете мастерски владеть скриптами и автоматизировать все с их помощью, но ваши коллеги не сильно обрадуются этому факту, если им придется принять у вас обслуживание этой системы. Да и самому элементарно можно забыть, где лежит и для чего нужен тот или иной скрипт, особенно если подробного документирования не производилось.
Поэтому первый плюс systemd – это унификация и стандартизация. Теперь у нас есть юниты: юниты служб, юниты таймеров, юниты путей, юниты монтирования и т.д. и т.п.
Все юниты стандартизованы и научившись работать с одним типом вы без труда освоите другой. Кроме этого, юниты просты, очень просты и не идут ни в какое сравнение со скриптами.
Списки юнитов и их состояние также можно получить централизованно, одной простой командой. А чтобы проверить все возможные задания того же cron вам придется пробежать несколько каталогов, а также проверить crontab.
Второй плюс – это углубленная интеграция в систему, systemd предоставляет множество удобных инструментов, начиная от управления автозагрузкой и заканчивая средствами логирования.
Чтобы посмотреть результат работы скрипта – вам придется самому позаботиться о ведении лога. В systemd все это можно посмотреть «не отходя от кассы», стандартными инструментами. При этом никаких особых усилий к этому прикладывать не придется.
Из этого вытекает еще одно большое преимущество юнитов – их гораздо проще отлаживать. Во-первых, у вас уже есть лог, который ведется автоматически. Во-вторых, юниты предсказуемы и работают одинаково, вне зависимости от того, запущены они вручную или другим юнитом.
В тоже время отлично работающий при интерактивном запуске скрипт может оказаться неработоспособным при вызове через cron или из другого скрипта просто потому, что оказался запущен в другом контексте, с другими переменными окружения.
До сих пор нами были перечислены простые задачи, на которых преимущества systemd, конечно, видны, но еще не раскрыли всех своих возможностей.
Начнем с зависимостей. Как мы уже говорили – современные системы сложны. Многие их компоненты и службы зависят от других служб или предоставляемых ими ресурсов. Например, нам нужно выполнить какое-то задание, но только после того, как поднимется сеть и будут доступны некоторые сетевые ресурсы.
Для традиционного решения этой задачи придется немало поломать голову, выполнить кучу проверок или, как делается чаще всего, пойти по пути костылей и синей изоленты. Скажем, просто поставить задержку, в надежде что за это время сервис, от которого зависит работа успеет подняться. Ну а нет, так нет…
Systemd предоставляет простой и удобный способ работы с зависимостями. При этом вы можете указывать как отдельные службы, так и цели (таргеты), которые составляют группы служб, объединенные по некоторому признаку. Нужна сеть? Просто указываем в зависимостях network.target.
Еще одна важная задача – обработка отказа. Если служба упала – вы можете ее автоматически перезапустить. Но это можно сделать и без systemd, а вот systemd позволяет сделать это грамотно, указав частоту и количество попыток.
Если проблема приняла системный характер или находится на другой стороне, то systemd попробует несколько раз перезапустить службу и прекратит это делать, не получив результата. И это гораздо лучше, чем тупо долбить скриптом, вызывая повышенную нагрузку на систему и сеть.
Размер заметки не дает углубиться в подробности, но даже перечисленное дает исчерпывающий ответ на вопрос: почему именно systemd?
Почему именно systemd?
Практически после каждой нашей заметки о возможностях systemd в комментариях появляются читатели, которые пишут, что мол, а не проще ли это сделать … и далее идет перечисление простых утилит или скриптов.
С одной стороны, они могут показаться в чем-то правы. Зачем нужны все эти юниты, когда можно просто дернуть утилиту, получить результат и обернуть все это в скрипт.
Но это очень узкий и односторонний взгляд. Современные системы очень сложны и требуют стандартизации и унификации средств администрирования.
Вы можете мастерски владеть скриптами и автоматизировать все с их помощью, но ваши коллеги не сильно обрадуются этому факту, если им придется принять у вас обслуживание этой системы. Да и самому элементарно можно забыть, где лежит и для чего нужен тот или иной скрипт, особенно если подробного документирования не производилось.
Поэтому первый плюс systemd – это унификация и стандартизация. Теперь у нас есть юниты: юниты служб, юниты таймеров, юниты путей, юниты монтирования и т.д. и т.п.
Все юниты стандартизованы и научившись работать с одним типом вы без труда освоите другой. Кроме этого, юниты просты, очень просты и не идут ни в какое сравнение со скриптами.
Списки юнитов и их состояние также можно получить централизованно, одной простой командой. А чтобы проверить все возможные задания того же cron вам придется пробежать несколько каталогов, а также проверить crontab.
Второй плюс – это углубленная интеграция в систему, systemd предоставляет множество удобных инструментов, начиная от управления автозагрузкой и заканчивая средствами логирования.
Чтобы посмотреть результат работы скрипта – вам придется самому позаботиться о ведении лога. В systemd все это можно посмотреть «не отходя от кассы», стандартными инструментами. При этом никаких особых усилий к этому прикладывать не придется.
Из этого вытекает еще одно большое преимущество юнитов – их гораздо проще отлаживать. Во-первых, у вас уже есть лог, который ведется автоматически. Во-вторых, юниты предсказуемы и работают одинаково, вне зависимости от того, запущены они вручную или другим юнитом.
В тоже время отлично работающий при интерактивном запуске скрипт может оказаться неработоспособным при вызове через cron или из другого скрипта просто потому, что оказался запущен в другом контексте, с другими переменными окружения.
До сих пор нами были перечислены простые задачи, на которых преимущества systemd, конечно, видны, но еще не раскрыли всех своих возможностей.
Начнем с зависимостей. Как мы уже говорили – современные системы сложны. Многие их компоненты и службы зависят от других служб или предоставляемых ими ресурсов. Например, нам нужно выполнить какое-то задание, но только после того, как поднимется сеть и будут доступны некоторые сетевые ресурсы.
Для традиционного решения этой задачи придется немало поломать голову, выполнить кучу проверок или, как делается чаще всего, пойти по пути костылей и синей изоленты. Скажем, просто поставить задержку, в надежде что за это время сервис, от которого зависит работа успеет подняться. Ну а нет, так нет…
Systemd предоставляет простой и удобный способ работы с зависимостями. При этом вы можете указывать как отдельные службы, так и цели (таргеты), которые составляют группы служб, объединенные по некоторому признаку. Нужна сеть? Просто указываем в зависимостях network.target.
Еще одна важная задача – обработка отказа. Если служба упала – вы можете ее автоматически перезапустить. Но это можно сделать и без systemd, а вот systemd позволяет сделать это грамотно, указав частоту и количество попыток.
Если проблема приняла системный характер или находится на другой стороне, то systemd попробует несколько раз перезапустить службу и прекратит это делать, не получив результата. И это гораздо лучше, чем тупо долбить скриптом, вызывая повышенную нагрузку на систему и сеть.
Размер заметки не дает углубиться в подробности, но даже перечисленное дает исчерпывающий ответ на вопрос: почему именно systemd?
👍35❤4👎3⚡2🤮1
systemd.path – реагируем на события файловой системы
Как мы уже рассказывали systemd предоставляет администраторам простые, но в тоже время мощные инструменты на все случаи жизни.
Сегодня мы рассмотрим еще один тип юнита – path, который предназначен для контроля событий файловой системы. Сейчас он позволяет реагировать на создание, изменение или модификацию файлов или на появление файлов в директории.
Создадим для примера юнит
И внесем в него следующие строки:
В общем и целом, стандартный юнит, ничего необычного, кроме секции
Если секция Path не содержит директивы
Если требуется запуск другой службы, то ее требуется указать явно, т.е.:
Для начала работы юнит нужно запустить и добавить в автозагрузку:
Или одной командой:
В секции
Для отслеживания событий можно использовать следующие директивы:
▫️
▫️
▫️
▫️
▫️
Дополнительно с последней можно использовать:
▫️
Еще две опции позволяют задать временные лимиты срабатывания.
▫️
Отдельно следует отметить, что systemd.path работает только с локальными файловыми системами и не будет работать с SMB или NFS.
Как мы уже рассказывали systemd предоставляет администраторам простые, но в тоже время мощные инструменты на все случаи жизни.
Сегодня мы рассмотрим еще один тип юнита – path, который предназначен для контроля событий файловой системы. Сейчас он позволяет реагировать на создание, изменение или модификацию файлов или на появление файлов в директории.
Создадим для примера юнит
/etc/systemd/system/my_name.pathИ внесем в него следующие строки:
[Unit]
Description= Path test
[Path]
PathExists=/a/b/c/filename
[Install]
WantedBy=multi-user.target
В общем и целом, стандартный юнит, ничего необычного, кроме секции
Path, в директиве PathExists – путь, который мы отслеживаем.Если секция Path не содержит директивы
Unit, то будет найден и запушен одноименный сервис, т.е. my_name.service.Если требуется запуск другой службы, то ее требуется указать явно, т.е.:
[Path]
PathExists=/a/b/c/filename
Unit=123.service
Для начала работы юнит нужно запустить и добавить в автозагрузку:
systemctl start my_name.path
systemctl enable my_name.path
Или одной командой:
systemctl enable --now my_name.path
В секции
[Path] можно одновременно отслеживать несколько путей, запуск юнита произойдет при выполнении любого условия. Однако если хоть одно условие содержит пустую строку, то все директивы будут проигнорированы и юнит работать не будет.Для отслеживания событий можно использовать следующие директивы:
▫️
PathExists= проверяет существование файла▫️
PathExistsGlob= тоже самое, но позволяет использовать шаблоны подстановки▫️
PathChanged= проверяет изменение файла, срабатывает по окончанию редактирования▫️
PathModified= проверяет модификацию файла, срабатывает сразу, не дожидаясь окончания редактирования.▫️
DirectoryNotEmpty= проверяет появление файлов в директорииДополнительно с последней можно использовать:
▫️
MakeDirectory= при указании true каталог для отслеживания будет автоматически создан▫️ DirectoryMode= права на созданный каталог, по умолчанию 0755Еще две опции позволяют задать временные лимиты срабатывания.
▫️ TriggerLimitIntervalSec= юнит будет срабатывать не чаще указанного промежутка времени, по умолчанию 2 секунды.▫️
TriggerLimitBurst= количество активаций за указанное время, по умолчанию 200. Таким образом если произойдет более 200 срабатываний за 2 секунды, то юнит перейдет в режим сбоя не будет работать до перезапуска. Отдельно следует отметить, что systemd.path работает только с локальными файловыми системами и не будет работать с SMB или NFS.
👍23❤4👌2🔥1
Куда шагает отечественное информационное IT-сообщество сегодня
Над этим вопросом я задумался после вопроса по поводу будущего нашего сайта от одного из подписчиков. Вопрос не праздный, потому как формат статьи на сайте и формат заметки в Телеграм с лимитом в 4000 символов – вещи принципиально разные.
Да, есть определенные технические сложности, но этот фактор в том или ином виде был всегда, это я могу сказать совершенно точно, как человек, который крутится в этой сфере без малого 20 лет.
Сейчас, например, это ИИ, которые перехватывают значительную долю трафика, особенно к статьям из которой можно сделать краткую выжимку на один-два абзаца. Но они не первые и не последние, кто за все это время отравлял жизнь создателей контента.
При том, что ведение информационного ресурса на регулярной основе – это не хобби, а еще одна работа на половину или четверть ставки. И поэтому или ресурс находит свою экономическую модель, либо тихо загибается.
Иного не дано, энтузиазмом сыт не будешь и семью не обеспечишь. Есть расхожее выражение: любовная лодка разбилась о быт. Тут ровно тоже самое.
Но, до последнего времени, были вполне неплохие альтернативы, позволяющие и волков накормить, и овец сберечь. Речь в первую очередь идет о Телеграм и каналах в нем, которые сегодня стали реальной альтернативой СМИ.
А где есть аудитория, там будут рекламодатели, там будет выручка, которая позволяла тянуть даже убыточный сайт и дополнять короткие посты в Телеге емкими материалами, и перекачивать пользователей с сайта в Телегу, с Телеги на сайт.
Модель получилась достаточно стабильная и позволяла многим авторам спокойно заниматься производством контента как деятельностью, приносящей реальный доход.
Но в последнее время все изменилось. И это лежит уже не в технической области, а в законодательной. Мне до сих пор кажется, то регуляторы сами не понимают, что именно они регулируют, но легче не становится.
С каждым днем все больше и больше информации проходит у нас по рангу нежелательной, которую нельзя публиковать, на которую нельзя ссылаться, или надо обязательно ставить сноски, что данная информация распространена нежелательным элементом и все такое прочее.
Но, позвольте, закон обратной силы не имеет! Еще как имеет. Если ваша веб-страница с материалами, нарушающими действующее законодательство доступна здесь и сейчас, хотя и написана была далеко до, то у вас длящееся правонарушение, которое возникло в момент признания этих материалов противоправными.
А много кто помнит, что именно от писал 10 лет назад и нет ли там состава противоправного деяния?
Ну да ладно, мы отвлеклись. Текущая модель предусматривала Телеграм как основной финансовый поток, за счет которого тянулись остальные части проекта. Но с 2027 года реклама в ТГ объявлена вне закона.
Это чувствуется уже сейчас, рекламные доходы существенно просели. Но это не о деньгах, а о мотивации к созданию контента.
Сегодня даже в порядке хобби это крайне сомнительная инициатива. С учетом того, что некоторое известное ведомство из трех букв приравняло IP-адрес к персональным данным.
Т.е. создал сайт – получил проблемы на ровном месте, а если еще что-то там опубликовал, то постоянно смотри, не нарушаешь ли ты чего там, ибо правило обратной силы тут не действует.
И что скажет молодой потенциальный автор? Да нафига оно ему надо, если эта деятельность вместо пары десятков тысяч рублей в семейный бюджет подведет его к куда более крупным штрафам.
Да и о чем писать? Если половину тем под запретом, а остальная половина не будет работать без запретного слова КВН.
Фактически отрасль или выдавливается из страны, или вгоняется в стагнацию, копайтесь в местном болоте и не отсвечивайте.
Но это мы уже проходили и программируемые калькуляторы, при всей моей ностальгии к ним, СССР не спасли.
Над этим вопросом я задумался после вопроса по поводу будущего нашего сайта от одного из подписчиков. Вопрос не праздный, потому как формат статьи на сайте и формат заметки в Телеграм с лимитом в 4000 символов – вещи принципиально разные.
Да, есть определенные технические сложности, но этот фактор в том или ином виде был всегда, это я могу сказать совершенно точно, как человек, который крутится в этой сфере без малого 20 лет.
Сейчас, например, это ИИ, которые перехватывают значительную долю трафика, особенно к статьям из которой можно сделать краткую выжимку на один-два абзаца. Но они не первые и не последние, кто за все это время отравлял жизнь создателей контента.
При том, что ведение информационного ресурса на регулярной основе – это не хобби, а еще одна работа на половину или четверть ставки. И поэтому или ресурс находит свою экономическую модель, либо тихо загибается.
Иного не дано, энтузиазмом сыт не будешь и семью не обеспечишь. Есть расхожее выражение: любовная лодка разбилась о быт. Тут ровно тоже самое.
Но, до последнего времени, были вполне неплохие альтернативы, позволяющие и волков накормить, и овец сберечь. Речь в первую очередь идет о Телеграм и каналах в нем, которые сегодня стали реальной альтернативой СМИ.
А где есть аудитория, там будут рекламодатели, там будет выручка, которая позволяла тянуть даже убыточный сайт и дополнять короткие посты в Телеге емкими материалами, и перекачивать пользователей с сайта в Телегу, с Телеги на сайт.
Модель получилась достаточно стабильная и позволяла многим авторам спокойно заниматься производством контента как деятельностью, приносящей реальный доход.
Но в последнее время все изменилось. И это лежит уже не в технической области, а в законодательной. Мне до сих пор кажется, то регуляторы сами не понимают, что именно они регулируют, но легче не становится.
С каждым днем все больше и больше информации проходит у нас по рангу нежелательной, которую нельзя публиковать, на которую нельзя ссылаться, или надо обязательно ставить сноски, что данная информация распространена нежелательным элементом и все такое прочее.
Но, позвольте, закон обратной силы не имеет! Еще как имеет. Если ваша веб-страница с материалами, нарушающими действующее законодательство доступна здесь и сейчас, хотя и написана была далеко до, то у вас длящееся правонарушение, которое возникло в момент признания этих материалов противоправными.
А много кто помнит, что именно от писал 10 лет назад и нет ли там состава противоправного деяния?
Ну да ладно, мы отвлеклись. Текущая модель предусматривала Телеграм как основной финансовый поток, за счет которого тянулись остальные части проекта. Но с 2027 года реклама в ТГ объявлена вне закона.
Это чувствуется уже сейчас, рекламные доходы существенно просели. Но это не о деньгах, а о мотивации к созданию контента.
Сегодня даже в порядке хобби это крайне сомнительная инициатива. С учетом того, что некоторое известное ведомство из трех букв приравняло IP-адрес к персональным данным.
Т.е. создал сайт – получил проблемы на ровном месте, а если еще что-то там опубликовал, то постоянно смотри, не нарушаешь ли ты чего там, ибо правило обратной силы тут не действует.
И что скажет молодой потенциальный автор? Да нафига оно ему надо, если эта деятельность вместо пары десятков тысяч рублей в семейный бюджет подведет его к куда более крупным штрафам.
Да и о чем писать? Если половину тем под запретом, а остальная половина не будет работать без запретного слова КВН.
Фактически отрасль или выдавливается из страны, или вгоняется в стагнацию, копайтесь в местном болоте и не отсвечивайте.
Но это мы уже проходили и программируемые калькуляторы, при всей моей ностальгии к ним, СССР не спасли.
👍59❤6⚡4🤔4🤮2
Особенности директории /etc/pve
Не все знают, что
Поэтому если вы загрузитесь с диска восстановления или подключите диск к другому ПК с целью скопировать конфигурацию гипервизора, то вас ждет неприятный сюрприз – папка окажется пуста.
В этом случае вам понадобится файл базы данных SQLite в котором реально хранятся данные:
Поэтому, если вам нужно сохранить настройки гипервизора, в который вы не можете загрузиться нормальным образом – вам нужно скопировать именно этот файл и потом заменить им базу на новом экземпляре гипервизора.
Если вы хотите просмотреть содержимое базы данных, то выполните запрос:
В выводе вы получите следующую структуру: номер inode, имя объекта и его тип (4 – директория, 8 – файл).
Если хотите получить список объектов директории выполните запрос с указанием ее inode, в нашем случае 12:
Прочитать содержимое файла из базы вы можете запросом (в данном случае мы читаем файл с inode 6):
При необходимости можем сохранить вывод в файл:
Это дает нам возможность не заменять базу целиком, а скопировать из нее только нужные файлы, скажем – конфигурации виртуальных машин и контейнеров.
Не все знают, что
/etc/pve – это не просто директория на диске, а точка монтирования распределённой файловой системы pmxcfs (Proxmox Cluster File System). Данная система монтируется через FUSE при запуске службы pve-cluster и отражает текущую конфигурацию кластера в реальном времени.Поэтому если вы загрузитесь с диска восстановления или подключите диск к другому ПК с целью скопировать конфигурацию гипервизора, то вас ждет неприятный сюрприз – папка окажется пуста.
В этом случае вам понадобится файл базы данных SQLite в котором реально хранятся данные:
/var/lib/pve-cluster/config.dbПоэтому, если вам нужно сохранить настройки гипервизора, в который вы не можете загрузиться нормальным образом – вам нужно скопировать именно этот файл и потом заменить им базу на новом экземпляре гипервизора.
Если вы хотите просмотреть содержимое базы данных, то выполните запрос:
sqlite3 /var/lib/pve-cluster/config.db "SELECT inode, name, type FROM tree WHERE parent = 1;"
В выводе вы получите следующую структуру: номер inode, имя объекта и его тип (4 – директория, 8 – файл).
Если хотите получить список объектов директории выполните запрос с указанием ее inode, в нашем случае 12:
sqlite3 /var/lib/pve-cluster/config.db "SELECT inode, name, type FROM tree WHERE parent = 12;"
Прочитать содержимое файла из базы вы можете запросом (в данном случае мы читаем файл с inode 6):
sqlite3 /var/lib/pve-cluster/config.db "SELECT CAST(data AS TEXT) FROM tree WHERE inode = 6;"
При необходимости можем сохранить вывод в файл:
sqlite3 /var/lib/pve-cluster/config.db "SELECT CAST(data AS TEXT) FROM tree WHERE inode = 6;" > filename
Это дает нам возможность не заменять базу целиком, а скопировать из нее только нужные файлы, скажем – конфигурации виртуальных машин и контейнеров.
👍35🔥9❤3
Веселая иллюминация на Mikrotik
Сегодня коллега из одного филиала прислал эту фотографию с вопросом: а нормально ли это, что роутер сияет всеми цветами как новогодняя елка?
Начнем с пятого порта, это нормально, на этой модели данный порт имеет функцию PoE-out и в данной конфигурации включена подача питания на порт.
А вот почему светится желтым четвертый порт? Документация не содержит четкого описания цветов и режимов для каждой модели, но найденная в сети информация сбила коллегу с толку, намекая на то, что порт работает в нестандартном режиме (например, 10 Мбит/с).
Но изучение режимов работы порта не выявило никаких отклонений от своих соседей. Почему же тогда он желтый?
Для правильного ответа на этот вопрос я предложил ему временно выключить светодиод на пятом порте. После чего все сразу вернулось на круги своя.
Дело в том, что в данной модели Mikrotik индикаторы распаяны прямо на плате, а рассеиватель физически устроен так, что более яркий красный может спокойно «слепить» соседние зеленые.
В результате мы на месте индикатора четвертого порта и видим желтый цвет, также обратите внимание на средний (третий) индикатор – он немного более желтого оттенка, чем первые два.
Эту особенность хорошо знают те, кто много работает с Mikrotik и подвержены ей все модели в аналогичных корпусах. Если вас все же терзают сомнения, то попробуйте выключить соседние светодиоды в System – LEDs и проверить реальный цвет «подозрительного индикатора».
Сегодня коллега из одного филиала прислал эту фотографию с вопросом: а нормально ли это, что роутер сияет всеми цветами как новогодняя елка?
Начнем с пятого порта, это нормально, на этой модели данный порт имеет функцию PoE-out и в данной конфигурации включена подача питания на порт.
А вот почему светится желтым четвертый порт? Документация не содержит четкого описания цветов и режимов для каждой модели, но найденная в сети информация сбила коллегу с толку, намекая на то, что порт работает в нестандартном режиме (например, 10 Мбит/с).
Но изучение режимов работы порта не выявило никаких отклонений от своих соседей. Почему же тогда он желтый?
Для правильного ответа на этот вопрос я предложил ему временно выключить светодиод на пятом порте. После чего все сразу вернулось на круги своя.
Дело в том, что в данной модели Mikrotik индикаторы распаяны прямо на плате, а рассеиватель физически устроен так, что более яркий красный может спокойно «слепить» соседние зеленые.
В результате мы на месте индикатора четвертого порта и видим желтый цвет, также обратите внимание на средний (третий) индикатор – он немного более желтого оттенка, чем первые два.
Эту особенность хорошо знают те, кто много работает с Mikrotik и подвержены ей все модели в аналогичных корпусах. Если вас все же терзают сомнения, то попробуйте выключить соседние светодиоды в System – LEDs и проверить реальный цвет «подозрительного индикатора».
👍42😁27❤5
Как получить список подключенных USB-устройств в Windows
Возникла необходимость просмотреть список подключенных устройств на удаленном ПК с Windows. Задача не самая простая, ну не бегать же глазами по диспетчеру устройств. В Linux для этого есть команда
Для этой цели будем использовать командлет
Кроме идентификатора мы можем использовать в отборе класс, но в этом случае в вывод не попадут такие устройства как камеры или смарт-карты (токены), но может попасть совсем не USB-устройство, например, контроллер USB на PCIe шине:
При желании можем оба отбора скомбинировать и получить только устройства класса USB подключенные именно как USB:
Как видим, PowerShell дает не меньше возможностей и позволяет легко выполнять отборы по требуемым параметрам.
Возникла необходимость просмотреть список подключенных устройств на удаленном ПК с Windows. Задача не самая простая, ну не бегать же глазами по диспетчеру устройств. В Linux для этого есть команда
lsusb, посмотрим, что может нам предложить PowerShell.Для этой цели будем использовать командлет
Get-PnpDevice, для начала отберем устройства по идентификатору в котором присутствует USB, опция Status OK покажет только активные устройства:Get-PnpDevice -InstanceId 'USB*' -Status OK
Кроме идентификатора мы можем использовать в отборе класс, но в этом случае в вывод не попадут такие устройства как камеры или смарт-карты (токены), но может попасть совсем не USB-устройство, например, контроллер USB на PCIe шине:
Get-PnpDevice -Class 'USB' -Status OK
При желании можем оба отбора скомбинировать и получить только устройства класса USB подключенные именно как USB:
Get-PnpDevice -InstanceId 'USB*' -Class USB -Status OK
Как видим, PowerShell дает не меньше возможностей и позволяет легко выполнять отборы по требуемым параметрам.
👍32🤝5❤3⚡2
Установка и настройка сервера лицензирования 1С:Предприятие
Управление лицензиями 1С:Предприятия - задача не простая, особенно если у вас в эксплуатации несколько серверов или используется виртуализация.
Основные проблемы - это оптимизация распределения лицензий и привязка лицензий к параметрам оборудования, что создает трудности в виртуальной среде.
Облегчить работу и централизовать управление лицензиями вам поможет выделенный сервер лицензирования, как его установить и настроить мы расскажем в этой статье.
https://interface31.ru/tech_it/2024/11/ustanovka-i-nastroyka-servera-licenzirovaniya-1spredpriyatie.html
Управление лицензиями 1С:Предприятия - задача не простая, особенно если у вас в эксплуатации несколько серверов или используется виртуализация.
Основные проблемы - это оптимизация распределения лицензий и привязка лицензий к параметрам оборудования, что создает трудности в виртуальной среде.
Облегчить работу и централизовать управление лицензиями вам поможет выделенный сервер лицензирования, как его установить и настроить мы расскажем в этой статье.
https://interface31.ru/tech_it/2024/11/ustanovka-i-nastroyka-servera-licenzirovaniya-1spredpriyatie.html
👍23❤2
Lazydocker – легкая консольная утилита для управления Docker
Управлять инфраструктурой Docker в голом терминале не очень удобно и каждый раз, когда речь заходит об этом, на ум приходят Portainer и его аналоги.
Но если у вас пяток-десяток контейнеров на недорогом VPS, то тянуть туда еще один тяжелый контейнер для управления – это перебор.
В этом случае может пригодиться Lazydocker – интерактивная консольная утилита, закрывающая все основные потребности по управлению и контролю Docker инфраструктуры.
Для ее установки можно воспользоваться инструкцией из официального репозитория, которая скачивает и запускает скрипт, но в этом случае утилита будет размещена в $HOME/.local/bin, что не очень удобно, поэтому сразу определим место установки.
Если мы хотим, чтобы утилита была доступна всем пользователям сервера по стандартному пути, то установим ее в
Теперь можно запускать сам скрипт:
А дальше просто:
Навигация осуществляется стрелками, цифрами и фигурными скобками (по горизонтали).
Основных разделов шесть: проекты и сервисы – это то, что вы запускаете при помощи Docker Compose, затем идут отдельные контейнеры, образы, тома и сети.
В каждом разделе вы можете посмотреть доступную информацию: настройки, логи, статистику или выполнить набор команд, который доступен в меню по кнопке x, кнопкой b можно вызвать массовые команды для групповых действий.
Все быстро, просто, удобно. Если вы обладаете базовыми знаниями Docker и понимаете, что и для чего, то освоение утилиты займет пару минут.
Утилита написана на Go, работает быстро, потребляет минимум ресурсов и, главное, поработали – закрыли.
Управлять инфраструктурой Docker в голом терминале не очень удобно и каждый раз, когда речь заходит об этом, на ум приходят Portainer и его аналоги.
Но если у вас пяток-десяток контейнеров на недорогом VPS, то тянуть туда еще один тяжелый контейнер для управления – это перебор.
В этом случае может пригодиться Lazydocker – интерактивная консольная утилита, закрывающая все основные потребности по управлению и контролю Docker инфраструктуры.
Для ее установки можно воспользоваться инструкцией из официального репозитория, которая скачивает и запускает скрипт, но в этом случае утилита будет размещена в $HOME/.local/bin, что не очень удобно, поэтому сразу определим место установки.
Если мы хотим, чтобы утилита была доступна всем пользователям сервера по стандартному пути, то установим ее в
/usr/local/bin, для чего перед запуском скрипта определим переменную окружения: export DIR=/usr/local/bin
Теперь можно запускать сам скрипт:
curl https://raw.githubusercontent.com/jesseduffield/lazydocker/master/scripts/install_update_linux.sh | bash
А дальше просто:
lazydocker
Навигация осуществляется стрелками, цифрами и фигурными скобками (по горизонтали).
Основных разделов шесть: проекты и сервисы – это то, что вы запускаете при помощи Docker Compose, затем идут отдельные контейнеры, образы, тома и сети.
В каждом разделе вы можете посмотреть доступную информацию: настройки, логи, статистику или выполнить набор команд, который доступен в меню по кнопке x, кнопкой b можно вызвать массовые команды для групповых действий.
Все быстро, просто, удобно. Если вы обладаете базовыми знаниями Docker и понимаете, что и для чего, то освоение утилиты займет пару минут.
Утилита написана на Go, работает быстро, потребляет минимум ресурсов и, главное, поработали – закрыли.
👍35🔥6❤2🤝1
Можно ли заплутать в трех соснах при помощи ИИ?
Сейчас вокруг ИИ складывается большой ажиотаж, многие считают, что наличие такого помощника обесценивает знания и опыт и позволяет даже начинающим сотрудникам выполнять работу старших товарищей, не напрягаясь и не вникая.
Ну да, вкалывают роботы – счастлив человек. Это мы слышали не раз и не два. Но любой, кто серьезно работал с ИИ понимает, что несмотря на весь достигнутый прогресс – это просто помощник: неутомимый, исполнительный, но туповатый, хотя и начитанный.
Это как? Да вот так, теория без практики мертва, практика без теории – сборник магических заклинаний, камланий и ритуалов. И только совмещение первого и второго дают устойчивый результат в виде экспертных знаний и навыков.
Сегодня мы провели небольшой эксперимент, задали трем сетям один провокационный вопрос, в «забеге» участвовали ChatGPT, Gemini и Qwen. А вопрос был простой:
Почему Joplin при размере контейнера в 554 МБ развернулся в 4,46 ГБ?
Сетки начинают активно думать и строить предположения, в целом ход их мысли правильный и грамотный, что может усыпить бдительность вопрошающего. Они совершенно правильно предлагают выполнить внутри контейнера определенные команды, чтобы понять, кто занял все это место.
Но вывод делают абсолютно неправильный, только увидев, что это папка
В общем сразу нагнали жути, а дальше пошли ценные указания как подключить к контейнеру том и на горячую перенести в него данные, чтобы они бесследно не пропали при перезапуске.
Хорошо, демонстративно делаю:
И снова показываю размер образа, и поясняю, что все мои данные на месте. После чего ИИ выдвигает новую гипотезу, что это могут быть временные файлы, логи, кеши и сессии. А дальше идут новые рекомендации как это все оптимизировать, вынести, разнести и т.д. и т.п.
При этом все три сетки продолжают нагнетать жути:
Ладно, предлагаю им ознакомиться с образцом Compose-файла от самих разработчиков, где никаких томов к контейнеру Joplin не монтируется, но в ответ снова идут размышления, что там просто пример, а на практике может быть всякое.
Скажем честно, если бы мы заранее не знали правильный ответ, но возможно бы и повелись, больно все хорошо обосновано было.
Но в итоге мы при помощи тех же самых команд, что советовала сетка показали ей что на самом деле занимает место.
И что? А ничего, ИИ моментально переобулся на ходу (это он умеет):
На самом деле все просто, Joplin Server написан на Node.js, который отлично жмется, а в развернутом виде и составляет те самые 4,5 ГБ.
Сейчас вокруг ИИ складывается большой ажиотаж, многие считают, что наличие такого помощника обесценивает знания и опыт и позволяет даже начинающим сотрудникам выполнять работу старших товарищей, не напрягаясь и не вникая.
Ну да, вкалывают роботы – счастлив человек. Это мы слышали не раз и не два. Но любой, кто серьезно работал с ИИ понимает, что несмотря на весь достигнутый прогресс – это просто помощник: неутомимый, исполнительный, но туповатый, хотя и начитанный.
Это как? Да вот так, теория без практики мертва, практика без теории – сборник магических заклинаний, камланий и ритуалов. И только совмещение первого и второго дают устойчивый результат в виде экспертных знаний и навыков.
Сегодня мы провели небольшой эксперимент, задали трем сетям один провокационный вопрос, в «забеге» участвовали ChatGPT, Gemini и Qwen. А вопрос был простой:
IMAGE ID DISK USAGE CONTENT SIZE EXTRA
joplin/server:latest 5d9e7f9d31b4 4.46GB 554MB U
Почему Joplin при размере контейнера в 554 МБ развернулся в 4,46 ГБ?
Сетки начинают активно думать и строить предположения, в целом ход их мысли правильный и грамотный, что может усыпить бдительность вопрошающего. Они совершенно правильно предлагают выполнить внутри контейнера определенные команды, чтобы понять, кто занял все это место.
Но вывод делают абсолютно неправильный, только увидев, что это папка
/home/joplin сразу возникает гипотеза: Вот и виновник: 3.4 ГБ в папке /home.
В образе Joplin Server по умолчанию рабочая директория и данные пользователя находятся именно в /home/joplin. Поскольку база данных у тебя вынесена в отдельный контейнер Postgres, эти 3.4 ГБ — это не заметки, а скорее всего хранилище ресурсов (Resources/Attachments): картинки, PDF-файлы и другие вложения, которые ты синхронизировал.
Почему это плохо в текущем виде?
Риск потери данных: Если ты сделаешь docker compose down и удалишь контейнер (а не просто остановишь), всё, что не в базе и не в Volume, исчезнет навсегда.
В общем сразу нагнали жути, а дальше пошли ценные указания как подключить к контейнеру том и на горячую перенести в него данные, чтобы они бесследно не пропали при перезапуске.
Хорошо, демонстративно делаю:
docker compose down
docker compose up -d
И снова показываю размер образа, и поясняю, что все мои данные на месте. После чего ИИ выдвигает новую гипотезу, что это могут быть временные файлы, логи, кеши и сессии. А дальше идут новые рекомендации как это все оптимизировать, вынести, разнести и т.д. и т.п.
При этом все три сетки продолжают нагнетать жути:
Для Joplin на Postgres это обычно не критично (всё в БД), но если ты используешь FileSystem как хранилище для ресурсов (Storage Driver), то обязательно выноси эту папку на хост.
Вердикт: Если docker system prune не скинет эти 4ГБ, значит, Joplin хранит вложения или логи внутри себя. Для «чистого» сервера это ненормально, и лучше поправить маппинг папок в конфиге сейчас, пока ты не залил туда всю свою базу заметок.
Ладно, предлагаю им ознакомиться с образцом Compose-файла от самих разработчиков, где никаких томов к контейнеру Joplin не монтируется, но в ответ снова идут размышления, что там просто пример, а на практике может быть всякое.
Скажем честно, если бы мы заранее не знали правильный ответ, но возможно бы и повелись, больно все хорошо обосновано было.
Но в итоге мы при помощи тех же самых команд, что советовала сетка показали ей что на самом деле занимает место.
И что? А ничего, ИИ моментально переобулся на ходу (это он умеет):
Вот мы и нашли "жирок". Эти 3.4 ГБ — это исходный код и зависимости самого приложения Joplin.
Что происходит?
В образе Joplin Server разработчики упаковали всё дерево в /home/joplin/packages.
Это нормально: Это не мусор, а рабочие модули (парсеры, рендерер, сам сервер), без которых приложение не заведется.
На самом деле все просто, Joplin Server написан на Node.js, который отлично жмется, а в развернутом виде и составляет те самые 4,5 ГБ.
👍32😁5❤2
Режимы запуска bash
Скрипты и команды bash – это то, с чем ежедневно сталкивается системный администратора, поэтому важно знать режимы запуска командной оболочки и контекст выполнения команд bash в каждом конкретном случае.
1️⃣ Начнем с режима входа в систему, в этом случае bash является оболочкой входа и при завершении процесса сеанс прекратится. Такой режим используется при интерактивном входе в систему или при подключении через SSH.
При запуске в качестве оболочки входа bash создает новую базовую среду и считывает файлы инициализации
Кроме того,
Таким образом в режиме входа в систему bash создает базовую среду на основе как системных настроек, так и персональных для выполнившего вход пользователя.
2️⃣ Следующий режим – интерактивный, он запускается, когда стандартные потоки ввода-вывода подключены к эмулятору терминала. Например, если вы запустили терминал в графической среде. Или явно запустили bash внутри оболочки входа (а это может быть не обязательно bash).
В этом случае новая базовая среда не создается, а наследуется контекст окружения текущей оболочки, в дополнение к этому считываются персональные настройки из
Если сравнивать интерактивный режим и режим оболочки входа, то основной разницей является то, что интерактивный режим наследует текущее окружение и только лишь дополняет его персональными настройками.
3️⃣ Третий режим – неинтерактивный. Он используется при запуске
Этот режим существенно отличается как от режима оболочки входа, так и интерактивного. Основное его отличие в том, что при запуске создается новая минимальная базовая среда, но при этом не считываются никакие файлы инициализации, кроме файла указанного в переменной
Таким образом большинство привычных настроек, включая пути исполнения, в неинтерактивном режиме окажутся недоступны. И если скрипт у вас прекрасно работал интерактивно, то в неинтерактивном режиме вас может поджидать неприятная неожиданность.
Как избежать данной проблемы? Не запускать скрипты интерактивно. Т.е. вместо
В чем разница? В первом случае скрипт будет исполнен интерактивно, в режиме оболочки входа или интерактивной оболочки. Во втором bash будет запущен неинтерактивно, с минимальным контекстом выполнения, также как и при вызове скрипта системой.
Скрипты и команды bash – это то, с чем ежедневно сталкивается системный администратора, поэтому важно знать режимы запуска командной оболочки и контекст выполнения команд bash в каждом конкретном случае.
1️⃣ Начнем с режима входа в систему, в этом случае bash является оболочкой входа и при завершении процесса сеанс прекратится. Такой режим используется при интерактивном входе в систему или при подключении через SSH.
При запуске в качестве оболочки входа bash создает новую базовую среду и считывает файлы инициализации
/etc/profile и один из файлов: ~/.bash_profile, ~/.bash_login или ~/.profile который будет найден первым при поиске в указанном порядке.Кроме того,
/etc/profile считывает файлы /etc/profile.d/*.sh и /etc/bash.bashrc, а ~/.bash_profile содержит указание на исполнение файла ~/.bashrc.Таким образом в режиме входа в систему bash создает базовую среду на основе как системных настроек, так и персональных для выполнившего вход пользователя.
2️⃣ Следующий режим – интерактивный, он запускается, когда стандартные потоки ввода-вывода подключены к эмулятору терминала. Например, если вы запустили терминал в графической среде. Или явно запустили bash внутри оболочки входа (а это может быть не обязательно bash).
В этом случае новая базовая среда не создается, а наследуется контекст окружения текущей оболочки, в дополнение к этому считываются персональные настройки из
~/.bash_profile и общие из /etc/bash.bashrc. Если сравнивать интерактивный режим и режим оболочки входа, то основной разницей является то, что интерактивный режим наследует текущее окружение и только лишь дополняет его персональными настройками.
3️⃣ Третий режим – неинтерактивный. Он используется при запуске
bash -с или bash имя_скрипта, а также при вызове команд и скриптов системными процессами, тем же cron.Этот режим существенно отличается как от режима оболочки входа, так и интерактивного. Основное его отличие в том, что при запуске создается новая минимальная базовая среда, но при этом не считываются никакие файлы инициализации, кроме файла указанного в переменной
BASH_ENV среды окружения (если задан).Таким образом большинство привычных настроек, включая пути исполнения, в неинтерактивном режиме окажутся недоступны. И если скрипт у вас прекрасно работал интерактивно, то в неинтерактивном режиме вас может поджидать неприятная неожиданность.
Как избежать данной проблемы? Не запускать скрипты интерактивно. Т.е. вместо
./my_script.sh используйте bash my_script.sh.В чем разница? В первом случае скрипт будет исполнен интерактивно, в режиме оболочки входа или интерактивной оболочки. Во втором bash будет запущен неинтерактивно, с минимальным контекстом выполнения, также как и при вызове скрипта системой.
👍21❤2👌1