Используя etckeeper - защита и другие вопросы

Для материала Windows мне нравятся форумы Sysinternals.

5
задан 13 April 2017 в 15:14
2 ответа

При рассмотрении полного журнала bzr, а не shortlog Вы будете видеть, что, фиксируя изменения в / и т.д. после того, как способное выполнение сопровождается списком пакетов, которые изменились. По крайней мере, это - поведение на моем ноутбуке Ubuntu и сервере. Для подавляющего большинства случаев я подозреваю, что это более полезно, чем "sudo склонный - получают обновление" сообщение о фиксации.

Причина Вам препятствуют получить доступ к журналу bzr как обычному пользователю, состоит в том, что bzr repo имеет полный доступ к теневому репозиторию. Вероятно, самый большой глюк к остановке этого - то, что при удалении файла из bzr repo это все еще будет доступно в более старых изменениях. Существует, вероятно, некоторый вуду, вроде которого можно использовать svndumpfilter | svnadmin --import но для bzr, но я не попробовал его.

Одна альтернатива, которую Вы могли бы попробовать, sudo su. Или возможно можно сделать нового пользователя и группу, поместить пользователя в ту группу, дать групповой доступ к .bzr, и su тому пользователю для операций интереса bzr.

5
ответ дан 3 December 2019 в 01:21

Любой путь от помещения команды, которую Вы делаете в сообщение изменения.

При понимании, как работы etckeeper означают, необходимо понять, как работают системы управления версиями. С системами VCS у Вас есть понятие Вашего репозитория, в основном база данных всех изменений, рабочий каталог, где Вы в настоящее время изменяете вещи.

Etckeeper может на самом деле использовать один из нескольких бэкендов DVCS, он может поддерживать bzr, мерзавца и hg. Безотносительно бэкенда Вы используете все это работы о том же. Я использую мерзавца в качестве бэкенда, так как я намного более знаком с мерзавцем.

С Etckeeper Ваш рабочий каталог почти всегда /etc, хотя можно использовать его для других каталогов. Когда все о текущем состоянии Вашего рабочего каталога фиксировалось, Ваш рабочий каталог считается чистым. Если бы Вы вносите изменение в некоторый файл и хотели бы, чтобы Ваше изменение посвятило себя репозиторию, Вы выполняете команду etckeeper commit "Your log message here". Можно проверить, чтобы видеть, находитесь ли Вы репозиторий в чистом состоянии путем выполнения команды как etckeeper unclean && echo $.

С фоном из пути я могу войти, как etckeeper сцепляется в помочь Вам отслеживать то, что склонный делает. Когда etckeeper установлен, файл конфигурации добавляется к способной конфигурации в /etc/apt/apt.conf.d/05etckeeper. Это настраивает некоторые рычаги, поэтому, когда склонный попросился установить пакет (пакеты), он выполнит команду, прежде чем установка будет начата, и он выполнит команду после того, как установка будет завершена. Видеть точно, что пред и команда установки сообщения действительно смотрят на сценарии в /etc/etckeeper/pre-install.d и /etc/etckeeper/post-install.d каталоги.

В основном предварительно устанавливать команда сделает фиксацию, если Ваш рабочий каталог не будет чистым. Если Вам не нравится это, Вы могли бы просто не забыть вручную выполнять фиксацию после изменения чего-либо. Если Вы сильно возражаете против автоматической фиксации, можно скорректировать Ваш /etc/etckeeper/etckeeper.conf файл и некомментарий AVOID_COMMIT_BEFORE_INSTALL=1 строка. Внесение этого изменения будет означать, что Вы будете вынуждены вручную фиксировать, прежде чем можно будет работать склонный. Если Вам действительно не нравится автоматическая фиксация, можно также хотеть отключить ежедневную автоматическую фиксацию, существующую в более новых версиях.

Я хочу смочь сделать запросы на bzr репозитории от обычного пользователя.

Это - чрезвычайно плохая идея, по-моему. Существует много файлов в / и т.д., который не должен быть читаемым конечному пользователю. Если Вы хотите сделать свою жизнь легче, Вы могли бы установить sudo для не запроса счета на пароль при использовании bzr или etckeeper.

Есть ли любые глюки в удалении файлов (таких как/etc/shadow/от управления etckeeper

Правильный способ сделать это должно использовать проигнорировать функцию бэкенда DVCS, который Вы выбрали. Если бы Вы, где использование мерзавца Вы добавили бы файл к Вашему /etc/.gitignore, Я полагаю, что существует a /etc/.bzrignore это должно сделать то же самое, но Вы, возможно, должны bzr эксперту подтвердить это для Вас. Лично, я думаю, что мне нравится отслеживать /etc/shadow файл, так как это позволяет мне знать, удалось ли кому-то зло изменить сервисную учетную запись, которая, как предполагается, имеет отключенный пароль, имеет пароль, который позволил бы этому использоваться для логинов.

3
ответ дан 3 December 2019 в 01:21

Теги

Похожие вопросы