16

Обзор + вопрос

Мне нужен контроль метаданных файловой системы, подобный etckeeper, для не /etc, каталогов, контролируемых git. Домашние каталоги и каталоги веб-приложений, помимо прочего, классически чувствительны к метаданным (владение файлами, ACL, разрешения). Это может быть чрезвычайно полезно / важно для использования git для автоматического развертывания сервера (наряду с такими инструментами, как Fabric), между прочим. Я хотел бы повторно использовать etckeeper-подобную возможность на указанных каталогах, либо с самим etckeeper, либо с чем-то еще.

Может кто-нибудь предложить какие-либо советы / хитрости / рабочие решения, чтобы обеспечить одно или оба из следующих:

  1. применять механизм etckeeper (заботится только о специфических для git возможностях etckeeper) к каталогам, не относящимся к /etc, и контролируемым git. (Можно предположить, по крайней мере, Debian /Ubuntu Linux; хотелось бы поддержки MacOSX /homebrew, если это возможно.)
  2. расширить поддержку git с помощью метаданных (помимо чрезмерно упрощенных вещей, таких как git-cache-meta) для поддержки возможности, подобной etckeeper, или лучше?

Подробнее, фон

Растет интерес к расширению git с помощью возможностей контроля метаданных файловой системы. По моему опыту, "движок" метаданных etckeeper кажется достаточно мощным и надежным, и etckeeper, похоже, популярен и среди других. metastore меньше, по крайней мере, частично из-за нетекстовых проблем / недружественных слияний метастазов. Кроме того, etckeeper, похоже, начал с ядра на основе метастазов, но затем переключился на свое собственное (умозрительное?).

Очевидно, что это зависит от ОС / файловой системы. (например, не пытается автоматически развернуть в Windows.) Предложите необязательное расширение (если это "собственное расширение") git, включенное по требованию пользователя с понятными последствиями кросс-платформенного сбоя, так что нативное поведение не нарушает кроссплатформенность git по умолчанию. Кроме того, не нужно сохранять экстравагантные метаданные unix / darwin / etc (например, ACL); базовый пользователь / группа / другие привилегии и владелец пользователя / группы будет в порядке. (Это единственные вещи, которые в настоящее время ломают вещи в моей «безопасности / управлении уязвимостями / политиками».) Конкретные ОС, на которые я нацеливаюсь заранее: Debian, Ubuntu, MacOS 10.6+. Позже: Redhat's (CentOS, Fedora, RHEL), SUSE, возможно, другие Linux, и * BSD (FreeBSD, NetBSD, OpenBSD). Не вижу необходимости / приложения для Windows / VMS (даже если VMS может быть удобной для posix) или других не-unix-подобных ОС в любой обозримой точке.

См. Также: справочная информация о ранее существовавшем git, возможности отслеживания метаданных файлов / типов файлов в этом вопросе о стековом потоке, который я разместил.

Разработать требования для нового проекта?

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

2 ответа2

4

Согласно этому ответу сервера, вы просто делаете это:

Это прямо на странице руководства.

  • Создать каталог /foo
  • Инициализировать с помощью etckeeper: etckeeper -d /foo init
  • Коммит применяет коммиты в каталог: etckeeper -d /foo commit 'message'
4

Я копался в этой проблеме и решил создать для нее проект git-store-meta .

git-store-meta - это скрипт на Perl, который объединяет в себе приятные функции git-cache-meta, metastore, setgitperms и mtimestore. Это должно служить хорошим компромиссом в отношении гибкости, функциональности, производительности, а также межплатформенной переносимости и согласованности.

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .