pax_global_header00006660000000000000000000000064145314263420014516gustar00rootroot0000000000000052 comment=0629c4f76e3724e9a8daee68a0812fb88b4be44e etckeeper-1.18.21/000077500000000000000000000000001453142634200136375ustar00rootroot00000000000000etckeeper-1.18.21/.gitattributes000066400000000000000000000000451453142634200165310ustar00rootroot00000000000000CHANGELOG merge=dpkg-mergechangelogs etckeeper-1.18.21/CHANGELOG000066400000000000000000001152041453142634200150540ustar00rootroot00000000000000etckeeper (1.18.21) upstream; urgency=medium * Consistently use mktemp if available, falling back to tempfile otherwise. Thanks, Adam Dinwoodie -- Joey Hess Tue, 28 Nov 2023 14:09:16 -0400 etckeeper (1.18.20) upstream; urgency=medium * Fix a reversion in etckeeper init in version 1.18.19. Thanks, Georgy Yakovlev -- Joey Hess Wed, 04 Jan 2023 13:23:19 -0400 etckeeper (1.18.19) upstream; urgency=medium * Added support for Gentoo (emerge, qlist, and cave) Thanks, Sam James * Skip running pre-commit hook inside linked worktrees, to avoid it updating .etckeeper with the permissions of files not in /etc. Thanks, Håkon Løvdal * commit: Run bzr with --quiet, since it outputs non-errors to stderr. Closes: #1018874 -- Joey Hess Mon, 02 Jan 2023 14:18:29 -0400 etckeeper (1.18.18) upstream; urgency=medium * Replace deprecated egrep with grep -E. Thanks, Sam James * Added support for Void Linux's xbps package manager. Thanks, Zev Weiss. -- Joey Hess Thu, 08 Sep 2022 12:12:46 -0400 etckeeper (1.18.17) upstream; urgency=medium * Fix committing of files with spaces in name when perl is not available. Thanks, Henrik Riomar * Ignore udev's FHS violating large binary cache file /etc/udev/hwdb.bin * Avoid warning messages from grep about binary files when there are filenames in /etc that do not correspond to the current locale settings. Thanks, thm -- Joey Hess Fri, 07 Jan 2022 11:15:07 -0400 etckeeper (1.18.16) upstream; urgency=medium * Improve sorting stability. * Prefer mktemp over tempfile as the latter displays a deprecation warning since debianutils 4.10. Thanks, Luke Mlsna. -- Joey Hess Sat, 02 Jan 2021 11:31:23 -0400 etckeeper (1.18.15) upstream; urgency=medium * Use "command -v" rather than "which" to detect installed programs, as it is more portable. Thanks, Eli Schwartz. * Improve commit messages generated by package manager changes, listing packages that are responsible for the changed config files. Thanks to emkael for the patch. * If gc.auto is not configured, override the default to make it gc ten times more frequently, to avoid wasting space with loose objects. * update-ignore: Preserve permissions from any preexisting VCS ignore file. Thanks, Austin Chu. * Removed the debian directory from the upstream source package as it's not being maintained; see the debian package for an up-to-date one. * debian/changelog moved to CHANGELOG and debian/copyright to COPYRIGHT. -- Joey Hess Mon, 23 Nov 2020 12:19:15 -0400 etckeeper (1.18.14) unstable; urgency=medium * pacman 5.2 deprecated File hooks, use Path. Thanks, Christian Hesse * Fix vcs subcommand setup for zsh completion. Thanks, James Rowe. -- Joey Hess Wed, 22 Jan 2020 09:59:04 -0400 etckeeper (1.18.13) unstable; urgency=medium * Added zsh completion. Thanks, James Rowe * commit: Recent changes added code that does not work on all POSIX shells. Fixed by Thorsten Glaser. -- Joey Hess Fri, 20 Dec 2019 16:19:09 -0400 etckeeper (1.18.12) unstable; urgency=medium * Fix bug in hostname determination in the previous release. Thanks, Christian Hesse -- Joey Hess Fri, 29 Nov 2019 11:42:34 -0400 etckeeper (1.18.11) unstable; urgency=medium * Support platforms without a hostname command, fall back to reading /etc/hostname. Thanks, Chris Morgan * commit: Support -mmessage, without a space, since eg git commit can be used that way. Thanks, martin f. krafft * commit: When multiple parameters are given, use them all as the commit message, instead of the old behavior of only using the first parameter and throwing the rest away. Thanks, martin f. krafft -- Joey Hess Thu, 28 Nov 2019 18:14:46 -0400 etckeeper (1.18.10) unstable; urgency=medium * Avoid post-install failing when ps is from busybox or another version not supporting procps-specific options. * Use ps --no-headers rather than problimatic -h option. -- Joey Hess Sun, 23 Dec 2018 13:05:44 -0400 etckeeper (1.18.9) unstable; urgency=medium * When run during a package installation, include in the commit message the command line that caused etckeeper to run. Thanks, Laszlo Gombos -- Joey Hess Wed, 12 Dec 2018 01:01:05 -0400 etckeeper (1.18.8) unstable; urgency=medium * Work around git commit's lack of robustness, by providing reasonable default values for GIT_COMMITTER_EMAIL etc. This was already done as part of the su/sudo handling, and is now always done. * Don't hardcode the master branch when pushing to PUSH_REMOTE. Instead, let git push whatever branches it is configured to push to that remote. -- Joey Hess Tue, 05 Jun 2018 16:00:41 -0400 etckeeper (1.18.7) unstable; urgency=medium * Added some unit tests. Thanks, Henrik Riomar. * etckeeper will work on systems that do not have perl installed. (perl is still used when available as it's faster) Thanks, William Johansson and radhus. * Prevent LC_ALL overriding the LC_COLLATE used to sort metadata. -- Joey Hess Thu, 08 Jun 2017 12:58:20 -0400 etckeeper (1.18.6) unstable; urgency=medium * Only show errors (no progress indicators) when pushing Git/Mercurial repos to avoid unncessary cron mails. Thanks, Nils Steinger. * Fix regex in 20-warn-problem-files. * Added support for apk (alpine linux) Thanks, Henrik Riomar. -- Joey Hess Sun, 29 Jan 2017 14:37:24 -0400 etckeeper (1.18.5) unstable; urgency=medium * Make etckeeper commit store metadata changes. The pre-commit hook has always (and continues) to do that, but pre-commit is only run when there are changes to tommit. This makes metadata-only changes get committed. * Move systemd files to /lib/systemd; /usr/lib/systemd is not used on Debian. -- Joey Hess Sun, 17 Jul 2016 18:53:54 -0400 etckeeper (1.18.4) unstable; urgency=medium * Optimised find for special and hard linked files. Thanks, Rike-Benjamin Schuppner. * Adjust when Pacman 5 calls etckeeper hooks. Thanks, Tilman Blumenbach and Christian Hesse. * Only run Pacman hooks when files in /etc have changed. Thanks, Christian Hesse. * Added systemd timer that can run etckeeper 10 minutes after boot, and also daily. It's not enabled by default, partly because of overlap with the cron job. Thanks, Christian Hesse. -- Joey Hess Mon, 20 Jun 2016 01:05:30 -0400 etckeeper (1.18.3) unstable; urgency=medium * Added support for pacmatic, contributed by nicolaichuk. * bzr: make sure EMAIL is defined Thanks, Serge E. Hallyn * Fix Makefile version patterns to ignore non-native version number (Antoine Beaupré) * Support ~/.config/git/config when determining the author name and email. Thanks, Richard Savio * Added support for Arch's pacman package manager version 5. Thanks, Tilman Blumenbach. * Set HOME if it's not set, as is the case when using ubuntu's update-manager. * Move bash completion out of etc and into usr. -- Joey Hess Mon, 15 Feb 2016 13:11:20 -0400 etckeeper (1.18.2) unstable; urgency=medium * Use getent utility instead of perl. (Elan Ruusamäe) * Initial FreeBSD support with pkgng plugin. (William Johansson) * Fix README.md symlink in package (Sebastian Schmidt, Antoine Beaupré, closes: #791566) * Fix typo of GIT_COMMITTER_EMAIL. -- Joey Hess Tue, 04 Aug 2015 10:13:08 -0400 etckeeper (1.18.1) unstable; urgency=medium * Add myself as maintainer (Closes: #768516) * Keeping the package native as I do not intend to diverge from upstream. * Update git URL in control file. -- Antoine Beaupré Sat, 21 Mar 2015 18:30:07 -0400 etckeeper (1.18) unstable; urgency=medium * Send yum pre-commit output to /dev/null Thanks, Andrew Colin Kissa * Set LANG=C internally when doing some operations that have been reported to fail in other locales. -- Joey Hess Sat, 14 Mar 2015 13:24:07 -0400 etckeeper (1.17) unstable; urgency=medium * Fix name of DNF plugin. * Add --version Thanks Andreas Wansner. * New website, http://etckeeper.branchable.com/ * Add build-depends on dh-python. -- Joey Hess Mon, 22 Dec 2014 16:42:26 -0400 etckeeper (1.16) unstable; urgency=medium * Added support for Fedora's DNF highlevel package manager. Thanks, Peter Listiak and Petr Spacek. * Add architecture info to dpkg list-installed. Closes: #768145 * Orphaned the Debian package. -- Joey Hess Fri, 07 Nov 2014 21:30:50 -0400 etckeeper (1.15) unstable; urgency=medium * Recommend cron-daemon, rather than cron, as etckeeper only needs cron.daily functionality. Closes: #762721 -- Joey Hess Thu, 16 Oct 2014 12:21:48 -0400 etckeeper (1.14) unstable; urgency=medium * Handle failure to commit in post-install, pre-install by showing a warning, rather than propigating the error to apt. This avoids breaking the apt run when eg, git is misconfigured and cannot commit. pre-install already did this when it was able to use debconf to display a message, but now debconf is not used, and it always behaves this way. Closes: #760011 -- Joey Hess Thu, 04 Sep 2014 15:47:32 -0400 etckeeper (1.13) unstable; urgency=medium * Ignore check-mk-agent-logwatch's FHS violating /etc/check_mk/logwatch.state. Closes: #753903 * Only allow [-a-z_] in etckeeper commands to avoid any possible directory traversal etc issues. * update-ignore, uninit: Fix parsing of ignore files containing '\' -- Joey Hess Sat, 09 Aug 2014 13:05:55 -0400 etckeeper (1.12) unstable; urgency=medium * Portability fixes. Thanks, Harald Dunkel. * Add support for pushing to multiple remote repositories. Thanks, Rouben. * Fix handling of git ignores like dir/* Thanks, Pim van den Berg -- Joey Hess Fri, 13 Jun 2014 12:03:06 -0400 etckeeper (1.11) unstable; urgency=low * Fix too broad matching of .gitignored files. Closes: #732339 -- Joey Hess Tue, 17 Dec 2013 22:24:29 -0400 etckeeper (1.10) unstable; urgency=low * Remove lvm/backup from default ignores, because lvm documentation recommends backing that up, for use by vgcfgrestore. * Fix exporting of some git variables. Closes: #728583 -- Joey Hess Sun, 03 Nov 2013 12:14:02 -0400 etckeeper (1.9) unstable; urgency=low * Fix git update-ignore syntax. Closes: #721873 -- Joey Hess Wed, 04 Sep 2013 21:43:42 -0400 etckeeper (1.8) unstable; urgency=low * Avoid listing .gitignored files in .etckeeper file. Closes: #607665 Thanks, Zdenek Crha -- Joey Hess Wed, 04 Sep 2013 09:31:37 -0400 etckeeper (1.7) unstable; urgency=low * Fix hilarious typo hardcoding my name. Closes: #718425 -- Joey Hess Wed, 31 Jul 2013 11:33:45 -0400 etckeeper (1.6) unstable; urgency=low * Guard git config calls. Closes: #717957 -- Joey Hess Sat, 27 Jul 2013 12:24:30 -0400 etckeeper (1.5) unstable; urgency=low * Quote user and group names, in case one contains a space. * Added support for the pacman package manager. (Thanks, Tiago Stürmer Daitx) * Use user.name and user.email from the .gitconfig file belonging to the user who sued or sudoed to root, in preference to making up values for that user. * cron.daily: Fix typo in stale lockfile handling code. Closes: #717908 -- Joey Hess Fri, 26 Jul 2013 11:03:48 -0400 etckeeper (1.4) unstable; urgency=low * Deal with unix^wlinux portability nonsense. -- Joey Hess Mon, 17 Jun 2013 12:00:59 -0400 etckeeper (1.3) unstable; urgency=low * Fix type -p bashism that crept in via recent patches. Closes: #707319 -- Joey Hess Wed, 08 May 2013 22:36:30 -0400 etckeeper (1.2) unstable; urgency=low * Call type -p in a more compatable way. * When a file is owned by a uid or a gid with no corresponding user or group, put a numeric chown into .etckeeper. Previously, a broken chown was outputted. -- Joey Hess Wed, 08 May 2013 11:51:51 -0400 etckeeper (1.1) unstable; urgency=low * Fix warning when PUSH_REMOTE is not set. Closes: #706917 -- Joey Hess Mon, 06 May 2013 09:49:24 -0400 etckeeper (1.0) unstable; urgency=low [ Joey Hess ] * Unset GIT_DIR and GIT_WORK_TREE. Closes: #689101 * PUSH_REMOTE can be set to automatically push to a remote on commit. Thanks, L. Alberto Giménez * Ignore fake-hwclock.data. Closes: #701491 [ Jelmer Vernooij ] * Auto-detect the VCS setting if there already is a repository in /etc. -- Joey Hess Sat, 04 May 2013 23:45:25 -0400 etckeeper (0.64) unstable; urgency=low * Added support for openSUSE's zypper package manager. Thanks, Catalin Iacob * Add Brazilian Portuguese debconf translation. Closes: #685771 Thanks, Adriano Rafael Gomes -- Joey Hess Sat, 25 Aug 2012 11:53:08 -0400 etckeeper (0.63) unstable; urgency=low * bzr: Improve detection of unclean repos, to work when there are shelved changes. * uninit: Now preserves parts of the gitignore and similar files that are outside the managed by etckeeper block. Closes: #673996 Thanks, David De La Harpe Golden (Squared Financial) -- Joey Hess Sat, 02 Jun 2012 18:22:37 -0400 etckeeper (0.62) unstable; urgency=low * Autocommit git staged files. Closes: #662614 -- Joey Hess Mon, 05 Mar 2012 10:41:46 -0400 etckeeper (0.61) unstable; urgency=low * Fix up botched git-rm conffile removal from 0.58. The file could be in any of three states; absent, present, or .dpkg-dist. Finish fully removing it. Closes: #655836 -- Joey Hess Sat, 14 Jan 2012 12:42:50 -0400 etckeeper (0.60) unstable; urgency=low * Updated Dutch translation of debconf templates. Closes: #654244 * Support -h and --help. Closes: #654188 * Fix typo in bugfix for #651168. * Improve yum hook to avoid running if etckeeper was just removed. Thanks, Mykola Marzhan -- Joey Hess Fri, 06 Jan 2012 19:23:42 -0400 etckeeper (0.59) unstable; urgency=low * Add /etc/cups/subscriptions.conf to default ignores, as the content of this file does not normally contain configuration and it changes frequently. Closes: #651168 * Shell quoting fix. Thanks, Daniel Hahler -- Joey Hess Thu, 22 Dec 2011 11:48:50 -0400 etckeeper (0.58) unstable; urgency=low * Changed to store all permissions of files and directories, even those with standard permissions of 644 and 755. This is unfortunately necessary in order to support etckeeper init on a checkout that was made with a nonstandard umask, in which case the files that were expected to be 644 and 755, won't be. Closes: #649701 Thanks to Дмитрий Матросов for reporting the bug and developing a fixup script (attached to the bug) which could be used if you've already encountered this problem. * Bugfix for filenames containing single quotes. * Use git add -A, which automatically removes deleted files, and avoids a separate call to git add -u. Thanks to Miklos Vajna, whose patch in 2008 was deferred because -A was then too new, and languished in a branch until found today. * Optimised metadata storage. * cron.daily: Don't stop committing when a stale packagelist.pre-install file exists. Thanks to gulikoza for noticing this bug. -- Joey Hess Fri, 25 Nov 2011 20:03:36 -0400 etckeeper (0.57) unstable; urgency=low * Use find -path instead of less portable find -wholename. -- Joey Hess Fri, 04 Nov 2011 17:03:46 -0400 etckeeper (0.56) unstable; urgency=low * Converted to use dh_python2. Closes: #616800 * Handle files with % in their names. -- Joey Hess Tue, 12 Jul 2011 14:38:09 -0400 etckeeper (0.55) unstable; urgency=low * Fix error propigation to yum, which makes AVOID_COMMIT_BEFORE_INSTALL work. Closes: https://bugzilla.redhat.com/show_bug.cgi?id=709487 Thanks, Thomas Moschny * Avoid being noisy in post-install after automatic yum updates. (Tuomo Soini) * Ignore FHS violating prelink.cache and openvpn-status.log. * Ignore *.LOCK files, as used by selinux policies. * Add AVOID_SPECIAL_FILE_WARNING to config file, and set it in cron job to avoid daily noise. (gulikoza) -- Joey Hess Sun, 19 Jun 2011 15:21:20 -0400 etckeeper (0.54) unstable; urgency=low * Ignore inssev's FHS violating /etc/init.d/.depend.* files. Closes: #619407 See #619409 * Use hg pre-commit hook, rather than its precommit hook, as the latter is run after the files staged for commit are determined and so .etckeeper cannot be staged as part of the current commit. Closes: #621827 -- Joey Hess Mon, 30 May 2011 18:11:40 -0400 etckeeper (0.53) unstable; urgency=low [ Joey Hess ] * Install bzr hook lazily, clean up some compatibility code. (Jelmer Vernooij) [ Josh Triplett ] * Only set environment variables for commit authorship (EMAIL, GIT_AUTHOR_NAME, GIT_AUTHOR_EMAIL, GIT_COMMITTER_EMAIL) if they don't already exist. [ Joey Hess ] * Add .pyc and .pyo files to ignore. * Add lvm/backup and lvm/cache to ignore. Closes: #462355 * Avoid warning about special or hard linked files that are ignored by hg. Thanks Sjoerd Mullender for patch. Closes: https://bugzilla.redhat.com/show_bug.cgi?id=688991 -- Joey Hess Fri, 18 Mar 2011 15:37:54 -0400 etckeeper (0.52) unstable; urgency=low * Rewrote 50git-rm to avoid using git ls-files, and thus avoid encoding problems with filenames. -- Joey Hess Sun, 06 Feb 2011 00:00:55 -0400 etckeeper (0.51) unstable; urgency=low * Updated Vietnamese translation of debconf templates. Closes: #601921 * Improve rpm version change detection. * Move etckeeper out of sbin, to avoid needing to work around broken root PATH settings in eg, crontab. Closes: #602438 * Added Polish translation of debconf templates. Closes: #607563 -- Joey Hess Sat, 25 Dec 2010 14:39:57 -0400 etckeeper (0.50) unstable; urgency=low * Add Danish translation of debconf templates. Closes: #597768 * Ignore /etc/.initctl. Closes: #598121 * Do not warn about special files or hardlinks if they are ignored by git. Fixes #549354 for git, but not for other VCSs. * Set GIT_COMMITTER_EMAIL to root@$hostname to avoid git prompting the user to configure it in .gitconfig. Closes: #599749 * Deal with strange systems that include the domain name in the hostname, by stripping it. Closes: #600026 -- Joey Hess Wed, 20 Oct 2010 14:06:21 -0400 etckeeper (0.49) unstable; urgency=low * Ensure that PATH contains the directory containing etckeeper, so that hook scripts that re-exec etckeeper are guaranteed to find it. * Ignore -m switch to etckeeper commit, in case someone tries to use it with that option common to several VCS. Closes: #592050 * Remove HOME setting in etckeeper. sudo now defaults to setting HOME itself as of version 1.7.4p4, so it is not necessary for etckeeper to work around its behavior anymore. (sudo also allows disabling that for those who enjoy using guns around feet.) Closes: #583899 * Fix file quoting problem in processing .etckeeper file in init. -- Joey Hess Mon, 13 Sep 2010 13:10:43 -0400 etckeeper (0.48) unstable; urgency=low * Fix backwards test for HGUSER. (Mike Rich) Closes: #589242 * 'etckeeper vcs' can be used to run arbitrary VCS subcommands in the etckeeper environment. (Thanks, Stefan Tomanek) -- Joey Hess Fri, 16 Jul 2010 15:14:05 -0400 etckeeper (0.47) unstable; urgency=low * Set HOME=~root so that VCS like bzr do not drop root-owned files in user home directory when sudo etckeeper is run. Closes: #583581 * hg: Set HGUSER (if not already set) to avoid warning message when committing. Closes: #533298 * Both git and bzr default to showing the author of a commit, and not the committer. So, set the author to the user running sudo for both. The committer will then be root. -- Joey Hess Sun, 30 May 2010 16:50:09 -0400 etckeeper (0.46) unstable; urgency=low * Support etckeeper commit --stdin * Fix bug where after a large upgrade, etckeeper's automatic commit message was so long it exceeded command line length limits. Closes: #581678 -- Joey Hess Sun, 16 May 2010 19:10:57 -0400 etckeeper (0.45) unstable; urgency=low * Revert darcs to using --logfile again, necessary for multiline commit messages. Closes: #577915 * Fix logic error in darcs user code. Closes: #577918 -- Joey Hess Thu, 15 Apr 2010 11:50:22 -0400 etckeeper (0.44) unstable; urgency=low * Add example to README of how to automatically push changes to a backup repository. * Add fuse lock file to ignore list. * Changed darcs to specify --author instead of noting the committing user inside the commit log. * Add -a to DARCS_COMMIT_OPTIONS so commits are noninteractive by default, but users who want darcs prompting can disable it. * Use darcs record -m to specify commit message, instead of using a logfile. * Closes: #519228 * Update depends for git-core to git transition. Closes: #577732 * Avoid using hostname -f, since on Solaris that sets the hostname to -f. Yay, Unix portability! (Instead, use dnsdomainname if available, and otherwise, fall back to the unqualified hostname.) * Other portability fixes for non-GNU tools and OS X. Thanks, Neil Mayhew. -- Joey Hess Wed, 14 Apr 2010 15:43:14 -0400 etckeeper (0.43) unstable; urgency=low * Fix cleanup of /var/cache/etckeeper/packagelist.pre-install after an upgrade where no conffiles are changed. * Prevent cron job autocommit from happening if pre-install file is present, to avoid committing state in the middle of an apt run. Closes: #567538 * Add /etc/webmin/webmin/oscache to ignore list. Closes: #567255 * Check owner of tty to determine who has su'd to root when committing, based on a patch by Jakov Sosic. * Add apparmor.d/cache/ to default ignores. * Record real committer username in the darcs log, so that the man page can say that for every VCS the username is recorded. -- Joey Hess Thu, 18 Feb 2010 14:01:45 -0500 etckeeper (0.42) unstable; urgency=low * Deal with removal of the cache directory. Closes: #559418 * Add ucf backups to ignore list. (See #462355) * Add webmin fsdump status files to ignore list. Closes: #567000 * Add *.old to ignore list (See #462355) * Add *.elc to ignore list (See #491401) * Add ntp.conf.dhcp and X11/xdm/authdir/authfiles/* to ignore list. Closes: #491401 * Fix handling of "#*#" ignores for git and hg. * Add runit and daemontools supervise files to ignore list. Closes: #529253 -- Joey Hess Tue, 26 Jan 2010 16:20:38 -0500 etckeeper (0.41) unstable; urgency=low * Change etckeeper uninit to not remove .gitignore (etc) file if it lacks the "managed by etckeeper" comment. Closes: #545137 * Fix hgrc setup code to not warn if the hgrc already contains a call to etckeeper. (Thanks, Jakov Sosic) * Updated Czech debconf translation from Miroslav Kure. Closes: #546411 -- Joey Hess Sat, 26 Sep 2009 15:58:15 -0400 etckeeper (0.40) unstable; urgency=low * Add Spanish debconf translation. Closes: #539589 * Updated Italian debconf translation. Closes: #540516 * Avoid infinite loop when displaying message about failure to commit changes in /etc. Closes: #540596 -- Joey Hess Sat, 08 Aug 2009 21:21:27 -0400 etckeeper (0.39) unstable; urgency=low * Document ETCKEEPER_CONF_DIR in man page. * Typo. Closes: #536799 * bzr: Set author to root when committing via sudo. Committer will be the sudo user, as it is in git. -- Joey Hess Fri, 31 Jul 2009 13:47:09 -0400 etckeeper (0.38) unstable; urgency=low * Use hostname if hostname -f fails. Closes: #533295 * Automatically commit on initial install, so users can begin relying on etckeeper right away. Closes: #533290 -- Joey Hess Wed, 08 Jul 2009 14:40:58 -0400 etckeeper (0.37) unstable; urgency=low * Make postinst check for the configured VCS before trying to run etckeeper init. Closes: #530497 * Update French debconf translation. Closes: #530795 * Fix typo in cruft file. Closes: #530819 * Update Portuguese debconf translation. Closes: #528109 * Update German debconf translation. Closes: #532346 -- Joey Hess Mon, 08 Jun 2009 13:24:13 -0400 etckeeper (0.36) unstable; urgency=low * Add cruft ignore file. Closes: #522513 * Update Japanese debconf translation. Closes: #527921 * Update Swedish debconf translation. Closes: #528575 * Update Russian debconf translation. Closes: #528798 -- Joey Hess Sat, 16 May 2009 18:22:49 -0400 etckeeper (0.35) unstable; urgency=low * Make etckeeper uninit -f disable the prompt. * Uninit on purge, guarded by a debconf prompt. Closes: #527218 -- Joey Hess Wed, 06 May 2009 14:52:30 -0400 etckeeper (0.34) unstable; urgency=low * Add support for mktemp if tempfile is not available. * Fix uninit prompt to accept 'y' as well as 'yes'. Closes: #517911 * README: Typo. Closes: #517914 -- Joey Hess Mon, 02 Mar 2009 17:01:09 -0500 etckeeper (0.33) unstable; urgency=low * Add support for yum. Thanks, Jimmy Tang. -- Joey Hess Wed, 25 Feb 2009 14:38:12 -0500 etckeeper (0.32) unstable; urgency=low * Add uninit subcommand, which cleans up all etckeeper and VCS droppings in /etc. This is useful if you want to switch to a different VCS and don't have any history to preserve. (Preserving history and converting is of course possible, but significantly harder.) * Run etckeeper init on initial install. Closes: #505772 (The idea being that if someone doesn't want to use git, they can immediatly uninit to easily reverse this.) * Document how to change the VCS used by etckeeper, without preserving any history. Preserving history left as an exersise for the reader. Closes: #515237 * Implement list-installed for rpm. * Added a spec file contributed by Jimmy Tang. -- Joey Hess Tue, 24 Feb 2009 23:01:55 -0500 etckeeper (0.31) unstable; urgency=low * Avoid relying on USER being set, won't be for cron job. Closes: #515602 * Add .sw? to ignores. vim uses that if editing an unspecified file name. Closes: #515628 -- Joey Hess Mon, 16 Feb 2009 15:40:42 -0500 etckeeper (0.30) unstable; urgency=low * Add vim .*.sw? files to default ignores. * Also add emacs #*# autosave files to default ignores. * And DEADJOE files, for good measure. * etckeeper update-ignore will automatically update the VCS ignore file, only touching the part inside a "# managed by etckeeper" comment block. (You may want to add such a comment block to your existing .gitignore, or delete the file and regenerate it.) * Run etckeeper update-ignore on upgrade. * Fix handling of -d in recursive calls to etckeeper -- Joey Hess Sat, 14 Feb 2009 01:21:22 -0500 etckeeper (0.29) unstable; urgency=low * Add a daily cron job to autocommit changes to /etc. Closes: #515100 The cron job is enabled by default but can be disabled via etckeeper.conf. (Thanks to Thierry Carrez) * Fix executable bits on two darcs support scripts. -- Joey Hess Fri, 13 Feb 2009 13:43:02 -0500 etckeeper (0.28) unstable; urgency=low * Support darcs. Thanks to Gian Piero Carrubba. Closes: #510032 -- Joey Hess Thu, 12 Feb 2009 17:13:23 -0500 etckeeper (0.27) unstable; urgency=low * Use SUDO_USER as the committer if set. Closes: #498739 (Thierry Carrez) * bzr: Avoid use of etckeeper pre-commit on Trees not on the filesystem. (Jelmer Vernooij) -- Joey Hess Sun, 01 Feb 2009 17:20:11 -0500 etckeeper (0.26) unstable; urgency=low * Add Japanese debconf translation. Closes: #512869 * Prevent git from removing a directory when the last file in it has been removed, but the directory is left existing and empty, by touching a flag file before calling git rm. Closes: 513006 -- Joey Hess Sun, 25 Jan 2009 13:55:56 -0500 etckeeper (0.25) unstable; urgency=low * Fix filter_unknown calls. Closes: 509888 -- Joey Hess Wed, 31 Dec 2008 13:01:31 -0500 etckeeper (0.24) unstable; urgency=low * Make .etckeeper test that files actually exist before acting on them. Closes: #509888 -- Joey Hess Mon, 29 Dec 2008 15:37:25 -0500 etckeeper (0.23) unstable; urgency=low * Fix hook scripts to use new etckeeper path. Closes: #509742 -- Joey Hess Thu, 25 Dec 2008 16:25:25 -0500 etckeeper (0.22) unstable; urgency=low * Move etckeeper to sbin, and man page to section 8, since only an admin can really use etckeeper. Closes: #509152 * Mention README file from man page. * Build using python-central. For some reason bzr does not pick up on plugins built using python-support. -- Joey Hess Tue, 23 Dec 2008 18:51:14 -0500 etckeeper (0.21) unstable; urgency=low * Swedish debconf translation from Martin Ågren. Closes: #492063 * Make etckeeper init -d set up commit hooks that call etckeeper -d. (Note that if you've relied on it setting up such commit hooks for a repo outside of /etc already, it created broken ones that need to be fixed to use -d.) Thanks, Wolfgang Karall. -- Joey Hess Thu, 11 Sep 2008 16:41:16 -0400 etckeeper (0.20) unstable; urgency=low [ Jelmer Vernooij ] * Use new Bazaar API. * Pass --quiet to bzr add to avoid new files from being printed twice. * Don't consider warnings from bzr plugins when checking if tree was modified. -- Joey Hess Mon, 07 Jul 2008 12:04:30 -0400 etckeeper (0.19) unstable; urgency=low * Patch from Miklos Vajna to fix one more git- command that crept in. -- Joey Hess Sat, 05 Jul 2008 08:34:22 -0400 etckeeper (0.18) unstable; urgency=low * Allow AVOID_COMMIT_BEFORE_INSTALL to be set to zero to disable. * Don't allow LC_COLLATE to reorder the .etckeeper file. Closes: #489057 -- Joey Hess Thu, 03 Jul 2008 00:47:40 -0400 etckeeper (0.17) unstable; urgency=low * Fix backwards test for AVOID_COMMIT_BEFORE_INSTALL. Closes: #486922 -- Joey Hess Wed, 18 Jun 2008 20:36:52 -0400 etckeeper (0.16) unstable; urgency=low [ Joey Hess] * Add a AVOID_COMMIT_BEFORE_INSTALL option in the config file to make it easy to configure etckeeper to abort an installation if there are uncommitted changes in /etc. Closes: #478754 -- Joey Hess Mon, 16 Jun 2008 19:21:16 -0400 etckeeper (0.15) unstable; urgency=low [ Daniel Hahler ] * bzr: Set nickname for tree in init.d/40vcs-init. * Add script to add new files during "commit" for bzr (commit.d/30bzr-add). Closes: #477321 * Fix handling of files with spaces, by setting IFS to "newline" in commit.d/40git-rm. [ Jelmer Vernooij ] * Support for the new bzr pre-commit hook. This requires bzr version 1.4. Closes: #473069 * Remove pointless commit.d/40bzr-rm script. [ Joey Hess ] * debhelper v7; rules file minimisation -- Joey Hess Sat, 03 May 2008 15:08:12 -0400 etckeeper (0.14.2) unstable; urgency=low * Handle nonzero exit status when building package list diff. -- Joey Hess Thu, 17 Apr 2008 13:00:29 -0400 etckeeper (0.14.1) unstable; urgency=low * Fix typo in bzr-precommit script. Closes: #473069 This is an interim fix -- full bzr precommit support has been implemented, but the bzr that supports it is not yet released. * Fix handling of files with spaces, by setting IFS to NL. -- Joey Hess Wed, 16 Apr 2008 19:16:52 -0400 etckeeper (0.14) unstable; urgency=low * When deleting the .metadata, only $VCS rm it if using git. hg write locks the repo when the pre-commit hook is running, so it would lock. -- Joey Hess Sat, 29 Mar 2008 13:43:20 -0400 etckeeper (0.13) unstable; urgency=low * Drop the debconf prompt before committing in pre-install. Closes: #470577, #462161, #471157, #462161 * Stop using metastore, instead add shell commands to .etckeeper to handle permissions. Patch by Scott Bronson. The main advantages of this approach are: - .etckeeper uses less disk space than .metadata. - Git diff includes changes to the commands in the file, which is more transparent than a change to the binary .metadata file, and does not produce conflicts during merging. - Revision control directories such as .hg are filtered out. Closes: #471371 Note that repositories still including .metadata files will be automatically transitioned, and the file removed. Also, etckeeper init on a historical version of a repository that still contains .metadata will use it, if metastore is installed. * Keep track of what packages change state during an installation, and include that in the commit message at the end. Closes: #459384 -- Joey Hess Tue, 25 Mar 2008 20:53:23 -0400 etckeeper (0.12) unstable; urgency=low * Use git ls-files instead of git status. Depend on new enough git for this. * Add support for bzr, thanks to Mark A. Hershberger. Closes: #470515 (Note that bzr does not support etckeeper's pre-commit hook.) -- Joey Hess Tue, 11 Mar 2008 15:06:29 -0400 etckeeper (0.11) unstable; urgency=low * Add lvm cache dir to default ignores. (#462355) * Updated German translation. Closes: #463153 * Some initial rpm support. Patch from Евгений Терешков. * Add apt hooks for rpm based systems. * Add nologin to default ignores. -- Joey Hess Mon, 11 Feb 2008 00:43:19 -0500 etckeeper (0.10) unstable; urgency=low * Convert the directory parameter of etckeeper into "-d directory". * Pass other patameters on from etckeeper to the .d scripts. * Stop using run-parts for various reasons. * Split out a commit.d that contains committing code that's used by both the pre-install.d and post-install.d scripts. * Split out an unclean.d that tests if the WC contains uncommitted changes. * Don't commit in post-install.d if there are no uncommitted changes. * German debconf translation. Closes: #460940, #458751 * Use git status instead of git-status (missed this one before). -- Joey Hess Tue, 15 Jan 2008 14:35:29 -0500 etckeeper (0.9) unstable; urgency=low * Separate debconf use from the main flow of the script so the commit stage can use editors etc. Closes: #459547 * Remove the hint about setting -e to get interactive commits, since I don't want to encourage users to do that. (For one thing, it's unlikely to work if a graphical package manager is used..) -- Joey Hess Mon, 07 Jan 2008 13:46:22 -0500 etckeeper (0.8) unstable; urgency=low * Typo fixes from Miklos Vajna * Add backwards compatability code to handle post-apt action. Closes: #459441 -- Joey Hess Sun, 06 Jan 2008 12:54:51 -0500 etckeeper (0.7) unstable; urgency=low [ Joey Hess ] * Added configuration options for highlevel and lowlevel package managers in etckeeper.conf. * Only install apt hooks if apt is used. * Only add backup conffile exclusion to gitignore if dpkg is used. * Rename pre/post-apt.d to pre/post-install.d to allow the same directories to be used for other package managers. * Use the name of the highlevel package manager in commit messages. * Add gnarly conffile renaming code. * Support mercurial as an alternative to git. Original patch by Mathieu Clabaut, significantly changed. [ Miklos Vajna ] * Add support for frugalware's pacman-g2 package manager. * Stop using git-foo commands. [ Christian Perrier ] * Debconf templates and debian/control reviewed by the debian-l10n-english team as part of the Smith review project. Closes: #454774 * [Debconf translation updates] * Galician. Closes: #455790 * Finnish. Closes: #455967 * Italian. Closes: #456509 * Portuguese. Closes: #456543 * French. Closes: #456920 * Vietnamese. Closes: #457307 * Czech. Closes: #457678 * Dutch. Closes: #457806 * Basque. Closes: #457830 * Russian. Closes: #457871 [ Joey Hess ] * Commit removed files in the pre-install hook to git, as was already done for hg. Avoided changing the debconf template so bubulle doesn't murder me; the current wording is just vague enough to still work with the current behavior. -- Joey Hess Fri, 04 Jan 2008 18:46:49 -0500 etckeeper (0.6) unstable; urgency=low * Depend on a fairly recent git-core. Closes: #453063 -- Joey Hess Sun, 02 Dec 2007 15:46:12 -0500 etckeeper (0.5) unstable; urgency=low * Typo. Closes: #452926 -- Joey Hess Mon, 26 Nov 2007 03:16:14 -0500 etckeeper (0.4) unstable; urgency=low * Portuguese translation from Américo Monteiro. Closes: #451798 * Pass --quiet to git-rm calls. -- Joey Hess Tue, 20 Nov 2007 01:04:32 -0500 etckeeper (0.3) unstable; urgency=low * Patch from Remi Vanicat adding an etckeeper.conf file and a GIT_COMMIT_OPTIONS configuration setting. Closes: #451167 * Add network/run and adjtime to default gitignore. Closes: #451347 * Patch from Rémi Vanicat adding bash completion. Closes: #451302 * Remove redundant dependency on debconf. Closes: #451378 -- Joey Hess Thu, 15 Nov 2007 12:21:02 -0500 etckeeper (0.2) unstable; urgency=low * Add .pwd.lock to default ignores, this file is created by programs that call getspent(). * Add tests for /etc/.git not yet existing and avoid doing bad things. Closes: #451185 * If /etc/.git doesn't exist, display a suggestion to run etckeeper-init. -- Joey Hess Tue, 13 Nov 2007 19:09:11 -0500 etckeeper (0.1) unstable; urgency=low * First release. -- Joey Hess Sun, 11 Nov 2007 01:11:21 -0500 etckeeper-1.18.21/COPYRIGHT000066400000000000000000000033711453142634200151360ustar00rootroot00000000000000Format: http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/ Files: * Copyright: © 2007-2014 Joey Hess and contributors License: GPL-2+ The full text of the GPL is distributed as doc/GPL in etckeeper's source, and is distributed in /usr/share/common-licenses/GPL-2 on Debian systems. Files: pkgng/* Copyright: 2015 William Johansson 2012 Marin Atanasov Nikolov License: BSD-2-clause * All rights reserved. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * 1. Redistributions of source code must retain the above copyright * notice, this list of conditions and the following disclaimer * in this position and unchanged. * 2. Redistributions in binary form must reproduce the above copyright * notice, this list of conditions and the following disclaimer in the * documentation and/or other materials provided with the distribution. * * THIS SOFTWARE IS PROVIDED BY THE AUTHOR(S) ``AS IS'' AND ANY EXPRESS OR * IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. * IN NO EVENT SHALL THE AUTHOR(S) BE LIABLE FOR ANY DIRECT, INDIRECT, * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. etckeeper-1.18.21/GPL000066400000000000000000000431031453142634200142050ustar00rootroot00000000000000 GNU GENERAL PUBLIC LICENSE Version 2, June 1991 Copyright (C) 1989, 1991 Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed. Preamble The licenses for most software are designed to take away your freedom to share and change it. By contrast, the GNU General Public License is intended to guarantee your freedom to share and change free software--to make sure the software is free for all its users. This General Public License applies to most of the Free Software Foundation's software and to any other program whose authors commit to using it. (Some other Free Software Foundation software is covered by the GNU Lesser General Public License instead.) You can apply it to your programs, too. When we speak of free software, we are referring to freedom, not price. Our General Public Licenses are designed to make sure that you have the freedom to distribute copies of free software (and charge for this service if you wish), that you receive source code or can get it if you want it, that you can change the software or use pieces of it in new free programs; and that you know you can do these things. To protect your rights, we need to make restrictions that forbid anyone to deny you these rights or to ask you to surrender the rights. These restrictions translate to certain responsibilities for you if you distribute copies of the software, or if you modify it. For example, if you distribute copies of such a program, whether gratis or for a fee, you must give the recipients all the rights that you have. You must make sure that they, too, receive or can get the source code. And you must show them these terms so they know their rights. We protect your rights with two steps: (1) copyright the software, and (2) offer you this license which gives you legal permission to copy, distribute and/or modify the software. Also, for each author's protection and ours, we want to make certain that everyone understands that there is no warranty for this free software. If the software is modified by someone else and passed on, we want its recipients to know that what they have is not the original, so that any problems introduced by others will not reflect on the original authors' reputations. Finally, any free program is threatened constantly by software patents. We wish to avoid the danger that redistributors of a free program will individually obtain patent licenses, in effect making the program proprietary. To prevent this, we have made it clear that any patent must be licensed for everyone's free use or not licensed at all. The precise terms and conditions for copying, distribution and modification follow. GNU GENERAL PUBLIC LICENSE TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION 0. This License applies to any program or other work which contains a notice placed by the copyright holder saying it may be distributed under the terms of this General Public License. The "Program", below, refers to any such program or work, and a "work based on the Program" means either the Program or any derivative work under copyright law: that is to say, a work containing the Program or a portion of it, either verbatim or with modifications and/or translated into another language. (Hereinafter, translation is included without limitation in the term "modification".) Each licensee is addressed as "you". Activities other than copying, distribution and modification are not covered by this License; they are outside its scope. The act of running the Program is not restricted, and the output from the Program is covered only if its contents constitute a work based on the Program (independent of having been made by running the Program). Whether that is true depends on what the Program does. 1. You may copy and distribute verbatim copies of the Program's source code as you receive it, in any medium, provided that you conspicuously and appropriately publish on each copy an appropriate copyright notice and disclaimer of warranty; keep intact all the notices that refer to this License and to the absence of any warranty; and give any other recipients of the Program a copy of this License along with the Program. You may charge a fee for the physical act of transferring a copy, and you may at your option offer warranty protection in exchange for a fee. 2. You may modify your copy or copies of the Program or any portion of it, thus forming a work based on the Program, and copy and distribute such modifications or work under the terms of Section 1 above, provided that you also meet all of these conditions: a) You must cause the modified files to carry prominent notices stating that you changed the files and the date of any change. b) You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License. c) If the modified program normally reads commands interactively when run, you must cause it, when started running for such interactive use in the most ordinary way, to print or display an announcement including an appropriate copyright notice and a notice that there is no warranty (or else, saying that you provide a warranty) and that users may redistribute the program under these conditions, and telling the user how to view a copy of this License. (Exception: if the Program itself is interactive but does not normally print such an announcement, your work based on the Program is not required to print an announcement.) These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it. Thus, it is not the intent of this section to claim rights or contest your rights to work written entirely by you; rather, the intent is to exercise the right to control the distribution of derivative or collective works based on the Program. In addition, mere aggregation of another work not based on the Program with the Program (or with a work based on the Program) on a volume of a storage or distribution medium does not bring the other work under the scope of this License. 3. You may copy and distribute the Program (or a work based on it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you also do one of the following: a) Accompany it with the complete corresponding machine-readable source code, which must be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or, b) Accompany it with a written offer, valid for at least three years, to give any third party, for a charge no more than your cost of physically performing source distribution, a complete machine-readable copy of the corresponding source code, to be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or, c) Accompany it with the information you received as to the offer to distribute corresponding source code. (This alternative is allowed only for noncommercial distribution and only if you received the program in object code or executable form with such an offer, in accord with Subsection b above.) The source code for a work means the preferred form of the work for making modifications to it. For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable. However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable. If distribution of executable or object code is made by offering access to copy from a designated place, then offering equivalent access to copy the source code from the same place counts as distribution of the source code, even though third parties are not compelled to copy the source along with the object code. 4. You may not copy, modify, sublicense, or distribute the Program except as expressly provided under this License. Any attempt otherwise to copy, modify, sublicense or distribute the Program is void, and will automatically terminate your rights under this License. However, parties who have received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance. 5. You are not required to accept this License, since you have not signed it. However, nothing else grants you permission to modify or distribute the Program or its derivative works. These actions are prohibited by law if you do not accept this License. Therefore, by modifying or distributing the Program (or any work based on the Program), you indicate your acceptance of this License to do so, and all its terms and conditions for copying, distributing or modifying the Program or works based on it. 6. Each time you redistribute the Program (or any work based on the Program), the recipient automatically receives a license from the original licensor to copy, distribute or modify the Program subject to these terms and conditions. You may not impose any further restrictions on the recipients' exercise of the rights granted herein. You are not responsible for enforcing compliance by third parties to this License. 7. If, as a consequence of a court judgment or allegation of patent infringement or for any other reason (not limited to patent issues), conditions are imposed on you (whether by court order, agreement or otherwise) that contradict the conditions of this License, they do not excuse you from the conditions of this License. If you cannot distribute so as to satisfy simultaneously your obligations under this License and any other pertinent obligations, then as a consequence you may not distribute the Program at all. For example, if a patent license would not permit royalty-free redistribution of the Program by all those who receive copies directly or indirectly through you, then the only way you could satisfy both it and this License would be to refrain entirely from distribution of the Program. If any portion of this section is held invalid or unenforceable under any particular circumstance, the balance of the section is intended to apply and the section as a whole is intended to apply in other circumstances. It is not the purpose of this section to induce you to infringe any patents or other property right claims or to contest validity of any such claims; this section has the sole purpose of protecting the integrity of the free software distribution system, which is implemented by public license practices. Many people have made generous contributions to the wide range of software distributed through that system in reliance on consistent application of that system; it is up to the author/donor to decide if he or she is willing to distribute software through any other system and a licensee cannot impose that choice. This section is intended to make thoroughly clear what is believed to be a consequence of the rest of this License. 8. If the distribution and/or use of the Program is restricted in certain countries either by patents or by copyrighted interfaces, the original copyright holder who places the Program under this License may add an explicit geographical distribution limitation excluding those countries, so that distribution is permitted only in or among countries not thus excluded. In such case, this License incorporates the limitation as if written in the body of this License. 9. The Free Software Foundation may publish revised and/or new versions of the General Public License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns. Each version is given a distinguishing version number. If the Program specifies a version number of this License which applies to it and "any later version", you have the option of following the terms and conditions either of that version or of any later version published by the Free Software Foundation. If the Program does not specify a version number of this License, you may choose any version ever published by the Free Software Foundation. 10. If you wish to incorporate parts of the Program into other free programs whose distribution conditions are different, write to the author to ask for permission. For software which is copyrighted by the Free Software Foundation, write to the Free Software Foundation; we sometimes make exceptions for this. Our decision will be guided by the two goals of preserving the free status of all derivatives of our free software and of promoting the sharing and reuse of software generally. NO WARRANTY 11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION. 12. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. END OF TERMS AND CONDITIONS How to Apply These Terms to Your New Programs If you develop a new program, and you want it to be of the greatest possible use to the public, the best way to achieve this is to make it free software which everyone can redistribute and change under these terms. To do so, attach the following notices to the program. It is safest to attach them to the start of each source file to most effectively convey the exclusion of warranty; and each file should have at least the "copyright" line and a pointer to where the full notice is found. Copyright (C) This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA. Also add information on how to contact you by electronic and paper mail. If the program is interactive, make it output a short notice like this when it starts in an interactive mode: Gnomovision version 69, Copyright (C) year name of author Gnomovision comes with ABSOLUTELY NO WARRANTY; for details type `show w'. This is free software, and you are welcome to redistribute it under certain conditions; type `show c' for details. The hypothetical commands `show w' and `show c' should show the appropriate parts of the General Public License. Of course, the commands you use may be called something other than `show w' and `show c'; they could even be mouse-clicks or menu items--whatever suits your program. You should also get your employer (if you work as a programmer) or your school, if any, to sign a "copyright disclaimer" for the program, if necessary. Here is a sample; alter the names: Yoyodyne, Inc., hereby disclaims all copyright interest in the program `Gnomovision' (which makes passes at compilers) written by James Hacker. , 1 April 1989 Ty Coon, President of Vice This General Public License does not permit incorporating your program into proprietary programs. If your program is a subroutine library, you may consider it more useful to permit linking proprietary applications with the library. If this is what you want to do, use the GNU Lesser General Public License instead of this License. etckeeper-1.18.21/INSTALL000077700000000000000000000000001453142634200177652doc/install.mdwnustar00rootroot00000000000000etckeeper-1.18.21/Makefile000066400000000000000000000074061453142634200153060ustar00rootroot00000000000000# You should configure etckeeper.conf for your distribution before # installing etckeeper. CONFFILE=etckeeper.conf include $(CONFFILE) DESTDIR?= prefix=/usr bindir=${prefix}/bin etcdir=/etc mandir=${prefix}/share/man vardir=/var systemddir=/lib/systemd/system bashcompletiondir=${prefix}/share/bash-completion/completions zshcompletiondir=${prefix}/share/zsh/vendor-completions CP=cp -R INSTALL=install INSTALL_EXE=${INSTALL} INSTALL_DATA=${INSTALL} -m 0644 PYTHON=python FAKEROOT := $(shell command -v fakeroot 2> /dev/null) TESTDIR := $(shell mktemp -u -d) build: etckeeper.spec etckeeper.version -$(PYTHON) ./etckeeper-bzr/__init__.py build || echo "** bzr support not built" -$(PYTHON) ./etckeeper-dnf/etckeeper.py build || echo "** DNF support not built" install: etckeeper.version mkdir -p $(DESTDIR)$(etcdir)/etckeeper/ $(DESTDIR)$(vardir)/cache/etckeeper/ $(CP) *.d $(DESTDIR)$(etcdir)/etckeeper/ $(INSTALL_EXE) daily $(DESTDIR)$(etcdir)/etckeeper/daily $(INSTALL_DATA) $(CONFFILE) $(DESTDIR)$(etcdir)/etckeeper/etckeeper.conf mkdir -p $(DESTDIR)$(bindir) $(INSTALL_EXE) etckeeper $(DESTDIR)$(bindir)/etckeeper mkdir -p $(DESTDIR)$(mandir)/man8 $(INSTALL_DATA) etckeeper.8 $(DESTDIR)$(mandir)/man8/etckeeper.8 mkdir -p $(DESTDIR)$(bashcompletiondir) $(INSTALL_DATA) bash_completion $(DESTDIR)$(bashcompletiondir)/etckeeper mkdir -p $(DESTDIR)$(zshcompletiondir) $(INSTALL_DATA) zsh_completion $(DESTDIR)$(zshcompletiondir)/_etckeeper mkdir -p $(DESTDIR)$(systemddir) $(INSTALL_DATA) systemd/etckeeper.service $(DESTDIR)$(systemddir)/etckeeper.service $(INSTALL_DATA) systemd/etckeeper.timer $(DESTDIR)$(systemddir)/etckeeper.timer ifeq ($(HIGHLEVEL_PACKAGE_MANAGER),apt) mkdir -p $(DESTDIR)$(etcdir)/apt/apt.conf.d $(INSTALL_DATA) apt.conf $(DESTDIR)$(etcdir)/apt/apt.conf.d/05etckeeper mkdir -p $(DESTDIR)$(etcdir)/cruft/filters-unex $(INSTALL_DATA) cruft_filter $(DESTDIR)$(etcdir)/cruft/filters-unex/etckeeper endif ifeq ($(LOWLEVEL_PACKAGE_MANAGER),pacman) mkdir -p $(DESTDIR)$(prefix)/share/libalpm/hooks $(INSTALL_DATA) ./pacman-pre-install.hook $(DESTDIR)$(prefix)/share/libalpm/hooks/05-etckeeper-pre-install.hook $(INSTALL_DATA) ./pacman-post-install.hook $(DESTDIR)$(prefix)/share/libalpm/hooks/zz-etckeeper-post-install.hook endif ifeq ($(LOWLEVEL_PACKAGE_MANAGER),pacman-g2) mkdir -p $(DESTDIR)$(etcdir)/pacman-g2/hooks $(INSTALL_DATA) pacman-g2.hook $(DESTDIR)$(etcdir)/pacman-g2/hooks/etckeeper endif ifeq ($(HIGHLEVEL_PACKAGE_MANAGER),yum) mkdir -p $(DESTDIR)$(prefix)/lib/yum-plugins $(INSTALL_DATA) yum-etckeeper.py $(DESTDIR)$(prefix)/lib/yum-plugins/etckeeper.py mkdir -p $(DESTDIR)$(etcdir)/yum/pluginconf.d $(INSTALL_DATA) yum-etckeeper.conf $(DESTDIR)$(etcdir)/yum/pluginconf.d/etckeeper.conf endif ifeq ($(HIGHLEVEL_PACKAGE_MANAGER),dnf) -$(PYTHON) ./etckeeper-dnf/etckeeper.py install --root=$(DESTDIR) ${PYTHON_INSTALL_OPTS} || echo "** DNF support not installed" endif ifeq ($(HIGHLEVEL_PACKAGE_MANAGER),zypper) mkdir -p $(DESTDIR)$(prefix)/lib/zypp/plugins/commit $(INSTALL) zypper-etckeeper.py $(DESTDIR)$(prefix)/lib/zypp/plugins/commit/zypper-etckeeper.py endif -$(PYTHON) ./etckeeper-bzr/__init__.py install --root=$(DESTDIR) ${PYTHON_INSTALL_OPTS} || echo "** bzr support not installed" echo "** installation successful" clean: etckeeper.spec etckeeper.version rm -rf build test: mkdir $(TESTDIR) ifdef FAKEROOT testdir=$(TESTDIR) fakeroot ./test-etckeeper else testdir=$(TESTDIR) ./test-etckeeper endif rm -rf $(TESTDIR) etckeeper.spec: sed -i~ "s/Version:.*/Version: $$(perl -e '$$_=<>;m/\((.*?)(-.*)?\)/;print $$1;';m/\((.*?)(-.*)?\)/;print $$1;' &2 echo "etckeeper warning: run etckeeper init to enable it" >&2 } if [ "$VCS" = git ] && [ ! -d .git ]; then not_enabled_warning elif [ "$VCS" = hg ] && [ ! -d .hg ]; then not_enabled_warning elif [ "$VCS" = bzr ] && [ ! -d .bzr ]; then not_enabled_warning elif [ "$VCS" = darcs ] && [ ! -d _darcs ]; then not_enabled_warning fi etckeeper-1.18.21/commit.d/20store-metadata000077700000000000000000000000001453142634200260542../pre-commit.d/30store-metadataustar00rootroot00000000000000etckeeper-1.18.21/commit.d/30bzr-add000077500000000000000000000002121453142634200167600ustar00rootroot00000000000000#!/bin/sh set -e if [ "$VCS" = bzr ] && [ -d .bzr ]; then if ! bzr add -q .; then echo "etckeeper warning: bzr add failed" >&2 fi fi etckeeper-1.18.21/commit.d/30darcs-add000077500000000000000000000004561453142634200172710ustar00rootroot00000000000000#!/bin/sh set -e if [ "$VCS" = darcs ] && [ -d _darcs ]; then rc=0 res=$( darcs add -qr . 2>&1 ) || rc=$? if test $rc -ne 0; then if ! test $rc -eq 2 -a "${res%No files were added}" != "$res"; then printf "%s" "$res" echo "etckeeper warning: darcs add failed" >&2 fi fi unset rc res fi etckeeper-1.18.21/commit.d/30git-add000077500000000000000000000002121453142634200167460ustar00rootroot00000000000000#!/bin/sh set -e if [ "$VCS" = git ] && [ -d .git ]; then if ! git add --all; then echo "etckeeper warning: git add --all" >&2 fi fi etckeeper-1.18.21/commit.d/30hg-addremove000077500000000000000000000002171453142634200200040ustar00rootroot00000000000000#!/bin/sh set -e if [ "$VCS" = hg ] && [ -d .hg ]; then if ! hg addremove .; then echo "etckeeper warning: hg addremove failed" >&2 fi fi etckeeper-1.18.21/commit.d/50vcs-commit000077500000000000000000000076241453142634200175360ustar00rootroot00000000000000#!/bin/sh set -e cleanup () { if [ -n "$logfile" ]; then rm -f "$logfile" fi } if [ -n "$1" ]; then if command -v mktemp >/dev/null; then tempfile="mktemp -t etckeeper-$VCS.XXXXXXXXXX" elif command -v tempfile >/dev/null; then tempfile="tempfile" else echo "etckeeper warning: can't find tempfile or mktemp" >&2 exit 1 fi trap cleanup EXIT logfile="$($tempfile)" if [ "x$1" = "x--stdin" ]; then cat > "$logfile" else sed '1s/^-m \{0,1\}//' >"$logfile" <<-EOF $* EOF fi else logfile="" fi hostname=`hostname 2>/dev/null || cat /etc/hostname` hostname="${hostname%%.*}" dnsdomainname=`dnsdomainname 2>/dev/null || true` if [ -n "$dnsdomainname" ]; then hostname="$hostname.$dnsdomainname" fi ORIG_USER=$USER USER= if [ -n "$SUDO_USER" ]; then USER="$SUDO_USER" else # try to check tty ownership, in case user su'd to root TTY="$(tty 2>/dev/null || true)" if [ -n "$TTY" ] && [ -c "$TTY" ]; then USER="$(find "$TTY" -printf "%u")" fi fi if [ "$VCS" = git ] && [ -d .git ]; then # When not su'd to root, still set environment variables, # since git's own code to determine the author and committer # has several edge cases where it fails and would prevent the # commit. if [ -z "$USER" ]; then USER="$(whoami)" fi if [ -n "$USER" ]; then # Use user.name and user.email from the gitconfig belonging # to USER. USER_HOME="$(getent passwd "$USER" | cut -d: -f6)" if [ -n "$USER_HOME" ] && [ -e "$USER_HOME/.gitconfig" ]; then if [ -z "$GIT_AUTHOR_NAME" ]; then GIT_AUTHOR_NAME="$(git config -f "$USER_HOME/.gitconfig" user.name)" || true export GIT_AUTHOR_NAME fi if [ -z "$GIT_AUTHOR_EMAIL" ]; then GIT_AUTHOR_EMAIL="$(git config -f "$USER_HOME/.gitconfig" user.email)" || true export GIT_AUTHOR_EMAIL fi fi if [ -z "$GIT_AUTHOR_NAME" ] || [ -z "$GIT_AUTHOR_EMAIL" ]; then if [ -n "$USER_HOME" ] && [ -e "$USER_HOME/.config/git/config" ]; then if [ -z "$GIT_AUTHOR_NAME" ]; then GIT_AUTHOR_NAME="$(git config -f "$USER_HOME/.config/git/config" user.name)" || true export GIT_AUTHOR_NAME fi if [ -z "$GIT_AUTHOR_EMAIL" ]; then GIT_AUTHOR_EMAIL="$(git config -f "$USER_HOME/.config/git/config" user.email)" || true export GIT_AUTHOR_EMAIL fi fi fi if [ -z "$GIT_COMMITTER_EMAIL" ]; then GIT_COMMITTER_EMAIL="$(git config --global user.email)" || true export GIT_COMMITTER_EMAIL fi if [ -z "$GIT_AUTHOR_NAME" ]; then GIT_AUTHOR_NAME="$USER" export GIT_AUTHOR_NAME fi if [ -z "$GIT_AUTHOR_EMAIL" ]; then GIT_AUTHOR_EMAIL="$USER@$hostname" export GIT_AUTHOR_EMAIL fi if [ -z "$GIT_COMMITTER_EMAIL" ]; then GIT_COMMITTER_EMAIL=`whoami`"@$hostname" export GIT_COMMITTER_EMAIL fi fi # gc ten times more frequently than the default # (unless some other config is set) GIT_GC_OPTIONS= if ! git config gc.auto >/dev/null; then GIT_GC_OPTIONS="-c gc.auto=670" fi if [ -n "$logfile" ]; then git $GIT_GC_OPTIONS commit $GIT_COMMIT_OPTIONS -F "$logfile" else git $GIT_GC_OPTIONS commit $GIT_COMMIT_OPTIONS fi elif [ "$VCS" = hg ] && [ -d .hg ]; then if [ -n "$USER" ]; then LOGNAME="$USER" export LOGNAME fi if [ -z "$HGUSER" ]; then HGUSER="$USER@$hostname" export HGUSER fi if [ -n "$logfile" ]; then hg commit $HG_COMMIT_OPTIONS -l "$logfile" else hg commit $HG_COMMIT_OPTIONS fi elif [ "$VCS" = bzr ] && [ -d .bzr ]; then if [ -z "$EMAIL" ] && [ -n "$USER" ]; then EMAIL="$USER <$USER@$hostname>" export EMAIL else bzr whoami >/dev/null 2>&1 || export EMAIL="$ORIG_USER <$ORIG_USER@$hostname>" fi if [ -n "$logfile" ]; then bzr commit $BZR_COMMIT_OPTIONS -F "$logfile" else bzr commit --quiet $BZR_COMMIT_OPTIONS fi elif [ "$VCS" = darcs ] && [ -d _darcs ]; then if [ -z "$USER" ]; then USER=root fi if [ -n "$logfile" ]; then darcs record --author="$USER" $DARCS_COMMIT_OPTIONS --logfile="$logfile" else darcs record --author="$USER" $DARCS_COMMIT_OPTIONS fi fi etckeeper-1.18.21/commit.d/99push000077500000000000000000000005111453142634200164350ustar00rootroot00000000000000#!/bin/sh if [ -n "$PUSH_REMOTE" ]; then if [ "$VCS" = git ] && [ -d .git ]; then for REMOTE in $PUSH_REMOTE; do git push "$REMOTE" || true done elif [ "$VCS" = hg ] && [ -d .hg ]; then for REMOTE in $PUSH_REMOTE; do hg push "$REMOTE" || true done else echo "PUSH_REMOTE not yet supported for $VCS" >&2 fi fi etckeeper-1.18.21/commit.d/README000066400000000000000000000003011453142634200162230ustar00rootroot00000000000000Files in this directory are run when there might be changes to commit. (Before and after packages are installed, upgraded, etc.) They should commit changes and new files in /etc to repository. etckeeper-1.18.21/cruft_filter000066400000000000000000000002571453142634200162560ustar00rootroot00000000000000/etc/.etckeeper /etc/.gitignore /etc/.git /etc/.git/** /etc/.hgignore /etc/.hg /etc/.hg/** /etc/.bzrignore /etc/.bzr /etc/.bzr/** /etc/.darcsignore /etc/_darcs /etc/_darcs/** etckeeper-1.18.21/daily000077500000000000000000000010471453142634200146710ustar00rootroot00000000000000#!/bin/sh # Script that can be run daily to autocommit /etc changes. set -e if [ -x /usr/bin/etckeeper ] && [ -e /etc/etckeeper/etckeeper.conf ]; then # avoid autocommit if an install run is in progress lockfile=/var/cache/etckeeper/packagelist.pre-install if [ -e "$lockfile" ] && [ -n "$(find "$lockfile" -mtime +1)" ]; then rm -f "$lockfile" # stale fi if [ ! -e "$lockfile" ]; then AVOID_SPECIAL_FILE_WARNING=1 export AVOID_SPECIAL_FILE_WARNING if etckeeper unclean; then etckeeper commit "daily autocommit" >/dev/null fi fi fi etckeeper-1.18.21/doc/000077500000000000000000000000001453142634200144045ustar00rootroot00000000000000etckeeper-1.18.21/doc/.gitignore000066400000000000000000000000121453142634200163650ustar00rootroot00000000000000/.ikiwiki etckeeper-1.18.21/doc/README.mdwn000066400000000000000000000255601453142634200162400ustar00rootroot00000000000000etckeeper is a collection of tools to let `/etc` be stored in a git, mercurial, bazaar or darcs repository. This lets you use git to review or revert changes that were made to `/etc`. Or even push the repository elsewhere for backups or cherry-picking configuration changes. It hooks into package managers like apt to automatically commit changes made to /etc during package upgrades. It tracks file metadata that git does not normally support, but that is important for /etc, such as the permissions of `/etc/shadow`. It's quite modular and configurable, while also being simple to use if you understand the basics of working with version control. ## Security warnings First, a big warning: By checking /etc into version control, you are creating a copy of files like /etc/shadow that must remain secret. Anytime you have a copy of a secret file, it becomes more likely that the file contents won't remain secret. etckeeper is careful about file permissions, and will make sure that repositories it sets up don't allow anyone but root to read their contents. However, you *also* must take care when cloning or copying these repositories, not to allow anyone else to see the data. Since git mushes all the files into packs under the .git directory, the whole .git directory content needs to be kept secret. (Ditto for mercurial and .hg as well as bazaar and .bzr) Also, since version control systems don't keep track of the mode of files like the shadow file, it will check out world readable, before etckeeper fixes the permissions. The tutorial has some examples of safe ways to avoid these problems when cloning an /etc repository. Also note that `etckeeper init` runs code stored in the repository. So don't use it on repositories from untrusted sources. ## What etckeeper does etckeeper has special support to handle changes to /etc caused by installing and upgrading packages. Before apt installs packages, `etckeeper pre-install` will check that /etc contains no uncommitted changes. After apt installs packages, `etckeeper post-install` will add any new interesting files to the repository, and commit the changes. You can also run `etckeeper commit` by hand to commit changes. There is also a cron job, that will use etckeeper to automatically commit any changes to /etc each day. ## VCS limitations Version Control Systems are designed as a way to manage source code, not as a way to manage arbitrary directories like /etc. This means there are a few limitations that etckeeper has to work around. These include file metadata storage, empty directories, and special files. Most VCS, including git, mercurial and bazaar have only limited tracking of file metadata, being able to track the executable bit, but not other permissions or owner info. (darcs doesn't even track executable bits.) So file metadata is stored separately. Among other chores, `etckeeper init` sets up a `pre-commit` hook that stores metadata about file owners and permissions into a `/etc/.etckeeper` file. This metadata is stored in version control along with everything else, and can be applied if the repo should need to be checked back out. git and mercurial cannot track empty directories, but they can be significant sometimes in /etc. So the `pre-commit` hook also stores information that can be used to recreate the empty directories in the `/etc/.etckeeper` file. Most VCS don't support several special files that you _probably_ won't have in /etc, such as unix sockets, named pipes, hardlinked files (but symlinks are fine), and device files. The `pre-commit` hook will warn if your /etc contains such special files. Darcs doesn't support symlinks, so they are also stored in `/etc/.etckeeper`. ## Tutorial A quick walkthrough of using etckeeper. Note that the default VCS is git, and this tutorial assumes you're using it. Using other VCSes should be broadly similar. First, get etckeeper installed. Something like: apt-get install etckeeper The `etckeeper init` command initialises an /etc/.git/ repository. If you installed etckeeper from a package, this was probably automatically performed during the package installation. If not, your first step is to run it by hand: etckeeper init The `etckeeper init` command is careful to never overwrite existing files or directories in /etc. It will create a `.gitignore` if one doesn't already exist (or update content inside a "managed by etckeeper" comment block), sets up pre-commit hooks if they don't already exist, and so on. It does *not* commit any files, but does `git add` all interesting files for an initial commit later. Now you might want to run `git status` to check that it includes all the right files, and none of the wrong files. And you can edit the `.gitignore` and so forth. Once you're ready, it's time to commit: cd /etc git status git commit -m "initial checkin" git gc # pack git repo to save a lot of space After this first commit, you can use regular git commands to handle further changes: passwd someuser git status git commit -a -m "changed a password" Rinse, lather, repeat. You might find that some files are changed by daemons and shouldn't be tracked by git. These can be removed from git: git rm --cached printcap # modified by CUPS echo printcap >> .gitignore git commit -a -m "don't track printcap" etckeeper hooks into apt (and similar systems) so changes to interesting files in /etc caused by installing or upgrading packages will automatically be committed. Here "interesting" means files that are not ignored by `.gitignore`. You can use any git commands you like, but do keep in mind that, if you check out a different branch or an old version, git is operating directly on your system's /etc. If you do decide to check out a branch or tag, make sure you run "etckeeper init" again, to get any metadata changes: git checkout april_first_joke_etc etckeeper init Often it's better to clone /etc to elsewhere and do potentially dangerous stuff in a staging directory. You can clone the repository using git clone, but be careful that the directory it's cloned into starts out mode 700, to prevent anyone else from seeing files like `shadow`, before `etckeeper init` fixes their permissions: mkdir /my/workdir cd /my/workdir chmod 700 . git clone /etc cd etc etckeeper init -d . chmod 755 .. Another common reason to clone the repository is to make a backup to a server. When using `git push` to create a new remote clone, make sure the new remote clone is mode 700! (And, obviously, only push over a secure transport like ssh, and only to a server you trust.) ssh server 'mkdir /etc-clone; cd /etc-clone; chmod 700 .; git init --bare' git remote add backup ssh://server/etc-clone git push backup --all If you have several machines using etckeeper, you can start with a etckeeper repository on one machine, then add another machine's etckeeper repository as a git remote. Then you can diff against it, examine its history, merge with it, and so on. It would probably not, however, be wise to "git checkout" the other machine's branch! (And if you do, make sure to run "etckeeper init" to update file permissions.) root@darkstar:/etc>git remote add dodo ssh://dodo/etc root@darkstar:/etc>git fetch dodo root@darkstar:/etc>git diff dodo/master group |head diff --git a/group b/group index 0242b84..b5e4384 100644 --- a/group +++ b/group @@ -5,21 +5,21 @@ sys:x:3: adm:x:4:joey tty:x:5: disk:x:6: -lp:x:7:cupsys +lp:x:7: Incidentally, this also means I have a backup of dodo's /etc on darkstar. So if darkstar is compromised, that data could be used to attack dodo too. On the other hand, if dodo's disk dies, I can restore it from this handy backup. Of course, it's also possible to pull changes from a server onto client machines, to deploy changes to /etc. Once /etc is under version control, the sky's the limit.. ## Configuration The main configuration file is `/etc/etckeeper/etckeeper.conf` etckeeper runs the executable files in `/etc/etckeeper/$command.d/`. (It ignores the same ones that run-parts(1) would ignore.) You can modify these files, or add your own custom files. Each individual file is short, simple, and does only one action. For example, here's how to configure it to run `git gc` after each apt run, which will save a lot of disk space: cd /etc/etckeeper/post-install.d (echo '#!/bin/sh' ; echo 'exec git gc') > 99git-gc chmod +x 99git-gc git add . git commit -m "run git gc after each apt run" Here's how to disable the automatic commits after each apt run, while still letting it git add new files: rm /etc/etckeeper/commit.d/50vcs-commit ## sudo integration etckeeper will notice if it's being run by way of sudo, and makes a commit with the author set to the user who sudoed to root. This is useful when a system has multiple admins; as long as they use sudo while doing their administration, and run `sudo etckeeper commit` to commit their changes, `git blame` can show who was responsible for each change. ## changing VCS By default, etckeeper uses git. This choice has been carefully made; git is the VCS best supported by etckeeper and the VCS users are most likely to know. [ It's possible that your distribution has chosen to modify etckeeper so its default VCS is not git -- if they have please complain to them, as they're making things unnecessarily difficult for you, and causing unnecessary divergence of etckeeper installations. You should only be using etckeeper with a VCS other than git if you're in love with the other VCS. ] If you would like to use some other VCS, and `etckeeper init` has already been run to set up a git repository, you have a decision to make: Is the history recorded in that repository something you need to preserve, or can you afford to just blow it away and check the current /etc into the new VCS? In the latter case, you just need to follow three steps: etckeeper uninit # deletes /etc/.git! vim /etc/etckeeper/etckeeper.conf etckeeper init In the former case, you will need to convert the git repository to the other VCS using whatever tools are available to do that. Then you can run `etckeeper uninit`, move files your new VCS will use into place, edit `etckeeper.conf` to change the VCS setting, and finally `etckeeper init`. This procedure is clearly only for the brave. ## Inspiration Two blog posts provided inspiration for techniques used by etckeeper: * * isisetup had some of the same aims as etckeeper, however, unlike it, etckeeper does not aim to be a git porcelain with its own set of commands for manipulating the /etc repository. Instead, etckeeper provides a simple setup procedure and hooks for setting up an /etc repository, and then gets out of your way; you manage the repository using regular VCS commands. ## License etckeeper is licensed under version 2 or greater of the GNU GPL. ## Website ## Author Joey Hess etckeeper-1.18.21/doc/comments.mdwn000066400000000000000000000005231453142634200171200ustar00rootroot00000000000000[[!sidebar content=""" [[!inline pages="comment_pending(*)" feedfile=pendingmoderation description="comments pending moderation" show=-1]] Comments in the [[!commentmoderation desc="moderation queue"]]: [[!pagecount pages="comment_pending(*)"]] """]] Recent comments posted to this site: [[!inline pages="comment(*)" template="comment"]] etckeeper-1.18.21/doc/forum.mdwn000066400000000000000000000003651453142634200164270ustar00rootroot00000000000000This is a place to discuss using etckeeper, share tips and tricks, etc. If you need help, advice, or anything, post about it here. [[!inline pages="forum/* and !*/Discussion" archive=yes rootpage=forum postformtext="Add a new thread titled:"]] etckeeper-1.18.21/doc/forum/000077500000000000000000000000001453142634200155345ustar00rootroot00000000000000etckeeper-1.18.21/doc/forum/1.18.9_broken_with_busybox_ps.mdwn000066400000000000000000000023011453142634200240250ustar00rootroot00000000000000Hi, The following commit: ec8d1ad Add the package manager or any other parent process command to the commit log breaks etckeeper on systems with Busybox ps: ps: unrecognized option: h BusyBox v1.29.3 (2018-11-21 11:45:56 UTC) multi-call binary. Usage: ps [-o COL1,COL2=HEADER] Show list of processes -o COL1,COL2=HEADER Select columns for display From the Debian manpage on the `h` option: h No header. (or, one header per screen in the BSD personality). The h option is problematic. Standard BSD ps uses this option to print a header on each page of output, but older Linux ps uses this option to totally disable the header. This version of ps follows the Linux usage of not printing the header unless the BSD personality has been selected, in which case it prints a header on each page of output. Regardless of the current personality, you can use the long options --headers and --no-headers to enable printing headers each page or disable headers entirely, respectively. So the use of `h` could affect the portability of `etckeeper` and the problem is not limited to Busybox `ps`. etckeeper-1.18.21/doc/forum/1.18.9_broken_with_busybox_ps/000077500000000000000000000000001453142634200231425ustar00rootroot00000000000000comment_1_ee6109c7209febb6fbec0e99c3901672._comment000066400000000000000000000010421453142634200332160ustar00rootroot00000000000000etckeeper-1.18.21/doc/forum/1.18.9_broken_with_busybox_ps[[!comment format=mdwn username="joey" subject="""comment 1""" date="2018-12-23T16:52:32Z" content=""" Another problem with busybox ps and that patch is that while `ps 1` normally shows only pid 1, `busybox ps 1` lists all pids. So it doesn't seem that code path can support busybox ps at all, and probably the safest thing to do is to use --no-headers to make procps's ps always do the right thing no matter how configured, and if that fails, /dev/null the error and fall back to not including the command line in the commit message. """]] comment_2_b89bc67dd20946798691372635ba91b0._comment000066400000000000000000000002761453142634200326600ustar00rootroot00000000000000etckeeper-1.18.21/doc/forum/1.18.9_broken_with_busybox_ps[[!comment format=mdwn username="joey" subject="""comment 2""" date="2018-12-23T17:05:17Z" content=""" Fixed. (Ps, please use the todo page not the forum for reporting problems.) """]] Can_etckeeper_hook_into_the_snapd_install_machinery_like_it_does_for_apt_.mdwn000066400000000000000000000005311453142634200353410ustar00rootroot00000000000000etckeeper-1.18.21/doc/forumI like that etckeeper can block my attempt at apt-get installing anything when there are pending changes in /etc Can this also be done with stuff installed from the Snap Store (https://snapcraft.io/store)? I've been looking for the git repository for this project to look for an issue tracker, but couldn't find anything 'official'. Cheers Can_etckeeper_hook_into_the_snapd_install_machinery_like_it_does_for_apt_/000077500000000000000000000000001453142634200344535ustar00rootroot00000000000000etckeeper-1.18.21/doc/forumcomment_1_431b3e7e1887d897335f35b1bfaf0351._comment000066400000000000000000000003421453142634200443640ustar00rootroot00000000000000etckeeper-1.18.21/doc/forum/Can_etckeeper_hook_into_the_snapd_install_machinery_like_it_does_for_apt_[[!comment format=mdwn username="joey" subject="""comment 1""" date="2019-08-08T15:25:59Z" content=""" Whether that is possible depends on what hooks, if any, snapd supports. etckeeper's todo list is here: [[todo]] """]] etckeeper-1.18.21/doc/forum/Comparing___47__etcs.mdwn000066400000000000000000000022651453142634200223340ustar00rootroot00000000000000I have two hosts which have been set up identically, except for a few things like hostnames and the like. I also have a git server (gitea) separate from both. I set up etckeeper as per the following (running Debian): apt install etckeeper cd /etc/ git status git diff git commit -m "initial commit" git gc git remote add origin http://git.server/user/server_etc.git Since I have two hosts, I thought it would be useful/convenient to give each one a named branch in the same repo: git branch -m host-one git push --set-upstream origin host-one And same for host-two. In gitea I successfully can see the two branches (and there is no master). However git/gitea does not see them as related branches and so will not compare them. This makes sense to me as they were both new branches. How can I make them related branches, ideally without clobbering my hosts (I'd rather not pull anything on those)? I think I have to give each branch a common parent (maybe a blank master?), but I'm happy to make host-two a branch of host-one if that's easier. (I realise this isn't strictly a etckeeper question but I posted here in case it help others with a similar usecase). etckeeper-1.18.21/doc/forum/Comparing___47__etcs/000077500000000000000000000000001453142634200214405ustar00rootroot00000000000000etckeeper-1.18.21/doc/forum/Comparing___47__etcs/comment_1_7a417a317cf5fbc78924575dc7b5e32b._comment000066400000000000000000000012341453142634200315150ustar00rootroot00000000000000[[!comment format=mdwn username="sshaikh" avatar="http://cdn.libravatar.org/avatar/e31e0ba78d2df04dc252e1bf87e8f378" subject="comment 1" date="2020-05-23T14:58:39Z" content=""" I think this does what I need: #use a temp dir mkdir /tmp/etc cd /tmp/etc git init git remote add origin http://git.server/user/server_etc.git touch init git add . git commit -m \"init\" git push --set-upstream origin master git fetch git checkout host-one git rebase master #lots of merge errors due to master being empty repo git add . git rebase --continue git push --force #as local is now \"ahead\" of remote. """]] etckeeper-1.18.21/doc/forum/Comparing___47__etcs/comment_2_2b2d1a57ad72a1196f0d2a2d546b0c2e._comment000066400000000000000000000005461453142634200315400ustar00rootroot00000000000000[[!comment format=mdwn username="joey" subject="""comment 2""" date="2020-05-26T23:09:08Z" content=""" git diff does not care one bit if the branches are related or not. (git merge does care, but it can be overridden with --allow-unrelated-histories) It may be that gitea has some check in its UI to avoid diffing related braches for some reason. """]] etckeeper-1.18.21/doc/forum/Composite___47___multi-step_changes.mdwn000066400000000000000000000023541453142634200253520ustar00rootroot00000000000000I'd like to be able to `commit` a single change into etckeeper's VCS that reflected more than one `apt` action. As a developer I prefer to see commits representing a logically complete piece of work, not something that requires follow-on commits before the system is back in a sane / consistent state. Consider the case of installing Sublime Text for Linux (** - see bottom), there are several steps, all of which are parts of a single logical action that should be committed as one operation into git (or whatever VCS). * wget ... | apt-key add - * apt-get install apt-transport-https * create /etc/apt/sources.list.d/sublime-text.list * apt-get update * apt-get install sublime-text Ideally the work-flow would look like: * etckeeper begin-transaction * wget ... | apt-key add - * git add apt/trusted.gpg * apt-get install apt-transport-https # etckeeper WARNS about uncommitted changes / transaction still open # (instead of aborting) * create /etc/apt/sources.list.d/sublime-text.list * git add apt/sources.list.d/sublime-text.list * apt-get update # etckeeper WARNS... * apt-get install sublime-text # etckeeper WARNS... * etckeeper finish-transaction # commits to VCS (*) https://www.sublimetext.com/docs/3/linux_repositories.html etckeeper-1.18.21/doc/forum/Composite___47___multi-step_changes/000077500000000000000000000000001453142634200244575ustar00rootroot00000000000000comment_1_a381633b6acebfc83ca68eaa1e181840._comment000066400000000000000000000012211453142634200345650ustar00rootroot00000000000000etckeeper-1.18.21/doc/forum/Composite___47___multi-step_changes[[!comment format=mdwn username="joey" subject="""comment 1""" date="2018-05-08T15:59:07Z" content=""" One way to accomplish this is to `git branch -f transaction master` at the start, and once all intermediate commits have been made (by etckeeper or by you), run `git reset transaction; etckeeper commit "transaction description"`. It's also sometimes handy to then generate a merge commit between the final transaction commit and the last intermediate commit; then you have both the transactions and all the intermediate steps accessible in git log; the git history has a diamond shape. I'd be willing to consider patches along these lines.. """]] etckeeper-1.18.21/doc/forum/Does_not_create_config.mdwn000066400000000000000000000005541453142634200230510ustar00rootroot00000000000000I've just installed etckeeper however there is no /etc/etckeeper/etckeeper.conf file and no default config. i can't remove it with apt now either because it complains it needs a VCS set up in the config file.. which doesn't exist. how can i fix this? i need to be able to use apt to update, install and remove stuff.. i can't even use it because of this VCS thing etckeeper-1.18.21/doc/forum/Does_not_create_config/000077500000000000000000000000001453142634200221565ustar00rootroot00000000000000comment_2_f6bdb049f8090fe7f1fbf827f793ef10._comment000066400000000000000000000005271453142634200323350ustar00rootroot00000000000000etckeeper-1.18.21/doc/forum/Does_not_create_config[[!comment format=mdwn username="joey" subject="""comment 2""" date="2020-07-20T23:42:10Z" content=""" It would probably be helpful if you explained how you installed it, if you want help with that. The file is: * installed by "make install" * included in the debian package * included in the source repository as "etckeeper.conf" """]] etckeeper-1.18.21/doc/forum/How_to_submit_pull_requests__63__.mdwn000066400000000000000000000001201453142634200251720ustar00rootroot00000000000000I have a few improvements that I'd like to submit, do you accept pull requests? etckeeper-1.18.21/doc/forum/How_to_submit_pull_requests__63__/000077500000000000000000000000001453142634200243125ustar00rootroot00000000000000comment_1_a1ef90ca5f66af6c35ea66b6c520ddd5._comment000066400000000000000000000003321453142634200345730ustar00rootroot00000000000000etckeeper-1.18.21/doc/forum/How_to_submit_pull_requests__63__[[!comment format=mdwn username="joey" subject="""comment 1""" date="2022-11-16T20:47:32Z" content=""" Just go to [[todo]] and make a post there, and include the url of the git repository and branch to pull. """]] etckeeper-1.18.21/doc/forum/How_would_I_rebase_all_commits_older_than_two_weeks__63__.mdwn000066400000000000000000000047101453142634200320030ustar00rootroot00000000000000Hi; I'm implementing etckeeper for all of our servers, but I'm concerned about the "unlimited growth potential" of the /etc/.git repository. (Note: I'm not a git expert by any means.) Google hasn't explicitly said so, but there are hints that rebasing (followed by garbage collection) will let me squash commits and keep the repository from filling up the root partition. The command `git log --before 'two weeks ago' -1` shows the last commit made just before that point in time, so that may be useful in the final solution. Also, [[this post|Prevent_hook_running_during_rebase]] briefly describes the correct process for rebasing: `clone /etc repo, edit, and force pull the changes` So, in a nutshell: * How can I squash all commits older than (say) two weeks into a single commit at the root of the /etc repo, leaving younger commits alone? - This should nuke all the copies of things that were deleted from /etc more than two weeks ago, yes? * If I wanted to emulate monthly, weekly and daily backups (with different retention periods) in the etckeeper repository, how could it be done? Thanks! --- # 2021-11-04 Ok, I'm back, I think I've found a solution: ``` git checkout master # To make sure you're where you think you are root_commit=$(git rev-list --max-parents=0 HEAD) git log --before "2 weeks ago" -1 # See the commit id and check the date is suitable, don't continue until you're happy git rebase -i $root_commit # Starts an editor with a list of every commit since the dawn of time, oldest at the top, latest at the bottom ``` In the editor, change 'pick' to 'squash' for every commit **except**: * the first (it'll generate an error if you try, as there's nothing to squash it into) * the one you found with 'git log', above * and all the commits after that After that, run `git gc`; it should clear out all the now-unused commits that were squashed. To emulate weekly/monthly backups, use that `git log --before "X weeks/months ago" -1` command to find the commits, and then leave them as 'pick' (not 'squash') during the rebase! :-) Cautions: * This worked for me, but may not work for you. (YMMV) * Copy /etc to another directory for experimentation. * Back up /etc before you do it for real. * If you break it, you get to keep both pieces! Good luck! References: * https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History * https://git-scm.com/docs/git-rebase * https://www.cloudbees.com/blog/git-squash-how-to-condense-your-commit-history etckeeper-1.18.21/doc/forum/How_would_I_rebase_all_commits_older_than_two_weeks__63__/000077500000000000000000000000001453142634200311125ustar00rootroot00000000000000comment_1_f4d51ea1f265f09ebbc37ef9d3242be1._comment000066400000000000000000000011251453142634200413140ustar00rootroot00000000000000etckeeper-1.18.21/doc/forum/How_would_I_rebase_all_commits_older_than_two_weeks__63__[[!comment format=mdwn username="hlovdal" nickname="kode" avatar="http://cdn.libravatar.org/avatar/e513ee57b6b0d2c0ae8dfa4b9e85f566" subject="This should not be necessary" date="2022-11-27T17:50:02Z" content=""" Unless you have a super constrained environment like [openwrt](https://openwrt.org/) then disk usage of `/etc/.git` is completely ignorable (and even so, my openwrt router only uses 2.1Mb for `/etc/.git`, initial commit 2016). I checked all my servers and desktops and the largest was 196Mb on a machine that used to be my main desktop with the repository started in 2017. """]] etckeeper-1.18.21/doc/forum/Ignore_passwd_backup_files.mdwn000066400000000000000000000003021453142634200237310ustar00rootroot00000000000000The passwd, shadow and group files have backups that just create unnecessary churn on the repository, since they are already being tracked. Ignore: ``` /passwd- /shadow- /group- /gshadow- ``` etckeeper-1.18.21/doc/forum/Ignore_passwd_backup_files/000077500000000000000000000000001453142634200230475ustar00rootroot00000000000000comment_1_e799e0a5f18cdffc52d29d337c401a19._comment000066400000000000000000000012431453142634200331240ustar00rootroot00000000000000etckeeper-1.18.21/doc/forum/Ignore_passwd_backup_files[[!comment format=mdwn username="joey" subject="""comment 1""" date="2022-01-09T15:19:03Z" content=""" These files are unlikely to change without their originals changing too, so how is that unncessary churn? (And if they did change without the originals changing, that seems like the kind of event it might be useful to have a record of.) And the hash of the files is the same as the hash of a previous version of the original, so including them does not even use more disk space. Aside from gratuitous files that do not belong in /etc, etckeeper should accurately reflact the actual contents of the directory by default. To do otherwise risks being surprising. """]] etckeeper-1.18.21/doc/forum/Is_there_a_bug_tracker_for_etckeeper___63__.mdwn000066400000000000000000000001351453142634200270350ustar00rootroot00000000000000Hi, I'm having trouble finding the bug tracker for etckeeper is there actually one ? Thanks. etckeeper-1.18.21/doc/forum/Is_there_a_bug_tracker_for_etckeeper___63__/000077500000000000000000000000001453142634200261475ustar00rootroot00000000000000comment_1_33806aefc8706e6db0afec2a9672f3f0._comment000066400000000000000000000001771453142634200363030ustar00rootroot00000000000000etckeeper-1.18.21/doc/forum/Is_there_a_bug_tracker_for_etckeeper___63__[[!comment format=mdwn username="joey" subject="""comment 1""" date="2022-10-04T16:37:11Z" content=""" See [[todo]]. """]] comment_2_67b06a471f9021ec7e4d41cbaeb8b5bd._comment000066400000000000000000000003171453142634200363450ustar00rootroot00000000000000etckeeper-1.18.21/doc/forum/Is_there_a_bug_tracker_for_etckeeper___63__[[!comment format=mdwn username="jerrythepineapple" avatar="http://cdn.libravatar.org/avatar/d152617d7827ea33fe921456f23a7672" subject="comment 2" date="2022-11-17T22:48:28Z" content=""" Thanks!! """]] etckeeper-1.18.21/doc/forum/Is_there_a_workaround_for_a_git_repository_under___47__etc__63__.mdwn000066400000000000000000000020261453142634200332140ustar00rootroot00000000000000I did some research and found out that there is no good way to avoid etckeeper commit "daily autocommit" exiting with status code other than zero if there is a git repository under the /etc hierarchy? This causes the /etc/cron.daily/etckeeper to send an e-mail every day with body "run-parts: /etc/cron.daily/etckeeper exited with return code 1." I've attempted to add the repo as git submodule in /etc/.gitmodules and tried to add "-path ./myrepo -prune -o" to the NOVCS in /etc/etckeeper/pre-commit.d/30store-metadata but neither of these fixed the issue. If I have a git repo in /etc/myrepo: # etckeeper commit "daily autocommit" On branch master Changes not staged for commit: (use "git add ..." to update what will be committed) (use "git restore ..." to discard changes in working directory) (commit or discard the untracked or modified content in submodules) modified: myrepo (untracked content) no changes added to commit (use "git add" and/or "git commit -a") # echo $? 1 etckeeper-1.18.21/doc/forum/Is_there_a_workaround_for_a_git_repository_under___47__etc__63__/000077500000000000000000000000001453142634200323255ustar00rootroot00000000000000comment_1_5eb9fcc0e3384f702da7e188b19c3858._comment000066400000000000000000000027051453142634200423360ustar00rootroot00000000000000etckeeper-1.18.21/doc/forum/Is_there_a_workaround_for_a_git_repository_under___47__etc__63__[[!comment format=mdwn username="me_and" avatar="http://cdn.libravatar.org/avatar/f8647c2810c056bbdb8857117708ae3d" subject="comment 1" date="2023-02-23T13:27:23Z" content=""" What are you trying to achieve here? I'm not sure what your goal is from the question. Would you rather… - Have etckeeper ignore the `/etc/myrepo` directory entirely - Have etckeeper automatically commit changes to `/etc/myrepo` as a submodule, then automatically commit submodule changes to the `/etc` repository - Have etckeeper not run daily commits at all - Something else… If you _just_ want to disable the non-zero exit status, you can change `/etc/etckeeper/commit.d/50vcs-commit` to suppress the exit status. To do that, change the following lines: ``` if [ -n \"$logfile\" ]; then git $GIT_GC_OPTIONS commit $GIT_COMMIT_OPTIONS -F \"$logfile\" else git $GIT_GC_OPTIONS commit $GIT_COMMIT_OPTIONS fi ``` to ``` if [ -n \"$logfile\" ]; then git $GIT_GC_OPTIONS commit $GIT_COMMIT_OPTIONS -F \"$logfile\" || : else git $GIT_GC_OPTIONS commit $GIT_COMMIT_OPTIONS || : fi ``` But all that will do is prevent any errors from being reported, which I suspect isn't what you're after! All `etckeeper commit` is doing is running the scripts in `/etc/etckeeper/commit`, though, so you should be able to change it to do whatever you want just by editing those scripts. """]] comment_2_a9d66633132fe5d135499720e0beaaa3._comment000066400000000000000000000006601453142634200422270ustar00rootroot00000000000000etckeeper-1.18.21/doc/forum/Is_there_a_workaround_for_a_git_repository_under___47__etc__63__[[!comment format=mdwn username="pulk" avatar="http://cdn.libravatar.org/avatar/3aca97ac14e8c43b9da4a9070d45e443" subject="Comment 2" date="2023-02-28T11:41:37Z" content=""" Hi! And thanks for the tip. I think I am okay with the first and second option (ignore the dir completely or have as submodule) you provided. And I would indeed like to know about any other error messages, I do not wish to ignore them completely. """]] comment_3_39cb7f40edffb43b79fdb275670ffbd9._comment000066400000000000000000000004511453142634200426400ustar00rootroot00000000000000etckeeper-1.18.21/doc/forum/Is_there_a_workaround_for_a_git_repository_under___47__etc__63__[[!comment format=mdwn username="me_and" avatar="http://cdn.libravatar.org/avatar/f8647c2810c056bbdb8857117708ae3d" subject="comment 3" date="2023-03-02T20:46:48Z" content=""" In that case, I'd recommend just having the directory ignored: ``` sudo sed -i 1i/myrepo /etc/.gitignore ``` """]] comment_4_fb987b5a4ea73f83d01536f60f301a1a._comment000066400000000000000000000005511453142634200423070ustar00rootroot00000000000000etckeeper-1.18.21/doc/forum/Is_there_a_workaround_for_a_git_repository_under___47__etc__63__[[!comment format=mdwn username="pulk" avatar="http://cdn.libravatar.org/avatar/3aca97ac14e8c43b9da4a9070d45e443" subject="comment 4" date="2023-03-16T14:18:17Z" content=""" Unfortunately that does not work. I tried all these in /etc/.gitignore: myrepo myrepo/* /myrepo /myrepo/* But I still get the error each time. """]] comment_5_b6a7557835e91cf2e8f362913b6fc6ee._comment000066400000000000000000000010521453142634200423430ustar00rootroot00000000000000etckeeper-1.18.21/doc/forum/Is_there_a_workaround_for_a_git_repository_under___47__etc__63__[[!comment format=mdwn username="joey" subject="""comment 5""" date="2023-04-21T16:02:43Z" content=""" Your repo has already been added as a submodule. That's why git commit is complaining about it. If you put it in /etc/.gitignore before `etckeeper commit`, it will be ignored from the beginning. At this point you will need to remove the submodule as well as ignoring it. I was a little surprised to see etckeeper adding git repos within /etc as submodules, but it turns out that `git add --all` or `git add .` do add submodules that way. """]] comment_6_cc18dab78617cec7efddb8b0450f7f07._comment000066400000000000000000000004731453142634200426320ustar00rootroot00000000000000etckeeper-1.18.21/doc/forum/Is_there_a_workaround_for_a_git_repository_under___47__etc__63__[[!comment format=mdwn username="pulk" avatar="http://cdn.libravatar.org/avatar/3aca97ac14e8c43b9da4a9070d45e443" subject="comment 6" date="2023-04-25T05:43:57Z" content=""" Thanks! That solved the issue. I did not remember that I had previously attempted to add it as submodule to workaround the issue. """]] etckeeper-1.18.21/doc/forum/Joey_you_just_blew_my_mind..mdwn000066400000000000000000000005171453142634200241000ustar00rootroot00000000000000While trying to add etckeeper to some other system today, I ran: $ etckeeper help etckeeper: /etc/etckeeper/help.d does not exist And now I'm wondering why I don't just make *all* of my big scripts call `run-parts` on the subcommands. # Why was I not informed sooner? Anyway thanks, Joey, I learned a cool new trick today! List_of_files_or_directories_to_daily_auto_commit_or_commit_before_install.mdwn000066400000000000000000000003321453142634200356230ustar00rootroot00000000000000etckeeper-1.18.21/doc/forumHello, There is a solution include in etckeeper that allow to create a list of files or directories that can be automatically commit even if we desactivate global daily autocommit or install before install ? Regards 0fd902cfee7f53ade08d72f0dfe61f75a1e30324.paxheader00006660000000000000000000000214145314263420020730xustar00rootroot00000000000000140 path=etckeeper-1.18.21/doc/forum/Make_pre-commit.d__47__30store-metadata:generate__95__metadata__40____41___filter_Git_sub_modules.mdwn 0fd902cfee7f53ade08d72f0dfe61f75a1e30324.data000066400000000000000000000006111453142634200175670ustar00rootroot00000000000000It would be great if the function generate_metadata() in pre-commit.d/30store-metadata would not only filter ignore patterns from .gitignore, but if it would also filter any files inside Git sub modules. Information about Git sub modules is being stored in a .gitmodules files, similar to this (example): ``` [submodule "path/to/dir"] path = path/to/dir url = https://... ``` etckeeper-1.18.21/doc/forum/Prevent_hook_running_during_rebase.mdwn000066400000000000000000000016341453142634200255230ustar00rootroot00000000000000Normally, when I wish to fix or clean up history I’ll do The Right Thing(clone `/etc` repo, edit, and force `pull` the changes). *However*, occasionally I’ll perform a quick in-place `rebase` when the depth is *very* shallow or will be non-destructive. If — like me — you do this then you’ve probably been bitten by `.etckeeper` breakage when simply re-ordering commits. If so, then the following addition to your `.git/hooks/pre-commit` will prevent the hook running while in a `rebase` session. ``` if git branch | grep -q '^\* (no branch'; then echo "Skipping pre-commit hook in rebase" >&2 exit 0 fi ``` **Note**: The unbalanced parenthesis in the match is on purpose, depending on your `git` version you could have a simple `(no branch)` or the far more helpful `(no branch, rebasing )` branch name. I’d be interested to know if other users have a better way to handle this. -- James etckeeper-1.18.21/doc/forum/Prevent_hook_running_during_rebase/000077500000000000000000000000001453142634200246305ustar00rootroot00000000000000comment_1_101f16d09f46b477811b7c864abbc8bb._comment000066400000000000000000000047121453142634200346150ustar00rootroot00000000000000etckeeper-1.18.21/doc/forum/Prevent_hook_running_during_rebase[[!comment format=mdwn username="hlovdal" nickname="kode" avatar="http://cdn.libravatar.org/avatar/e513ee57b6b0d2c0ae8dfa4b9e85f566" subject="Use git worktree" date="2022-11-27T22:50:32Z" content=""" While cloning and pulling between repos works, it is as you mentioned a bit cumbersome. What works much better is to create a lightweight [worktree](https://git-scm.com/docs/git-worktree), e.g. `git worktree add /root/etc.worktree main.worktree`. Then `/etc` and `/root/etc.worktree` shares all commits and sort of works like instantly synchronised clones. The only limitation is that the same branch cannot be checked out in both worktrees (I use `main.worktree` as a shadow of `main`). With that the update scenario will be like `cd /root/worktree` `git checkout main.worktree # Probably default and not needed` `git merge --ff main # Bring it up to date` `git rebase --interactive HEAD~10 # Or whatever history modification you want to use` `cd /etc` Finish with either `git merge main.worktree` or `git reset --hard main.worktree # NB! reset --hard is a command that might cause you to loose data if you are not careful.` I mainly use worktree to painlessly resolve new `*.rpmnew` files which are created if a package is updated and a config file update would overwrite some custom non-package modification, e.g say for instance you have changed `GIT_COMMIT_OPTIONS` in `etckeeper.conf` and a newer version of etckeeper has some other update to that config file. If it is the first time I resolve a update conflict I create a branch `rpmnew/etckeeper.conf` from a commit right before I made the `GIT_COMMIT_OPTIONS` modification (which might have been a while ago, so resetting back to that inside /etc would likely be a disaster. Inside a linked worktree there is no problem). Then I overwrite `/root/etc.worktree/etckeeper/etckeeper.conf` with `/etc/etckeeper/etckeeper.conf.rpmnew` and check in. Then the final step is `git checkout main.worktree && git merge rpmnew/etckeeper.conf`. This could potentially result in merge conflicts, but there are excellent tools like [KDiff3](https://kdiff3.sourceforge.net/) to [use for that](https://github.com/hlovdal/git-resolve-conflict-using-kdiff3). The problem with the pre-commit hook still applies in this scenario, but I have just [asked for a patch to be applied that will prevent the hook from running inside linked worktrees](https://etckeeper.branchable.com/todo/Skip_running_pre-commit_hook_inside_linked_worktrees/). """]] etckeeper-1.18.21/doc/forum/Why_backup_files_like_passwd-_are_not_being_ignored__63__.mdwn000066400000000000000000000010111453142634200316630ustar00rootroot00000000000000From https://git.joeyh.name/index.cgi/etckeeper.git/tree/update-ignore.d/01update-ignore#n110: > \# Not currently ignored as admins tend to rely on these files. > \#ignore "passwd-" > \#ignore "group-" > \#ignore "shadow-" > \#ignore "gshadow-" But I can't understand the reason, considering that ignoring these backup files justs leaves them there so admins can still use them. In the other hand, having the original files (e.g. `passwd`) under version control will provide admins the expected history of changes. etckeeper-1.18.21/doc/forum/Why_backup_files_like_passwd-_are_not_being_ignored__63__/000077500000000000000000000000001453142634200310035ustar00rootroot00000000000000comment_1_a14869bdf298370a0b307c352759ee80._comment000066400000000000000000000006251453142634200405620ustar00rootroot00000000000000etckeeper-1.18.21/doc/forum/Why_backup_files_like_passwd-_are_not_being_ignored__63__[[!comment format=mdwn username="joey" subject="""comment 1""" date="2019-12-25T19:44:29Z" content=""" An admin might expect to be able to `mv passwd- passwd` to undo the most recent change, and if so that might as well be supported after restoring /etc from backup. There is essentially no overhead in adding these files since they have the same content as an older commit of the passwd file. """]] etckeeper-1.18.21/doc/forum/__39__git_commit__39___vs___39__etckeeper_commit__39__.mdwn000066400000000000000000000006001453142634200305210ustar00rootroot00000000000000In the readme documentation for etckeeper, after the initial `etckeeper init` all commands are run using git (eg `git commit` or `git status`). Before finding the readme, I read several tutorials, DigitalOcean has one, that uses etckeeper instead (eg `etckeeper commit` or `etckeeper vcs status`). Do these pretty much do the same thing or should one be used over the other? Thanks! etckeeper-1.18.21/doc/forum/__39__git_commit__39___vs___39__etckeeper_commit__39__/000077500000000000000000000000001453142634200276365ustar00rootroot00000000000000comment_1_2e638229f7460b34ded7d5dec9f24ef6._comment000066400000000000000000000003171453142634200377300ustar00rootroot00000000000000etckeeper-1.18.21/doc/forum/__39__git_commit__39___vs___39__etckeeper_commit__39__[[!comment format=mdwn username="joey" subject="""comment 1""" date="2020-04-24T16:30:32Z" content=""" `etckeeper commit` adds any new files, and records any changes to file permissions or owners. """]] etckeeper-1.18.21/doc/forum/can_etckeeper_track_selinux_contexts__63__.mdwn000066400000000000000000000005611453142634200270440ustar00rootroot00000000000000Would it be possible to extend etckeeper to track SELinux contexts the same way it does user/group ownership and permissions? These are stored in the security.selinux xattr, so seems like some 'setfattr' calls to restore them could easily be part of the /etc/.etckeeper file. Also, etckeeper could set the SELinux context for /etc/.git, the same way it does chmod 700. etckeeper-1.18.21/doc/forum/check__95__root_test_does_not_work_in_user__95__namespaces.mdwn000066400000000000000000000006021453142634200321050ustar00rootroot00000000000000when building etckeeper in void linux, which uses user_namespaces(7) to chroot, the tests 8 (and sometimes 7) fail. see https://github.com/void-linux/void-packages/pull/42192 and https://github.com/void-linux/void-packages#chroot-methods this is (likely) due to the check_root test not detecting that the build is performed inside a chroot. any suggestion how one could improve that? etckeeper-1.18.21/doc/forum/etckeeper_doesnt_play_well_with_twoversion_control_systems.mdwn000066400000000000000000000007601453142634200327020ustar00rootroot00000000000000I use etc keeper with git, and some etc files are simultaneous manually managed with RCS (mainly historic reasons) etckeeper wants to checkin the ,v RCS repository files. Shouldnt "RCS/*,v" or something be the default in .gitignore Or more generally, should it ignore repo files for *all* vc systems not just the one its using? Where would I make this change locally to fix this, so it applies to all directories and version control systems? Right now Ive just amended the git ignore file etckeeper-1.18.21/doc/forum/etckeeper_doesnt_play_well_with_twoversion_control_systems/000077500000000000000000000000001453142634200320105ustar00rootroot00000000000000comment_1_ff9b3387ee900ebe609ecba89b28e7c8._comment000066400000000000000000000005071453142634200422500ustar00rootroot00000000000000etckeeper-1.18.21/doc/forum/etckeeper_doesnt_play_well_with_twoversion_control_systems[[!comment format=mdwn username="joey" subject="""comment 1""" date="2020-11-23T16:33:13Z" content=""" I think this is an unusual configuration, and it would be very clunky to need to keep track of every file that might need to be ignored for every VCS. Editing the .gitignore seems like the right solution for you. """]] etckeeper-1.18.21/doc/forum/etckeeper_failed_to_commit_changes_in___47__etc_using_git.mdwn000066400000000000000000000022021453142634200317740ustar00rootroot00000000000000Hello, I am having issues with etckeeper, failing to commit changes: Changes not staged for commit: (use "git add ..." to update what will be committed) (use "git restore ..." to discard changes in working directory) (commit or discard the untracked or modified content in submodules) modified: letsencrypt/letsencrypt-autoupdater (modified content) no changes added to commit (use "git add" and/or "git commit -a") warning: etckeeper failed to commit changes in /etc using git (Reading database ... 206470 files and directories currently installed.) Removing knxd-build-deps (0.14.42-1) ... On branch master Changes not staged for commit: (use "git add ..." to update what will be committed) (use "git restore ..." to discard changes in working directory) (commit or discard the untracked or modified content in submodules) modified: letsencrypt/letsencrypt-autoupdater (modified content) no changes added to commit (use "git add" and/or "git commit -a") I did try a git add letsencrypt/letsencrypt-autoupdater and git commit -a with no effect. Can you tell me, how to fix this? Regards, Hendrik etckeeper-1.18.21/doc/forum/etckeeper_for_arbitrary_directories__63__.mdwn000066400000000000000000000034001453142634200266550ustar00rootroot00000000000000I have some files outside of /etc I want to track (/usr/local/bin/*, /usr/lib/systemd/*, /boot/loader/entries/*). I suppose the `-d` option lets you use repos for arbitrary directories, but I would like to keep everything outside of $HOME in one repo as a opposed to a separate repo for /usr/local/bin, /usr/lib/systemd, etc. as they are all related system files. [This suggestion](https://serverfault.com/a/858674) suggests a `etckeeper init -d /` will work (and presumably ignore everything but those files in directories above, via gitignore) but when I do that, I run out of disk space (the resulting `/.git` repo is 7.9GB+ until my disk runs out of space. If I do a `git init /` instead, there's no issues. I suppose the issue is `etckeeper init` automatically adds all files to the index, resulting in the repo taking up a large amount of space that is proportional to `/`? Is it possible to make `/` a repo ignoring all files except those in the directories above along with etc? Things like `.gitignore` and `showUntrackedFiles = no` cannot be applied when `etckeeper init -d /` cannot set up the repo due to lack of space. P.S. A [workaround](https://serverfault.com/a/293081) is a hook that copies files outside of `/etc` into the `/etc` repo (presumably as a pre-commit hook?) so that they can be tracked. Another hook (assuming it's possible? It wasn't mentioned in that thread but something is needed. Otherwise, a wrapper script) would copy those files back to the appropriate location. This is satisfactory, but duplicate files involved is not ideal. Any suggestions is much appreciated. etckeeper seems appropriate for my uses because it looks to be a simple git wrapper that preserves metadata (ownership, permissions, etc.) and offers package management integration. etckeeper-1.18.21/doc/forum/etckeeper_for_arbitrary_directories__63__/000077500000000000000000000000001453142634200257715ustar00rootroot00000000000000comment_1_279cbf0d45b2091ea258ddd645240d5c._comment000066400000000000000000000014031453142634200357460ustar00rootroot00000000000000etckeeper-1.18.21/doc/forum/etckeeper_for_arbitrary_directories__63__[[!comment format=mdwn username="joey" subject="""comment 1""" date="2021-11-19T19:31:21Z" content=""" I choose not to grow etckeeper in this direction, because focus is important: etckeeper needs to be as good as possible at version controlling /etc, even if that means choices that don't make any sense for version controlling another directory. If you're going to version control a whole system, or some subset of it, you have a number of hard problems to solve. etckeeper solves probably none of them, except for the solution of "let's only version control /etc and so those other problems are not our problems". So it is not a useful starting point to do that, probably. If it somehow is a useful starting point to that, forking it would be appropriate. """]] etckeeper_uses_git_despite_VCS__61____34__hg__34___when_a___47__etc__47__.git_directory_exists.mdwn000066400000000000000000000031051453142634200401730ustar00rootroot00000000000000etckeeper-1.18.21/doc/forum#Setup etckeeper version: * `etckeeper/stable,stable,now 1.18.16-1 all [residual-config]` Environment: * `Linux Debian-1101-bullseye-amd64-base 5.10.0-9-amd64` Installed via `apt install etckeeper` on _Debian 11 Bullseye_, so using Debian's [https://packages.debian.org/bullseye/etckeeper](https://packages.debian.org/bullseye/etckeeper). In case only downstream Debian is the culprit, sorry for reporting here and not downstream - but Debian's bugtracker is so awful to use ... # Issue Despite `/etc/etckeeper/etckeeper.conf` being configured with `VCS="hg"`, the moment a git directory `/etc/.git/` (and/or file `/etc/.gitignore`?) exists, _etckeeper_ will use git (and e.g. `.gitignore` instead of `.hgignore`). Maybe this issue is not limited to Mercurial/hg only, but affects any other VCS (mercurial, bazaar, or darcs) as well. # My scenario I noticed this issue as I wanted to set up _etckeeper_ with Mercurial while still being able to use my own git-managed `/etc` hierarchy in parallel: use _etckeeper_ to version/backup all `/etc` files and at the same time have an additional git repository for cherry-picked etc files: _etckeeper_ tracks all files including my custom `conf.d/` etc files and package-provided vanilla files; my additional git repository only tracks my custom `conf.d/` etc files. Unfortunately, [it's not possible to have two git repositories in the same directory (here `/etc`) due to a git repository's `.gitignore` location not being configurable](https://stackoverflow.com/a/17313342/923560), hence my unsuccessful workaround with _etckeeper_ to use hg/Mercurial. etckeeper_uses_git_despite_VCS__61____34__hg__34___when_a___47__etc__47__.git_directory_exists/000077500000000000000000000000001453142634200373055ustar00rootroot00000000000000etckeeper-1.18.21/doc/forumcomment_1_167ca2ab91c1e4b969ba58f532528a82._comment000066400000000000000000000010621453142634200472720ustar00rootroot00000000000000etckeeper-1.18.21/doc/forum/etckeeper_uses_git_despite_VCS__61____34__hg__34___when_a___47__etc__47__.git_directory_exists[[!comment format=mdwn username="joey" subject="""comment 1""" date="2022-01-07T15:09:03Z" content=""" We can see why right in /usr/bin/etckeeper: if [ -d ".git" ]; then VCS=git elif [ -d ".hg" ]; then VCS=hg elif [ -d "_darcs" ]; then VCS=darcs elif [ -d ".bzr" ]; then VCS=bzr fi So the VCS config is only used to control what `etckeeper init` does. See also this todo item about it, with more discussion: [[todo/doc/todo/Give_preference_to_etckeeper.conf_over_existing_repository_for_defining___36__VCS]] """]] comment_2_d1d40ba983bdf52502c53c13f8f73919._comment000066400000000000000000000026241453142634200472770ustar00rootroot00000000000000etckeeper-1.18.21/doc/forum/etckeeper_uses_git_despite_VCS__61____34__hg__34___when_a___47__etc__47__.git_directory_exists[[!comment format=mdwn username="Abdull" avatar="http://cdn.libravatar.org/avatar/739dfa7b7b4580406c6e45fc8b3e3520" subject="comment 2" date="2022-01-11T11:56:28Z" content=""" Thank your for the info, I found your mentioned TODO at *[[todo/Give preference to etckeeper.conf over existing repository for defining $VCS]]*. I was able to accomplish my scenario (one personal git repository with cherry-picked selected configuration files in one repository AND using etckeeper as well) with the following workaround setup: * Set up my personal git repository at the root filesystem location `/`. * Configure etckeeper to use mercurial/hg. I noticed that (at least in Debian 11.2 bullseye) `apt install etckeeper` automatically runs `etckeeper init`, thereby setting up a **git**-based etckeeper according to the [default `etckeeper.conf` file](https://git.joeyh.name/index.cgi/etckeeper.git/tree/etckeeper.conf?h=debian&id=e2efb7797cfc0a6b366a9db01d37f685ccf04e22) - but I want **hg**. I looked around, but there doesn't currently seem to be a way (e.g. *debconf*) to configure etckeeper at *pre-installation time* to use hg other than [having an appropriate `/etc/etckeeper/etckeeper.conf` file in place before running `apt install etckeeper`](https://git.joeyh.name/index.cgi/etckeeper.git/tree/debian/postinst?h=debian&id=e2efb7797cfc0a6b366a9db01d37f685ccf04e22#n80). Or is there? Thanks for your help! """]] etckeeper-1.18.21/doc/forum/etckeeper_wants_root_git_identity.mdwn000066400000000000000000000020171453142634200254250ustar00rootroot00000000000000I've installed etckeeper & git on a new machine running arch. I've got sudo and git setup for my regular user. When I `sudo etckeeper commit "Initial commit"` git gives me the usual message about empty ident name for root@host. Documentation suggests that sudo will grab the ident of sudo user but that doesn't seem to be working. I'm running etckeeper 1.18.12-1. What am I missing? --- [[!comment format=mdwn username="https://peterjmello.wordpress.com/" nickname="RogueScholar" date="2020-01-10T19:22:30-0800" content=""" One possible solution to your issue would be to edit `/etc/etckeeper/etckeeper.conf` and change the VCS variable value to include the location of your gitconfig file. Assuming yours is in the default location of `~/.gitconfig` that would mean changing it from `VCS="git"` to `VCS="git -f /home//.gitconfig"` (be sure to use the canonical path to the file rather than relying on the `~` alias for your home directory because in this instance ~ points to `/root`). -Peter """ ]] >[[!fortune ]] etckeeper-1.18.21/doc/forum/etckeeper_wants_root_git_identity/000077500000000000000000000000001453142634200245365ustar00rootroot00000000000000comment_1_b7f0c09b843edebfa06117c660b8a9d3._comment000066400000000000000000000006041453142634200346570ustar00rootroot00000000000000etckeeper-1.18.21/doc/forum/etckeeper_wants_root_git_identity[[!comment format=mdwn username="joey" subject="""comment 1""" date="2020-05-05T18:36:14Z" content=""" I don't know. The code that does it is in /etc/etckeeper/commit.d/50vcs-commit AFAICS, unless sudo does not set `SUDO_USER` (which it usually does) or "whoami" does not output a username, that code *always* sets `GIT_AUTHOR_NAME` etc, which avoid git failing in that way. """]] comment_2_9042f537f95e45e35aba9fa37459e2ee._comment000066400000000000000000000042311453142634200345500ustar00rootroot00000000000000etckeeper-1.18.21/doc/forum/etckeeper_wants_root_git_identity[[!comment format=mdwn username="psydev" avatar="http://cdn.libravatar.org/avatar/b841d7f8d20a92d96cb4e6407f7ac7a1" subject="comment 2" date="2020-05-10T09:46:37Z" content=""" I've hit the same issue, it seems to be due to `50vcs-commit` not setting `GIT_COMMITTER_NAME`. I've fixed it with the following patch: > --- /home/psydev/Documents/50vcs-commit.orig 2020-05-10 11:24:46.678103463 +0200 > +++ /etc/etckeeper/commit.d/50vcs-commit 2020-05-10 11:19:26.710380696 +0200 > @@ -54,22 +54,26 @@ > if [ -n \"$USER_HOME\" ] && [ -e \"$USER_HOME/.gitconfig\" ]; then > if [ -z \"$GIT_AUTHOR_NAME\" ]; then > GIT_AUTHOR_NAME=\"$(git config -f \"$USER_HOME/.gitconfig\" user.name)\" || true > - export GIT_AUTHOR_NAME > + GIT_COMMITTER_NAME=\"$GIT_AUTHOR_NAME\" > + export GIT_AUTHOR_NAME GIT_COMMITTER_NAME > fi > if [ -z \"$GIT_AUTHOR_EMAIL\" ]; then > GIT_AUTHOR_EMAIL=\"$(git config -f \"$USER_HOME/.gitconfig\" user.email)\" || true > - export GIT_AUTHOR_EMAIL > + GIT_COMMITTER_EMAIL=\"$GIT_AUTHOR_EMAIL\" > + export GIT_AUTHOR_EMAIL GIT_COMMITTER_EMAIL > fi > fi > if [ -z \"$GIT_AUTHOR_NAME\" ] || [ -z \"$GIT_AUTHOR_EMAIL\" ]; then > if [ -n \"$USER_HOME\" ] && [ -e \"$USER_HOME/.config/git/config\" ]; then > if [ -z \"$GIT_AUTHOR_NAME\" ]; then > GIT_AUTHOR_NAME=\"$(git config -f \"$USER_HOME/.config/git/config\" user.name)\" || true > - export GIT_AUTHOR_NAME > + GIT_COMMITTER_NAME=\"$GIT_AUTHOR_NAME\" > + export GIT_AUTHOR_NAME GIT_COMMITTER_NAME > fi > if [ -z \"$GIT_AUTHOR_EMAIL\" ]; then > GIT_AUTHOR_EMAIL=\"$(git config -f \"$USER_HOME/.config/git/config\" user.email)\" || true > - export GIT_AUTHOR_EMAIL > + GIT_COMMITTER_EMAIL=\"$GIT_AUTHOR_EMAIL\" > + export GIT_AUTHOR_EMAIL GIT_COMMITTER_EMAIL > fi > fi > fi The formatting rules on this wiki gave me more trouble than the fix though... ;) Where/how can I contribute this? I've seen multiple github repos, can the author point me to the correct place? Thanks """]] comment_3_88c973d26858bec68055fcd3d35268d6._comment000066400000000000000000000002521453142634200344230ustar00rootroot00000000000000etckeeper-1.18.21/doc/forum/etckeeper_wants_root_git_identity[[!comment format=mdwn username="joey" subject="""comment 3""" date="2020-08-10T21:27:43Z" content=""" [[install]] says where the git repo is. (Not on github.) """]] etckeeper-1.18.21/doc/forum/etckeeper_without_perl_and_files_with_spaces.mdwn000066400000000000000000000003641453142634200275770ustar00rootroot00000000000000Etckeeper fails to commit files with spaces in the non `Perl` implementation of `maybe_chmod_chown()` I have prepared a fix for this here: https://gitlab.com/HRio/etckeeper/-/commits/fix-whitespace Joey can you have a look? Thanks, Henrik etckeeper-1.18.21/doc/forum/etckeeper_without_perl_and_files_with_spaces/000077500000000000000000000000001453142634200267055ustar00rootroot00000000000000comment_1_690145504a22c701f7f0a707526577a6._comment000066400000000000000000000002241453142634200362230ustar00rootroot00000000000000etckeeper-1.18.21/doc/forum/etckeeper_without_perl_and_files_with_spaces[[!comment format=mdwn username="joey" subject="""comment 1""" date="2022-01-07T15:02:29Z" content=""" I've applied the patch. Thank you. """]] etckeeper-1.18.21/doc/forum/git_gc___40__garbage_collection__41___message_triggers_Anacron_mail.mdwn000066400000000000000000000013321453142634200335170ustar00rootroot00000000000000Hi there, I'm using etckeeper 1.18.17 on Ubuntu kinetic (22.10). Every few days (roughly 4-8 days, the exact frequency varies, probably depending on how much I change in /etc) I get a mail from Anacron that has the following content: ``` /etc/cron.daily/etckeeper: Auto packing the repository in background for optimum performance. See "git help gc" for manual housekeeping. ``` I guess the automatic garbage collection of git is executed, which prints this unimportant bit of information to stdout, thus triggering an e-mail by Anacron. Since there is no actual problem, we should suppress this output, so that no mail will be sent. One idea would be to just run 'git gc --auto' on a daily basis, I guess? Cheers, Patrick. etckeeper-1.18.21/doc/forum/git_gc___40__garbage_collection__41___message_triggers_Anacron_mail/000077500000000000000000000000001453142634200326315ustar00rootroot00000000000000comment_1_16b78a25b142a7b9f8cfc52e584a3a22._comment000066400000000000000000000004741453142634200426170ustar00rootroot00000000000000etckeeper-1.18.21/doc/forum/git_gc___40__garbage_collection__41___message_triggers_Anacron_mail[[!comment format=mdwn username="joey" subject="""comment 1""" date="2023-04-21T16:10:58Z" content=""" `etckeeper commit` is what the cron job runs. That does not run `git gc`. I don't think a git commit triggers a gc either, normmally. Have you perhaps added a hook or something that causes the git gc? """]] etckeeper-1.18.21/doc/forum/intended_behavior_of_the_sudo_integration__63__.mdwn000066400000000000000000000005461453142634200300270ustar00rootroot00000000000000I noticed that with the `sudo` integration, the author will be set to the administrator. However, the commiter is still using the automatically-generated email address for root user. The issue is that I still need to set the full name for that “user”. How about also generating its full name? Or simply use the administrator as both author and commiter? etckeeper-1.18.21/doc/forum/intended_behavior_of_the_sudo_integration__63__/000077500000000000000000000000001453142634200271335ustar00rootroot00000000000000comment_1_a610753a92db835cdeaf3b870b7c72a5._comment000066400000000000000000000007451453142634200372010ustar00rootroot00000000000000etckeeper-1.18.21/doc/forum/intended_behavior_of_the_sudo_integration__63__[[!comment format=mdwn username="joey" subject="""comment 1""" date="2023-04-21T15:53:20Z" content=""" When user.email is not set in the global git config, etckeeper sets `GIT_COMMITTER_EMAIL` to `whoami`"@$hostname" Where $hostname is `hostname` with `dnsdomainname` added as the domain if that outputs anything. It's possible etckeeper could be improved, but I don't have a sufficiently broken system to see it fail, so patches or further analysis would be up to you. """]] etckeeper-1.18.21/doc/forum/move_git_directory_elsewhere__63__.mdwn000066400000000000000000000006371453142634200253360ustar00rootroot00000000000000To increase the reliability of our system (it has daily power outages), we've made the root partition read-only, and only make it writable when we're making a change. Etckeeper doesn't like it if /etc is read-only, and generates daily emails to root about it. One idea is to move /etc/.git to /var/etckeeper/.git and create a symlink in its place; would it work, or is git fussy about that sort of thing? Thanks etckeeper-1.18.21/doc/forum/move_git_directory_elsewhere__63__/000077500000000000000000000000001453142634200244415ustar00rootroot00000000000000comment_1_1a4787f587c13ec0ce7f59ff52a8ce66._comment000066400000000000000000000006741453142634200345450ustar00rootroot00000000000000etckeeper-1.18.21/doc/forum/move_git_directory_elsewhere__63__[[!comment format=mdwn username="ch-and-etckeeper.branchable.com@6e0ad263d7466ea3783deb474298632f286b1e3e" nickname="ch-and-etckeeper.branchable.com" avatar="http://cdn.libravatar.org/avatar/72e56d8e90557a374d5c1907319b48fc" subject="Yes, it works" date="2023-06-27T18:26:39Z" content=""" It works! In hindsight, I probably just should have tested it instead of bothering to ask the question, but hey, now you know the answer too! """]] etckeeper-1.18.21/doc/forum/openbsd_find_lacks_-printf.mdwn000066400000000000000000000011031453142634200236640ustar00rootroot00000000000000OpenBSD find does not have `-printf` which is used in `/etc/etckeeper/commit.d/50vcs-commit` to figure out who is running the command: # uname -a OpenBSD myhost 6.9 GENERIC.MP#473 amd64 # etckeeper commit find: -printf: unknown option I replaced `USER="$(find "$TTY" -printf "%u")"` with `USER=dunno` as this makes it work. OpenBSD has perl in its base so: perl -MFile::stat -E "my \$st = stat(\"$TTY\"); say( (getpwuid(\$st->uid))[0] )"; or perl -MFile::stat -E "my \$st = stat(qq{$TTY}); say( (getpwuid(\$st->uid))[0] )"; would work. -- cstamas etckeeper-1.18.21/doc/forum/path_contains_illegal_component.mdwn000066400000000000000000000017351453142634200250360ustar00rootroot00000000000000After upgrading one of my servers from Ubuntu 16.04 to 18.04, I started to receive error messages from the etckeeper cron.daily job. /etc/cron.daily/etckeeper: abort: path contains illegal component: .hg/undo.dirstate abort: path contains illegal component: .hg/undo.backup.dirstate Note that I use mercurial for etckeeper. (I use hg in preference to git wherever I have the option.) A search for the error message showed some very old error associated with hg. I attempted to install a more recent version of hg from a ppa repository, but I don't think that was successful. (I can't be more definite than that.) At any rate, the apt version of hg is 4.5.3-1ubuntu2.1 I eventually upgraded hg using pip install, and I now have 5.5.2 and that seems to have fixed the problem. I spoke too soon. For testing purposes, I moved cron.daily/etckeeper to cron.hourly. The error does not occur every hour, so there is some dependency on the path taken through the various etckeeper scripts. etckeeper-1.18.21/doc/forum/path_contains_illegal_component/000077500000000000000000000000001453142634200241415ustar00rootroot00000000000000comment_1_592f81618dde9f37c45ab7b0dd6baa8f._comment000066400000000000000000000011471453142634200343650ustar00rootroot00000000000000etckeeper-1.18.21/doc/forum/path_contains_illegal_component[[!comment format=mdwn username="etckeep@4f7bb5e4e71942aea2d70a344bc1ffc3d17e33b8" nickname="etckeep" avatar="http://cdn.libravatar.org/avatar/bedda0cf35898e15636d0f594ef83335" subject="Cannot version files in .hg directory" date="2020-10-12T00:01:30Z" content=""" There is a setting in /etc/etckeepeer.conf like so: # Uncomment the following to avoid special file warning # (the option is enabled automatically for daily autocommits regardless). AVOID_SPECIAL_FILE_WARNING=1 It is commented out by default because of the automatic enabling, but I have enabled it to see wheterh it makes a difference. """]] etckeeper-1.18.21/doc/forum/systemd__39__s___47__etc__47__.updated_should_be_ignored.mdwn000066400000000000000000000002541453142634200312000ustar00rootroot00000000000000systemd updates the /etc/.updated file with new timestamps frequently. This file should be ignored by etckeeper. Didn't find where to post bug reports except this forum. etckeeper-1.18.21/doc/forum/systemd__39__s___47__etc__47__.updated_should_be_ignored/000077500000000000000000000000001453142634200303105ustar00rootroot00000000000000comment_1_6af78141f196ceb20de7eab613726797._comment000066400000000000000000000011071453142634200402300ustar00rootroot00000000000000etckeeper-1.18.21/doc/forum/systemd__39__s___47__etc__47__.updated_should_be_ignored[[!comment format=mdwn username="joey" subject="""comment 1""" date="2021-11-19T19:39:01Z" content=""" It seems systemd-update-done writes the file , but on my Debian system that service is not included. It's only needed for a factory reset kind of feature, which probably does not make sense to include in many linux distributions. I'm not sure if it necessarily makes sense to avoid it in all cases. If systemd is depending on that state for something it might make sense to restore it. """]] etckeeper-1.18.21/doc/forum/yum_stuck_with___39__etckeeper:_pre_transaction_commit__39__.mdwn000066400000000000000000000017241453142634200323710ustar00rootroot00000000000000Whenever I try to install something on CentOS (release 7.8.2003, installed via epel) etckeeper pre/auto commit ll get stuck mostly on pre commit. I also got one server where post commit fails me, but on there one I can just abort the command. ``` Transaction Summary =================================================================================================================================================================== Upgrade 11 Packages Total size: 835 M Downloading packages: Running transaction check Running transaction test Transaction test succeeded Running transaction etckeeper: pre transaction commit ^[[A^[[A^ ``` ``` yum-3.4.3-167.el7.centos.noarch yum-utils-1.1.31-54.el7_8.noarch yum-plugin-fastestmirror-1.1.31-54.el7_8.noarch yum-metadata-parser-1.1.4-10.el7.x86_64 etckeeper-1.18.14-1.el7.noarch git-1.8.3.1-23.el7_8.x86_64 ``` For now, the workaround is to disable the yum-plugin with the config file /etc/yum/pluginconf.d/etckeeper.conf etckeeper-1.18.21/doc/forum/yum_stuck_with___39__etckeeper:_pre_transaction_commit__39__/000077500000000000000000000000001453142634200314765ustar00rootroot00000000000000comment_1_070706c7c067a87ca3610af59e0ff169._comment000066400000000000000000000007711453142634200413320ustar00rootroot00000000000000etckeeper-1.18.21/doc/forum/yum_stuck_with___39__etckeeper:_pre_transaction_commit__39__[[!comment format=mdwn username="joey" subject="""comment 1""" date="2020-11-23T16:35:34Z" content=""" I suggest you talk to the distribution maintainers about the problem, since etckeeper is included in centos, this is certianly an integration bug there, and one they should be well suited to dealing with. Even if it ought to be eventually fixed in etckeeper itself. (Jimmy Tang wrote the yum integration, but it was so long ago that I doubt trying to get in touch with him would be useful.) """]] etckeeper-1.18.21/doc/index.mdwn000066400000000000000000000016071453142634200164060ustar00rootroot00000000000000etckeeper is a collection of tools to let `/etc` be stored in a git, mercurial, bazaar or darcs repository. This lets you use git to review or revert changes that were made to `/etc`. Or even push the repository elsewhere for backups or cherry-picking configuration changes. It hooks into package managers like apt to automatically commit changes made to /etc during package upgrades. It tracks file metadata that git does not normally support, but that is important for /etc, such as the permissions of `/etc/shadow`. It's quite modular and configurable, while also being simple to use if you understand the basics of working with version control. [[!sidebar content=""" [[README]] [[Install]] [[News]] [[Todo]] [[Forum]] """]] etckeeper-1.18.21/doc/install.mdwn000066400000000000000000000007531453142634200167460ustar00rootroot00000000000000etckeeper is available in git at `git://git.joeyh.name/etckeeper`, or [in gitweb](https://git.joeyh.name/index.cgi/etckeeper.git). It's packaged in Debian, Ubuntu, Fedora, etc. Or, you can install it by hand. Before running 'make install', you should edit etckeeper.conf and make sure it configured appropriately for your distribution. Distribution packagers may find it more convenient to set CONFFILE to point to a different etckeeper.conf that is preconfigured for your distribution. etckeeper-1.18.21/doc/news.mdwn000066400000000000000000000000671453142634200162520ustar00rootroot00000000000000[[!inline pages="news/* and !*/Discussion" show="3"]] etckeeper-1.18.21/doc/news/000077500000000000000000000000001453142634200153605ustar00rootroot00000000000000etckeeper-1.18.21/doc/news/new_web_site.mdwn000066400000000000000000000000641453142634200207210ustar00rootroot00000000000000Finally set up a standalone website for etckeeper.. etckeeper-1.18.21/doc/news/version_1.18.16.mdwn000066400000000000000000000003731453142634200206330ustar00rootroot00000000000000etckeeper 1.18.16 released with [[!toggle text="these changes"]] [[!toggleable text=""" * Improve sorting stability. * Prefer mktemp over tempfile as the latter displays a deprecation warning since debianutils 4.10. Thanks, Luke Mlsna."""]]etckeeper-1.18.21/doc/news/version_1.18.17.mdwn000066400000000000000000000006601453142634200206330ustar00rootroot00000000000000etckeeper 1.18.17 released with [[!toggle text="these changes"]] [[!toggleable text=""" * Fix committing of files with spaces in name when perl is not available. Thanks, Henrik Riomar * Ignore udev's FHS violating large binary cache file /etc/udev/hwdb.bin * Avoid warning messages from grep about binary files when there are filenames in /etc that do not correspond to the current locale settings. Thanks, thm"""]]etckeeper-1.18.21/doc/news/version_1.18.18.mdwn000066400000000000000000000003541453142634200206340ustar00rootroot00000000000000etckeeper 1.18.18 released with [[!toggle text="these changes"]] [[!toggleable text=""" * Replace deprecated egrep with grep -E. Thanks, Sam James * Added support for Void Linux's xbps package manager. Thanks, Zev Weiss."""]]etckeeper-1.18.21/doc/news/version_1.18.19.mdwn000066400000000000000000000007201453142634200206320ustar00rootroot00000000000000etckeeper 1.18.19 released with [[!toggle text="these changes"]] [[!toggleable text=""" * Added support for Gentoo (emerge, qlist, and cave) Thanks, Sam James * Skip running pre-commit hook inside linked worktrees, to avoid it updating .etckeeper with the permissions of files not in /etc. Thanks, Håkon Løvdal * commit: Run bzr with --quiet, since it outputs non-errors to stderr. Closes: #[1018874](http://bugs.debian.org/1018874)"""]]etckeeper-1.18.21/doc/news/version_1.18.20.mdwn000066400000000000000000000002611453142634200206220ustar00rootroot00000000000000etckeeper 1.18.20 released with [[!toggle text="these changes"]] [[!toggleable text=""" * Fix a reversion in etckeeper init in version 1.18.19. Thanks, Georgy Yakovlev"""]]etckeeper-1.18.21/doc/todo.mdwn000066400000000000000000000004651453142634200162450ustar00rootroot00000000000000This is etckeeper's todo list, for both posting feature requests, and merge requests. Link items to [[todo/done]] when done. See also: [Debian BTS](http://bugs.debian.org/etckeeper). [[!inline pages="./todo/* and !./todo/done and !link(done) and !*/Discussion" actions=yes postform=yes show=0 archive=yes]] etckeeper-1.18.21/doc/todo/000077500000000000000000000000001453142634200153515ustar00rootroot00000000000000etckeeper-1.18.21/doc/todo/.mdwn000066400000000000000000000001471453142634200163210ustar00rootroot00000000000000fixed typo in README https://github.com/Yky/etckeeper/commit/5f2556abbc404eb0d06b31f620fe655c8802d8e7 etckeeper-1.18.21/doc/todo/30store-metadata_stores_metadata_for_untracked_files.mdwn000066400000000000000000000007361453142634200306520ustar00rootroot00000000000000I am trying to use etckeeper to track `/` (We need to track /etc and also /unionfs/overlay/etc, which is an etc that gets loaded onto a second computer). `git ls-files` lists only the files we want to track, and `.gitignore` correctly excludes all the files we don't want to match (such as `./home`, `./proc`, ), yet somehow `.etckeeper` contains metadata for a bunch of files that I don't want etckeeper to touch. > [[done]] not a supported way to use etckeeper. --[[Joey]] etckeeper-1.18.21/doc/todo/30store-metadata_stores_metadata_for_untracked_files/000077500000000000000000000000001453142634200277555ustar00rootroot00000000000000comment_1_c928791835e1d53cc42088ef6574e24c._comment000066400000000000000000000013671453142634200375550ustar00rootroot00000000000000etckeeper-1.18.21/doc/todo/30store-metadata_stores_metadata_for_untracked_files[[!comment format=mdwn username="joey" subject="""comment 1""" date="2020-05-05T19:36:16Z" content=""" I don't support using etckeeper to version control stuff other than /etc. 30store-metadata gets a list of all fils git is configured to ignore, and then runs a find and uses grep to exclude files in that list. I've verified this seems to work ok when etckeeper is used the usual way in /etc. Something about the non-supported way you're using etckeeper must be causing the problem. Perhaps git ls-files -oi --exclude-standard when run in / somehow doesn't list every single file in your entire computer, for whatever reason. When I tried putting a git repo in /.git/ and running that, it hung for a long time. Sorry, I'm going to close this. """]] etckeeper-1.18.21/doc/todo/50vcs-commit:_add_double_quotes_around_options.mdwn000066400000000000000000000056101453142634200274470ustar00rootroot00000000000000I'm using Arch Linux, and the version number of etckeeper is 1.18.20-2. Background information: I utilize GitHub to automatically push my /etc directory to a repository. However, when etckeeper uses my GitHub account's git author information, it affects the contribution graph. Unfortunately, GitHub doesn't offer an option to exclude a single repository from the contribution graph. As a result, I decided to modify the git author. Modifying the code directly is not considered good practice. Instead, I chose to modify the `/etc/etckeeper/etckeeper.conf` file. After the modification, the configuration looks like this: `GIT_COMMIT_OPTIONS="--author=\"username \""` When I execute the `etckeeper commit` command, it displays the following error: `fatal: --author '"username' is not 'Name ' and matches no existing author` Upon inspecting the code, I discovered that the commit.d/50vcs-commit script requires fixing. Specifically, double quotes need to be added around $GIT_COMMIT_OPTIONS. After including the double quotes, etckeeper functions as expected. I applied the same modification to $HG_COMMIT_OPTIONS, $BZR_COMMIT_OPTIONS, and $DARCS_COMMIT_OPTIONS. The resulting patch is provided below: ``` diff --git a/commit.d/50vcs-commit b/commit.d/50vcs-commit index a76eb7e..8ac8581 100755 --- a/commit.d/50vcs-commit +++ b/commit.d/50vcs-commit @@ -109,9 +109,9 @@ if [ "$VCS" = git ] && [ -d .git ]; then fi if [ -n "$logfile" ]; then - git $GIT_GC_OPTIONS commit $GIT_COMMIT_OPTIONS -F "$logfile" + git $GIT_GC_OPTIONS commit "$GIT_COMMIT_OPTIONS" -F "$logfile" else - git $GIT_GC_OPTIONS commit $GIT_COMMIT_OPTIONS + git $GIT_GC_OPTIONS commit "$GIT_COMMIT_OPTIONS" fi elif [ "$VCS" = hg ] && [ -d .hg ]; then if [ -n "$USER" ]; then @@ -123,9 +123,9 @@ elif [ "$VCS" = hg ] && [ -d .hg ]; then export HGUSER fi if [ -n "$logfile" ]; then - hg commit $HG_COMMIT_OPTIONS -l "$logfile" + hg commit "$HG_COMMIT_OPTIONS" -l "$logfile" else - hg commit $HG_COMMIT_OPTIONS + hg commit "$HG_COMMIT_OPTIONS" fi elif [ "$VCS" = bzr ] && [ -d .bzr ]; then if [ -z "$EMAIL" ] && [ -n "$USER" ]; then @@ -135,17 +135,17 @@ elif [ "$VCS" = bzr ] && [ -d .bzr ]; then bzr whoami >/dev/null 2>&1 || export EMAIL="$ORIG_USER <$ORIG_USER@$hostname>" fi if [ -n "$logfile" ]; then - bzr commit $BZR_COMMIT_OPTIONS -F "$logfile" + bzr commit "$BZR_COMMIT_OPTIONS" -F "$logfile" else - bzr commit --quiet $BZR_COMMIT_OPTIONS + bzr commit --quiet "$BZR_COMMIT_OPTIONS" fi elif [ "$VCS" = darcs ] && [ -d _darcs ]; then if [ -z "$USER" ]; then USER=root fi if [ -n "$logfile" ]; then - darcs record --author="$USER" $DARCS_COMMIT_OPTIONS --logfile="$logfile" + darcs record --author="$USER" "$DARCS_COMMIT_OPTIONS" --logfile="$logfile" else - darcs record --author="$USER" $DARCS_COMMIT_OPTIONS + darcs record --author="$USER" "$DARCS_COMMIT_OPTIONS" fi fi ``` etckeeper-1.18.21/doc/todo/50vcs-commit:_add_double_quotes_around_options/000077500000000000000000000000001453142634200265565ustar00rootroot00000000000000comment_1_bece365157ae43694c251ff7866f62f0._comment000066400000000000000000000003451453142634200365050ustar00rootroot00000000000000etckeeper-1.18.21/doc/todo/50vcs-commit:_add_double_quotes_around_options[[!comment format=mdwn username="joey" subject="""comment 1""" date="2023-06-13T15:01:39Z" content=""" Wouldn't this break providing multiple space-seperated options in `GIT_COMMIT_OPTIONS`, when it previously worked? """]] etckeeper-1.18.21/doc/todo/Adding_support_for_.hgignore.mdwn000066400000000000000000000154471453142634200240430ustar00rootroot00000000000000Hi, I wrote emails and a bugreport for this issue but never got an answer... Currently eetckeeper does ignore the .hgignore file. My workflow is like this: I have a hgignore to ignore everything and adding files explicitly. There are also exceptions from that where I want to track for new files: Ignoring everyhing would be: syntax: glob ** With exceptions: syntax: regexp # Ignore anything in root folder but include .hgignore and special folders: #^(?!.hgignore|data|DATA|NFS|usr(/local(/lib(/site_perl|$)|$)|$)|etc(/init.d(/*.sh$|$)|$)) # OR ^(?!boot(/config|$)|etc(/runlevels|$)) The long time problem is that etckeeper tries to scan the whole repo root which is / here because I also track some items in /usr/local or /root. Those find on / take far too long and never come back. Therefore I dropped pre-commit.d/20warn-problem-files completely since I know which files I added explicitly. I also dropped the search for empty directories because I only add specific files. As for 30store-metadata I added hg status -nacu for getting all relevant files: [[!format bash """ --- /root/src/etckeeper/pre-commit.d/30store-metadata 2015-02-19 13:13:46.171485949 +0100 +++ pre-commit.d/30store-metadata 2015-02-19 13:28:01.593456235 +0100 @@ -59,7 +59,10 @@ generate_metadata() { # (Note that when using this, the find expression must end with # -print or -exec, else the excluded directories will actually be # printed!) - NOVCS='. -path ./.git -prune -o -path ./.bzr -prune -o -path ./.hg -prune -o -path ./_darcs -prune -o' + if [ "$VCS" = hg ]; then + HG_FILES="$(hg status -nacu)" + fi + NOVCS="${HG_FILES:-.} -path ./.git -prune -o -path ./.bzr -prune -o -path ./.hg -prune -o -path ./_darcs -prune -o" # Keep the sort order the same at all times. LC_COLLATE=C @@ -68,8 +71,9 @@ generate_metadata() { if [ "$VCS" = git ] || [ "$VCS" = hg ]; then # These version control systems do not track directories, # so empty directories must be stored specially. - find $NOVCS -type d -empty -print | - sort | shellquote | sed -e "s/^/mkdir -p /" +# find ${HG_FILES:- } $NOVCS -type d -empty -print | +# sort | shellquote | sed -e "s/^/mkdir -p /" + true fi if [ "$VCS" = darcs ]; then @@ -110,12 +114,12 @@ generate_metadata() { s/^/$q/; s/$/$q/; if ($uid != $>) { - printf "maybe chown $q%s$q %s\n", uidname($uid), $_; + printf "maybe chown -c $q%s$q %s\n", uidname($uid), $_; } if ($gid != $)) { - printf "maybe chgrp $q%s$q %s\n", gidname($gid), $_; + printf "maybe chgrp -c $q%s$q %s\n", gidname($gid), $_; } - printf "maybe chmod %04o %s\n", $mode & 07777, $_; + printf "maybe chmod -c %04o %s\n", $mode & 07777, $_; ' """]] Thanks for the new website beside the very basic debian bugtracker. Please provide a bug tracker or ticket system. Please provide also simple tar-balls with the release-versions beside git-tags, that can be used by other package managers and distributions. Since some distros are already considered please integrate the Gentoo package manager so we can drop our patches: # There is something missing if only recording uid/gid/mode for tracked files... All dirnames of every file must also get the right permissions. I only did the hg source part. Using bash arrays could be better, I tried to stay sh compatible. This is a quick hack, not completely tested... [[!format bash """ # diff -uNr /root/src/etckeeper/pre-commit.d/30store-metadata /etc/etckeeper/pre-commit.d/30store-metadata --- /root/src/etckeeper/pre-commit.d/30store-metadata 2015-02-20 15:36:24.912374338 +0100 +++ /etc/etckeeper/pre-commit.d/30store-metadata 2015-02-20 15:34:10.770378997 +0100 @@ -44,6 +44,21 @@ sed -e "s/'/'\"'\"'/g" -e "s/^/'/" -e "s/$/'/" } +getdirname() { + # Permissions of all parent dirnames must also be recorded + local p + # Print the file itself + printf '%s' "$p" + p=${1%/*} + # Print the files dirnames + while [[ $p = */* ]]; do + printf ' %s' "$p" + p=${p%/*} + done + # Print the parent dirname + printf ' %s' "$p" +} + generate_metadata() { # This function generates the script commands to fix any file # ownerships that aren't owner=root, group=root, as well as to @@ -57,9 +72,17 @@ # but we want find to ignore the VCS files themselves. # # (Note that when using this, the find expression must end with - # -print or -exec, else the excluded directories will actually be - # printed!) - NOVCS='. -path ./.git -prune -o -path ./.bzr -prune -o -path ./.hg -prune -o -path ./_darcs -prune -o' + # -print or -exec, else the excluded directories will actually be + # printed!) + if [ "$VCS" = hg ]; then + HG_FILES="$(hg status -nacu)" + HG_FILES_DIRS="" + for file in $HG_FILES; do + HG_FILES_DIRS+=" $(getdirname $file)" + done + + fi + NOVCS="${ALL_FILES:-.} -path ./.git -prune -o -path ./.bzr -prune -o -path ./.hg -prune -o -path ./_darcs -prune -o" # Keep the sort order the same at all times. LC_COLLATE=C @@ -68,8 +91,9 @@ if [ "$VCS" = git ] || [ "$VCS" = hg ]; then # These version control systems do not track directories, # so empty directories must be stored specially. - find $NOVCS -type d -empty -print | - sort | shellquote | sed -e "s/^/mkdir -p /" +# find ${ALL_FILES:- } $NOVCS -type d -empty -print | +# sort | shellquote | sed -e "s/^/mkdir -p /" + true fi if [ "$VCS" = darcs ]; then @@ -83,7 +107,8 @@ # Store things that don't have the default user or group. # Store all file modes, in case the user has an unusual umask. - find $NOVCS \( -type f -or -type d \) -print | filter_ignore | sort | perl -ne ' + #find $NOVCS \( -type f -or -type d \) -print | filter_ignore | sort | perl -ne ' + echo $HG_FILES_DIRS | tr " " "\n" | sort -u | perl -ne ' BEGIN { $q=chr(39) } sub uidname { my $want=shift; @@ -110,12 +135,12 @@ s/^/$q/; s/$/$q/; if ($uid != $>) { - printf "maybe chown $q%s$q %s\n", uidname($uid), $_; + printf "maybe chown -c $q%s$q %s\n", uidname($uid), $_; } if ($gid != $)) { - printf "maybe chgrp $q%s$q %s\n", gidname($gid), $_; + printf "maybe chgrp -c $q%s$q %s\n", gidname($gid), $_; } - printf "maybe chmod %04o %s\n", $mode & 07777, $_; + printf "maybe chmod -c %04o %s\n", $mode & 07777, $_; ' # We don't handle xattrs. """]] I added an init hook for any update, so after cloning to a new location and updating, all permissions are going to be fixed: [hooks] [[!format python """ # pre-commit hook for etckeeper, to store metadata and do sanity checks pre-commit = etckeeper pre-commit -d "$(hg root)" post-update = etckeeper init "$(hg root)" """]] Best regards, Massimo etckeeper-1.18.21/doc/todo/Consistent_tempfile_creation.mdwn000066400000000000000000000017401453142634200241440ustar00rootroot00000000000000Currently etckeeper has two different mechanisms for creating temporary files. There's no clear reason for that, and it caught me out when I was trying to update some of the scripts for my own purposes. I don't particularly mind how this is resolved, but I'd like it resolved in some consistent fashion! I've made two patches for two different resolutions: - [Allow either `mktemp` or `tempfile` everywhere](https://github.com/me-and/etckeeper/commit/96d4da2314ad64147835554371d04372cb4a4612) (best for backwards compatibility, as it'll keep working for folk who don't have `mktemp`) - [Consistently assume `mktemp` is available](https://github.com/me-and/etckeeper/commit/3fb703588997590fec4776fb91e3b119ab3f75f9) (best for simplicity) > Thanks, I've applied the first patch. It looks like all the code that > assumed mktemp was available only ran when using darcs, so there are > presumably systems where mktemp is not available that the second patch > would break. [[done]] --[[Joey]] etckeeper-1.18.21/doc/todo/Correct_misspelling_of___34__committer__34__.mdwn000066400000000000000000000005151453142634200267250ustar00rootroot00000000000000In commit.d/50vcs-commit the word "committer" is misspelled twice (as "commiter"). Here it is in the code: https://github.com/joeyh/etckeeper/blob/master/commit.d/50vcs-commit#L58-L59 This is causing git to incorrectly attribute commits to root instead of the name and email specified in ~/.gitconfig. > [[fixed|done]] --[[Joey]] etckeeper-1.18.21/doc/todo/DNF:_fix_logging__44___so_it_will_work_from_Ansible.mdwn000066400000000000000000000012201453142634200302220ustar00rootroot00000000000000The following changes since commit c88551e939ed9349e7cc9be3e384749633b79655: I am in awe of /etc/etckeeper/*.d/ (2019-03-18 14:36:14 +0000) are available in the Git repository at: https://github.com/sourcejedi/etckeeper.git for you to fetch changes up to 040f5b2cb808ad9791d2c6f2f916fd887d2e16fa: DNF: fix logging, now it will work from Ansible (2019-04-13 18:21:47 +0100) ---------------------------------------------------------------- Alan Jenkins (1): DNF: fix logging, now it will work from Ansible etckeeper-dnf/etckeeper.py | 48 ++++++++++++++++++++++++++++++++++++++++++------ 1 file changed, 42 insertions(+), 6 deletions(-) etckeeper-1.18.21/doc/todo/DNF:_fix_logging__44___so_it_will_work_from_Ansible/000077500000000000000000000000001453142634200273405ustar00rootroot00000000000000comment_1_add80827135b358d3b55565e2168af00._comment000066400000000000000000000013741453142634200371070ustar00rootroot00000000000000etckeeper-1.18.21/doc/todo/DNF:_fix_logging__44___so_it_will_work_from_Ansible[[!comment format=mdwn username="sourcejedi" avatar="http://cdn.libravatar.org/avatar/599d943d715a521e4c23ab2a46ac70dc" subject="Oops. Revised version" date="2019-04-19T14:38:57Z" content=""" Please find a revised commit in the dnf branch of https://github.com/sourcejedi/etckeeper.git commit id: afbdce2d24b46bc91840044b953aca8b68f20fd3 (The previous commit was not as safe as I thought. If the etckeeper output includes an un-decodable byte, we would convert it to a unicode string which contains U+FFFD. This codepoint is *not* available in all character encodings, so it can cause UnicodeEncodeError. It's not fatal in current versions of dnf, because they set logging.RaiseExceptions = false. However it could lose an entire line of output.) """]] comment_2_81c341d479a56a2fa79c9c519a130ef3._comment000066400000000000000000000005111453142634200372460ustar00rootroot00000000000000etckeeper-1.18.21/doc/todo/DNF:_fix_logging__44___so_it_will_work_from_Ansible[[!comment format=mdwn username="joey" subject="""comment 2""" date="2019-04-23T23:09:47Z" content=""" Given the difficulty in feeding etckeeper output through this, would it perhaps be better to do something else with its output in this case, either /dev/nulling it or writing it to the syslog or something like that? """]] comment_2_ff2b6e899a2f363b623aa1eff6c0adcc._comment000066400000000000000000000013321453142634200377040ustar00rootroot00000000000000etckeeper-1.18.21/doc/todo/DNF:_fix_logging__44___so_it_will_work_from_Ansible[[!comment format=mdwn username="sourcejedi" avatar="http://cdn.libravatar.org/avatar/599d943d715a521e4c23ab2a46ac70dc" subject="Have a bonus commit: 3d431ea67922 "Do not use dnfpluginscore.logger"" date="2019-04-23T19:17:50Z" content=""" dnfpluginscore is not core support for dnf plugins, it is just a collection of \"core plugins\" for dnf. There is equally dnfpluginsextras and dnfpluginsextras.logger. A comment in dnf.logger comment says the logger name 'dnf.plugin' is \"api\". So we can safely rely on that name. Technically you can install etckeeper without the dnfpluginscore package (at least I managed to run into this for python2, on a Fedora 29 system which uses python3 for dnf by default). """]] comment_3_1dcb2bdbc7ae9fc8746e75d9ce8305ff._comment000066400000000000000000000010251453142634200377260ustar00rootroot00000000000000etckeeper-1.18.21/doc/todo/DNF:_fix_logging__44___so_it_will_work_from_Ansible[[!comment format=mdwn username="webknjaz@282aadd575f8161e52a787ad51e8ba046b8289a9" nickname="webknjaz" avatar="http://cdn.libravatar.org/avatar/6268a71f6afd8dc3875df5624f8bf85c" subject="Reference to the corresponding bug analysis in Ansible " date="2019-06-06T20:16:40Z" content=""" Hi, I've been tracking down this issue on the Ansible side and just wanted to share [this comment on GitHub](https://github.com/ansible/ansible/issues/54949#issuecomment-499541669). Any estimations on when this gets applied upstream? """]] comment_5_b117c5f77ebb26d26634248f68ee3e1a._comment000066400000000000000000000022711453142634200373420ustar00rootroot00000000000000etckeeper-1.18.21/doc/todo/DNF:_fix_logging__44___so_it_will_work_from_Ansible[[!comment format=mdwn username="alan.christopher.jenkins@a53b5c6056bc7d7b09e181c23cc2ec8362fa7abe" nickname="alan.christopher.jenkins" avatar="http://cdn.libravatar.org/avatar/599d943d715a521e4c23ab2a46ac70dc" subject="How about "etckeeper > /dev/null" ?" date="2019-10-28T17:08:20Z" content=""" See same github repo, branch \"dnf2\", commit 7cda9678b1e60c0495a2a522721b319843d5fae0 Sorry for the delay. I can't find a record of an email notification. In response to Joey's comment, I've tried sending all the etckeeper output to /dev/null. I find the resulting code more friendly to read, because it avoids my very long code comment :). I interpreted \"in this case\" as just meaning \"in etckeeper-dnf\". I think you could technically check whether you are dnf v.s. a different libdnf client like Ansible, but I didn't want to :). syslog.syslog() did not seem very helpful. In python2 it appears to encode unicode using ascii, regardless of the locale. I think we might be able to drop support for python2-dnf. But still, the system log seems a bit unexpected, compared to stderr, /var/log/dnf.plugin.log, /var/log/dnf.log, or whatever custom logger the host program set up. """]] comment_6_0e06add692d4dc5cd61ba037159669be._comment000066400000000000000000000012041453142634200374060ustar00rootroot00000000000000etckeeper-1.18.21/doc/todo/DNF:_fix_logging__44___so_it_will_work_from_Ansible[[!comment format=mdwn username="joey" subject="""comment 6""" date="2020-01-21T19:23:41Z" content=""" dnf2 sinks etckeeper's stdout and stderr to /dev/null `etckeeper pre-install`, when `AVOID_COMMIT_BEFORE_INSTALL` is set, outputs an error to stderr, and exits nonzero. The expectation is that the package installation is canceled. (I don't know if that happens with etckeeper-dnf; it kind of looks like it warns and continues?) If etckeeper pre-install exiting nonzero does prevent the upgrade from happening, and the message about it goes to /dev/null, that seems like a surprising situation for the user to be confronted with. """]] comment_7_30b13e28d24f3d37e933de8f07e4dd51._comment000066400000000000000000000017341453142634200373420ustar00rootroot00000000000000etckeeper-1.18.21/doc/todo/DNF:_fix_logging__44___so_it_will_work_from_Ansible[[!comment format=mdwn username="http://thm.id.fedoraproject.org/" nickname="thm" avatar="http://cdn.libravatar.org/avatar/f274b586047bb4a60d0332e647cd1bea" subject="comment 7" date="2021-02-10T16:09:35Z" content=""" In Fedora, we have that patch for a while now. However recently, someone [stumbled](https://bugzilla.redhat.com/show_bug.cgi?id=1917461) over the issue joey described in his last comment. Seems like there is indeed only a warning and dnf continues instead of cancelling package installation. The commit message of the [patch](https://github.com/sourcejedi/etckeeper/commit/8266a4fb) reads: > For the pre-transaction etckeeper run, this message replaces an exception. So we now avoid logging a traceback, which did not appear to add anything useful. (In my testing, dnf was continued to install after the exception was logged). hence I suspect, some more investigation has to happen on how to actually cancel the transaction from within a dnf plugin/hook? """]] etckeeper-1.18.21/doc/todo/Detailed_post-install_commit_messages.mdwn000066400000000000000000000015751453142634200257330ustar00rootroot00000000000000I've written some code to extend the VCS hook to provide more detailed log messages for post-install commits. Basically, it matches the list of altered files against package manager file list and lists packages with actual configuration changes (plus non-package files) in addition to the list of all changed packages that's listed now. I find it useful on large system updates, when the package list gets long and commit message consists mostly of irrelevant package names. I have to note that I don't use package managers other than apt/rpm or vcs other than git on regular basis, so it would be useful if someone with more experience on those takes a look at mercurial/bazaar/darcs and pacman/pkgng implementations of the functions. Patch for the post-install.d/50vcs-commit file is available at: > [[done]] --[[Joey]] etckeeper-1.18.21/doc/todo/Detailed_post-install_commit_messages/000077500000000000000000000000001453142634200250345ustar00rootroot00000000000000comment_1_817aca821300362a4c4582bb8fb1dc8c._comment000066400000000000000000000015471453142634200350100ustar00rootroot00000000000000etckeeper-1.18.21/doc/todo/Detailed_post-install_commit_messages[[!comment format=mdwn username="joey" subject="""comment 1""" date="2016-10-18T14:57:14Z" content=""" Good idea! Reviewing the patch, I noticed that dpkg -S is run once per changed file. It should be faster to pass all the changed files to it, and parse the output. (Other package managers may also be able to be optimised this way, but I only care about dpkg, and happen to know dpkg -S can be pretty slow.. rpm -qf may be fast enough that running repeatedly is not a problem.) I think that the "Non-package (maintainer script/removed package) configuration files changed" list can be omitted. At least on debian there are unfortunately going to be a lot of such files, and it seems just added noise in the commit log, and added complication to build the list. Please use tabs and not spaces for indentation, in keeping with the rest of etckeeper's code. """]] comment_2_e7bb6d14f2362997f1e15ea3bc448788._comment000066400000000000000000000014331453142634200347650ustar00rootroot00000000000000etckeeper-1.18.21/doc/todo/Detailed_post-install_commit_messages[[!comment format=mdwn username="emkael" avatar="http://cdn.libravatar.org/avatar/c2b5d5c4ae4866f14e2f42274f3ebc2d" subject="comment 2" date="2016-10-18T17:28:56Z" content=""" The per-file lookup was just a way to catch non-package files without too much hassle with splitting piped output. Since that section is dropped, the updated patch provides lookup on one run of dpkg -S (and similar, for all package managers), plus some cleanup of the sort/uniq \"post-processing\". The only thing I'm worried about is argument length limit - from what I was able to see, dpkg -S does not read arguments from stdin, so I'm just storing the file list in a variable. Is that much of a risk? Just updated the previous gist: """]] comment_4_bf387e2effc4e14e331610e7e588693a._comment000066400000000000000000000005341453142634200350450ustar00rootroot00000000000000etckeeper-1.18.21/doc/todo/Detailed_post-install_commit_messages[[!comment format=mdwn username="joey" subject="""comment 4""" date="2016-10-21T19:14:23Z" content=""" Good thought about argument length limit. Use xargs? There is a disturbing lack of quoting on `$FILELIST` which I think could be a problem with filenames containing spaces etc. Using xargs with `-d \n` should also avoid that problem. """]] comment_5_2264f62f2b9c86e019fa8bacac699e81._comment000066400000000000000000000005141453142634200351230ustar00rootroot00000000000000etckeeper-1.18.21/doc/todo/Detailed_post-install_commit_messages[[!comment format=mdwn username="emkael" avatar="http://cdn.libravatar.org/avatar/c2b5d5c4ae4866f14e2f42274f3ebc2d" subject="comment 5" date="2016-10-23T12:49:46Z" content=""" Yeah, `xargs` should do the trick. I've updated the patch or, if you prefer, pushed it to my local fork at: `http://emkael.info/cgit/etckeeper/` """]] comment_5_d63d5c8b4a8a928c1edd0d5ef24bd538._comment000066400000000000000000000004031453142634200352470ustar00rootroot00000000000000etckeeper-1.18.21/doc/todo/Detailed_post-install_commit_messages[[!comment format=mdwn username="joey" subject="""comment 5""" date="2020-05-05T20:04:18Z" content=""" Seems I forgot all about this for 4 years, oops. Good thing is, the patch still applied with only a few changes, so it's in, finally. Thank you. """]] etckeeper-1.18.21/doc/todo/Do_not_recreate_ignored_empty_directory.mdwn000066400000000000000000000006061453142634200263470ustar00rootroot00000000000000Hi * I made some change to have a more powerful ignore_filter https://github.com/jeremiejig/etckeeper/commit/faed9ba87a71a2d09cf078c0154bd3a6bd36786a The filtering process concern only **git**. * And I filter the empty directories to avoid creating ignored empty directories https://github.com/jeremiejig/etckeeper/commit/4f257707ed85097a93289b4a33f18ea21dcf3a6e Tell me what you think. etckeeper-1.18.21/doc/todo/Do_not_recreate_ignored_empty_directory/000077500000000000000000000000001453142634200254565ustar00rootroot00000000000000comment_1_3214141a915a102378fc65084cae597a._comment000066400000000000000000000011111453142634200351220ustar00rootroot00000000000000etckeeper-1.18.21/doc/todo/Do_not_recreate_ignored_empty_directory[[!comment format=mdwn username="anarcat" avatar="http://cdn.libravatar.org/avatar/1bb99a4f017a1d253ad5790c150d0f0b" subject="comment 1" date="2022-11-08T17:27:31Z" content=""" i'm not sure that's the right way. i think you're right in that `grep -x` doesn't do the right thing, but I'm not sure I understand what you're trying to do with that extra `sed 's-^///--'` pattern there... I have proposed another solution which you might be interested in, in [[todo/metadata_ignore_filters_do_not_work]], which is basically to stop trying to reimplement git-ignore ourselves... """]] etckeeper-1.18.21/doc/todo/Doesn__39__t_work_for_symlinks_to_dev-null__44___used_by_systemd.mdwn000066400000000000000000000005271453142634200330470ustar00rootroot00000000000000etckeeper fails to track symlinks to /dev/null, as created by `systemctl mask X`. This is because git refuses to track symlinks to files which lie outside the git repository. Supporting symlinks outside the repository is also required for /etc/alternatives. - Huh, I was 100% wrong. [[done]]. Some user error, I can't work out what though. etckeeper-1.18.21/doc/todo/Doesn__39__t_work_for_symlinks_to_dev-null__44___used_by_systemd/000077500000000000000000000000001453142634200321545ustar00rootroot00000000000000comment_1_f17abb85a67bae90ee485d2eb5be183b._comment000066400000000000000000000005551453142634200424470ustar00rootroot00000000000000etckeeper-1.18.21/doc/todo/Doesn__39__t_work_for_symlinks_to_dev-null__44___used_by_systemd[[!comment format=mdwn username="joey" subject="""comment 1""" date="2017-01-06T00:11:26Z" content=""" git has no trouble storing a symlink to /dev/null here. AFAIK, git doesn't care in the slightest where a symlink points and never has. And, I have a /etc/systemd/system/minetest-server.service link to /dev/null here which etckeeper committed in 2015. """]] comment_2_ec7b55ad5d6b13e843e8179266a2f911._comment000066400000000000000000000012461453142634200420760ustar00rootroot00000000000000etckeeper-1.18.21/doc/todo/Doesn__39__t_work_for_symlinks_to_dev-null__44___used_by_systemd[[!comment format=mdwn username="https://openid.stackexchange.com/user/9df74bc5-3799-4cb1-8f54-971c8423ddaa" nickname="alan.christopher.jenkins" avatar="http://cdn.libravatar.org/avatar/8e723c6cf403714781c6f1ca93551ac5f15f1c982669ab553fb2b73bb896a69a" subject="comment 2" date="2017-01-21T11:50:59Z" content=""" Huh, I was 100% wrong. [[done]]. Some user error, I can't work out what though. I'm fairly sure this was when I masked fwupd.service. That was on Fedora 25 Workstation, my current laptop. I can successfully use `git log` on either /etc/systemd/system or `-- /etc/systemd/system/fwupd.service`, and I see the service being masked and later unmasked. """]] etckeeper-1.18.21/doc/todo/Fix_warnings_on_netbsd.mdwn000066400000000000000000000046521453142634200227400ustar00rootroot00000000000000I use etckeeper from [pkgsrc](http://pkgsrc.se/sysutils/etckeeper) on NetBSD with a nightly cron job, and it generates warnings each night: ~~~ dnsdomainname: not found find: -not: unknown option find: -not: unknown option [master e4e5623] Daily autocommit 5 files changed, 90 deletions(-) ...and so on... ~~~ I've traced the issue to not-quite-POSIX args to `find` in `pre-commit.d/20warn-problem-files`, made a patch, and Amitai (schmonz) has applied the patch to the pkgsrc version. I thought you might want to include it at the source: ~~~ diff --git a/etckeeper/pre-commit.d/20warn-problem-files b/etckeeper/pre-commit.d/20warn-problem-files index f7c7580..f28d5ac 100755 --- a/etckeeper/pre-commit.d/20warn-problem-files +++ b/etckeeper/pre-commit.d/20warn-problem-files @@ -6,14 +6,14 @@ exclude_internal () { } if [ "$VCS" = bzr ] || [ "$VCS" = darcs ]; then - special=$(find . -not -type d -not -type f -not -type l | exclude_internal) || true - hardlinks=$(find . -type f -not -links 1 | exclude_internal ) || true + special=$(find . ! -type d ! -type f ! -type l | exclude_internal) || true + hardlinks=$(find . -type f ! -links 1 | exclude_internal ) || true elif [ "$VCS" = hg ]; then - special=$(find . -not -type d -not -type f -not -type l | exclude_internal) || true - hardlinks=$(find . -type f -not -links 1 -exec hg status {} \; | exclude_internal ) || true + special=$(find . ! -type d ! -type f ! -type l | exclude_internal) || true + hardlinks=$(find . -type f ! -links 1 -exec hg status {} \; | exclude_internal ) || true elif [ "$VCS" = git ]; then - special=$(find . -not -type d -not -type f -not -type l -exec git ls-files --exclude-standard --cached --others {} \; | exclude_internal) || true - hardlinks=$(find . -type f -not -links 1 -exec git ls-files --exclude-standard --cached --others {} \; | exclude_internal) || true + special=$(find . ! -type d ! -type f ! -type l -exec git ls-files --exclude-standard --cached --others {} \; | exclude_internal) || true + hardlinks=$(find . -type f ! -links 1 -exec git ls-files --exclude-standard --cached --others {} \; | exclude_internal) || true else special="" fi ~~~ Thanks! > This change was already made to etckeeper back in 2014, there > is no "-not" in the etckeeper source code anywhere now. > I wonder why netbsd is apparently using such an out of date etckeeper. > Anyway, [[done]] --[[Joey]] etckeeper-1.18.21/doc/todo/Fix_warnings_on_netbsd/000077500000000000000000000000001453142634200220425ustar00rootroot00000000000000comment_1_03217ebec4076aa066df755c99ba92fd._comment000066400000000000000000000010161453142634200321100ustar00rootroot00000000000000etckeeper-1.18.21/doc/todo/Fix_warnings_on_netbsd[[!comment format=mdwn username="http://schmonz.livejournal.com/" subject="never added this patch" date="2017-06-28T17:43:39Z" content=""" pkgsrc had been on a really old version (1.3!) until mid-May, when Nathan sent me these patches. I brought us up to 1.18.5.1, saw that this patch was unneeded, and applied just [[the other one|Truly-quiet when there's nothing to commit]]. Hoping for a 1.18.7 distfile to appear (maybe [here](https://packages.debian.org/stretch/etckeeper)?) so I can keep pkgsrc at the latest. """]] Give_preference_to_etckeeper.conf_over_existing_repository_for_defining___36__VCS.mdwn000066400000000000000000000022071453142634200363640ustar00rootroot00000000000000etckeeper-1.18.21/doc/todoI'm using etckeeper with hg and I will use git to manage some files under /etc apart from etckeeper for some reason. However, after I initialize new git repository as /etc/.git, etckeeper starts to use git as $VCS contrary to definition in etckeeper.conf. So I think that definition in etckeeper.conf should be given priority over existing repository. The patch is below (from https://github.com/hiraku/etckeeper/commit/02f6d37e50cacddc9605dcbc5c8844b3f4658d6e ): ```diff diff --git a/etckeeper b/etckeeper index 93f2b00..6c63ffb 100755 --- a/etckeeper +++ b/etckeeper @@ -109,14 +109,16 @@ fi cd "$ETCKEEPER_DIR" export ETCKEEPER_DIR -if [ -d ".git" ]; then - VCS=git -elif [ -d ".hg" ]; then - VCS=hg -elif [ -d "_darcs" ]; then - VCS=darcs -elif [ -d ".bzr" ]; then - VCS=bzr +if [ -z "$VCS" ]; then + if [ -d ".git" ]; then + VCS=git + elif [ -d ".hg" ]; then + VCS=hg + elif [ -d "_darcs" ]; then + VCS=darcs + elif [ -d ".bzr" ]; then + VCS=bzr + fi fi if [ -z "$VCS" ]; then ``` I would appreciate your consideration. Thank you. Give_preference_to_etckeeper.conf_over_existing_repository_for_defining___36__VCS/000077500000000000000000000000001453142634200354745ustar00rootroot00000000000000etckeeper-1.18.21/doc/todocomment_1_3cafcd2709f32dfe583dc42933f542cb._comment000066400000000000000000000016121453142634200457020ustar00rootroot00000000000000etckeeper-1.18.21/doc/todo/Give_preference_to_etckeeper.conf_over_existing_repository_for_defining___36__VCS[[!comment format=mdwn username="joey" subject="""comment 1""" date="2020-01-21T19:00:14Z" content=""" I'm not thrilled by this idea. It's not uncommon for etckeeper.conf to be packaged by a distribution. Upgrading the package may replace the local etckeeper.conf (takes only answering "Y" on debian). If that changes out the VCS setting, then etckeeper suddently stops using the repository it was using. The README documents how to change the VCS that etckeeper uses. So I think it would be better to document that VCS setting in etckeeper.conf only applies to `etckeeper init`. Or alternatively, to add a parameter like `etckeeper init --vcs=git`. It's true that neither of those options would cater to a system that has two different version control repositories checked out in /etc at the same time, but that sounds like a sufficiently strange/bad idea that I see no reason to cater to it. """]] etckeeper-1.18.21/doc/todo/LANG_issue_with_grep_in_store-metadata.mdwn000066400000000000000000000010471453142634200257230ustar00rootroot00000000000000Two users report issues ([here](https://bugzilla.redhat.com/show_bug.cgi?id=1979456), [here](https://bugzilla.redhat.com/show_bug.cgi?id=2036327)) with `pre-commit.d/30store-metadata` resp. `commit.d/20store-metadata`: In a German locale, `etckeeper commit 'daily autocommit'` creates messages like this: ``` grep: (Standardeingabe): Übereinstimmungen in Binärdatei ``` coming from the `grep` in line 25. It can be fixed by either setting `LC_CTYPE=C` (maybe generally, in that file), or by adding `-a` to the `grep` call. > [[done]] --[[Joey]] etckeeper-1.18.21/doc/todo/LANG_issue_with_grep_in_store-metadata/000077500000000000000000000000001453142634200250325ustar00rootroot00000000000000comment_1_0fd1ffa807fe438edee04ca8883f9333._comment000066400000000000000000000020341453142634200351750ustar00rootroot00000000000000etckeeper-1.18.21/doc/todo/LANG_issue_with_grep_in_store-metadata[[!comment format=mdwn username="joey" subject="""comment 1""" date="2021-12-31T15:37:27Z" content=""" Using grep -a would be fine, except people do use etckeeper on non-gnu systems and I worry about breaking portability. I guess the idea with setting `LC_CTYPE=C` is not to force this error message to English, which would not be useful, but because whatever the locale is set to is causing grep to interpret the input as binary. Except.. the C locale seems equally likely cause that as whatever locale they are using? Indeed the one user who mentioned their locale was using `de_DE.utf8` so why would setting C help at all? grep is complaining about its stdin, which comes from running a find in /etc, so there must be some particular file whose name causes grep to behave this way. Apparently one that, in a unicode locale, grep thinks is not unicode, but binary. (Also, there was [[!commit 0dd5ff64bf4dba9a2e54c7f29c96998af5dcebce]] which also involved setting LANG=C when using grep, in similarly hard to understand circumstances.) """]] comment_2_8ddcd82e06ca0a3c835bf122fcfb2be0._comment000066400000000000000000000026361453142634200353650ustar00rootroot00000000000000etckeeper-1.18.21/doc/todo/LANG_issue_with_grep_in_store-metadata[[!comment format=mdwn username="http://thm.id.fedoraproject.org/" nickname="thm" avatar="http://cdn.libravatar.org/avatar/f274b586047bb4a60d0332e647cd1bea" subject="comment 2" date="2022-01-02T16:38:37Z" content=""" > I guess the idea with setting LC_CTYPE=C is not to force this error message to English, which would not be useful, but because whatever the locale is set to is causing grep to interpret the input as binary. Exactly. > Except.. the C locale seems equally likely cause that as whatever locale they are using? Indeed the one user who mentioned their locale was using de_DE.utf8 so why would setting C help at all? Because, according to the `grep`'s man page: \"In the C or POSIX locale, all characters are encoded as a single byte and every byte is a valid character.\" > grep is complaining about its stdin, which comes from running a find in /etc, so there must be some particular file whose name causes grep to behave this way. Apparently one that, in a unicode locale, grep thinks is not unicode, but binary. While I don't know which files caused the issue for the reporters of the two bugs, I was able to reproduce the issue by running `touch $'\xf6'` in `/etc`, creating a file named 'ö' in a latin-1 locale, but with an invalid name if interpreted as utf-8. (This can also be seen running `find /etc | iconv -f utf8 - -o /dev/null` which yields `iconv: illegal input sequence at position XY`.) """]] comment_3_0b32bf35a6ae4117f277bda7f1a60fd4._comment000066400000000000000000000002511453142634200351400ustar00rootroot00000000000000etckeeper-1.18.21/doc/todo/LANG_issue_with_grep_in_store-metadata[[!comment format=mdwn username="joey" subject="""comment 3""" date="2022-01-07T15:05:15Z" content=""" Thanks, I understand. I've applied the `LC_CTYPE` fix. """]] etckeeper-1.18.21/doc/todo/Patch:_Make_Pacman_5_call_etckeeper_hooks_as_late_as_possible.mdwn000066400000000000000000000010341453142634200323270ustar00rootroot00000000000000Pacman 5 calls its hooks in alphabetical order. The hooks I added in my previous patch (see [[__91__Patch__93___Support_Pacman_5.x_hooks]]) have no numerical prefix -- which is needed in order to ensure that Pacman calls the hooks as late as possible (i. e. after all other hooks). My patch remedies that minor issue by adding the proper numerical prefix to the filenames of the Pacman 5 hooks. It may be found here: > [[done]] thanks --[[Joey]] etckeeper-1.18.21/doc/todo/Porting_to_LEDE___40__OpenWRT__41___opkg.mdwn000066400000000000000000000001171453142634200254530ustar00rootroot00000000000000Hello What we need to do (to code) for working etckeeper under LEDE/OpenWRT? etckeeper-1.18.21/doc/todo/Porting_to_LEDE___40__OpenWRT__41___opkg/000077500000000000000000000000001453142634200245655ustar00rootroot00000000000000comment_1_9131efb9888659f72a55fc732c87a566._comment000066400000000000000000000003321453142634200343730ustar00rootroot00000000000000etckeeper-1.18.21/doc/todo/Porting_to_LEDE___40__OpenWRT__41___opkg[[!comment format=mdwn username="http://roschacker.id.mail.ru/" subject="What dependencies we need?" date="2017-07-15T13:09:41Z" content=""" python is NOT installed by default nither perl but git is present """]] comment_2_8524d920029e401175ab6d2fe1362cc5._comment000066400000000000000000000030371453142634200343230ustar00rootroot00000000000000etckeeper-1.18.21/doc/todo/Porting_to_LEDE___40__OpenWRT__41___opkg[[!comment format=mdwn username="http://roschacker.id.mail.ru/" subject="make install" date="2017-07-15T13:52:11Z" content=""" root@LEDE:~/etckeeper.branchable.com# make sed -i~ \"s/Version:.*/Version: $(perl -e '$_=<>;m/\((.*?)(-.*)?\)/;print $1;';m/\((.*?)(-.*)?\)/;print $1;' from bzrlib.errors import BzrError ImportError: No module named bzrlib.errors ** bzr support not built python ./etckeeper-dnf/etckeeper.py build || echo \"** DNF support not built\" Traceback (most recent call last): File \"./etckeeper-dnf/etckeeper.py\", line 10, in from dnfpluginscore import logger ImportError: No module named dnfpluginscore ** DNF support not built root@LEDE:~/etckeeper.branchable.com# root@LEDE:~/etckeeper.branchable.com# root@LEDE:~/etckeeper.branchable.com# make install sed -i~ \"s/Version:.*/Version: $(perl -e '$_=<>;m/\((.*?)(-.*)?\)/;print $1;' Good patch, [[done]]! --[[Joey]] etckeeper-1.18.21/doc/todo/Truly-quiet_when_there__39__s_nothing_to_commit.mdwn000066400000000000000000000033521453142634200276520ustar00rootroot00000000000000I use etckeeper from [pkgsrc](http://pkgsrc.se/sysutils/etckeeper) on NetBSD in a nightly cron job. My configuration for git includes `-q` but that isn't enough to fully silence it when there's nothing to commit, so I get an email from cron every night, even when there's nothing to commit. Amitai (schmonz) applied this patch to pkgsrc, and I thought you might like it upstream. Note that the patch will always skip attempting the commit, if there is nothing to commit, which is maybe not what you intended. But it's the only way to actually get silent nightlies. If you wanted to preserve backwards compatibility, it would be tricky, I think. There are also more-efficient ways to do this; the `diff` could be run right at the top of this script, and the rest of it skipped. But I wanted to be minimally-invasive, so I did it this way. ~~~ diff --git a/etckeeper/commit.d/50vcs-commit b/etckeeper/commit.d/50vcs-commit index 2a2176a..bcd02df 100755 --- a/etckeeper/commit.d/50vcs-commit +++ b/etckeeper/commit.d/50vcs-commit @@ -87,10 +87,12 @@ if [ "$VCS" = git ] && [ -d .git ]; then export GIT_COMMITTER_EMAIL fi fi - if [ -n "$logfile" ]; then - git commit $GIT_COMMIT_OPTIONS -F "$logfile" - else - git commit $GIT_COMMIT_OPTIONS + if ! git diff --cached --quiet; then + if [ -n "$logfile" ]; then + git commit $GIT_COMMIT_OPTIONS -F "$logfile" + else + git commit $GIT_COMMIT_OPTIONS + fi fi elif [ "$VCS" = hg ] && [ -d .hg ]; then if [ -n "$USER" ]; then ~~~ Thank you! > [[closed|done]] because `etckeeper unclean` is a better way to do this. > --[[Joey]] etckeeper-1.18.21/doc/todo/Truly-quiet_when_there__39__s_nothing_to_commit/000077500000000000000000000000001453142634200267605ustar00rootroot00000000000000comment_1_22aeb26fb522fb0806a2791970369080._comment000066400000000000000000000010751453142634200364410ustar00rootroot00000000000000etckeeper-1.18.21/doc/todo/Truly-quiet_when_there__39__s_nothing_to_commit[[!comment format=mdwn username="joey" subject="""comment 1""" date="2017-06-28T16:33:30Z" content=""" That patch makes etckeeper only commit changes that have been staged (eg added with `git add`). If a file has been changed, but not staged, `git diff --cached` will ignore the change, and it won't get committed. So the patch is broken. On debian, a daily cron job uses `etckeeper unclean` to determine if there are any changes in need of committing. That works with every VCS that etckeeper supports, and my suggestion is that netbsd use the same mechanism. """]] comment_2_21482b7d984aabd310c09539f1dc8f0b._comment000066400000000000000000000005011453142634200367340ustar00rootroot00000000000000etckeeper-1.18.21/doc/todo/Truly-quiet_when_there__39__s_nothing_to_commit[[!comment format=mdwn username="truist" avatar="http://cdn.libravatar.org/avatar/cbb99b0a9724faf8fc7f4464b7bfab11" subject="comment 2" date="2017-06-29T16:17:33Z" content=""" Wow - I'm not sure how I missed that behavior. Sorry about that. And yes, it sounds like `etckeeper unclean` is a much better option. """]] comment_3_d88dfbf82994d484a50a8fb751fc4c83._comment000066400000000000000000000007351453142634200370650ustar00rootroot00000000000000etckeeper-1.18.21/doc/todo/Truly-quiet_when_there__39__s_nothing_to_commit[[!comment format=mdwn username="truist" avatar="http://cdn.libravatar.org/avatar/cbb99b0a9724faf8fc7f4464b7bfab11" subject="comment 3" date="2017-06-29T16:30:56Z" content=""" I see why I used `--cached` - because `30git-add` runs before this script, so the files to be added are always already cached by the time this script runs. Doing the diff without `--cached` wouldn't work. However, your solution is still better, in case users have customized the scripts. """]] etckeeper-1.18.21/doc/todo/Use_portable_command_-v.mdwn000066400000000000000000000016121453142634200227640ustar00rootroot00000000000000``` The following changes since commit 1b418610133e6de2b091ddf148df2846d535d5e8: some issues with systemd and autocommit (2020-04-17 21:19:29 +0000) are available in the Git repository at: https://github.com/eli-schwartz/etckeeper for you to fetch changes up to d3f820b12d6dad3f59790780fbfcee0f30e6b11a: Use portable "command -v" to detect installed programs (2020-04-19 04:27:59 -0400) ---------------------------------------------------------------- Eli Schwartz (1): Use portable "command -v" to detect installed programs debian/postinst | 2 +- etckeeper | 2 +- init.d/10restore-metadata | 2 +- pre-commit.d/30store-metadata | 2 +- uninit.d/50vcs-uninit | 4 ++-- update-ignore.d/01update-ignore | 4 ++-- vcs.d/50vcs-cmd | 2 +- 7 files changed, 9 insertions(+), 9 deletions(-) ``` > [[done]] --[[Joey]] etckeeper-1.18.21/doc/todo/Use_portable_command_-v/000077500000000000000000000000001453142634200220755ustar00rootroot00000000000000comment_1_75d97a77ffdccc3be06940f68b2b6ac1._comment000066400000000000000000000011371453142634200323160ustar00rootroot00000000000000etckeeper-1.18.21/doc/todo/Use_portable_command_-v[[!comment format=mdwn username="joey" subject="""comment 1""" date="2020-04-24T16:43:02Z" content=""" The way this was presented left me at sea about the rationalle for the change. I had to read the commit message (which was excellent) to understand. Surprising to me that posh is apparently out of date on standards, and I could not find a bug report on it to get it updated either. However, I was quickly able to find command -v use in scripts on a debian system, so anyone using posh as their system shell is already experiencing other breakage. So no worries on that front. Applying as-is. """]] etckeeper-1.18.21/doc/todo/Yet_another_patch_for_the_Pacman_5_hooks.mdwn000066400000000000000000000025451453142634200263220ustar00rootroot00000000000000It turns out that my last patch ([[Patch:_Make_Pacman_5_call_etckeeper_hooks_as_late_as_possible]]) was not perfect after all. Calling both the pre-transaction and the post-transaction hook as late as possible seemed to make sense at the time, but now that I think about it, I would say that only the post-transaction hook should be called after all other hooks; the **pre-transaction** hook should be called as **early** as possible. That way, the pre-transaction hook can make sure that... - ...everything in `/etc` gets committed before any other hook gets the chance to introduce more changes (therefore making any changes made by other hooks part of the post-transaction commit) *and*... - ...it can abort the transaction and thus all hooks that come after the pre-transaction hook if `/etc` is not clean and the user wants to prevent the package manager from running in that case. This prevents any later hooks from making changes that should not be made in the first place (since the entire transaction is being aborted due to a dirty `/etc`). My patch which makes Pacman call the pre-transaction hook as early as possible can be found here: Hopefully, this will be the last patch related to the Pacman hooks for some time... Sorry for the noise. > [[done]] --[[Joey]] 03adfa4a9470a0912eac478c98b5717b3f6d0886.paxheader00006660000000000000000000000227145314263420020445xustar00rootroot00000000000000151 path=etckeeper-1.18.21/doc/todo/__91__BUG__93___Arch_Linux:_hooks_don__39__t_trigger_when___47__etc_is_only_modified_by_post-install_scripts..mdwn 03adfa4a9470a0912eac478c98b5717b3f6d0886.data000066400000000000000000000012371453142634200173050ustar00rootroot00000000000000The pacman hooks that etckeeper use only trigger if a package changes a file in /etc. This breaks when a package only changes /etc in it's post-install script. An example of this is archlinux-keyring, which runs a post install script to update the gpg trust db in /etc/pacman. The solution is to change the hooks to always run. Instead of: ``` Type = Path Target = etc/* ``` use something like: ``` Type = Package Target = * ``` At least when using git, `etckeeper pre-install` and `etckeeper post-install` are quick enough on my computer that running when not needed is not a big deal. Here is the Arch Linux bug about this: https://bugs.archlinux.org/task/76826 a47164aa13d939c04fefba0b513e0cf4bc78b440.paxheader00006660000000000000000000000223145314263420020627xustar00rootroot00000000000000147 path=etckeeper-1.18.21/doc/todo/__91__BUG__93___Arch_Linux:_hooks_don__39__t_trigger_when___47__etc_is_only_modified_by_post-install_scripts./ a47164aa13d939c04fefba0b513e0cf4bc78b440.data000077500000000000000000000000001453142634200174665ustar00rootroot00000000000000comment_1_2e5c41b9d32669974703285279c05784._comment000066400000000000000000000003571453142634200516040ustar00rootroot00000000000000etckeeper-1.18.21/doc/todo/__91__BUG__93___Arch_Linux:_hooks_don__39__t_trigger_when___47__etc_is_only_modified_by_post-install_scripts.[[!comment format=mdwn username="joey" subject="""comment 1""" date="2022-12-14T18:02:09Z" content=""" Since I'm not in a position to test this myself, it would be great if you could develop a patch, test it, and send the patch. """]] etckeeper-1.18.21/doc/todo/__91__Patch__93___Support_Pacman_5.x_hooks.mdwn000066400000000000000000000011051453142634200261220ustar00rootroot00000000000000The 5.0.0 release of Arch Linux' *Pacman* package manager [finally supports hooks](https://projects.archlinux.org/pacman.git/tree/NEWS?id=fea9abc8db3b8161ab32774a0ddd7c405cfbe44f), making it possible to properly integrate etckeeper with it. I have added the necessary hook files to etckeeper and also modified the `Makefile` to install them if the user chooses `pacman` as the `LOWLEVEL_PACKAGE_MANAGER`. You can find my patch [here](https://github.com/joeyh/etckeeper/compare/master...Tblue:master.patch). Please consider applying it. :-) > merged, thanks. [[done]] --[[Joey]] etckeeper-1.18.21/doc/todo/add_support_pacmatic_http:__47____47__kmkeen.com__47__pacmatic__47__.mdwn000066400000000000000000000003361453142634200330660ustar00rootroot00000000000000Please add support pacmatic http://kmkeen.com/pacmatic/ https://github.com/nicolaichuk/etckeeper/commit/52846aebb91770e3bbc466881998714c88cbcaa6 Patch attached: 'add_support_pacmatic.patch' > [[merged|done]] --[[Joey]] etckeeper-1.18.21/doc/todo/automatic_git_gc.mdwn000066400000000000000000000002011453142634200215330ustar00rootroot00000000000000Hi You should add so it runs "git gc" automatic. I know I can add it manually but better if its included > [[done]] --[[Joey]] etckeeper-1.18.21/doc/todo/automatic_git_gc/000077500000000000000000000000001453142634200206535ustar00rootroot00000000000000etckeeper-1.18.21/doc/todo/automatic_git_gc/comment_1_a0d10512edff8765066bac4bbc8a0561._comment000066400000000000000000000003461453142634200307610ustar00rootroot00000000000000[[!comment format=mdwn username="florian.kaiser@0f461a60da03d93431a5fdc965f53e6265e3f91e" nickname="florian.kaiser" subject="comment 1" date="2016-03-08T13:32:03Z" content=""" Git does git gc automatically when needed. """]] etckeeper-1.18.21/doc/todo/automatic_git_gc/comment_2_1af062eb15d4b90644a5a67e31916657._comment000066400000000000000000000006111453142634200304730ustar00rootroot00000000000000[[!comment format=mdwn username="https://marcussundberg.com/openid/" avatar="http://cdn.libravatar.org/avatar/12ed25dc622fa3b47194a892662e9131c7e70a4d65d9453cba062f2c6487c9d5" subject="In that case git has a crazy notion about "needed"..." date="2016-11-19T13:55:35Z" content=""" Running gc in one of my etckeeper repos shrunk the .git directory from 500+ MiB to ~45 MiB. """]] etckeeper-1.18.21/doc/todo/automatic_git_gc/comment_3_0da657ee0aca64875b1623d52bd17592._comment000066400000000000000000000027461453142634200306450ustar00rootroot00000000000000[[!comment format=mdwn username="joey" subject="""comment 3""" date="2020-05-05T20:07:40Z" content=""" 10x pack improvement is not unusual when running git gc. Just gced my /etc from 32mb down to 3.9mb. But that does not tell me that git is not running gc often enough in /etc, necessarily. I think the question is, might the way etckeeper uses git happen to avoid the git commands that do auto gc? After all, the only command run in some etckeeper repos is git commit, and some git ls-files and similar query commands. One command I know triggers an auto gc is git fetch, which is never run. Looking at git's source code, git commit does seem to run gc --auto. Verified that with `GIT_TRACE=1 git commit` So, it seems to me that if git has not gc'ed a 500 mb repo, it must be because the default or system gc.auto config didn't make it want to, not that it didn't have the opportunity. If there are less than 6700 objects, it by default won't. Suppose there's a 100 kb config file that keeps getting modified and commited by etckeeper. 6000 versions of that file stored as loose objects would bloat the repo up to 585 mb (well, a bit less, git does compress the objects), and would not be enough objects to trigger gc.auto. Something like that seems plausible. What 100 kb config file, you ask? /etc/.etkeeper runs around that large! So do my dnssec zone files (which get auto-regenerated regularly). So, I think it would make sense for etckeeper to set gc.auto to a smaller number, say 670. """]] etckeeper-1.18.21/doc/todo/basic_alpine_linux_support.mdwn000066400000000000000000000003711453142634200236650ustar00rootroot00000000000000Hi, I have prepared a small change with very basic support for Alpine Linux. The change can be found here: https://github.com/HRio/etckeeper/commit/0afeb5b4585b2251e83cec32687ed6c99a39fb9a Thanks, / Henrik > applied, thanks [[done]] --[[Joey]] etckeeper-1.18.21/doc/todo/clear_up_confusion_about_daily_autocommit_and_systemd.mdwn000066400000000000000000000012541453142634200313260ustar00rootroot00000000000000there are two bugs in the Debian BTS that should probably be upstreamed here. I'm bundling them together because they are related, but it's true they are two distinct issues. * [Please don't start both cron job and systemd.timer](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=883263) * [daily autocommit is run even though AVOID_DAILY_AUTOCOMMITS=1](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=884824) I bundle them because they somewhat depend on each other. Could you review those patches and see if they are appropriate? They at least look good to me and I'm considering inclusion in the next upload... Let me know! -- [[anarcat]], your faithful debian packager... etckeeper-1.18.21/doc/todo/clear_up_confusion_about_daily_autocommit_and_systemd/000077500000000000000000000000001453142634200304355ustar00rootroot00000000000000comment_1_d5620588716a2dc82bc6372482eaaca6._comment000066400000000000000000000040571453142634200403460ustar00rootroot00000000000000etckeeper-1.18.21/doc/todo/clear_up_confusion_about_daily_autocommit_and_systemd[[!comment format=mdwn username="joey" subject="""comment 1""" date="2020-05-05T18:46:14Z" content=""" Well, this seems like quite a mess at first glance. The commit that added the timer claims that the timer is not enabled by default. If the timer is enabled by default, then everything that was done to intergrate it seems like it must rest on a faulty foundation. Afaik, systemd does not enable a unit just because the file is dropped into /lib/systemd; it has to be enabled. So what is enabling it? I checked a few systems, and they all had the timer enabled due to /etc/systemd/system/multi-user.target.wants/etckeeper.timer existing. git log seems to indicate the file got created before etckeeper's first commit to /etc. I do not know what creates it. It seems to me we need to understand the root cause of what is enabling that to fix it. The patch in 883263 adds some ugliness to the cron job to check if the timer is enabled. The patch 884824 in makes `AVOID_DAILY_AUTOCOMMITS` prevent the timer from committing. The way this is supposed to work is documented in etckeeper.conf: # Etckeeper includes both a cron job and a systemd timer, which each # can commit exiting changes to /etc automatically once per day. # To enable the systemd timer, run: systemctl enable etckeeper.timer # The cron job is enabled by default; to disable it, uncomment this next line. #AVOID_DAILY_AUTOCOMMITS=1 The second patch would make that documentation be incorrect because it would also start disabling the timer. The first patch should not be necessary if that documentation is followed, except for the problem that the timer is apparently being wrongly enabled by default. So I would rather understand and fix the root cause than patch over it in ways that add complexity and change the meaning of existing configurations. (Alternatively, could just remove the cron job, remove `AVOID_DAILY_AUTOCOMMITS` and let the timer be disabled if the user doesn't want it, but that would need some explicit, understood mechanism that enables the timer. Or could just remove the timer.) """]] comment_2_a225ebacd104f793dcffe08ec5ab880d._comment000066400000000000000000000017721453142634200410050ustar00rootroot00000000000000etckeeper-1.18.21/doc/todo/clear_up_confusion_about_daily_autocommit_and_systemd[[!comment format=mdwn username="joey" subject="""comment 2""" date="2020-05-05T19:16:58Z" content=""" I tried, as an experiment, adding a copy of etckeeper.service and etckeeper.timer with a different name (netkeeper). They were not enabled after writing the files, or after a systemctl daemon-reload. I even tried rebooting, and they're still not enabled. Next experiment: I uninstalled etckeeper and deleted the symlink in /etc for its timer. systemd no longer had the timer enabled. I then reinstalled it with apt. systemd still didn't have the timer enabled, the symlink did not come back. (Even after rebooting.) So, I'd think that there is no bug at all, except I am seeing the timer be enabled by that symlink on multiple machines, including a machine that I'm positive I've deployed entirely from configuration management. And I'm pretty sure I never manually enabled it on any of the machines I see it enabled on. Maybe something used to cause the timer to get auto-enabled and no longer does? """]] etckeeper-1.18.21/doc/todo/decide_what_to_do_about_the_debian_patches.mdwn000066400000000000000000000050511453142634200267300ustar00rootroot00000000000000There is a number of patches in the Debian BTS that has been pending since before I took over maintainership of the package. I am wondering what to do with them - a bunch seem relevant and I could bundle them in `debian/patches` but I am not sure I want to carry such a "fork" of etckeeper forever, so I would prefer to approve them here first. On the other hand, I do not want to flood you with 8 feature requests you have already seen. So I figured I would open a single todo item to quickly allow you to review the [patch set](https://bugs.debian.org/cgi-bin/pkgreport.cgi?include=tags%3Apatch&exclude=tags%3Apending&pend-exc=done&repeatmerged=no&src=etckeeper): * #519420 etckeeper: Add option to force commit after apt run. Hack to force an empty commit to keep track of package changes. Last change: Apr 2009. Marked "wontfix" in 2014. * #549354 etckeeper: don't warn about ignored files git-specific patch available, not sure how it behaves with other VCSes. seems to have at least another user (fmarier) Last change: Oct 2010. * #576915 30store-metadata: use GNUisms to achieve 1s runtime. concerns about portability to solaris, is this still an issue? Last change: Apr 2010. * #592158 etckeeper: Example for tracking installed packages sample post-install hook to keep track of installed packages in /etc. similar to #519420 - close? Last change: Aug 2010 * #612029 etckeeper: Example hook for generating GPG-encrypted bundle after every commit another sample post-install hook to secretely ship a git bundle to a backup server Last change: Feb 2011 * #613278 etckeeper: writing a commit message for the autocommit that happens after apt patch for git, with possible patch for bzr as well, requiring proposed upstream change for bzr, not merged. last change: Sep 2013 * #698062 logout hook yet *another* sample hook, by yours truly, add a new "logout" subcommand that can be added to bash_logout scripts. last change: Jan 2013 * #777612 etckeeper should read XDG_CONFIG_HOME/git/config look in standard locations for the git config, seems sound last change: Feb 2015 So to simplify, there are those groups of proposed changes: * sample hooks (592158, 612029, 698062) * bugfixes (549354, 777612) * features and improvements (519420, 576915, 613278) So any opinion about what to do with those? Should I submit them as separate issues? Or should I ask the original reporters to do that here? Or should I just close those issues? Thanks! -- [[anarcat]] etckeeper-1.18.21/doc/todo/done.mdwn000066400000000000000000000001721453142634200171650ustar00rootroot00000000000000recently fixed [[todo]] items. [[!inline pages="./* and link(./done) and !*/Discussion" sort=mtime show=10 archive=yes]] etckeeper-1.18.21/doc/todo/etckeeper_with_git_breaks_update-manager_.mdwn000066400000000000000000000027471453142634200265570ustar00rootroot00000000000000[Ubuntu LaunchPad bug #1335391](https://bugs.launchpad.net/ubuntu/+source/etckeeper/+bug/1335391) (Quoting the LaunchPad bug below, but I have experienced this issue in an identical manner.) I have configured etckeeper to use git. It works fine if I use apt-get or synaptic packet manager. But when the update-manger install new packet versions it ends with an "installation failed" message. When I check the status of the git repository in the etc directory, some changes are not committed, e.g.: On branch master Changes to be committed: (use "git reset HEAD ..." to unstage) modified: apt/apt.conf.d/01autoremove-kernels modified: init.d/resolvconf ProblemType: Bug DistroRelease: Ubuntu 14.04 Package: etckeeper 1.9ubuntu2 ProcVersionSignature: Ubuntu 3.13.0-29.53-generic 3.13.11.2 Uname: Linux 3.13.0-29-generic x86_64 NonfreeKernelModules: wl tbs6982fe tbs6680fe tbs6923fe tbs6985se tbs6928se tbs6982se tbs6991fe tbs6618fe tbs6922fe tbs6928fe tbs6991se ApportVersion: 2.14.1-0ubuntu3.2 Architecture: amd64 CurrentDesktop: Unity Date: Sat Jun 28 09:42:13 2014 InstallationDate: Installed on 2014-03-30 (89 days ago) InstallationMedia: Ubuntu 14.04 LTS "Trusty Tahr" - Daily amd64 (20140329) PackageArchitecture: all SourcePackage: etckeeper UpgradeStatus: No upgrade log present (probably fresh install) mtime.conffile..etc.etckeeper.etckeeper.conf: 2014-03-30T16:33:03.109833 > [[done]] --[[Joey]] etckeeper-1.18.21/doc/todo/etckeeper_with_git_breaks_update-manager_/000077500000000000000000000000001453142634200256565ustar00rootroot00000000000000comment_1_2ae8af745340c6f4d5ee87c74c96e870._comment000066400000000000000000000016111453142634200356710ustar00rootroot00000000000000etckeeper-1.18.21/doc/todo/etckeeper_with_git_breaks_update-manager_[[!comment format=mdwn username="https://launchpad.net/~codex24" nickname="codex24" subject="Workaround" date="2016-02-14T23:12:10Z" content=""" With etckeeper installed in Ubuntu using git as its VCS, using the Ubuntu Software Center fails with errors installArchives() failed: fatal: $HOME not set Correct this by adding the following file, /etc/etckeeper/pre-install.d/20setenv: #!/bin/sh # /etc/etckeeper/pre-install.d/20setenv: set HOME dir due to # unpassed environment in priviledge escallation of Ubuntu Software Center. # see https://bugs.launchpad.net/ubuntu/+source/etckeeper/+bug/1335391 if \[[ -z \"$HOME\" ]]; then export HOME=$(getent passwd root | cut -d: -f6) fi Also, ensure that the root account's git environment is properly initialized: root@janus:/etc# git config -l user.name=Root Janus user.email=codex24@gmail.com """]] comment_2_0324393d5a4f4e6a6174c27f1a53e886._comment000066400000000000000000000004441453142634200354330ustar00rootroot00000000000000etckeeper-1.18.21/doc/todo/etckeeper_with_git_breaks_update-manager_[[!comment format=mdwn username="joey" subject="""comment 2""" date="2016-02-15T17:09:15Z" content=""" user.email and user.name are set by etckeeper to sane fallback defaults. ubuntu has a seriously ancient version of etckeeper, which predates that. I've added a default for HOME. """]] etckeeper-1.18.21/doc/todo/etkeeper_warning_about_hardlinks_doesn__39__t_exclude_ignored_files.mdwn000066400000000000000000000010051453142634200337440ustar00rootroot00000000000000Etckeeper checks for possible hardlinks in the file `/etc/etckeeper/pre-commit.d/20warn-problem-files` but it doesn't seem to exclude the files that match the ".gitignore" directives. Tested: # cat .gitignore | grep -i py *.pyc *.pyo 15:12 root@someserver:/etc/fail2ban/action.d # ls -l smtp.pyc -rw-r--r-- 2 root root 5921 Jul 13 2017 smtp.pyc It would be better, for monitoring reasons, to exclude all those files that fall in the .gitignore pattern, as they won't be tracked anyway. etckeeper-1.18.21/doc/todo/fixed_typo_in_README.mdwn000066400000000000000000000002061453142634200221130ustar00rootroot00000000000000fixed typo in README https://github.com/Yky/etckeeper/commit/5f2556abbc404eb0d06b31f620fe655c8802d8e7 > applied [[done]] --[[Joey]] etckeeper-1.18.21/doc/todo/freebsd_pkgng_plugin.mdwn000066400000000000000000000005611453142634200224200ustar00rootroot00000000000000Get the same integration with FreeBSD pkg as with other package managers. Basic working plugin available at: > I've merged this. Of course it would be good to get the main Makefile > able to install it. Please open new todos if you have updates and thanks! > [[done]] > --[[Joey]] etckeeper-1.18.21/doc/todo/how_to_restore_from_etckeeper.mdwn000066400000000000000000000006531453142634200243600ustar00rootroot00000000000000Could we get in the README some info about how to restore from etckeeper assuming it's even possible. So say I hose my system. I reinstall everything. But now I'd like to migrate my old config but keep tracking changes going forward. What I've tried: 1) Renaming /etc breaks sudo 2) clone over /etc breaks passwd 3) clone to staging area and then move things over selectively Is #3 the proper way to restore an /etc Thanks etckeeper-1.18.21/doc/todo/how_to_restore_from_etckeeper/000077500000000000000000000000001453142634200234655ustar00rootroot00000000000000comment_1_e97948136569a070265c1cd757e3c889._comment000066400000000000000000000006141453142634200331320ustar00rootroot00000000000000etckeeper-1.18.21/doc/todo/how_to_restore_from_etckeeper[[!comment format=mdwn username="joey" subject="""comment 1""" date="2015-03-28T16:10:49Z" content=""" I would definitely go with #3. Unless I knew that the new system was identical to the old before any customizations to /etc -- in that case, cloning to /etc would work. Note that `etckeeper init` will fix up the file permissions of a clone of the repo, since etckeeper stores them. """]] etckeeper-1.18.21/doc/todo/include_mtime_into_metadata.mdwn000066400000000000000000000005571453142634200237560ustar00rootroot00000000000000It's impossible to know file modification time using git. etckeeper also saves some metadata, but not mtimes. Per-file mtimes are very useful to determine later when exactly change was happened. As of now, only date could be known, knowing there is `daily autocommit`, but time information is lost. Date is very imprecise, because there can be many changes per day. etckeeper-1.18.21/doc/todo/include_mtime_into_metadata/000077500000000000000000000000001453142634200230605ustar00rootroot00000000000000comment_1_9e75c36722c194fecef316ae99d1d75e._comment000066400000000000000000000017251453142634200331610ustar00rootroot00000000000000etckeeper-1.18.21/doc/todo/include_mtime_into_metadata[[!comment format=mdwn username="joey" subject="""comment 1""" date="2016-09-27T13:31:57Z" content=""" Are there any config files in /etc whose mtime influences the program they configure in some way? That would be a very good reason to include the mtime. If the goal is to keep track of multiple manual changes to /etc, the best thing to do is to manually run etckeeper commit after making the change. Relying on the daily autocommit is at best a fallback. Need to consider the resource impact of adding mtimes to /etc/.etckeeper would not be very bad. The files are already statted, so no extra overhead there. How about the size increase of /etc/.etckeeper? For each file in /etc, a line like `maybe touch -d '1970-01-01 00:00Z' foo` would be needed. (That seems the most compact available way to specifiy a time to touch.) On my system, that adds 136kb to /etc/.etckeeper, a little bit more than doubling its size. That doesn't seem too bad a resource impact. """]] etckeeper-1.18.21/doc/todo/make_Perl_optional.mdwn000066400000000000000000000006531453142634200220500ustar00rootroot00000000000000Hi Joey, New change making Perl optional, on smaller systems: https://gitlab.com/HRio/etckeeper/tree/remove-perl-3-rebased It will use Perl if its installed or else fall back to Bourne Shell. "make test" passes on Alpine Linux without Perl installed. Can you please review? Thanks, Henrik this change replaces: https://etckeeper.branchable.com/todo/remove_remaining_perl_usage/ > merge [[done]] thank you! --[[Joey]] etckeeper-1.18.21/doc/todo/metadata_changes_don__39__t_cause_a_new_commit.mdwn000066400000000000000000000010631453142634200274050ustar00rootroot00000000000000If the only changes in /etc are metadata changes that the VCS doesn't natively track, then etckeeper refuses to make a new commit for them. At least with git. This is because the metadata in `/etc/.etckeeper` is only updated from `etckeeper pre-commit`, which is only called by the VCS pre-commit hook; and since the VCS doesn't track the metadata changes, it doesn't think that a new commit needs to be made, and doesn't call the hook! I think the best solution might be to call `etckeeper pre-commit` from in `etckeeper commit`. > [[fixed|done]] --[[Joey]] etckeeper-1.18.21/doc/todo/metadata_changes_don__39__t_cause_a_new_commit/000077500000000000000000000000001453142634200265165ustar00rootroot00000000000000comment_1_760124afc8a858dc1e407c9126d606b8._comment000066400000000000000000000005121453142634200363440ustar00rootroot00000000000000etckeeper-1.18.21/doc/todo/metadata_changes_don__39__t_cause_a_new_commit[[!comment format=mdwn username="lukeshu" avatar="http://cdn.libravatar.org/avatar/002a91d6bdfd6cfecde043c0a7f39123" subject="comment 1" date="2016-11-08T14:40:31Z" content=""" Relatedly, `etckeeper unclean` won't show metadata changes, which means that things like `/etc/etckeeper/daily` won't end up making a commit. """]] etckeeper-1.18.21/doc/todo/metadata_ignore_filters_do_not_work.mdwn000066400000000000000000000120771453142634200255260ustar00rootroot00000000000000I'm seeing numerous performance problems with etckeeper on my servers. It generally happens when there is a git repository underneath `/etc` or some other thing that generates lots of small files. Typically, what I try next is to make git ignore those files, which works for the git side of things, but not for the etckeeper side of things, as all those files still get listed (and parsed) by etckeeper's `.etckeeper` metadata file. The problem here is the metadata "ignore" filter doesn't really work. We can see this in multiple different bug reports here, like [[todo/etkeeper_warning_about_hardlinks_doesn__39__t_exclude_ignored_files]], [[todo/Do_not_recreate_ignored_empty_directory]], or [[todo/what_if_there_is_a_Git_repo_somewhere_underneath___47__etc__63__/]]. I think the approach taken to solve this problem is incorrect, which is why I am opening this issue to regroup all of them in one single place. From what I can tell, the `30store-metadata` script tries to ignore files ignored by git. But it tries to do that using `grep`, and git ignore files are not `grep` patterns at all. In fact, they're not even regular expressions, they are like glob patterns, but with many different exceptions (like `!` to negate a pattern, for example). I do not think there is a command that can faithfully reproduce this outside of git itself. Right now, we basically do this: 1. list all empty directories, and add them to the metadata, regardless of gitignore (which is [[todo/Do_not_recreate_ignored_empty_directory]]) 2. then list all files and directories (empty or not), try to filter out ignored files, and try to ignore normal modes, which means: 1. `find $NOVCS \( -type f -or -type d \)` (basically skips `.git` and friends) 2. `sed 's/^\.\///' | grep -xFvf $(git ls-files -oi --exclude-standard; git ls-files -oi --exclude-standard --directory | sort -u)` 3. some inline perl script which actually systematically chmods all files, and optionally changes the owner and group if they are not the EUID/EGID Now, the problem that concerns us here is mostly in step 2.2 above. That `grep` command is bad for many reasons, but the first of which is `-x`: that will do a full match on the entire line so if you have, say, `puppet` in your `.gitignore` that will match the `puppet` directory, but nothing *underneath*, which is not how gitignore files work *at all*. I think the proper way to do this is to actually start from files git actually tracks, since in that step, we're trying to keep track of modes and owners of actual files managed by git. It seems to me much better to make git list the files, then process *that*, than try to reimplement git-ignore outside of git. I think the pseudocode then would be something like, for the git case: 1. `git ls-files | sort -u | maybe_chmod_chown` 2. `git ls-files --others --exclude-standard --directory | sed -e "s/^/mkdir -p /"` ... and that's it! The trick here is we separate the normal file tracking (first step) from the empty directory listing (second step). I haven't actually tested this because I'm out of battery in that third yak razor, but I wanted to brainstorm this here first to see if we could somehow make sense of this. (Also, I don't think that the `maybe_chmod_chown` script should systematically change the mode on files, but that's a different story (and optimization)...) -- [[anarcat]] Update: and I think the patch is [something like this](https://salsa.debian.org/debian/etckeeper/-/commit/0a4305886c6e9501eec223880fa9ae8776b4947e) (see [branch](https://salsa.debian.org/debian/etckeeper/-/commits/new-git-ignores) for latest. it doesn't *quite* work the way I expected, unfortunately. a few examples: [[!format diff """ diff --git a/.etckeeper b/.etckeeper index 71fb3188..8b34a087 100755 --- a/.etckeeper +++ b/.etckeeper @@ -3,34 +3,28 @@ mkdir -p './ImageMagick' mkdir -p './X11/xkb' mkdir -p './X11/xorg.conf.d' -mkdir -p './apm/event.d' -mkdir -p './apm/scripts.d' +mkdir -p './apm' [...] """]] in the above example, you see that `apm` is correctly added but not the underlying `events.d` and `scripts.d`... it *does* correctly follow ignores for most stuff however, which is an improvement. I did have to bend over backwards to remove symlinks from the listing, with that ungodly `sed`. and, in general, we have quoting problems here because we pipe filenames that might have newlines in them... thankfully, we might consider `/etc` trusted, but that's something that makes me uncomfortable about this whole thing in the first place... here at least, a bunch of stuff is cleaned up: [[!format txt """ root@marcos:/etc# git diff --cached --stat .etckeeper | 636 ++++------------------------------------------------------------------------------------------------------------------------------------------------ 1 file changed, 17 insertions(+), 619 deletions(-) root@marcos:/etc# wc -l .etckeeper 7419 .etckeeper """]] Anyways, let me know what you think. The main tradeoff here is that we lose empty subdirectories, which maybe is a big deal, but for my use cases, I don't expect etckeeper to recover everything like this, that's what backups are for. ;) etckeeper-1.18.21/doc/todo/metadata_ignore_filters_do_not_work/000077500000000000000000000000001453142634200246305ustar00rootroot00000000000000comment_1_a0a00282ce442b3b485d0c3b6f1a8b32._comment000066400000000000000000000010721453142634200345560ustar00rootroot00000000000000etckeeper-1.18.21/doc/todo/metadata_ignore_filters_do_not_work[[!comment format=mdwn username="joey" subject="""comment 1""" date="2022-11-08T18:11:53Z" content=""" You have misunderstood (and oddly, misquoted) the code. 30store-metadata already uses `git ls-files -oi --exclude-standard` to list gitignored files. The use of grep is only to search through the resulting list of ignored files, to find an exact match for a filename.. That is indeed inefficient when there are a lot of ignored files. But it matches ignored files correctly. (30store-metadata does grep .darcsignore, I don't know if that is a good idea.) """]] comment_2_23349351fd7f424bfd3073136a6f606c._comment000066400000000000000000000020401453142634200343700ustar00rootroot00000000000000etckeeper-1.18.21/doc/todo/metadata_ignore_filters_do_not_work[[!comment format=mdwn username="anarcat" avatar="http://cdn.libravatar.org/avatar/1bb99a4f017a1d253ad5790c150d0f0b" subject="comment 2" date="2022-11-15T17:49:48Z" content=""" > You have misunderstood (and oddly, misquoted) the code. > > 30store-metadata already uses git ls-files -oi --exclude-standard to list gitignored files. The use of grep is only to search through the resulting list of ignored files, to find an exact match for a filename.. That is indeed inefficient when there are a lot of ignored files. But it matches ignored files correctly. But why do we list *all* the ignored files in the metadata store? Shouldn't we store data only about files tracked with git? Maybe you are correct and I do not understand the purpose of this code, I thought the point of the metadata store was to restore modes when checking out files, and therefore that adding ignored files in there was not necessary. > (30store-metadata does grep .darcsignore, I don't know if that is a good idea.) that, i cannot say. i haven't used darcs in ages. """]] comment_3_eff7bec1a6b87cc6c2546d181ce8296e._comment000066400000000000000000000012461453142634200350610ustar00rootroot00000000000000etckeeper-1.18.21/doc/todo/metadata_ignore_filters_do_not_work[[!comment format=mdwn username="joey" subject="""comment 3""" date="2022-11-16T17:15:50Z" content=""" > But why do we list _all_ the ignored files in the metadata store? It doesn't. This code is what filters those ignored files out of the ones that are included. It's easy to show it works: root@darkstar:~>grep mtab /etc/.gitignore mtab mtab.fuselock root@darkstar:~>ls /etc/mtab /etc/mtab@ root@darkstar:~>grep mtab /etc/.etckeeper - exit 1 root@darkstar:~>grep adjtime /etc/.gitignore adjtime root@darkstar:~>ls /etc/adjtime /etc/adjtime root@darkstar:~>grep adjtime /etc/.etckeeper - exit 1 You have not yet given an example of it not working. """]] comment_4_dc188a789e1b40158b14a88d7d088ee2._comment000066400000000000000000000045151453142634200345630ustar00rootroot00000000000000etckeeper-1.18.21/doc/todo/metadata_ignore_filters_do_not_work[[!comment format=mdwn username="anarcat" avatar="http://cdn.libravatar.org/avatar/1bb99a4f017a1d253ad5790c150d0f0b" subject="some examples" date="2022-11-23T16:32:38Z" content=""" here's an example, from my workstation, which has a similar configuration to the server i was working on for this: root@curie:/etc# grep puppet/code/production .gitignore .etckeeper .gitignore:puppet/code/production .etckeeper:mkdir -p './puppet/code/production' .etckeeper:maybe chown 'puppet' 'puppet/code/production' .etckeeper:maybe chgrp 'puppet' 'puppet/code/production' .etckeeper:maybe chmod 0750 'puppet/code/production' root@curie:/etc# ls -al puppet/code/production/ total 18 drwxr-x--- 2 puppet puppet 2 30 jun 2020 . drwxr-xr-x 3 root root 3 30 jun 2020 .. here you see the empty directory is managed in .etckeeper even though it's ignored. i thought i provided clearer examples of this in the original article, but i guess it wasn't very explicit... here's an example: right now, if i revert the changes I made to `etckeeper/pre-commit.d/30store-metadata`, and run the hook: VCS=git /etc/etckeeper/pre-commit.d/30store-metadata ... i get this: root@marcos:/etc# grep puppet/code/production .gitignore puppet/code/production root@marcos:/etc# grep -c puppet/code/production .etckeeper 87 it's mostly empty directories, but there's also other stuff: root@marcos:/etc# grep puppet/code/production .etckeeper | head -3 mkdir -p './puppet/code/production/.g10k/CraigWatson1987-transmission-2.2.1/spec/fixtures' mkdir -p './puppet/code/production/.g10k/duritong-sysctl-0.0.12/spec/fixtures/manifests' mkdir -p './puppet/code/production/.g10k/duritong-sysctl-0.0.12/spec/fixtures/modules/sysctl' root@marcos:/etc# grep puppet/code/production .etckeeper | tail -3 mkdir -p './puppet/code/production/modules/inifile/locales/ja' maybe chown 'anarcat' 'puppet/code/production' maybe chmod 0755 'puppet/code/production' with the patch, it looks like this instead: root@marcos:/etc# grep puppet/code/production .gitignore puppet/code/production root@marcos:/etc# grep -c puppet/code/production .etckeeper 0 the patch proposed here, together with the one on [[todo/metadata_ignore_filters_do_not_work]] improve etckeeper performance tremendously in my case. """]] comment_5_e43de8fe580d3f6884cc7b94c52e0a5b._comment000066400000000000000000000003761453142634200350060ustar00rootroot00000000000000etckeeper-1.18.21/doc/todo/metadata_ignore_filters_do_not_work[[!comment format=mdwn username="anarcat" avatar="http://cdn.libravatar.org/avatar/1bb99a4f017a1d253ad5790c150d0f0b" subject="comment 5" date="2022-11-23T16:33:06Z" content=""" argh, i meant [[todo/optimize_mode_metadata:_ignore_defaults]]... """]] etckeeper-1.18.21/doc/todo/multiple_highlevel_package_managers.mdwn000066400000000000000000000004541453142634200254550ustar00rootroot00000000000000Apparently openSUSE supports both ZYpp and YUM highlevel package managers. The `HIGHLEVEL_PACKAGE_MANAGER` config doesn't allow expressing that. There's a pull request here, but it needs changes to eg, handle etckeeper.spec's tweaking of etckeeper.conf. etckeeper-1.18.21/doc/todo/multiple_highlevel_package_managers/000077500000000000000000000000001453142634200245635ustar00rootroot00000000000000comment_1_be96d2f726ce5c9adabdaf46cd17dcc6._comment000066400000000000000000000006411453142634200352770ustar00rootroot00000000000000etckeeper-1.18.21/doc/todo/multiple_highlevel_package_managers[[!comment format=mdwn username="https://www.google.com/accounts/o8/id?id=AItOawkZ9t02dAh3YsUhVRJ9uBE4xUt_ZUrDs8s" nickname="さんご" subject="How should we send you new patches?" date="2014-12-24T00:37:10Z" content=""" I will rewrite the patch of supporting multi highlevel-package-manager. But, how should we send you new patches? a) pullrequest on GitHub. b) the others(????????) Please tell us. """]] etckeeper-1.18.21/doc/todo/optimize_mode_metadata:_ignore_defaults.mdwn000066400000000000000000000050441453142634200262730ustar00rootroot00000000000000here's another idea: why do we store metadata for files that have "default" modes (as understood by git) like `0755` (for directories) or `0644` (for files)? This seems like a huge waste of time and something that grows the `.etckeeper` metadata file needlessly. I believe the following patch would improve things quite a bit: [[!format diff """ modified pre-commit.d/30store-metadata @@ -92,7 +92,9 @@ maybe_chmod_chown() { if ($gid != $)) { printf "maybe chgrp $q%s$q %s\n", gidname($gid), $_; } - printf "maybe chmod %04o %s\n", $mode & 07777, $_; + if ($mode != 0100644 and $mode != 040755) { + printf "maybe chmod %04o %s\n", $mode & 07777, $_; + } ' return $? else """]] See also [this commit](https://salsa.debian.org/debian/etckeeper/-/commit/73fccbde9c30156209362d74811e04dd12de9106) which is the current HEAD of [my optimize-default-metadata branch](https://salsa.debian.org/debian/etckeeper/-/commits/optimize-default-metadata). In my messy home server, this gives me that resulting diff: [[!format txt """ root@marcos:/etc# git diff --cached --stat .etckeeper | 10231 -------------------------------------------------------------------------------------------------------------------------------------------------- 1 file changed, 10231 deletions(-) """]] yes, you read that right, that's 10 *thousand* files cleaned up. and yes, it seems like i have over 20,000 files in /etc. yikes. (it's mostly because this is a puppet server and there's lots of git repos under there, and cache files. and yes, those are in the .gitignore and shouldn't even be in the `.etckeeper` file in the first place, but that's a different story, see [[todo/metadata_ignore_filters_do_not_work]]. before this and the git ignore patch: [[!format txt """ root@marcos:/etc# VCS=git time sh /home/anarcat/src/etckeeper/pre-commit.d/30store-metadata 0.22user 0.13system 0:00.34elapsed 104%CPU (0avgtext+0avgdata 11500maxresident)k 0inputs+12088outputs (0major+4497minor)pagefaults 0swaps """]] after: [[!format txt """ root@marcos:/etc# VCS=git time sh /etc/etckeeper/pre-commit.d/30store-metadata 0.07user 0.02system 0:00.09elapsed 106%CPU (0avgtext+0avgdata 7748maxresident)k 0inputs+2080outputs (0major+3287minor)pagefaults 0swaps """]] it doesn't look like much, but that's a 10-fold improvement. and it doesn't count the time it takes to actually do the commit, which I haven't benchmarked, but it takes a few *seconds* to commit before the change, and a few miliseconds after. so anyways, i figured that would be a worthwhile optimisation! :) --[[anarcat]] etckeeper-1.18.21/doc/todo/optimize_mode_metadata:_ignore_defaults/000077500000000000000000000000001453142634200254015ustar00rootroot00000000000000comment_1_bd12401aec0d25d31e2cb260389cb98e._comment000066400000000000000000000003111453142634200354160ustar00rootroot00000000000000etckeeper-1.18.21/doc/todo/optimize_mode_metadata:_ignore_defaults[[!comment format=mdwn username="joey" subject="""comment 1""" date="2022-11-08T18:49:10Z" content=""" You are assuming that root has a umask of 022. With other umasks, git uses other modes. """]] comment_2_fb6294e6d3d04eb26609aca0163d0720._comment000066400000000000000000000003711453142634200352710ustar00rootroot00000000000000etckeeper-1.18.21/doc/todo/optimize_mode_metadata:_ignore_defaults[[!comment format=mdwn username="anarcat" avatar="http://cdn.libravatar.org/avatar/1bb99a4f017a1d253ad5790c150d0f0b" subject="comment 2" date="2022-11-15T17:50:17Z" content=""" sure, parsing umask is a possible improvement to this patch. """]] etckeeper-1.18.21/doc/todo/origin_branch.mdwn000066400000000000000000000011331453142634200210420ustar00rootroot00000000000000keep an origin branch with the files debian ships Not sure quite how to do this yet, it seems it would need to clone the repo, switch to origin, and commit, then push back to /etc, and either merge origin or commit a second time. And do this after apt runs only, of course. Alternatively, commit in /etc, then clone the repo, switch to origin, and cherry pick the commit into origin? Of coure, unless etckeeper is installed by debootstrap or thereabouts, you won't have a true pristine origin branch. etcgit manages this, maybe steal its method? git://git.debian.org/git/users/jo-guest/etcgit.git etckeeper-1.18.21/doc/todo/preserve_permissions_in_update-ignore.mdwn000066400000000000000000000053561453142634200260500ustar00rootroot00000000000000I've recently noticed that update-ignore forces my /etc/.gitignore permissions to be 0600. I've written up [a patch to let it preserve any preexisting VCS ignore file's permissions and ownership](https://gitlab.com/eefi/etckeeper/-/commit/3b824ea5c8218022347a325a20811a84efa6feb7). The main practical impact of the current state before this patch is that, at least on Debian systems, the second commit into the /etc repo is sullied by an unexpected edit to /etc/.etckeeper updating the permissions for .gitignore from 0644 to 0600. This happens through the following course of events: 1. During initial etckeeper package installation, the postinst runs `etckeeper init`, creating a 0644 .gitignore file, because update-ignore just follows the active umask when creating a brand new VCS ignore file. 2. This initial `etckeeper init` creates a first commit that includes an .etckeeper that records the 0644 permissions for .gitignore. 3. Still during this initial etckeeper package installation, the last step of postinst is to run `etckeeper update-ignore`. This causes the permissions on .gitignore to be changed to 0600. 4. The administrator makes some changes in /etc. 5. The administrator uses `etckeeper vcs status` (or `git -C /etc status`) to check what she's about to commit. Because .etckeeper usually isn't updated until the pre-commit is run, the pending change to the .gitignore permissions isn't shown. 6. The administrator commits her changes. The pre-commit hook updates .etckeeper with .gitignore's new permissions, and that change gets silently lumped in with the other changes actually explicitly planned by the administrator. My patch takes the approach of preserving any special permissions and ownership an administrator might set. An alternative could be to make update-ignore force root:root 0600 always, by making the results from creating a new VCS ignore file match the results when updating an existing VCS ignore file. But either way, I'd propose that update-ignore be made consistent. The following are details from `git request-pull` for where to get the specific commit I'm requesting get pulled. ``` The following changes since commit 38d24e461f332ede0dd76d78e63948812ef1b5ab: (2020-11-09 09:39:52 +0000) are available in the Git repository at: https://gitlab.com/eefi/etckeeper.git eefi/preserve-perms-in-update-ignore for you to fetch changes up to 3b824ea5c8218022347a325a20811a84efa6feb7: update-ignore: Preserve existing permissions (2020-11-22 16:48:21 -0500) ---------------------------------------------------------------- Austin Chu (1): update-ignore: Preserve existing permissions debian/changelog | 2 ++ update-ignore.d/01update-ignore | 5 +++++ 2 files changed, 7 insertions(+) ``` > [[fixed|done]] --[[Joey]] etckeeper-1.18.21/doc/todo/preserve_permissions_in_update-ignore/000077500000000000000000000000001453142634200251505ustar00rootroot00000000000000comment_1_7b06f2e4211c4631f5fa6f8992ac6723._comment000066400000000000000000000013421453142634200350020ustar00rootroot00000000000000etckeeper-1.18.21/doc/todo/preserve_permissions_in_update-ignore[[!comment format=mdwn username="joey" subject="""comment 1""" date="2020-11-23T16:14:15Z" content=""" Crucially, etckeeper does not write anything sensitive to .gitignore, so there's no information exposure risk, except for anything the admin may choose to put in it. So it's fine to leave it 0644 by default on new installs. Conversely, etckeeper can't easily tell if the admin might have put something sensitive into .gitignore, so it should not try to force the permissions back to 0644 on existing installs that have inherited the temp file permissions. Ingenious way to preserve the permissions there. I checked and busybox cp supports -fp, so it should bee portable enough to not be a problem. I'm applying this patch. """]] etckeeper-1.18.21/doc/todo/push_remote_branch.mdwn000066400000000000000000000015121453142634200221060ustar00rootroot00000000000000Several people have written patches to extend `PUSH_REMOTE` to be able to push a branch other than master. For example, It seems that these are not fully flexible either. Maybe someone wants to push 2 branches, or push different branches to different remotes. I think that adding `PUSH_REMOTE` was a mistake. It would be better to remove it, and add to the readme an example of writing your own `/etc/etckeeper/commit.d/99push` script that does exactly the kind of pushing you want. The only reason I've not done so is it would break compatibility for anyone using this feature. --[[Joey]] > Well, there was no point in it hardcoding master. `git push origin` will > push whatever branches you've configured git to push. So, made that > change, which I think is sufficient. [[done]] --[[Joey]] etckeeper-1.18.21/doc/todo/push_remote_branch/000077500000000000000000000000001453142634200212205ustar00rootroot00000000000000etckeeper-1.18.21/doc/todo/push_remote_branch/comment_1_f56144bea11901b8b1df4bcf552df801._comment000066400000000000000000000005351453142634200313320ustar00rootroot00000000000000[[!comment format=mdwn username="jim" avatar="http://cdn.libravatar.org/avatar/b538cf412c3060bed47b86676cd7cba1" subject="Agreed! Please implement pushing to branches!" date="2017-01-31T23:56:51Z" content=""" Kind of a pain to constantly edit commit.d/99push to change the branch. An easy fix for a much needed feature. Please implement! """]] etckeeper-1.18.21/doc/todo/python3_support.mdwn000066400000000000000000000011321453142634200214350ustar00rootroot00000000000000etckeeper doesn't support python3 in its current form. in [bug 811180](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=811180), mattia provided a NMU that fixed this, but unfortunately I totally forgot to include it in the later uploads so it got destroyed. i have now remerged it in the debian branch, and you now have patches there to review to make etckeeper (or, more specifically, the bzr plugin) survive the Python 2 dead parrot stage. there's also another patch there to fix sort order with UTF-8 which I do not understand very well, but i hope you will find useful. thanks! -- [[anarcat]] etckeeper-1.18.21/doc/todo/python3_support/000077500000000000000000000000001453142634200205515ustar00rootroot00000000000000etckeeper-1.18.21/doc/todo/python3_support/comment_1_681d64c82b63eb4c1bab369b9a640787._comment000066400000000000000000000003011453142634200305360ustar00rootroot00000000000000[[!comment format=mdwn username="joey" subject="""comment 1""" date="2020-05-05T18:33:40Z" content=""" It's not clear to me what commits you're referring to, or where I can get them. """]] etckeeper-1.18.21/doc/todo/python3_support/comment_2_be3f3171c06d1baf0805a26065225414._comment000066400000000000000000000006631453142634200303510ustar00rootroot00000000000000[[!comment format=mdwn username="nathanst" avatar="http://cdn.libravatar.org/avatar/1844c7b9b45fdd9049494b4a09b26a49" subject="Debian patches" date="2020-05-13T22:54:12Z" content=""" I believe the patches referred to are found in this commit (pushed on the same date as this \"python3 support\" page was created): """]] etckeeper-1.18.21/doc/todo/python3_support/comment_3_3ca5e6f481d97b668a12ff754feda861._comment000066400000000000000000000012351453142634200307230ustar00rootroot00000000000000[[!comment format=mdwn username="joey" subject="""comment 3""" date="2020-11-23T16:40:33Z" content=""" I think that, since I've removed the debian directory upstream, the only relevant thing would be adding the new etckeeper-brz and perhaps dropping etckeeper-bzr. And maybe something about changing the PYTHON value in Makefile, but since that also affects etckeeper-dnf, it would need to be checked that that at least builds too. If someone wants to submit that as a git branch, ok.. Untangling it from a debian patch that includes other changes, including ones that don't actually do anything (http://bugs.debian.org/975562) does not appeal to me myself. """]] etckeeper-1.18.21/doc/todo/regex_in_20-warn-problem-files.mdwn000066400000000000000000000003601453142634200240430ustar00rootroot00000000000000 exclude_internal () { grep -E -v '(^|/)(.git|.hg|.bzr|_darcs)/' } should probably escape the `.`s. exclude_internal () { grep -E -v '(^|/)(\.git|\.hg|\.bzr|_darcs)/' } > [[fixed|done]] --[[Joey]] etckeeper-1.18.21/doc/todo/remove_remaining_perl_usage.mdwn000066400000000000000000000006131453142634200237740ustar00rootroot00000000000000In order to run etckeeper on e.g. embedded systems which does not have perl, I've removed the last parts using perl. I have run this on my custom system and it works as expected for me. Link to github commit: > [[done]]; another patch updated this one to address my review and has > been merged. --[[Joey]] etckeeper-1.18.21/doc/todo/remove_remaining_perl_usage/000077500000000000000000000000001453142634200231055ustar00rootroot00000000000000comment_1_c901ff31a0cddf4912123c6443876327._comment000066400000000000000000000010501453142634200326400ustar00rootroot00000000000000etckeeper-1.18.21/doc/todo/remove_remaining_perl_usage[[!comment format=mdwn username="joey" subject="""comment 1""" date="2015-06-10T19:50:30Z" content=""" Reviewing this patch, I noticed a bug in the first hunk. lsscripts currently limits the files it finds to those matching a regexp. IIRC, this is needed, amoung other things, to avoid .dpkg-old files being run. Looking at the second hunk, I suspect that calling `id` twice per file is going to be significantly slower than the perl implementation. There also seems to be missing escaping of single quotes in filenames in the second hunk. """]] requires___96__user.email__96___be_set_under_undocumented_circumstances.mdwn000066400000000000000000000045341453142634200343130ustar00rootroot00000000000000etckeeper-1.18.21/doc/todo[[https://unix.stackexchange.com/questions/368850/ansible-role-why-do-i-have-to-set-user-email-in-etckeeper/368851]] etckeeper expects that users set git `user.email`. But it does not document this, or suggest a best way to do it. In common usage, this expectation is masked. I believe the conditions for it breaking are: 1. user.email is not set in git, AND 2. the system hostname cannot be resolved to an FQDN, AND 3. /etc/mailname does not exist (it is created by the Debian exim packages?) AND 4. etckeeper is not run from sudo AND 5. etckeeper is not run from a tty In this situation, etckeeper requires users to set `user.email` in /root/.gitconfig, or to have set it in /etc/.git/config immediately after `etckeeper init`. This is not Ansible-specific: the last two conditions will also arise in the daily autocommit script. ● etckeeper.service - Autocommit of changes in /etc directory Loaded: loaded (/lib/systemd/system/etckeeper.service; static; vendor preset: enabled) Active: failed (Result: exit-code) since Sat 2017-06-03 00:22:20 BST; 5s ago Docs: man:etckeeper(8) Process: 2989 ExecStart=/etc/etckeeper/daily (code=exited, status=128) Main PID: 2989 (code=exited, status=128) Jun 03 00:22:20 unstable daily[2989]: Run Jun 03 00:22:20 unstable daily[2989]: git config --global user.email "you@example.com" Jun 03 00:22:20 unstable daily[2989]: git config --global user.name "Your Name" Jun 03 00:22:20 unstable daily[2989]: to set your account's default identity. Jun 03 00:22:20 unstable daily[2989]: Omit --global to set the identity only in this repository. Jun 03 00:22:20 unstable daily[2989]: fatal: unable to auto-detect email address (got 'root@unstable.(none)') Jun 03 00:22:20 unstable systemd[1]: etckeeper.service: Main process exited, code=exited, status=128/n/a Jun 03 00:22:20 unstable systemd[1]: Failed to start Autocommit of changes in /etc directory. Jun 03 00:22:20 unstable systemd[1]: etckeeper.service: Unit entered failed state. Jun 03 00:22:20 unstable systemd[1]: etckeeper.service: Failed with result 'exit-code'. IMO, considering how to document this behaviour shows it to be user-unfriendly. Therefore, it would be simplest if etckeeper could fall back to using `$(id -un)`, once `$(tty)` fails. > Set `USER=$(whoami)`, for git only. [[done]] --[[Joey]] etckeeper-1.18.21/doc/todo/requires___96__user.email__96___be_set_under_undocumented_circumstances/000077500000000000000000000000001453142634200334755ustar00rootroot00000000000000comment_1_f8399058ebbf3059000e6528296cc1e9._comment000066400000000000000000000022031453142634200432570ustar00rootroot00000000000000etckeeper-1.18.21/doc/todo/requires___96__user.email__96___be_set_under_undocumented_circumstances[[!comment format=mdwn username="joey" subject="""comment 1""" date="2017-06-08T17:00:19Z" content=""" What actually requires user.email be set under undocumented circumstances? git does. Personally, I feel this is a total misfeature on git's part; git commit should succeed under all configuraations. Every single program that automates `git commit` is potentially buggy otherwise. Anyway, yes, setting `USER=$(id -un)` (or whoami) would make the code that currently is used to handle sudo users be always run, and so git and any other VCSs that break in unusual circumstances would always work (at least as far as username and email goes, who knows what other requirements VCSs may have). The downside is that this could change etckeeper's behavior, since it would now be guessing at the user name and email, and may make different choices than git does. Setting USER would also impact the code for other VCSs than git. For example, the code for hg always sets HGUSER when USER is set. I don't know if the others VCSs are as picky as git; if this kind of breakage is not a problem for them it might be best to only set USER when using git. """]] etckeeper-1.18.21/doc/todo/running___96__find_.__96___in___47___prints_warnings.mdwn000066400000000000000000000021071453142634200301660ustar00rootroot00000000000000I am trying to make etckeeper track `/etc` and another folder in `/`. However the script `20-warn-problem-files` reports many errors like find: `./proc/7010/task/7010/fd/5': No such file or directory find: `./proc/7010/task/7010/fd/5': No such file or directory find: `./proc/7010/task/7010/fd/5': No such file or directory find: `./proc/7010/task/7010/fdinfo/5': No such file or directory find: `./proc/7010/task/7010/fdinfo/5': No such file or directory find: `./proc/7010/task/7010/fdinfo/5': No such file or directory Due to files in `/proc` being created and deleted while `find` is running. I am not sure why `find` needs to run at all, when instead one could analyze the output of git ls-files and see if any of those files are problematic. > Using etckeeper to track all of `/` is not a supported use case. > You're free to try to use etckeeper that way, but when it breaks, you get > to modify it to work yourself, and it seems unlikely that the resulting > patches would be suitable to be applied to etckeeper. > > So [[wontfix|done]], sorry. --[[Joey]] etckeeper-1.18.21/doc/todo/split_the_repo.mdwn000066400000000000000000000007251453142634200212640ustar00rootroot00000000000000split the repo One way to split it would be to put private (non-world-readable) files one one repo, and public in another. This would need either symlink farming or git "fake bare" repos, both of which are not pleasant, yet. Another way would be to allow splitting out subdirs into their own repos. This is already doable, would just need modifying the pre-install and post-instlal stuff (ie, it needs to commit in the subdirs too). Using mr would be a possibility.. etckeeper-1.18.21/doc/todo/track_multiple_directories.mdwn000066400000000000000000000003361453142634200236550ustar00rootroot00000000000000Some people would like etckeeper to be able to track multiple directories, not just /etc. There have been 2 patches proposed: * * etckeeper-1.18.21/doc/todo/track_multiple_directories/000077500000000000000000000000001453142634200227645ustar00rootroot00000000000000comment_10_89b0ea104e18ec73f743b6d3e9aee1a9._comment000066400000000000000000000003741453142634200332020ustar00rootroot00000000000000etckeeper-1.18.21/doc/todo/track_multiple_directories[[!comment format=mdwn username="voltagex@69f6e3462800a695a8565ddc064de13207caf99f" nickname="voltagex" subject="This is needed for FreeBSD" date="2016-03-20T04:43:30Z" content=""" FreeBSD splits configuration across /etc and /usr/local/etc """]] comment_11_353f4ec6cb4c575c9459b430236e27d1._comment000066400000000000000000000016131453142634200327000ustar00rootroot00000000000000etckeeper-1.18.21/doc/todo/track_multiple_directories[[!comment format=mdwn username="doneg" subject="comment 11" date="2016-09-23T09:14:21Z" content=""" You already have -d support, now can you do, please, another step to track multiple dirs by adding cycle into `/etc/cron.daily/etckeeper` which would commit from multiple dirs. This could be variable in `/etc/etckeeper/etckeeper.conf`, for example `ADD_DIRS=\"/usr/local/etc /boot/grub\"`, and cron.daily script could just `for dir in $ADD_DIRS` and `commit -d $dir` them all. This requires just few lines to acquire such great functionality. For example, `/etc/grub2.cfg` is very important for the health of a system and it's never tracked by etckeeper by default because it's symlink to `/boot/grub2/grub.cfg`. We just have another server not survive reboot after simple `yum update` because grub.conf got wrong lvm parameters, and we unable to track when this change was happened first time. """]] comment_1_de6b27ba6b98790101d9ab1a37d752dc._comment000066400000000000000000000003121453142634200330220ustar00rootroot00000000000000etckeeper-1.18.21/doc/todo/track_multiple_directories[[!comment format=mdwn username="joey" subject="""comment 1""" date="2014-12-22T20:54:14Z" content=""" Personally, this seems unnecessary complication and unnecessary widening of scope to me. """]] comment_2_042f7831f641c66396ef38c912692ae3._comment000066400000000000000000000036731453142634200325030ustar00rootroot00000000000000etckeeper-1.18.21/doc/todo/track_multiple_directories[[!comment format=mdwn username="https://www.google.com/accounts/o8/id?id=AItOawlCXirWXlbn1_Ma9G5w3KYILEmb75-I9Do" nickname="Salve J." subject="track multiple directories = good" date="2014-12-23T05:26:22Z" content=""" Allright, here's my use case. I have some applications i develop, where others now and then update its configurations. These applications may be installed using the packaging system in use on that machine (we make RPM and DEB packages), and that the accompaning \"configuration files\" might include templates, customer configuration files, documentation, and lots of other things that are deemed safe by $bosses to be \"safe for editing\". Some of these files are in /etc, most are not. The important thing is that they are regular text files.I' I also have some other regular services that have all their important/useful files outside /etc (e.g. our BIND installation, which has their zone files deep in some directory in /usr/local/etc somewhere). I'd like to track changes in those files too, with the useful features etckeeper do so well. For me, the important thing is to make sure that when someone does something stupid (as people sometimes do, myself included), that we have an easy undo facility to rely on. I think etckeeper would fit this role nicely, because etckeeper helps checking for uncommitted files in lots of useful situations, and does the committing if some of us happen to forget to do it. This means we get to have an \"undo button\" that actually WORKS (since stuff is actually committed!). I like that. Now, how would this actually be managed by etckeeper? No idea, but I'm happy to help and have a conversation around this. Maybe the best way is to allow for several etckeeper \"instances\" to run independently. Maybe it's a simple feature for defining a list of directories to check... Hope this gives you an idea of what I tried to do with my pull request at https://github.com/joeyh/etckeeper/pull/2 -- Salve """]] comment_3_5e52734a98bff9ccd4cd088cf6a4381d._comment000066400000000000000000000004651453142634200331410ustar00rootroot00000000000000etckeeper-1.18.21/doc/todo/track_multiple_directories[[!comment format=mdwn username="http://joeyh.name/" subject="comment 3" date="2014-12-23T18:30:15Z" content=""" It seems to me that it's easy to build a system where all configuration is in /etc. Or, it might make sense to use to manage the non-/etc repositories. """]] comment_4_50fad97b58a7f1875092c7acb3f3acd8._comment000066400000000000000000000020461453142634200331270ustar00rootroot00000000000000etckeeper-1.18.21/doc/todo/track_multiple_directories[[!comment format=mdwn username="https://www.google.com/accounts/o8/id?id=AItOawlCXirWXlbn1_Ma9G5w3KYILEmb75-I9Do" nickname="Salve J." subject="On putting everything in /etc" date="2014-12-30T15:38:19Z" content=""" Yes, it's *easy* to put everything in /etc. But sometimes it's also *wrong* to do so (eg. for templates, some application-specific config, app localization files, etc.). And sometimes it's not *possible* to do so (eg. for 3rd party applications where we need to keep track of changes). Sometimes I (the dev/admin) have full control of the workflow, other times I don't. There's a LOT of crazy stuff out there (not all in /etc), and having something like etckeeper help keep track of changes would make life a lot easier for people. But perhaps more importantly, there are people out there (myself included) who would love to use etckeeper in this way, but who would prefer this feature was committed to \"upstream\" (your git repo) instead of having to manage a fork of the project in order to get things done. I hope you understand. """]] comment_5_bec408cef5932ace7d6d136600827a1f._comment000066400000000000000000000005051453142634200330330ustar00rootroot00000000000000etckeeper-1.18.21/doc/todo/track_multiple_directories[[!comment format=mdwn username="https://www.google.com/accounts/o8/id?id=AItOawlCXirWXlbn1_Ma9G5w3KYILEmb75-I9Do" nickname="Salve J." subject="myrepos" date="2014-12-30T16:25:04Z" content=""" Not familiar with myrepos. Does it have any integration with packaging systems? (e.g. autocommit before apt-get install) """]] comment_6_bedb701e0175b2d3833041f2f496d3aa._comment000066400000000000000000000012451453142634200327370ustar00rootroot00000000000000etckeeper-1.18.21/doc/todo/track_multiple_directories[[!comment format=mdwn username="https://www.google.com/accounts/o8/id?id=AItOawnZJhzx-nwZRTgh9kjy2Q8zKYsgTLNM2zc" nickname="Evan" subject="intrusion detection?" date="2015-04-10T20:32:40Z" content=""" It seems to me that this would be particularly useful for narrowly scoped intrusion detection. For example, if I have an installed instance of a popular web app (Wordpress, Django, what have you) that is compromised (SQL injection, brute force, etcetera), every part of that app may become suspect even after the initial vulnerability is patched...in which case, a versioned log of what files were changed within the app directory(s) would be *extremely* useful. """]] comment_7_10615b0102e73f1b33f5a8d7207f8edb._comment000066400000000000000000000006451453142634200326650ustar00rootroot00000000000000etckeeper-1.18.21/doc/todo/track_multiple_directories[[!comment format=mdwn username="apaz" subject="Very much needed" date="2015-04-29T08:44:04Z" content=""" This is very much needed! Example of some folders in debian/ubuntu that people want to keep track of: /var/spool/cron/crontabs - user crontabs, yes you can use /etc/cron.d but not everyone does. /lib/ufw/ - If you use ufw, the rules will be saved here /usr/local/bin - for your own shellscripts and stuff """]] comment_8_98d099e5947fb750e5ae9f79b70e318e._comment000066400000000000000000000003711453142634200327500ustar00rootroot00000000000000etckeeper-1.18.21/doc/todo/track_multiple_directories[[!comment format=mdwn username="godblessfq@70ee431d0873d190e6376c984749de668791e42c" nickname="godblessfq" subject="Very good idea" date="2015-08-14T20:40:28Z" content=""" It would be very nice to keep all my configuration in one repo. """]] comment_9_63c1293cf56b1229d3b7e454306b74e0._comment000066400000000000000000000013311453142634200325330ustar00rootroot00000000000000etckeeper-1.18.21/doc/todo/track_multiple_directories[[!comment format=mdwn username="abozhenko@10aed7e09adef30729c54d5f74e1d94bc22dc6e2" nickname="abozhenko" subject="Track multiple dirs for all commands" date="2015-11-22T04:03:37Z" content=""" Hello. Please take a look: https://github.com/joeyh/etckeeper/pull/30 I tried to add support for multiple dirs for all commands, and leave it compatible with default old config and cli. This feature may be useful when you want to have more control on your system. There are other locations which do contain config/code that may be changed, and affects system, e.g.: python code at /usr/lib/python2.7/dist-packages/ pacemaker scripts at /usr/lib/ocf/resource.d/fuel libvirt vms xmls at /var/lib/nova/instances/*/*.xml ... """]] etckeeper-1.18.21/doc/todo/unit_tests_with_bats.mdwn000066400000000000000000000004541453142634200225100ustar00rootroot00000000000000Hi, I have started to implement some basic unit test cases using bats for etckeeper. During that work I found one small issue also fixed in the branch. Could you please review: https://gitlab.com/HRio/etckeeper/commits/unit-test ? Thanks, Henrik > merged the updated branch [[done]] --[[Joey]] etckeeper-1.18.21/doc/todo/unit_tests_with_bats/000077500000000000000000000000001453142634200216165ustar00rootroot00000000000000etckeeper-1.18.21/doc/todo/unit_tests_with_bats/comment_1_2f2834a99aa87aa6a5e6a21a4e7f05b0._comment000066400000000000000000000026361453142634200317410ustar00rootroot00000000000000[[!comment format=mdwn username="joey" subject="""comment 1""" date="2017-04-07T02:40:36Z" content=""" Wow, it's a very nice gift to add a test suite! When I tried running it on debian unstable, there were two test failures: (in test file test-etckeeper, line 32) `[ $(grep -E -c "^${mkdir_str} .*${testdir2}\'$" $metadata) -eq 1 ]' failed ✗ test: etckeeper commit non-default mode (in test file test-etckeeper, line 51) `[ $(grep -E -c "^${chmod_str} ${mode} .*${testfile}\'$" $metadata) -eq 1 ]' failed Unless your test suite found some bugs (which perhaps it did already, I noticed the bugfix commit fad539b0ed762a7f6bc1bd94e64351ef56a25f2a and have already merged that one), I think this must be a bug in the test suite. Perhaps a portability issue? Hmm, I think it's shell quoting fun: $ grep file2 /tmp/f maybe chmod 0577 './file2' $ grep -E -c "^maybe chmod 0577 .*file2\'$" /tmp/f 0 $ grep -E -c '^maybe chmod 0577 .*file2'\''$' /tmp/f 1 $ echo "^maybe chmod 0577 .*file2\'$" ^maybe chmod 0577 .*file2\'$ $ echo '^maybe chmod 0577 .*file2'\''$' ^maybe chmod 0577 .*file2'$ Indeed, when I change all the greps to not slash-escape the single quote, the test suite succeeds here. So why are those single quotes being slash-escaped? As far as I know, shells don't treat single quotes inside double quotes specially, and I don't think that egrep treats single quotes specially either. """]] etckeeper-1.18.21/doc/todo/unit_tests_with_bats_and_fakeroot.mdwn000066400000000000000000000002661453142634200252250ustar00rootroot00000000000000Hi Joey, Here are some more tests that uses fakeroot: https://gitlab.com/HRio/etckeeper/commits/fakeroot Can you please have a look? Thanks, Henrik > merged [[done]] --[[Joey]] etckeeper-1.18.21/doc/todo/unit_tests_with_bats_and_fakeroot/000077500000000000000000000000001453142634200243325ustar00rootroot00000000000000comment_1_a110104aeb4642c02fd71065b83e8377._comment000066400000000000000000000004271453142634200340570ustar00rootroot00000000000000etckeeper-1.18.21/doc/todo/unit_tests_with_bats_and_fakeroot[[!comment format=mdwn username="joey" subject="""comment 1""" date="2017-05-25T16:37:08Z" content=""" This looks good (and all passes here both under and not under fakeroot). Would it make sense for the Makefile to run the test using fakeroot if fakeroot is in PATH? """]] comment_2_891753882055435d7ed3a31c6d4666eb._comment000066400000000000000000000003721453142634200340410ustar00rootroot00000000000000etckeeper-1.18.21/doc/todo/unit_tests_with_bats_and_fakeroot[[!comment format=mdwn username="HRio" avatar="http://cdn.libravatar.org/avatar/1e868a9a6e947b63de9250e8775c73ef" subject="added" date="2017-05-26T18:59:45Z" content=""" added fakeroot check to Makefile. Thanks for a very good suggestion. """]] etckeeper-1.18.21/doc/todo/updaiting_error:_etckeeper.noarch_0:1.18.7-2.el6.mdwn000066400000000000000000000003651453142634200266450ustar00rootroot00000000000000I have installed version: 1.18.5 Trying to update: yum update from epel. getting error: Error: Package: etckeeper-1.18.7-2.el6.noarch (epel) Requires: hostname OS version: CentOS release 6.9 (Final) > [[notabug|done]] --[[Joey]] etckeeper-1.18.21/doc/todo/updaiting_error:_etckeeper.noarch_0:1.18.7-2.el6/000077500000000000000000000000001453142634200257525ustar00rootroot00000000000000comment_1_f5187936924ab40a8298d6103ddd683b._comment000066400000000000000000000003731453142634200355360ustar00rootroot00000000000000etckeeper-1.18.21/doc/todo/updaiting_error:_etckeeper.noarch_0:1.18.7-2.el6[[!comment format=mdwn username="joey" subject="""comment 1""" date="2018-05-17T18:44:54Z" content=""" That is not an error message produced by etckeeper, you'll need to talk to whoever produced the rpm of etckeeper that you have installed. """]] etckeeper-1.18.21/doc/todo/use_getent__40__1__41___from_glibc_to_retrieve_user_home___35__27.mdwn000066400000000000000000000010041453142634200324730ustar00rootroot00000000000000use getent(1) from glibc to retrieve user home #27 https://github.com/joeyh/etckeeper/pull/27 url for git am: https://patch-diff.githubusercontent.com/raw/joeyh/etckeeper/pull/27.patch > I had to guess at the motivation for this patch, which is never the best > position for a patch to leave its receiver in. > > I guess that getent is a little faster than running perl to do the same > thing. And, getent seems to always be available, at least on debian. > > So, applied, with some doubt. [[done]] --[[Joey]] etckeeper-1.18.21/doc/todo/vcs-commit_hook_is_not_POSIX-friendly.mdwn000066400000000000000000000017701453142634200255150ustar00rootroot00000000000000[Bug #946055](https://bugs.debian.org/946055) mentions that if `/bin/sh` is not bash, it will fail (specifically with mksh): > /etc/etckeeper/commit.d/50vcs-commit[22]: ${@#-m}: bad substitution > > This is because doing trim operations on an array are not implemented > in mksh, and unspecified in POSIX: > > […] If parameter is '#', '*', or '@', the result of the expansion is unspecified. […] > > cf. The bug suggests a patch that uses `sed` instead of that pattern substitution: --- a/commit.d/50vcs-commit +++ b/commit.d/50vcs-commit @@ -12,10 +12,9 @@ if [ -n "$1" ]; then if [ "x$1" = "x--stdin" ]; then cat > "$logfile" else - if [ "x$1" = "x-m" ]; then - shift 1 - fi - echo "${@#-m}" > "$logfile" + sed '1s/^-m \{0,1\}//' >"$logfile" <<-EOF + $* + EOF fi else logfile="" Thanks! -- [[anarcat]] > [[done]] --[[Joey]] etckeeper-1.18.21/doc/todo/what_if_there_is_a_Git_repo_somewhere_underneath___47__etc__63__.mdwn000066400000000000000000000003251453142634200327350ustar00rootroot00000000000000What will and what could be done if there is a Git repo somewhere underneath /etc? Perhaps, it could be stored verbatim, or as a submodule. Simply ignoring it would definitely loose information from the backup. etckeeper-1.18.21/doc/todo/what_if_there_is_a_Git_repo_somewhere_underneath___47__etc__63__/000077500000000000000000000000001453142634200320465ustar00rootroot00000000000000comment_1_3d18e005c10b5f3e671fe6c12e5aa03d._comment000066400000000000000000000011521453142634200420650ustar00rootroot00000000000000etckeeper-1.18.21/doc/todo/what_if_there_is_a_Git_repo_somewhere_underneath___47__etc__63__[[!comment format=mdwn username="https://openid.stackexchange.com/user/9df74bc5-3799-4cb1-8f54-971c8423ddaa" nickname="alan.christopher.jenkins" avatar="http://cdn.libravatar.org/avatar/8e723c6cf403714781c6f1ca93551ac5f15f1c982669ab553fb2b73bb896a69a" subject="comment 1" date="2017-01-05T12:41:13Z" content=""" What happened to me was that .etckeeper bloats up with files from the .git directories. Also it behaved confusingly different depending on the exact sequence of events. My notes on this are [here](https://unix.stackexchange.com/questions/323489/i-have-nested-git-repos-will-it-cause-a-problem) """]] comment_2_48e36e7c4b88b27129650e9c447a374c._comment000066400000000000000000000007771453142634200416520ustar00rootroot00000000000000etckeeper-1.18.21/doc/todo/what_if_there_is_a_Git_repo_somewhere_underneath___47__etc__63__[[!comment format=mdwn username="joey" subject="""comment 2""" date="2020-05-05T20:38:57Z" content=""" Gave this a try, and the nested repo gets commited as a submodule, which makes a certain amount of sense. But /etc/.etckeeper includes directories and files inside the rested repo, including even in its .git/ directory. The way pre-commit.d/30store-metadata finds files, and empty subdirectories, would need to be changed to take nested git repos into account. I don't immediately see a good way. """]] comment_3_f3618a15792640feef3f055ac108e940._comment000066400000000000000000000006721453142634200417050ustar00rootroot00000000000000etckeeper-1.18.21/doc/todo/what_if_there_is_a_Git_repo_somewhere_underneath___47__etc__63__[[!comment format=mdwn username="anarcat" avatar="http://cdn.libravatar.org/avatar/1bb99a4f017a1d253ad5790c150d0f0b" subject="comment 3" date="2022-11-08T17:25:58Z" content=""" i think the proper solution here is to stop trying to replace gitignore with our own implementation and defer everything to `git-ls-files`. i lay out that idea in [[todo/metadata_ignore_filters_do_not_work]] and would very much welcome feedback on that. """]] etckeeper-1.18.21/etckeeper000077500000000000000000000054621453142634200155430ustar00rootroot00000000000000#!/bin/sh set -e if [ -z "$ETCKEEPER_CONF_DIR" ]; then ETCKEEPER_CONF_DIR=/etc/etckeeper fi conf="$ETCKEEPER_CONF_DIR/etckeeper.conf" usage() { echo "usage: etckeeper command [-d directory]" >&2 exit 1 } if [ -e $conf ]; then . $conf fi if [ -n "$GIT_WORK_TREE" ]; then unset GIT_WORK_TREE fi if [ -n "$GIT_DIR" ]; then unset GIT_DIR fi program_directory="${0%/*}" if [ -n "$program_directory" ]; then PATH="$PATH:$program_directory" export PATH fi if [ ! -z "$GIT_COMMIT_OPTIONS" ]; then export GIT_COMMIT_OPTIONS fi if [ ! -z "$HG_COMMIT_OPTIONS" ]; then export HG_COMMIT_OPTIONS fi if [ ! -z "$BZR_COMMIT_OPTIONS" ]; then export BZR_COMMIT_OPTIONS fi if [ ! -z "$DARCS_COMMIT_OPTIONS" ]; then export DARCS_COMMIT_OPTIONS fi if [ ! -z "$HIGHLEVEL_PACKAGE_MANAGER" ]; then export HIGHLEVEL_PACKAGE_MANAGER fi if [ ! -z "$LOWLEVEL_PACKAGE_MANAGER" ]; then export LOWLEVEL_PACKAGE_MANAGER fi if [ ! -z "$AVOID_COMMIT_BEFORE_INSTALL" ]; then export AVOID_COMMIT_BEFORE_INSTALL fi if [ ! -z "$AVOID_SPECIAL_FILE_WARNING" ]; then export AVOID_SPECIAL_FILE_WARNING fi if [ ! -z "$PUSH_REMOTE" ]; then export PUSH_REMOTE fi if [ -z "$HOME" ]; then HOME=~root export HOME fi if [ -z "$1" ]; then usage elif [ "x$1" = "x-h" ] || [ "x$1" = "x--help" ]; then man etckeeper || echo "Usage: etckeeper command [-d directory]" >&2 exit 0 elif [ "x$1" = "x-v" ] || [ "x$1" = "x--version" ]; then # This is automatically updated by the Makefile. echo "Version: 1.18.21" exit 0 fi command="$1" shift 1 # compatability code if [ "$command" = "post-apt" ]; then command=post-install elif [ "$command" = "pre-apt" ]; then command=pre-install fi if echo "$command" | LANG=C grep -E -q '[^-a-z_]'; then echo "etckeeper: invalid command $command" >&2 exit 1 fi if [ ! -d "$ETCKEEPER_CONF_DIR/$command.d" ]; then echo "etckeeper: $ETCKEEPER_CONF_DIR/$command.d does not exist" >&2 exit 1 fi if [ "x$1" = "x-d" ]; then if [ -n "$2" ]; then ETCKEEPER_DIR="$2" shift 2 else usage fi fi if [ -z "$ETCKEEPER_DIR" ]; then ETCKEEPER_DIR=/etc fi cd "$ETCKEEPER_DIR" export ETCKEEPER_DIR if [ -d ".git" ]; then VCS=git elif [ -d ".hg" ]; then VCS=hg elif [ -d "_darcs" ]; then VCS=darcs elif [ -d ".bzr" ]; then VCS=bzr fi if [ -z "$VCS" ]; then echo "Please configure a VCS in $conf" >&2 exit 1 fi export VCS if command -v perl >/dev/null; then lsscripts() { LANG=C perl -e ' $dir=shift; print join "\n", grep { ! -d $_ && -x $_ } grep /^\Q$dir\/\E[-a-zA-Z0-9]+$/, glob "$dir/*"; ' "$1" } for script in $(lsscripts "$ETCKEEPER_CONF_DIR/$command.d"); do "$script" "$@" done else # fallback if perl isn't present for script in $ETCKEEPER_CONF_DIR/$command.d/*; do if [ ! -d "$script" -a -x "$script" ]; then echo "$script" | grep -E -q "/[-a-zA-Z0-9]+$" [ $? -eq 0 ] && "$script" "$@" fi done fi etckeeper-1.18.21/etckeeper-bzr/000077500000000000000000000000001453142634200164015ustar00rootroot00000000000000etckeeper-1.18.21/etckeeper-bzr/__init__.py000066400000000000000000000022031453142634200205070ustar00rootroot00000000000000# # Bazaar plugin that runs etckeeper pre-commit when necessary """Runs etckeeper pre-commit when necessary.""" from bzrlib.errors import BzrError import os def etckeeper_startcommit_hook(tree): abspath = getattr(tree, "abspath", None) if abspath is None or not os.path.exists(abspath(".etckeeper")): # Only run the commit hook when this is an etckeeper branch return import subprocess ret = subprocess.call(["etckeeper", "pre-commit", abspath(".")]) if ret != 0: raise BzrError("etckeeper pre-commit failed") try: from bzrlib.hooks import install_lazy_named_hook except ImportError: from bzrlib.mutabletree import MutableTree MutableTree.hooks.install_named_hook('start_commit', etckeeper_startcommit_hook, 'etckeeper') else: install_lazy_named_hook( "bzrlib.mutabletree", "MutableTree.hooks", 'start_commit', etckeeper_startcommit_hook, 'etckeeper') if __name__ == "__main__": from distutils.core import setup setup(name="bzr-etckeeper", packages=["bzrlib.plugins.etckeeper"], package_dir={"bzrlib.plugins.etckeeper":"etckeeper-bzr"}) etckeeper-1.18.21/etckeeper-dnf/000077500000000000000000000000001453142634200163535ustar00rootroot00000000000000etckeeper-1.18.21/etckeeper-dnf/__init__.py000066400000000000000000000000001453142634200204520ustar00rootroot00000000000000etckeeper-1.18.21/etckeeper-dnf/etckeeper.py000066400000000000000000000020251453142634200206730ustar00rootroot00000000000000# etckeeper.py, support etckeeper for dnf # # Copyright (C) 2014 Peter Listiak # https://github.com/plistiak/dnf-etckeeper # # Later modifications by Petr Spacek: # Distutils code below was copied from etckeeper-bzr distributed with v1.15 # from dnfpluginscore import logger import os import dnf class Etckeeper(dnf.Plugin): name = 'etckeeper' def _out(self, msg): logger.debug('Etckeeper plugin: %s', msg) def resolved(self): self._out('pre transaction commit') command = '%s %s' % ('etckeeper', " pre-install") ret = os.system(command) if ret != 0: raise dnf.exceptions.Error('etckeeper returned %d' % (ret >> 8)) def transaction(self): self._out('post transaction commit') command = '%s %s > /dev/null' % ('etckeeper', "post-install") os.system(command) if __name__ == "__main__": from distutils.core import setup setup(name="dnf-etckeeper", packages=["dnf-plugins"], package_dir={"dnf-plugins":"etckeeper-dnf"}) etckeeper-1.18.21/etckeeper.8000066400000000000000000000055431453142634200157060ustar00rootroot00000000000000.\" -*- nroff -*- .TH ETCKEEPER 8 "" "" "" .SH NAME etckeeper \- store /etc in git, mercurial, bazaar, or darcs .SH SYNOPSIS .B etckeeper command [-d directory] .SH DESCRIPTION etckeeper manages /etc be stored in a git, mercurial, bazaar, or darcs repository. By default each of the commands operates on /etc, but a different directory can be specified to operate on a clone of the /etc repository located elsewhere. .SH COMMANDS .TP .B init This initialises and sets up a git, mercurial, bazaar, or darcs repository (depending on the VCS setting in /etc/etckeeper/etckeeper.conf). Typically this is run in /etc once when starting to use etckeeper on a machine. It can also be used to initialise a clone of the /etc repository located elsewhere. .TP .B commit [message] Commits all changes in /etc to the repository. A commit message can be specified. You may also use the underlying VCS to commit manually. (Note that etckeeper commit will notice if a user has used sudo or su to become root, and record the original username in the commit.) .TP .B pre-commit This is called as a pre-commit hook. It stores metadata and does sanity checks. .TP .B pre-install This is called by apt's DPkg::Pre-Install-Pkgs hook, or by equivalent hooks of other package managers. It allows committing any uncommitted changes before packages are installed, upgraded, etc. .TP .B post-install This is called by apt's DPkg::Post-Invoke hook, or by equivalent hooks of other package managers. It commits changes made by packages into the repository. (You can also call this by hand after running dpkg by hand.) .TP .B unclean This returns true if the directory contains uncommitted changes. .TP .B update-ignore [-a] This updates the VCS ignore file. Content outside a "managed by etckeeper" block is not touched. This is generally run when upgrading to a new version of etckeeper. (The -a switch will add a "managed by etckeeper" block if one is not present.) .TP .B vcs subcommand [options ...] You can use this to run any subcommand of the VCS that etckeeper is configured to run. It will be run in /etc. For example, "etckeeper vcs diff" will run "git diff", etc. .TP .B uninit [-f] This command DESTROYS DATA! It is the inverse of the init command, removing VCS information and etckeeper's own bookkeeping information from the directory. Use with caution. A typical use case would be to run etckeeper uninit, then modify etckeeper.conf to use a different VCS, and then run etckeeper init. (The -f switch can be used to force uninit without prompting.) .SH FILES /etc/etckeeper/etckeeper.conf is the configuration file. /etc/etckeeper also contains directories containing the programs that are run for each of the above commands. .SH ENVIRONMENT VARIABLES ETCKEEPER_CONF_DIR path to configuration directory instead of default /etc/etckeeper. .SH SEE ALSO /usr/share/doc/etckeeper/README.md.gz .SH AUTHOR Joey Hess etckeeper-1.18.21/etckeeper.conf000066400000000000000000000030241453142634200164540ustar00rootroot00000000000000# The VCS to use. #VCS="hg" VCS="git" #VCS="bzr" #VCS="darcs" # Options passed to git commit when run by etckeeper. GIT_COMMIT_OPTIONS="" # Options passed to hg commit when run by etckeeper. HG_COMMIT_OPTIONS="" # Options passed to bzr commit when run by etckeeper. BZR_COMMIT_OPTIONS="" # Options passed to darcs record when run by etckeeper. DARCS_COMMIT_OPTIONS="-a" # Etckeeper includes both a cron job and a systemd timer, which each # can commit exiting changes to /etc automatically once per day. # To enable the systemd timer, run: systemctl enable etckeeper.timer # The cron job is enabled by default; to disable it, uncomment this next line. #AVOID_DAILY_AUTOCOMMITS=1 # Uncomment the following to avoid special file warning # (the option is enabled automatically for daily autocommits regardless). #AVOID_SPECIAL_FILE_WARNING=1 # Uncomment to avoid etckeeper committing existing changes to # /etc before installation. It will cancel the installation, # so you can commit the changes by hand. #AVOID_COMMIT_BEFORE_INSTALL=1 # The high-level package manager that's being used. # (apt, pacman, pacman-g2, yum, dnf, zypper, apk, xbps, emerge, cave, etc) HIGHLEVEL_PACKAGE_MANAGER=apt # The low-level package manager that's being used. # (dpkg, rpm, pacman, pacmatic, pacman-g2, apk, xbps, cave, qlist, etc) LOWLEVEL_PACKAGE_MANAGER=dpkg # To push each commit to a remote, put the name of the remote here. # (eg, "origin" for git). Space-separated lists of multiple remotes # also work (eg, "origin gitlab github" for git). PUSH_REMOTE="" etckeeper-1.18.21/etckeeper.spec000066400000000000000000000044221453142634200164640ustar00rootroot00000000000000Name: etckeeper Version: 1.18.21 Release: 4%{?dist} Summary: store /etc in git, mercurial, bzr or darcs Group: System Tools License: GPLv2 URL: http://etckeeper.branchable.com/ Source0: http://ftp.debian.org/debian/pool/main/e/etckeeper/%{name}_%{version}.tar.gz BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n) Requires: git >= 1.6.1-1 Obsoletes: etckeeper = snapshot, yum-etckeeper %description The etckeeper program is a tool to let /etc be stored in a git, mercurial, bzr or darcs repository. It hooks into yum to automatically commit changes made to /etc during package upgrades. It tracks file metadata that version control systems do not normally support, but that is important for /etc, such as the permissions of /etc/shadow. It's quite modular and configurable, while also being simple to use if you understand the basics of working with version control. %prep %setup -q -n %{name} %{__perl} -pi -e ' s|HIGHLEVEL_PACKAGE_MANAGER=apt|HIGHLEVEL_PACKAGE_MANAGER=yum|; s|LOWLEVEL_PACKAGE_MANAGER=dpkg|LOWLEVEL_PACKAGE_MANAGER=rpm|; ' %{_builddir}/%{name}/etckeeper.conf %build make %{?_smp_mflags} %install rm -rf $RPM_BUILD_ROOT make install DESTDIR=$RPM_BUILD_ROOT install -D debian/cron.daily $RPM_BUILD_ROOT/etc/cron.daily/etckeeper %clean rm -rf $RPM_BUILD_ROOT %post %{_bindir}/etckeeper init -d /etc/ mkdir -p %{_var}/cache/etckeeper %files %defattr(-,root,root,-) %doc GPL INSTALL README.md %{_bindir}/* %{_mandir}/* # this isn't very clever and its a manual process update. # but it works %config(noreplace) /etc/yum/pluginconf.d/etckeeper.conf %config(noreplace) /etc/etckeeper/etckeeper.conf /etc/etckeeper/*.d/* /etc/cron.daily/etckeeper /etc/bash_completion.d/etckeeper %{_prefix}/lib/* %changelog * Fri Feb 27 2009 Jimmy Tang - 0.33-4 - fix up initial install to make directory in /var/cache/etckeeper - install the etckeeper daily cron job - define some config files that shouldn't be replaced, should the hooks in commit.d, init.d etc... saved and not blown away? if so they can defined as config files. etckeeper should record the changes anyway. * Wed Feb 25 2009 Jimmy Tang - 0.32-1 - yum etckeeper plugin is now apart of this package * Tue Feb 24 2009 Jimmy Tang - 0.31-1 - initial package etckeeper-1.18.21/init.d/000077500000000000000000000000001453142634200150245ustar00rootroot00000000000000etckeeper-1.18.21/init.d/10restore-metadata000077500000000000000000000007541453142634200203620ustar00rootroot00000000000000#!/bin/sh set -e # Note that metastore doesn't check that the .metastore file only changes # perms of files in the current directory. It's ok to trust the .metastore # file won't do anything shady, because, as documented, etckeeper-init # should only be run on repositories you trust. if [ -e .metadata ]; then if command -v metastore >/dev/null; then metastore --apply --mtime else echo "etckeeper warning: legacy .metastore file is present but metastore is not installed" >&2 fi fi etckeeper-1.18.21/init.d/20restore-etckeeper000077500000000000000000000006371453142634200205520ustar00rootroot00000000000000#!/bin/sh set -e # Used by .etckeeper to run a command if the file it acts on # (the last parameter) exists. maybe () { command="$1" shift 1 if eval [ -e "\"\$$#\"" ]; then "$command" "$@" fi } # Yes, this runs code from the repository. As documented, etckeeper-init # should only be run on repositories you trust. if [ -e .etckeeper ]; then . ./.etckeeper else touch .etckeeper chmod 600 .etckeeper fi etckeeper-1.18.21/init.d/40vcs-init000077500000000000000000000007671453142634200166640ustar00rootroot00000000000000#!/bin/sh set -e description="$(hostname 2>/dev/null || cat /etc/hostname) /etc repository" if [ "$VCS" = git ] && [ ! -e .git ]; then git init echo "$description" > .git/description elif [ "$VCS" = hg ] && [ ! -e .hg ]; then hg init echo "[web]" > .hg/hgrc echo "description = $description" >> .hg/hgrc elif [ "$VCS" = bzr ] && [ ! -e .bzr ]; then bzr init bzr nick "$description" elif [ "$VCS" = darcs ] && [ ! -e _darcs ]; then darcs initialize echo "$description" > _darcs/prefs/motd fi etckeeper-1.18.21/init.d/50vcs-ignore000077500000000000000000000000651453142634200171740ustar00rootroot00000000000000#!/bin/sh set -e etckeeper update-ignore -a || true etckeeper-1.18.21/init.d/50vcs-perm000077500000000000000000000003051453142634200166510ustar00rootroot00000000000000#!/bin/sh set -e if [ "$VCS" = git ]; then chmod 700 .git elif [ "$VCS" = hg ]; then chmod 700 .hg elif [ "$VCS" = bzr ]; then chmod 700 .bzr elif [ "$VCS" = darcs ]; then chmod 700 _darcs fi etckeeper-1.18.21/init.d/50vcs-pre-commit-hook000077500000000000000000000050041453142634200207210ustar00rootroot00000000000000#!/bin/sh set -e case "$VCS" in git) if [ -x .git/hooks/pre-commit ]; then if ! grep -q "etckeeper pre-commit" .git/hooks/pre-commit; then echo "etckeeper warning: .git/hooks/pre-commit needs to be manually modified to run: etckeeper pre-commit -d `pwd`" >&2 fi else cat >.git/hooks/pre-commit <&2 fi else touch .hg/hgrc cat >>.hg/hgrc <&2 fi else cat >_darcs/prefs/defaults </dev/null; then tempfile="mktemp -t etckeeper-$VCS.XXXXXXXXXX" elif command -v tempfile >/dev/null; then tempfile="tempfile" else echo "etckeeper warning: can't find tempfile or mktemp" >&2 exit 1 fi filter_ignore() { if [ "$VCS" = darcs ]; then ignorefile=.darcsignore fi if [ "$VCS" = darcs ] && [ -e "$ignorefile" ]; then # Spaces embedded into patterns would break it. # But really, why would anyone want to use ' ' instead of '\s' ? #patterns=$( grep -v '^[[:space:]]*\(#\|$\)' "$ignorefile" | xargs -n 1 printf " -e %s" ) #grep -Ev $patterns #unset patterns # Alternative using a temp file patternsfile="$($tempfile)" grep -v '^[[:space:]]*\(#\|$\)' "$ignorefile" > "$patternsfile" || true grep -Evf "$patternsfile" rm -f "$patternsfile" unset patternsfile else cat - fi } if [ "$VCS" = darcs ];then NOVCS='. -path ./.git -prune -o -path ./.bzr -prune -o -path ./.hg -prune -o -path ./_darcs -prune -o' # We assume that if .etckeeper is empty this is the first run if [ -s .etckeeper ]; then linksindex="$($tempfile)" grep '^ln -s' .etckeeper | while IFS="'" read n n n link n; do printf "%s\n" "$link" >> "$linksindex" done # Warn about symbolic links that shouldn't exist if links=$( find $NOVCS -type l -print | filter_ignore | grep -vFf "$linksindex" ); then printf "%s\n%s\n" \ "The following symbolic links should not exist:" \ "$links" >&2 fi rm -f "$linksindex" unset links linksindex fi fi etckeeper-1.18.21/init.d/70vcs-add000077500000000000000000000011741453142634200164450ustar00rootroot00000000000000#!/bin/sh set -e if [ "$VCS" = git ]; then if ! git add .; then echo "etckeeper warning: git add failed" >&2 fi elif [ "$VCS" = hg ]; then if ! hg add .; then echo "etckeeper warning: hg add failed" >&2 fi elif [ "$VCS" = bzr ]; then if ! bzr add .; then echo "etckeeper warning: bzr add failed" >&2 fi elif [ "$VCS" = darcs ]; then # Don't warn if all the files were already added. rc=0 res=$( darcs add -qr . 2>&1 ) || rc=$? if test $rc -ne 0; then if ! test $rc -eq 2 -a "${res%No files were added}" != "$res"; then printf "%s" "$res" echo "etckeeper warning: darcs add failed" >&2 fi fi unset rc res fi etckeeper-1.18.21/init.d/README000066400000000000000000000012711453142634200157050ustar00rootroot00000000000000Executable files in this directory are run to initialise the working directory for use by etckeeper. If the working directory is not already in version control, that includes setting up the version control, but not actually committing anything. If the working directory is in version control, it includes applying stored metadata to the checked out files in the working directory. Please be careful to *never* overwrite existing files/directories in the working directory (or use absolute care when doing so). If a file you need to write already exists, check if its contents are sane, and if not, emit a warning on stderr. If initialisation fails, exit nonzero and no later files will be run. etckeeper-1.18.21/list-installed.d/000077500000000000000000000000001453142634200170115ustar00rootroot00000000000000etckeeper-1.18.21/list-installed.d/50list-installed000077500000000000000000000024301453142634200220330ustar00rootroot00000000000000#!/bin/sh if [ "$1" = fmt ]; then # If the list format changes, change the fmt if [ "$LOWLEVEL_PACKAGE_MANAGER" = dpkg ]; then echo 2 else echo "" fi else # Keep the sort order the same at all times. LC_COLLATE=C export LC_COLLATE unset LC_ALL # Output to stdout a *sorted* list of all currently installed # (or removed but still with config-files) packages, in the # format "package version\n" (or something similar). if [ "$LOWLEVEL_PACKAGE_MANAGER" = dpkg ]; then dpkg-query -W -f '${Status}\t${Package} ${Version} ${Architecture}\n' | \ grep -E '(ok installed|ok config-files)' | cut -f2,3 elif [ "$LOWLEVEL_PACKAGE_MANAGER" = rpm ]; then rpm -qa --qf "%|epoch?{%{epoch}}:{0}|:%{name}-%{version}-%{release}.%{arch}\n" | sort elif [ "$LOWLEVEL_PACKAGE_MANAGER" = pacman ]; then pacman -Q elif [ "$LOWLEVEL_PACKAGE_MANAGER" = pacmatic ]; then pacmatic -Q elif [ "$LOWLEVEL_PACKAGE_MANAGER" = pkgng ]; then pkg info -E "*" elif [ "$LOWLEVEL_PACKAGE_MANAGER" = apk ]; then apk info -v | sort elif [ "$LOWLEVEL_PACKAGE_MANAGER" = xbps ]; then xbps-query -l | awk '{print $2}' | sed -r 's/-([^-]+)$/ \1/g;' elif [ "$LOWLEVEL_PACKAGE_MANAGER" = qlist ]; then qlist -ICv elif [ "$LOWLEVEL_PACKAGE_MANAGER" = cave ]; then cave print-packages -r installed fi fi etckeeper-1.18.21/pacman-g2.hook000066400000000000000000000003141453142634200162640ustar00rootroot00000000000000#!/bin/sh pre_sysupgrade() { if [ -x /usr/bin/etckeeper ]; then etckeeper pre-install fi } post_sysupgrade() { if [ -x /usr/bin/etckeeper ]; then etckeeper post-install fi } op=$1 shift $op $* etckeeper-1.18.21/pacman-post-install.hook000066400000000000000000000004431453142634200204100ustar00rootroot00000000000000# etckeeper post-install hook for Pacman 5 and newer [Trigger] Operation = Install Operation = Upgrade Operation = Remove Type = Path Target = etc/* [Action] Description = etckeeper: post-transaction commit When = PostTransaction Exec = /usr/bin/etckeeper post-install Depends = etckeeper etckeeper-1.18.21/pacman-pre-install.hook000066400000000000000000000004531453142634200202120ustar00rootroot00000000000000# etckeeper pre-install hook for Pacman 5 and newer [Trigger] Operation = Install Operation = Upgrade Operation = Remove Type = Path Target = etc/* [Action] Description = etckeeper: pre-transaction commit When = PreTransaction Exec = /usr/bin/etckeeper pre-install Depends = etckeeper AbortOnFail etckeeper-1.18.21/pkgng/000077500000000000000000000000001453142634200147455ustar00rootroot00000000000000etckeeper-1.18.21/pkgng/Makefile000066400000000000000000000004361453142634200164100ustar00rootroot00000000000000.include PREFIX?= /usr/local LIBDIR= ${PREFIX}/lib/pkg/ SHLIB_DIR?= ${LIBDIR}/ SHLIB_NAME?= ${PLUGIN_NAME}.so PLUGIN_NAME= etckeeper SRCS= etckeeper.c PKGFLAGS!= pkgconf --cflags pkg CFLAGS+= ${PKGFLAGS} beforeinstall: ${INSTALL} -d ${LIBDIR} .include etckeeper-1.18.21/pkgng/README000066400000000000000000000002651453142634200156300ustar00rootroot00000000000000To use on FreeBSD, install etckeeper manually and install the plugin with: $ cd pkgng $ make $ make install and add this line to /usr/local/etc/pkg.conf: PLUGINS [ etckeeper ] etckeeper-1.18.21/pkgng/etckeeper.c000066400000000000000000000077621453142634200170740ustar00rootroot00000000000000/* * Copyright (c) 2015 William Johansson * All rights reserved. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * 1. Redistributions of source code must retain the above copyright * notice, this list of conditions and the following disclaimer * in this position and unchanged. * 2. Redistributions in binary form must reproduce the above copyright * notice, this list of conditions and the following disclaimer in the * documentation and/or other materials provided with the distribution. * * THIS SOFTWARE IS PROVIDED BY THE AUTHOR(S) ``AS IS'' AND ANY EXPRESS OR * IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. * IN NO EVENT SHALL THE AUTHOR(S) BE LIABLE FOR ANY DIRECT, INDIRECT, * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. * * Based upon the pkg plugin zfssnap: * Copyright (c) 2012 Marin Atanasov Nikolov */ #include #include #include #include #include #include #define PLUGIN_NAME "etckeeper" /* TODO: make configuration param? */ #define ETCKEEPER_PATH "/usr/local/bin/etckeeper" extern char **environ; struct pkg_plugin *self; static int pre_install_hook(void *data, struct pkgdb *db); static int post_install_hook(void *data, struct pkgdb *db); int pkg_plugin_init(struct pkg_plugin *p) { self = p; pkg_plugin_set(p, PKG_PLUGIN_NAME, PLUGIN_NAME); pkg_plugin_set(p, PKG_PLUGIN_DESC, "etckeeper plugin"); pkg_plugin_set(p, PKG_PLUGIN_VERSION, "1.0.0"); /* NOTE: upgrade/deinstall is regarded as install */ if (pkg_plugin_hook_register(p, PKG_PLUGIN_HOOK_PRE_INSTALL, &pre_install_hook) != EPKG_OK) { pkg_plugin_error(self, "failed to hook into the library"); return (EPKG_FATAL); } if (pkg_plugin_hook_register(p, PKG_PLUGIN_HOOK_POST_INSTALL, &post_install_hook) != EPKG_OK) { pkg_plugin_error(self, "failed to hook into the library"); return (EPKG_FATAL); } if (pkg_plugin_hook_register(p, PKG_PLUGIN_HOOK_PRE_DEINSTALL, &pre_install_hook) != EPKG_OK) { pkg_plugin_error(self, "failed to hook into the library"); return (EPKG_FATAL); } if (pkg_plugin_hook_register(p, PKG_PLUGIN_HOOK_POST_DEINSTALL, &post_install_hook) != EPKG_OK) { pkg_plugin_error(self, "failed to hook into the library"); return (EPKG_FATAL); } if (pkg_plugin_hook_register(p, PKG_PLUGIN_HOOK_PRE_UPGRADE, &pre_install_hook) != EPKG_OK) { pkg_plugin_error(self, "failed to hook into the library"); return (EPKG_FATAL); } if (pkg_plugin_hook_register(p, PKG_PLUGIN_HOOK_POST_UPGRADE, &post_install_hook) != EPKG_OK) { pkg_plugin_error(self, "failed to hook into the library"); return (EPKG_FATAL); } return (EPKG_OK); } static int call_etckeeper(char *arg) { int error, pstat; pid_t pid; char *argv[] = { "etckeeper", arg, NULL, }; if ((error = posix_spawn(&pid, ETCKEEPER_PATH, NULL, NULL, __DECONST(char **, argv), environ)) != 0) { errno = error; pkg_plugin_errno(self, "Failed to spawn process", arg); return (EPKG_FATAL); } while (waitpid(pid, &pstat, 0) == -1) { if (errno != EINTR) return (EPKG_FATAL); } if ((error = WEXITSTATUS(pstat)) != 0) { pkg_plugin_error(self, "etckeeper failed with exit code %d", error); return (EPKG_FATAL); } return (EPKG_OK); } static int pre_install_hook(void *data, struct pkgdb *db) { return call_etckeeper("pre-install"); } static int post_install_hook(void *data, struct pkgdb *db) { return call_etckeeper("post-install"); } etckeeper-1.18.21/post-install.d/000077500000000000000000000000001453142634200165125ustar00rootroot00000000000000etckeeper-1.18.21/post-install.d/50vcs-commit000077500000000000000000000064651453142634200207010ustar00rootroot00000000000000#!/bin/sh set -e pl="/var/cache/etckeeper/packagelist" # Parent process is etckeeper # (Only procps ps is currently supported, others will fail, # so this may end up empty.) ETCKEEPER_PID=$( ps --no-headers -o ppid "${PPID}" 2>/dev/null | sed 's/^ *//' ) # Find the parent of etckeeper and get the command line of the process if ! [ -z "${ETCKEEPER_PID}" ]; then ETCKEEPER_PPID=$( ps --no-headers -o ppid "${ETCKEEPER_PID}" | sed 's/^ *//' ) ETCKEEPER_PARENT_COMMAND_LINE=$( ps --no-headers -o args "${ETCKEEPER_PPID}" ) fi get_changes () { if [ "$VCS" = git ]; then git diff --stat | grep '|' | cut -d'|' -f1 | cut -b2- git ls-files --exclude-standard --others fi if [ "$VCS" = hg ]; then hg status --no-status fi if [ "$VCS" = bzr ]; then bzr status -S | cut -b5- fi if [ "$VCS" = darcs ]; then # ignore ' file -> file' lines for moved files # trim ' -M +N rP' from change summary darcs whatsnew --summary | grep -v '^ .* -> ' | cut -d' ' -f2- | sed 's/ [-+r][0-9]\+//g;s/^\.\///' # lines beginning with 'a' show unversioned files darcs whatsnew --look-for-adds --boring --summary | grep '^a' | cut -d' ' -f2- | sed 's/^\.\///' fi } get_changed_packages () { if [ "$LOWLEVEL_PACKAGE_MANAGER" = dpkg ]; then get_changes | sed 's/^/\/etc\//;s/\s*$//' | xargs -d '\n' dpkg 2>/dev/null -S | cut -d':' -f1 | sed 's/, /\n/g' fi if [ "$LOWLEVEL_PACKAGE_MANAGER" = rpm ]; then # if output contains file path, file was not found get_changes | sed 's/^/\/etc\//;s/\s*$//' | xargs -d '\n' rpm --qf '%{NAME}\n' -qf | grep -v "/etc/" fi # is it even possible to use pacmatic without pacman? if [ "$LOWLEVEL_PACKAGE_MANAGER" = pacman -o "$LOWLEVEL_PACKAGE_MANAGER" = pacmatic ]; then get_changes | sed 's/^/\/etc\//;s/\s*$//' | xargs -d '\n' pacman 2>/dev/null -Qo | rev | cut -d' ' -f1-2 | rev | cut -d' ' -f1 fi if [ "$LOWLEVEL_PACKAGE_MANAGER" = pkgng ]; then get_changes | sed 's/^/\/etc\//;s/\s*$//' | xargs -d '\n' pkg which --quiet | rev | cut -d'-' -f2- | rev fi if [ "$LOWLEVEL_PACKAGE_MANAGER" = xbps ]; then get_changes | sed 's/^/\/etc\//;s/\s*$//' | xargs -d '\n' xbps-query -o | cut -d':' -f1 fi } if etckeeper unclean; then if [ -z "${ETCKEEPER_PARENT_COMMAND_LINE}" ]; then message="committing changes in /etc after $HIGHLEVEL_PACKAGE_MANAGER run" else message="committing changes in /etc made by \"$ETCKEEPER_PARENT_COMMAND_LINE\"" fi set +e if [ -e $pl.pre-install ] && [ "$(cat $pl.fmt 2>/dev/null || true)" = "$(etckeeper list-installed fmt)" ]; then ( echo "$message" echo get_changed_packages | sort | uniq > $pl.found-pkgs if [ -s $pl.found-pkgs ]; then sed -i 's/^/^[-+]/;s/$/ /' $pl.found-pkgs etckeeper list-installed | diff -U0 $pl.pre-install - | tail -n+4 | grep -E '^[-+]' | grep -f $pl.found-pkgs > $pl.found-packages if [ -s $pl.found-packages ]; then echo "Packages with configuration changes:" cat $pl.found-packages || true echo fi fi echo "Package changes:" etckeeper list-installed | diff -U0 $pl.pre-install - | tail -n+4 | grep -E '^[-+]' || true ) | etckeeper commit --stdin else etckeeper commit "$(printf "$message")" fi status=$? set -e if [ "$status" != 0 ]; then echo "warning: etckeeper failed to commit changes in /etc using $VCS" >&2 fi fi rm -f $pl.pre-install $pl.fmt rm -f $pl.found-pkgs $pl.found-packages etckeeper-1.18.21/post-install.d/README000066400000000000000000000002151453142634200173700ustar00rootroot00000000000000Files in this directory are run after packages are installed, upgraded, etc. They should commit changes and new files in /etc to repository. etckeeper-1.18.21/pre-commit.d/000077500000000000000000000000001453142634200161355ustar00rootroot00000000000000etckeeper-1.18.21/pre-commit.d/20warn-problem-files000077500000000000000000000021621453142634200217330ustar00rootroot00000000000000#!/bin/sh set -e exclude_internal () { grep -E -v '(^|/)(\.git|\.hg|\.bzr|_darcs)/' } if [ "$VCS" = bzr ] || [ "$VCS" = darcs ]; then special=$(find . ! -type d ! -type f ! -type l | exclude_internal) || true hardlinks=$(find . -type f ! -links 1 | exclude_internal ) || true elif [ "$VCS" = hg ]; then special=$(find . ! -type d ! -type f ! -type l | exclude_internal) || true hardlinks=$(find . -type f ! -links 1 -exec hg status {} \; | exclude_internal ) || true elif [ "$VCS" = git ]; then special=$(find . ! -type d ! -type f ! -type l -exec git ls-files --exclude-standard --cached --others {} + | exclude_internal) || true hardlinks=$(find . -type f ! -links 1 -exec git ls-files --exclude-standard --cached --others {} + | exclude_internal) || true else special="" fi if [ -n "$special" ] && [ -z "$AVOID_SPECIAL_FILE_WARNING" ]; then echo "etckeeper warning: special files could cause problems with $VCS:" >&2 echo "$special" >&2 fi if [ -n "$hardlinks" ] && [ -z "$AVOID_SPECIAL_FILE_WARNING" ]; then echo "etckeeper warning: hardlinked files could cause problems with $VCS:" >&2 echo "$hardlinks" >&2 fi true etckeeper-1.18.21/pre-commit.d/30store-metadata000077500000000000000000000115771453142634200211530ustar00rootroot00000000000000#!/bin/sh set -e # Keep the sort order the same at all times. LC_COLLATE=C export LC_COLLATE unset LC_ALL filter_ignore() { case "$VCS" in darcs) ignorefile=.darcsignore ;; git) ignorefile=.gitignore ;; esac if [ -n "$ignorefile" ] && [ -e "$ignorefile" ]; then if command -v mktemp >/dev/null; then tempfile="mktemp -t etckeeper-$VCS.XXXXXXXXXX" elif command -v tempfile >/dev/null; then tempfile="tempfile" else echo "etckeeper warning: can't find tempfile or mktemp" >&2 exit 1 fi listfile="$($tempfile)" case "$VCS" in darcs) LC_CTYPE=C grep -v '^[[:space:]]*\(#\|$\)' "$ignorefile" > "$listfile" || true LC_CTYPE=C grep -Evf "$listfile" ;; git) (git ls-files -oi --exclude-standard; git ls-files -oi --exclude-standard --directory) | sort | uniq > "$listfile" || true if [ -s "$listfile" ]; then sed 's/^\.\///' | LC_CTYPE=C grep -xFvf "$listfile" else cat - fi ;; esac rm -f "$listfile" unset listfile else cat - fi } shellquote() { # Single quotes text, escaping existing single quotes. sed -e "s/'/'\"'\"'/g" -e "s/^/'/" -e "s/$/'/" } generate_metadata() { # This function generates the script commands to fix any file # ownerships that aren't owner=root, group=root, as well as to # store the permissions of files. # The script is produced on stdout. Errors go to stderr. # # The script can use a 'maybe' function, which only runs a command # if the file in its last argument exists. # We want files in the directory containing VCS data # but we want find to ignore the VCS files themselves. # # (Note that when using this, the find expression must end with # -print or -exec, else the excluded directories will actually be # printed!) NOVCS='. -path ./.git -prune -o -path ./.bzr -prune -o -path ./.hg -prune -o -path ./_darcs -prune -o' if [ "$VCS" = git ] || [ "$VCS" = hg ]; then # These version control systems do not track directories, # so empty directories must be stored specially. find $NOVCS -type d -empty -print | sort | shellquote | sed -e "s/^/mkdir -p /" fi if [ "$VCS" = darcs ]; then # This version control system does not track symlinks, # so they must be stored specially. find $NOVCS -type l -print | sort | filter_ignore | while read link; do dest=$( readlink "$link" ) printf "ln -sf '%s' '%s'\n" "$(echo "$dest" | shellquote)" "$(echo "$link" | shellquote)" done fi # Store things that don't have the default user or group. # Store all file modes, in case the user has an unusual umask. find $NOVCS \( -type f -or -type d \) -print | filter_ignore | sort | maybe_chmod_chown # We don't handle xattrs. # Maybe check for getfattr/setfattr and use them if they're available? } maybe_chmod_chown() { if command -v perl >/dev/null; then perl -ne ' BEGIN { $q=chr(39) } sub uidname { my $want=shift; if (exists $uidcache{$want}) { return $uidcache{$want}; } my $name=scalar getpwuid($want); return $uidcache{$want}=defined $name ? $name : $want; } sub gidname { my $want=shift; if (exists $gidcache{$want}) { return $gidcache{$want}; } my $name=scalar getgrgid($want); return $gidcache{$want}=defined $name ? $name : $want; } chomp; my @stat=stat($_); my $mode = $stat[2]; my $uid = $stat[4]; my $gid = $stat[5]; s/$q/$q"$q"$q/g; # escape single quotes s/^/$q/; s/$/$q/; if ($uid != $>) { printf "maybe chown $q%s$q %s\n", uidname($uid), $_; } if ($gid != $)) { printf "maybe chgrp $q%s$q %s\n", gidname($gid), $_; } printf "maybe chmod %04o %s\n", $mode & 07777, $_; ' return $? else # fallback if perl isn't present euid=$(id -u) egid=$(id -g) q="'" while read x; do stat=$(stat -c "%f:%u:%g:%a:%U:%G" "$x") IFS=":" read mode uid gid perm uname gname < .etckeeper echo >> .etckeeper # Make sure the file is not readable by others, since it can leak # information about contents of non-readable directories in /etc. chmod 700 .etckeeper generate_metadata >> .etckeeper # stage the file as part of the current commit if [ "$VCS" = git ]; then # this will do nothing if the metadata file is unchanged. git add .etckeeper fi # hg, bzr and darcs add not done, they will automatically # include the file in the current commit fi etckeeper-1.18.21/pre-commit.d/README000066400000000000000000000002201453142634200170070ustar00rootroot00000000000000This is run by a git pre-commit hook before committing changes to the repository. This can be used for storing metadata, and for sanity checks. etckeeper-1.18.21/pre-install.d/000077500000000000000000000000001453142634200163135ustar00rootroot00000000000000etckeeper-1.18.21/pre-install.d/10packagelist000077500000000000000000000003451453142634200206730ustar00rootroot00000000000000#!/bin/sh # This list will be later used when committing. mkdir -p /var/cache/etckeeper/ etckeeper list-installed > /var/cache/etckeeper/packagelist.pre-install etckeeper list-installed fmt > /var/cache/etckeeper/packagelist.fmt etckeeper-1.18.21/pre-install.d/50uncommitted-changes000077500000000000000000000010021453142634200223350ustar00rootroot00000000000000#!/bin/sh set -e if etckeeper unclean; then if [ "$AVOID_COMMIT_BEFORE_INSTALL" = 1 ]; then echo "" >&2 echo "** etckeeper detected uncommitted changes in /etc prior to $HIGHLEVEL_PACKAGE_MANAGER run" >&2 echo "** Aborting $HIGHLEVEL_PACKAGE_MANAGER run. Manually commit and restart." >&2 echo "" >&2 exit 1 fi if ! etckeeper commit "saving uncommitted changes in /etc prior to $HIGHLEVEL_PACKAGE_MANAGER run"; then echo "warning: etckeeper failed to commit changes in /etc using $VCS" >&2 fi fi etckeeper-1.18.21/pre-install.d/README000066400000000000000000000002411453142634200171700ustar00rootroot00000000000000Files in this directory are run before packages are installed, upgraded, etc. This is mostly used for sanity checks, ie, does /etc have any uncommitted changes? etckeeper-1.18.21/systemd/000077500000000000000000000000001453142634200153275ustar00rootroot00000000000000etckeeper-1.18.21/systemd/etckeeper.service000066400000000000000000000004271453142634200206630ustar00rootroot00000000000000[Unit] Description=Autocommit of changes in /etc directory Documentation=man:etckeeper(8) DefaultDependencies=no Conflicts=shutdown.target After=local-fs.target time-sync.target Before=shutdown.target [Service] Type=oneshot ExecStart=/etc/etckeeper/daily IOSchedulingClass=idle etckeeper-1.18.21/systemd/etckeeper.timer000066400000000000000000000002621453142634200203400ustar00rootroot00000000000000[Unit] Description=Daily autocommit of changes in /etc directory Documentation=man:etckeeper(8) [Timer] OnBootSec=15min OnUnitActiveSec=1d [Install] WantedBy=multi-user.target etckeeper-1.18.21/test-etckeeper000077500000000000000000000056101453142634200165130ustar00rootroot00000000000000#!/usr/bin/env bats # # [ -z "$testdir" ] && exit 1 [ ! -d "$testdir" ] && exit 1 export ETCKEEPER_CONF_DIR=$PWD export PATH=$PWD:$PATH export VCS=git export GIT_AUTHOR_EMAIL="nobody@example.com" export GIT_AUTHOR_NAME="nobody" export GIT_COMMITTER_NAME="$GIT_AUTHOR_EMAIL" export GIT_COMMITTER_EMAIL="$GIT_AUTHOR_NAME" metadata="$testdir/.etckeeper" chmod_str="maybe chmod" chown_str="maybe chown" chgrp_str="maybe chgrp" mkdir_str="mkdir -p" run() { ./etckeeper $1 -d "$testdir" "$2" } check_root() { # check if running in fakeroot or similar [ $(id -u) -eq 0 ] } @test "test: etckeeper init" { run init } @test "test: etckeeper commit" { run commit "initial commit" [ -f "$metadata" ] } @test "test: etckeeper commit empty dir" { testdir2="testdir" install -d $testdir/$testdir2 run commit "commit 2" [ $(grep -E -c "^${mkdir_str} .*${testdir2}'$" $metadata) -eq 1 ] } @test "test: etckeeper commit not empty dir" { local testdir2="testdir" install /dev/null $testdir/$testdir2/file run commit "commit 3" [ $(grep -E -c "^${mkdir_str} .*${testdir2}'$" $metadata) -eq 0 ] } @test "test: etckeeper commit non-default mode" { local testfile="file4" local mode="0577" install -m${mode} /dev/null $testdir/$testfile run commit "commit 4" [ $(grep -E -c "^${chmod_str} ${mode} .*${testfile}'$" $metadata) -eq 1 ] } @test "root_test: check if root" { if ! check_root; then skip "need to use fakeroot, the rest of the root tests will be skipped as well" fi } @test "root_test: create file owned by root:root" { check_root || skip local testfile="file5" local mode="0644" local owner="root" local group="root" install -o $owner -g $group -m $mode /dev/null $testdir/$testfile run commit "commit 5" [ $(grep -E -c "^${chmod_str} ${mode} .*${testfile}'$" $metadata) -eq 1 ] [ $(grep -E -c "^${chown_str} '${owner}' .*${testfile}'$" $metadata) -eq 0 ] [ $(grep -E -c "^${chgrp_str} '${group}' .*${testfile}'$" $metadata) -eq 0 ] } @test "root_test: create file owned by bin:daemon" { check_root || skip local testfile="file6" local mode="0644" local owner="bin" local group="daemon" install -o $owner -g $group -m $mode /dev/null $testdir/$testfile run commit "commit 6" [ $(grep -E -c "^${chmod_str} ${mode} .*${testfile}'$" $metadata) -eq 1 ] [ $(grep -E -c "^${chown_str} '${owner}' .*${testfile}'$" $metadata) -eq 1 ] [ $(grep -E -c "^${chgrp_str} '${group}' .*${testfile}'$" $metadata) -eq 1 ] } @test "test: etckeeper commit file with space" { local testfile="a b c" local mode="0705" install -m $mode /dev/null $testdir/"$testfile" run commit "commit 7" [ $(grep -E -c "^${chmod_str} ${mode} .*${testfile}'$" $metadata) -eq 1 ] } @test "test: etckeeper debug (git)" { skip git --git-dir $testdir/.git log --oneline --stat git --git-dir $testdir/.git show --stat false # return printouts for above commands } @test "test: etckeeper uninit -f" { run uninit "-f" [ ! -f "$metadata" ] } etckeeper-1.18.21/unclean.d/000077500000000000000000000000001453142634200155065ustar00rootroot00000000000000etckeeper-1.18.21/unclean.d/50test000077500000000000000000000005601453142634200165610ustar00rootroot00000000000000#!/bin/sh set -e if [ "$VCS" = git ]; then [ -d .git ] && [ -n "`git status --porcelain`" ] elif [ "$VCS" = hg ]; then [ -d .hg ] && ! hg status 2>&1 | wc -l | grep -q "^0$" elif [ "$VCS" = bzr ]; then [ -d .bzr ] && ! bzr version-info --custom --template="{clean}\n" | grep -q "^1$" elif [ "$VCS" = darcs ]; then [ -d _darcs ] && darcs whatsnew -l >/dev/null fi etckeeper-1.18.21/unclean.d/README000066400000000000000000000001261453142634200163650ustar00rootroot00000000000000Files in this directory are used to test if the working copy has uncommitted changes. etckeeper-1.18.21/uninit.d/000077500000000000000000000000001453142634200153675ustar00rootroot00000000000000etckeeper-1.18.21/uninit.d/01prompt000077500000000000000000000005621453142634200170020ustar00rootroot00000000000000#!/bin/sh set -e if [ "$1" != "-f" ]; then echo "** Warning: This will DESTROY all recorded history for $ETCKEEPER_DIR," echo "** including the $VCS repository." echo "" printf "Are you sure you want to do this? [yN] " read answer case "$answer" in [Yy]*) echo "Proceeding.." exit 0 ;; *) echo "Aborting etckeeper uninit." exit 1 ;; esac fi etckeeper-1.18.21/uninit.d/50remove-metadata000077500000000000000000000002361453142634200205360ustar00rootroot00000000000000#!/bin/sh set -e # Files generated by etckeeper to store metadata the VCS cannot preserve. rm -f .etckeeper rm -f .metadata # only generated by old versions etckeeper-1.18.21/uninit.d/50vcs-uninit000077500000000000000000000020001453142634200175510ustar00rootroot00000000000000#!/bin/sh set -e if [ "$VCS" = git ]; then rm -rf .git file=.gitignore elif [ "$VCS" = hg ]; then rm -rf .hg file=.hgignore elif [ "$VCS" = bzr ]; then rm -rf .bzr file=.bzrignore elif [ "$VCS" = darcs ]; then rm -rf _darcs file=.darcsignore fi managed_by_etckeeper="managed by etckeeper" if ! grep -q "$managed_by_etckeeper" "$file"; then exit 0 else realfile="$file" if command -v mktemp >/dev/null; then tempfile="mktemp -t etckeeper-$VCS.XXXXXXXXXX" elif command -v tempfile >/dev/null; then tempfile="tempfile" else echo "etckeeper warning: can't find tempfile or mktemp" >&2 exit 1 fi file=$($tempfile) otherentries= skipping= while read -r line; do if echo "$line" | grep -q "$managed_by_etckeeper"; then if [ ! "$skipping" ]; then skipping=1 else skipping= fi elif [ ! "$skipping" ]; then echo "$line" >> "$file" otherentries=1 fi done <"$realfile" if [ "$otherentries" ]; then mv -f "$file" "$realfile" else rm -f "$file" rm -f "$realfile" fi fi etckeeper-1.18.21/uninit.d/README000066400000000000000000000001741453142634200162510ustar00rootroot00000000000000Executable files in this directory are run to uninitialise the working directory, removing files added by `etckeeper init`. etckeeper-1.18.21/update-ignore.d/000077500000000000000000000000001453142634200166245ustar00rootroot00000000000000etckeeper-1.18.21/update-ignore.d/01update-ignore000077500000000000000000000120021453142634200214510ustar00rootroot00000000000000#!/bin/sh set -e if [ "$VCS" = git ]; then dir=.git file=.gitignore elif [ "$VCS" = hg ]; then dir=.hg file=.hgignore elif [ "$VCS" = bzr ]; then dir=.bzr file=.bzrignore elif [ "$VCS" = darcs ]; then dir=_darcs file=.darcsignore else echo "etckeeper: unsupported VCS $VCS" >&2 exit 1 fi if [ ! -d "$dir" ]; then exit 0 fi managed_by_etckeeper="managed by etckeeper" nl() { echo >>"$file" } comment() { comment="$1" echo "# $comment" >>"$file" } ignore() { glob="$1" case "$VCS" in git) # escape "#" in ignores, as otherwise it may # be considered a comment echo "$glob" | sed 's/#/\\#/g' >>"$file" ;; bzr) echo "$glob" >>"$file" ;; hg) # rather than converting the glob to a regexp, just # configure hg to use globs if [ -z "$hg_syntax_printed" ]; then comment "use glob syntax" echo "syntax: glob" >>"$file" nl hg_syntax_printed=1 fi echo "$glob" | sed 's/#/\\#/g' >>"$file" ;; darcs) # darcs doesn't understand globs, so we need to # translate them into regexs. Not a complete converter, # but suitable for given globs. if [ "${glob%\*}" != "$glob" ]; then glob="${glob%\*}" else glob="$glob"'($|/)' fi if [ "${glob#\*}" != "$glob" ]; then glob="${glob#\*}" else glob='(^|/)'"$glob" fi glob="$( printf %s $glob | sed -e 's/\./\\./g;s/\*/[^\/]*/g;s/\?/[^\/]/g' )" echo "$glob" >>"$file" esac } writefile () { comment "begin section $managed_by_etckeeper (do not edit this section by hand)" nl if [ "$VCS" = darcs ]; then darcs setpref boringfile .darcsignore fi if [ "$LOWLEVEL_PACKAGE_MANAGER" = dpkg ]; then comment "new and old versions of conffiles, stored by dpkg" ignore "*.dpkg-*" comment "new and old versions of conffiles, stored by ucf" ignore "*.ucf-*" nl elif [ "$LOWLEVEL_PACKAGE_MANAGER" = "rpm" ]; then comment "new and old versions of conffiles, stored by apt/rpm" ignore "*.rpm*" nl elif [ "$LOWLEVEL_PACKAGE_MANAGER" = "pacman-g2" -o "$LOWLEVEL_PACKAGE_MANAGER" = "pacman" -o "$LOWLEVEL_PACKAGE_MANAGER" = "pacmatic" ]; then comment "new and old versions of conffiles, stored by pacman" ignore "*.pacnew" ignore "*.pacorig" ignore "*.pacsave" nl elif [ "$LOWLEVEL_PACKAGE_MANAGER" = "apk" ]; then comment "new versions of conffiles, stored by apk" ignore "*.apk-new" nl elif [ "$LOWLEVEL_PACKAGE_MANAGER" = "xbps" ]; then comment "new versions of conffiles, stored by xbps" ignore "*.new-*_[0-9]*" nl elif [ "$LOWLEVEL_PACKAGE_MANAGER" = "qlist" -o "$LOWLEVEL_PACKAGE_MANAGER" = "cave" ]; then comment "new and old versions of conffiles, stored by emerge" ignore "._cfg*" nl fi comment "old versions of files" ignore "*.old" # Not currently ignored as admins tend to rely on these files. #ignore "passwd-" #ignore "group-" #ignore "shadow-" #ignore "gshadow-" nl comment "mount(8) records system state here, no need to store these" ignore blkid.tab ignore blkid.tab.old nl comment "some other files in /etc that typically do not need to be tracked" ignore nologin ignore ld.so.cache ignore prelink.cache ignore mtab ignore mtab.fuselock ignore .pwd.lock ignore "*.LOCK" ignore network/run ignore adjtime ignore udev/hwdb.bin ignore lvm/cache ignore lvm/archive ignore "X11/xdm/authdir/authfiles/*" ignore ntp.conf.dhcp ignore .initctl ignore "webmin/fsdump/*.status" ignore "webmin/webmin/oscache" ignore "apparmor.d/cache/*" ignore "service/*/supervise/*" ignore "service/*/log/supervise/*" ignore "sv/*/supervise/*" ignore "sv/*/log/supervise/*" ignore "*.elc" ignore "*.pyc" ignore "*.pyo" ignore "init.d/.depend.*" ignore "openvpn/openvpn-status.log" ignore "cups/subscriptions.conf" ignore "cups/subscriptions.conf.O" ignore "fake-hwclock.data" ignore "check_mk/logwatch.state" nl comment "editor temp files" ignore "*~" ignore ".*.sw?" ignore ".sw?" ignore "#*#" ignore DEADJOE nl comment "end section $managed_by_etckeeper" } if [ -e "$file" ]; then if ! grep -q "$managed_by_etckeeper" "$file"; then if [ "$1" != "-a" ]; then echo "etckeeper: "$file" does not contain \"$managed_by_etckeeper\" comment; not updating" exit 1 else echo "etckeeper: "$file" exists but does not contain \"$managed_by_etckeeper\" comment; updating" writefile exit 0 fi fi realfile="$file" if command -v mktemp >/dev/null; then tempfile="mktemp -t etckeeper-$VCS.XXXXXXXXXX" elif command -v tempfile >/dev/null; then tempfile="tempfile" else echo "etckeeper warning: can't find tempfile or mktemp" >&2 fi file=$($tempfile) # preserve permissions and ownership cp -fp "$realfile" "$file" cat /dev/null >"$file" ( skipping= while read -r line; do if echo "$line" | grep -q "$managed_by_etckeeper"; then if [ ! "$skipping" ]; then skipping=1 else skipping= writefile fi elif [ ! "$skipping" ]; then echo "$line" >> "$file" fi done if [ "$skipping" ]; then # reached end of file w/o ending block writefile fi ) <"$realfile" mv -f "$file" "$realfile" else writefile fi etckeeper-1.18.21/update-ignore.d/README000066400000000000000000000001551453142634200175050ustar00rootroot00000000000000Executable files in this directory are run to update the VCS ignore file, or create it if it does not exist. etckeeper-1.18.21/vcs.d/000077500000000000000000000000001453142634200146545ustar00rootroot00000000000000etckeeper-1.18.21/vcs.d/50vcs-cmd000077500000000000000000000003751453142634200163100ustar00rootroot00000000000000#!/bin/sh set -e # check whether we can locate the vcs binary if [ -n "$VCS" ] && command -v "$VCS" > /dev/null; then # pass commands to the VCS application $VCS "$@" else echo "error: VCS ($VCS) not set or not in PATH" >&2 exit 1 fi etckeeper-1.18.21/yum-etckeeper.conf000066400000000000000000000000211453142634200172560ustar00rootroot00000000000000[main] enabled=1 etckeeper-1.18.21/yum-etckeeper.py000066400000000000000000000022141453142634200167670ustar00rootroot00000000000000# # # author: jtang@tchpc.tcd.ie # # this plugin is based on the hello world example # from http://yum.baseurl.org/wiki/WritingYumPlugins # # to install, copy this file to /usr/lib/yum-plugins/etckeeper.py # and then create /etc/yum/pluginconf.d/etckeeper.conf with the contents # below. # # /etc/yum/pluginconf.d/etckeeper.conf: # [main] # enabled=1 # import os from glob import fnmatch import yum from yum.plugins import PluginYumExit, TYPE_CORE requires_api_version = '2.1' plugin_type = (TYPE_CORE,) def pretrans_hook(conduit): conduit.info(2, 'etckeeper: pre transaction commit') servicecmd = conduit.confString('main', 'servicecmd', '/usr/bin/etckeeper') command = '%s %s > /dev/null' % (servicecmd, " pre-install") ret = os.system(command) if ret != 0: raise PluginYumExit('etckeeper returned %d' % (ret >> 8)) def posttrans_hook(conduit): conduit.info(2, 'etckeeper: post transaction commit') if os.path.exists('/usr/bin/etckeeper'): servicecmd = conduit.confString('main', 'servicecmd', '/usr/bin/etckeeper') command = '%s %s > /dev/null' % (servicecmd, "post-install") os.system(command) etckeeper-1.18.21/zsh_completion000066400000000000000000000011721453142634200166200ustar00rootroot00000000000000#compdef etckeeper local _VCS=$(sed -n "s,^VCS=\([\"']\?\)\(.*\)\1$,\2,p" \ ${ETCKEEPER_CONF_DIR:-/etc/etckeeper}/etckeeper.conf 2>/dev/null) _arguments '--help[show this help message and exit]' \ '--version[show version information]' \ ":etckeeper command:(/etc/etckeeper/*.d(/:t:r))" \ '*::subcmd:->subcmd' && return 0 case "$words[1]" in (commit) _arguments ':message text: ' ;; (update-ignore) _arguments '-a[add a "managed by etckeeper" block]' ;; (uninit) _arguments '-f[force uninit without prompting]' ;; (vcs) [[ $_VCS == git ]] && service=git _$_VCS ;; (*) ;; esac etckeeper-1.18.21/zypper-etckeeper.py000077500000000000000000000022211453142634200175070ustar00rootroot00000000000000#!/usr/bin/python import errno import subprocess import zypp_plugin import os def _call_etckeeper(install_arg): # zypper interprets the plugin's stdout as described in # http://doc.opensuse.org/projects/libzypp/HEAD/zypp-plugins.html so it's # important that we don't write anything to it. We therefore redirect # etckeeper's stdout to the plugin's stderr. Since zypper writes the # stderr of plugins to its log file, etckeeper's stdout will go there as # well. subprocess.call(['etckeeper', install_arg], stdout=2) class EtckeeperPlugin(zypp_plugin.Plugin): def PLUGINBEGIN(self, headers, body): _call_etckeeper('pre-install') self.ack() def PLUGINEND(self, headers, body): try: _call_etckeeper('post-install') except OSError as e: # if etckeeper was just removed, executing it will fail with # ENOENT if e.errno != errno.ENOENT: # reraise so that we don't hide other errors than etckeeper # not existing raise self.ack() os.environ["LANG"] = "C" plugin = EtckeeperPlugin() plugin.main()