Допустим, в дистрибутиве 1 был создан контейнер lxc с дистрибутивом 2. Например, хостовым дистрибутивом был Debian, а в контейнере - Gentoo (но это только пример).

Далее контейнер был экспортирован с помощью lxc export. При этом получен архив gentoo.tar.gz, который был перенесён на другой дистрибутив (например, Ubuntu 22.04 LTS), и там импортирован с помощью lxc import.

Вопрос: существует ли матрица, которая бы показывала совместимость при такой миграции между дистрибутивами? Иными словами, куда можно мигрировать созданный в Debian контейнер с Gentoo? Можно на Arch? На другой Debian, но более старых версий? На какие дистры можно перенести контейнер? Это можно знать заранее или предостоит установить экспериментально?

Хостовая машина - debian11, lxc контейнер - gentoo. Соответственно хостовая машина имеет графическое окружение, а контейнер - только доступ к консоли посредством: lxc exec gentoo bash[/incline].

В контейнере лежит репозиторий с кодом и собранные из него библиотеки, которые нужно компилировать в ОС контейнера, то есть в gentoo.

Смысл использования контейнеров LXC состоит в данном случае в том, чтобы (1) разрабатывать код в gentoo и (2) чтобы контейнеры можно было бы легко переносить между машинами (посредством lxc export/import), на которых установлены Debian и потомки.

Редактировать же этот код хотелось бы снаружи контейнера из IDE, которая установлена на хостовой машине.

Способ установки был таким:

# snap install lxd
# lxd init (здесь была выбрана файловая система zfs, остальное выставлено по умолчанию)
# lxc launch gentoo/openrc/amd64 gentoo

Проблема в том, что не получается редактировать файлы контейнера извне (из внешней хостовой системы), потому что:

• даже если создать пользователя с тем же uid, он не имеет прав доступа;
• этот пользователь в любом случае не может попасть в директорию с файлами контейнера:

  # во внешней машине (debian):
  # id test1
  uid=1001000(test1) gid=1001000(test1) groups=1001000(test1)
  
  # директория, в которую нужно попасть имеет эти права, если смотреть из внешней машины (debian). Но юзер с этими правами не может туда попасть
  
  # su -l test1
  $ cd: /var/snap/lxd/common/mntns/var/snap/lxd/common/lxd/storage-pools/default/containers/gentoo/rootfs/mytest: Permission denied
  

• туда может попасть только рут, у обычного пользователя внешней машины нет прав даже зайти в директорию.

  Таким образом, пока что код внутри контейнера можно редактировать в произвольном консольном редакторе, зайдя в контейнер. Либо от рута внешней машины. А от обычного пользователя внешней машины - нельзя.

Вопрос: поставленный вопрос возникает естественно и лежит на поверхности, ведь частно нужно разрабатывать код, который находится в другом системном окружении.

Это же очень распространенная потребность, неужели она не была предусмотрена? Я понимаю, что в первую очередь в контейнеры кладутся сетевые сервисы, к которым потом доступ осуществляется по сети.

Возьмём удовлетворяющий всем пример FreeBSD jails. Датасет ZFS с jail может быть смонтирован в произвольную директорию. Там может быть создан такой же юзер, что и на внешней хостовой машине. Всё, из внешней машины можно редактировать файлы пользователя jail. Оба эти пользователя в могут их редактировать. Cистема в jail может несколько отличаться версиями, настройками и прочим. Вот то же самое хотелось бы получить в LXC.

Операции типа git status/checkout/switch сильно тормозят в файловой системе ZFS на репозитории с большой кодовой базой (несколько гигабайт).

Операции поиска файлов по имени не тормозят.

Пул настроен как zfs 3-way mirror, используются SAS Seagate 7200 rpm. Добавление l2arc несущественно влияет на производительность вышеуказанных операций.

Для таких задач можно было бы использовать ReiserFS, однако, придется использовать ZFS. Но, думаю, идея понятна.

Вопрос: какие свойства ZFS можно установить для датасета с кодовой базой для ускорения операций git?

P.S.: использование nvme не предлагать.

Спустя каких-то 50 лет с момента появления протокола FTP из разных источников стали сыпаться упрёки относительно якобы множественных недостатков этого протокола. Упреки направлены сразу на разные аспекты, т.е. разные конфигурации серверов FTP (как будто всё это используется одновременно). Поэтому, чтобы не валить эти претензии в кучу, рассмотрим следующую распространенную конфигурацию и её недостатки:

• ОС на сервере: Gentoo Linux (или FreeBSD);
• сервер vsftpd или proftpd;
• пассивный режим работы. Входящее соединение для команд FTP идёт на порт 21, а затем на порты из заранее заданного диапазона;
• разрешен анонимный доступ. То есть используется команда ftp ftp.[domain].***, затем вводится имя anonymous, а пароль либо не запрашивается, либо запрашивается и остаётся пустым;
• входящие соединения на порты FTP не фильтруются, доступ на порт 21 и на порты из диапазона для пассивного режима разрешен отовсюду из интернета;
• используются популярные клиенты: ftp (linux, BSD), lftp, filezilla, winscp;
• исходя из вышеуказанного, TLS не используется.
• UPD: модель использования - клиент скачивает бинарные файлы большого размера (>100Gb). Клиент не может ничего загружать на сервер, у него нет прав на запись.

Вопросы:

1 - какие проблемы могут возникнуть с такой конфигурацией? Уточнение: проблемы именно для безопасности сервера.

2 - если проверить ftp популярных ресурсов из мира opensource, то видно, что многие из тех, что были доступны раньше, теперь недоступны. То есть даже нет A-записи в доменной зоне для ftp. Что же сподвигло их отказаться от ftp именно в последние несколько лет?

Ведь (1) протокол FTP имел те же достоинства и недостатки и 15-20 лет назад. Кто-то скажет, что в 71-м году были несколько иные требования. А в 2005-м году всё было хорошо? И это в тех обстоятельствах, когда (2) значимая альтернатива не предложена: протокол HTTPS изначально создавался не для этих целей, а SFTP затрудняет организацию публичного доступа.

3 - каким образом передавать большие файлы (>100Gb, для примера)? Просто предложите пары сервер/клиент с любым открытым протоколом. SFTP не предлагать по вышеуказанной причине.

4 - что, по вашему мнению, стоит за упрёками в адрес FTP? Почему значимость недостатков внезапно выросла в течение последних нескольких лет?

Кто знает программу, которая позволяет делать отметки в файлах PDF (статьи и книги в PDF)? Нужно сделать так, чтобы пометки сохранялись после закрытия документа. Отметки аналогичны пометкам на полях:

• написать комментарий другим цветом (2-4 слова).
• выделить текст маркером.
• обвести текст в кружочек другим цветом.

Пожелание такое, чтобы оно не тянуло за собой какое-нибудь гигантское DE, поскольку обычно используется Awesome или Xmonad. Другое пожелание, конечно же, максимальная легкость редактирования в процессе чтения, чтобы не нужно было закрывать/переоткрывать/экспортировать документ, а просто отмечать по ходу чтения.

Интересует возможность бэкапа системного раздела OpenBSD. Кто знает наиболее продвинутые способы забекапить OpenBSD?

Например, если бы мы были на FreeBSD, мы могли бы использовать zfs snapshot и zfs send/receive. Кроме того, есть средства, позволяющие делать инкрементальные снапшоты, передавать удаленно и сохранять (и удалять) их в соответствии с некоторой функцией прореживания.

Ограничений на тип операционной системы нет. Пусть, допустим, все системы, учавствующие в бэкапе, будут только OpenBSD.

Какой наиболее продвинутый способ удаленно автоматически бэкапить OpenBSD?

Есть директория1 с исходным кодом проекта на несколько гигабайт (например, llvm). Объектные файлы находятся в отдельной директории2.

Проблема: переключение с помощью git checkout в другой бранч и обратно в директории1 без каких-либо правок кода влечет пересборку весьма значительной части того, что уже было собрано в директории2.

Вопрос: правильно ли я понимаю, что единственным способом избежать пересборки является фиксация директории1 с исходным кодом (т.е. один раз создать нужный бранч и писать код там, но не прыгать между бранчами)?

Такой вариант тоже мог бы устроить, но если хочешь посмотреть, что происходит в основном бранче, то придется клонировать этот репо в отдельную директорию с этим бранчем. Таким образом, не получится организовать схему «один репозиторий - множество сборок». Придется для каждой сборки иметь и отдельный репозиторий с кодом.

Важно мнение разработчиков C++ (необязательно использующих Emacs) на тему:

какие возможности, хорошо реализованные в различных IDE для C++, отсутствуют (недостаточно полно реализованы) в Emacs.

Под «IDE» подразумеваются любые передовые среды разработки, в том числе не open source и работающие только на оффтопике, если они работают удаленно с таргетом линукс.

Под словом «отсутствуют» подразумевается, что для настройки или реализации этого функционала в Emacs будет недостаточно существующих пакетов и написания нескольких тривиальных функций втечение суток.

Критерии сравнения (уточните название IDE, чтобы я мог протестировать):

1 - отдельные возможности (features). Предполагаемый вариант ответа:

«Не использую Emacs, но вряд ли там можно сделать [feature_name] так, как можно сделать в [my_ide]».

2 - целый рабочий процесс (workflow). Предполагаемый вариант ответа:

«В Emacs будет непросто выполнить [цепочка действий, например, рефакторинг] таким образом, как можно выполнить в [my_ide]:»

• - действие1
• - действие2
• - действие3

Цель вопроса?

Выделить разность по функционалу не в пользу Emacs, если есть. Особенно в свете развития LSP (например, clangd), с помощью которого индексация кода и построение различных связей между его элементами могут быть вынесены на отдельную машину. Т.е. ряд возможностей выносится за пределы средства разработки будь то Emacs, IDE, Vim и т.д. А значит возможности Emacs и IDE в этом плане уравниваются.

Система:

1 - дистр: gentoo, ядро 5.11.11, sys-fs/btrfs-progs 5.11.1;

2 - хранилище: RAID1 из 2-х SAS-дисков 1Tb;

3 - файловая система: в btrfs содержится 8 subvol (@root, @var и другие).

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

При этом iostat --human показывает запись за время работы в течение 1 суток: около 15Gb, и виновник этого (согласно iotop --accumulate) почти исключительно btrfs-transacti.

Надо сказать, что к данному результату привело отключение autodefrag на всех subvol (до отключения было ещё больше). Сейчас опции дефолтные, но с noatime

Вопрос: правильно я понимаю, что избавиться от записи 15Гб в простое невозможно?

Предполагаемые ответы:

1 - Так и задумано. От этого невозможно избавиться, поскольку причина такой массированной записи в простое - это результат природы CoW.

2 - Можно перейти с btrfs на ext4 (или ещё на какую-то файловую систему), где такой объемной записи не будет.

3 - Можно попробовать опции монтирования nodatacow и др. с соответствующими последствиями.

4 - Брать от жизни всё, а именно создать множество снапшотов для существующих subvol и больше не запускать iostat --human.

Очевидный ответ:

5 - В настоящее время подобная запись на диск - это нормально. Любой нормальный SAS такое выдержит.

Огорчает, что теперь наличие rust в десктопе становится практически неизбежным.

Графический браузер требует gtk+. Поскольку x11-libs/gtk+ зависит от gnome-base/librsvg, а последняя зависит от rust, то это всё придется установить. Таким образом, если хотите использовать браузер (хотя бы даже и распаковкой архива с firefox), то, кажется, в любом случае придется иметь rust.

1 - Можно ли избежать установки rust в любой его форме (dev-lang/rust, dev-lang/rust-bin, virtual/rust).

2 - Если нет, то какой наиболее минималистичный вариант?

Используется cgit+uwsgi+nginx. Дистрибутив gentoo.

Для ограничения просмотра репозиториев cgit с использованием браузера используется ограничение по паролю пользователя в nginx. А именно, используется протокол “HTTP Basic Authentication” c помощью директив auth_basic в nginx.

Проблема состоит в том, что при таком базовом способе аутентикации пользователь, который уже залогинился, может сидеть на страничке cgit сколько угодно. Разлогинить его не получится ни путём перезагрузки сервиса nginx на сервере, ни даже путём перезагрузки самой машины сервера. Когда сервер загрузится снова, пользователь сможет смотреть страницы дальше.

Поэтому опасения вызывает то, что пользователь может банально не закрыть браузер и уйти, а закрытая страница будет прочитана посторонними. Так можно скачать доступные репозитории.

Вопросы:

1 - как можно ограничить время логина и выкидывать пользователя через некоторый интервал времени?

2 - есть ли несложный способ прикрутить U2F (Universal 2nd Factor) к такой конфигурации? Под словом «несложный» подразумевается возможность справиться с этим методами системного администрирования.