New upstream version 1.2.3
intrigeri
5 years ago
0 | 1.2.3 (2017 06 27) | |
1 | ||
2 | * Update URLs: Redmine → Gitlab. | |
3 | * Tell mutt *not* to save outgoing email. | |
4 | This fixes Debian bug #657071. | |
5 | * Bypass root's mutt configuration file. | |
6 | ||
0 | 7 | 1.2.2 (2012 06 02) |
1 | 8 | |
2 | 9 | * Ignore changes to $WATCHED_DIR itself. |
0 | 0 | metche - reducing root bus factor |
1 | homepage: https://labs.riseup.net/code/projects/metche | |
2 | Git repository: git://labs.riseup.net/metche.git | |
1 | homepage: https://0xacab.org/metche/metche/ | |
2 | Git repository: https://0xacab.org/metche/metche.git | |
3 | 3 | dev team: metche AT lists DOT riseup DOT net |
4 | 4 | |
5 | 5 | ,------------------------------------------------------------------------------- |
35 | 35 | to $BACKUP_DIR (default: /var/lib/metche). |
36 | 36 | - send a nicely formatted email to a defined email address, listing the last |
37 | 37 | changes that have been made to the system. |
38 | See https://labs.riseup.net/code/projects/metche for an example. | |
38 | See https://0xacab.org/metche/metche for an example. | |
39 | 39 | |
40 | 40 | ,------------------------------------------------------------------------------- |
41 | 41 | | BASIC USAGE |
81 | 81 | _mail() { |
82 | 82 | local subject="$1" |
83 | 83 | if which mutt > /dev/null ; then |
84 | LC_ALL="$LOCALE" mutt -s "$subject" "$EMAIL_ADDRESS" | |
84 | LC_ALL="$LOCALE" mutt -F/dev/null -e 'set record="/dev/null"' -s "$subject" "$EMAIL_ADDRESS" | |
85 | 85 | elif which mail > /dev/null ; then |
86 | 86 | LC_ALL="$LOCALE" mail -s "$subject" "$EMAIL_ADDRESS" |
87 | 87 | elif [ -x /usr/sbin/sendmail ]; then |
0 | .TH METCHE 8 "June 5, 2011" "metche user manual" | |
1 | .SH NAME | |
2 | .PP | |
3 | metche - reducing root bus factor | |
4 | .SH SYNOPSIS | |
5 | .IP | |
6 | .nf | |
7 | \f[C] | |
8 | metche\ [-h\ VSERVER]\ report\ (stable|testing|unstable)-YYYYMMDDHHMM | |
9 | metche\ [-h\ VSERVER]\ list | |
10 | metche\ [-h\ VSERVER]\ stabilize\ testing-YYYYMMDDHHMM | |
11 | \f[] | |
12 | .fi | |
13 | .SH DESCRIPTION | |
14 | .PP | |
15 | metche is a tool meant to ease collective system administration by | |
16 | monitoring changes in the system configuration. | |
17 | .PP | |
18 | metche basic usage is to monitor changes in a directory, usually | |
19 | \f[C]/etc\f[]; optionally, metche can also monitor: | |
20 | .IP \[bu] 2 | |
21 | one or more user maintained changelog files, | |
22 | .IP \[bu] 2 | |
23 | the state of Debian packages and versions. | |
24 | .PP | |
25 | metche should be installed with a cronjob that regularly runs to | |
26 | automatically save the system state as needed. | |
27 | These states are saved in a way similar to the Debian development model: | |
28 | .IP \[bu] 2 | |
29 | \f[I]unstable\f[] states are saved as soon as a change is detected. | |
30 | They are kept until a new \f[I]testing\f[] state appears. | |
31 | .IP \[bu] 2 | |
32 | \f[I]testing\f[] states is created from the last \f[I]unstable\f[] state | |
33 | that has not been changed after a short amount of time (by default, one | |
34 | hour). | |
35 | Old \f[I]unstable\f[] states are deleted afterwards. | |
36 | .IP \[bu] 2 | |
37 | \f[I]stable\f[] states are created from the last \f[I]testing\f[] state, | |
38 | either manually, or after a long amount of time (by default, 3 days). | |
39 | Old \f[I]testing\f[] states are deleted afterwards. | |
40 | .PP | |
41 | When a new \f[I]testing\f[] state is saved, an email is sent to a | |
42 | configurable address, giving an overwiew of the differences with the | |
43 | previous \f[I]testing\f[]. | |
44 | A notification is also sent when a new \f[I]stable\f[] state is saved. | |
45 | .PP | |
46 | metche\[aq]s configuration is read from \f[C]/etc/metche.conf\f[]. | |
47 | Various settings like changelog monitoring or time between system state | |
48 | switches are described there. | |
49 | .SH OPTIONS | |
50 | .PP | |
51 | If \f[C]-h\ VSERVER\f[] is specified, the VServer \f[I]VSERVER\f[] is | |
52 | operated on instead of the host system. | |
53 | This, along with the \f[C]VSNAMES\f[] option, allows one to monitor | |
54 | several VServers running on the system. | |
55 | .PP | |
56 | One of the following commands must be specified on the command line: | |
57 | .TP | |
58 | .B report | |
59 | When run with the \f[I]report\f[] command, metche displays a report | |
60 | against the specified saved state, or if unspecified, against the latest | |
61 | testing state. | |
62 | This is useful when you have broken your system and want to know which | |
63 | changes have been made since a given, known working, system state. | |
64 | .RS | |
65 | .RE | |
66 | .TP | |
67 | .B list | |
68 | When run with the \f[I]list\f[] command, metche displays a list of all | |
69 | the saved states. | |
70 | .RS | |
71 | .RE | |
72 | .TP | |
73 | .B stabilize | |
74 | When run with the \f[I]stabilize\f[] command, metche turns a "testing | |
75 | state" into a "stable state". | |
76 | By default, it will use the last "testing state", but this can be | |
77 | overridden by giving a specific state as argument. | |
78 | .RS | |
79 | .RE | |
80 | .TP | |
81 | .B cron | |
82 | This command should not be called manually, but used from a cronjob. | |
83 | When called, it can perform various operations like: saving "unstable", | |
84 | "testing" or "stable" states as needed and sending reports and | |
85 | notification if configured to do so. | |
86 | This command does not support the \f[C]-h\f[] option. | |
87 | .RS | |
88 | .RE | |
89 | .SH FILES | |
90 | .PP | |
91 | \f[C]/etc/metche.conf\f[] contains metche configuration. | |
92 | .PP | |
93 | When configured to monitor one changelog, \f[C]CHANGELOG_FILE\f[] | |
94 | (default: \f[C]/root/Changelog\f[]). | |
95 | .PP | |
96 | When configured to monitor multiple changelogs, | |
97 | \f[C]CHANGELOG_DIR/*/Changelog\f[] (default: \f[C]/root/changelogs\f[]). | |
98 | .PP | |
99 | System states are saved in \f[C]BACKUP_DIR\f[] (default: | |
100 | \f[C]/var/lib/metche\f[]). | |
101 | .SH SECURITY | |
102 | .PP | |
103 | metche is able to use GnuPG to encrypt the email it sends, but does not | |
104 | by default; just enable the \f[C]ENCRYPT_EMAIL\f[] configuration option, | |
105 | and make sure \f[C]EMAIL_ADDRESS\f[]\[aq] public key is in root\[aq]s | |
106 | keyring, trusted enough to be used blindly by metche. | |
107 | If \f[C]EMAIL_ADDRESS\f[] is an email alias or mailing-list\[aq]s | |
108 | address, you probably want to use the \f[C]group\f[] option in | |
109 | \f[C]/root/.gnupg/gpg.conf\f[] so that metche reports are encrypted for | |
110 | every person subscribed to this alias or mailing-list; for more | |
111 | information, see \f[C]gpg(1)\f[]. | |
112 | .PP | |
113 | When \f[C]DO_DETAILS\f[] is enabled and \f[C]ENCRYPT_EMAIL\f[] is | |
114 | disabled, metche sends in \f[I]clear text email\f[] the changes made to | |
115 | the watched directory... | |
116 | either make sure that the \f[C]EXCLUDES\f[] configuration variable | |
117 | prevents it to send sensitive information, or triple check that secure | |
118 | connections will be used end-to-end on the email path. | |
119 | If unsure, set \f[C]EMAIL_ADDRESS\f[] configuration variable to a local | |
120 | mailbox. | |
121 | Please note that \f[C]EMAIL_ADDRESS\f[] is not used for VServers: a | |
122 | VServer\[aq]s report messages are sent to its root email address. | |
123 | .PP | |
124 | metche stores, in \f[C]BACKUP_DIR\f[] (default: | |
125 | \f[C]/var/lib/metche\f[]), various backups of \f[C]WATCHED_DIR\f[]. | |
126 | Make sure that this backup place is at least as secured as the source. | |
127 | .SH BUGS | |
128 | .PP | |
129 | See metche\[aq]s ticket | |
130 | system (https://labs.riseup.net/code/projects/metche/issues) for known | |
131 | bugs, missing features, and the development road-map. | |
132 | .SH AUTHORS | |
133 | metche and this manual page were written by the boum.org collective, and | |
134 | are now maintained by the metche developers collective | |
135 | <metche@lists.riseup.net>. |
0 | % METCHE(8) metche user manual | |
1 | % metche and this manual page were written by the boum.org collective, and are now maintained by the metche developers collective <metche@lists.riseup.net> | |
2 | % June 5, 2011 | |
3 | ||
4 | NAME | |
5 | ==== | |
6 | ||
7 | metche - reducing root bus factor | |
8 | ||
9 | SYNOPSIS | |
10 | ======== | |
11 | ||
12 | metche [-h VSERVER] report (stable|testing|unstable)-YYYYMMDDHHMM | |
13 | metche [-h VSERVER] list | |
14 | metche [-h VSERVER] stabilize testing-YYYYMMDDHHMM | |
15 | ||
16 | DESCRIPTION | |
17 | =========== | |
18 | ||
19 | metche is a tool meant to ease collective system administration by | |
20 | monitoring changes in the system configuration. | |
21 | ||
22 | metche basic usage is to monitor changes in a directory, usually | |
23 | `/etc`; optionally, metche can also monitor: | |
24 | ||
25 | * one or more user maintained changelog files, | |
26 | * the state of Debian packages and versions. | |
27 | ||
28 | metche should be installed with a cronjob that regularly runs to | |
29 | automatically save the system state as needed. These states are saved | |
30 | in a way similar to the Debian development model: | |
31 | ||
32 | * _unstable_ states are saved as soon as a change is detected. They | |
33 | are kept until a new _testing_ state appears. | |
34 | * _testing_ states is created from the last _unstable_ state that has | |
35 | not been changed after a short amount of time (by default, one | |
36 | hour). Old _unstable_ states are deleted afterwards. | |
37 | * _stable_ states are created from the last _testing_ state, either | |
38 | manually, or after a long amount of time (by default, 3 days). Old | |
39 | _testing_ states are deleted afterwards. | |
40 | ||
41 | When a new _testing_ state is saved, an email is sent to a | |
42 | configurable address, giving an overwiew of the differences with the | |
43 | previous _testing_. A notification is also sent when a new _stable_ | |
44 | state is saved. | |
45 | ||
46 | metche's configuration is read from `/etc/metche.conf`. Various | |
47 | settings like changelog monitoring or time between system state | |
48 | switches are described there. | |
49 | ||
50 | OPTIONS | |
51 | ======= | |
52 | ||
53 | If `-h VSERVER` is specified, the VServer _VSERVER_ is operated on | |
54 | instead of the host system. This, along with the `VSNAMES` option, | |
55 | allows one to monitor several VServers running on the system. | |
56 | ||
57 | One of the following commands must be specified on the command line: | |
58 | ||
59 | report | |
60 | : When run with the _report_ command, metche displays a report | |
61 | against the specified saved state, or if unspecified, against the | |
62 | latest testing state. This is useful when you have broken your | |
63 | system and want to know which changes have been made since a | |
64 | given, known working, system state. | |
65 | ||
66 | list | |
67 | : When run with the _list_ command, metche displays a list of all | |
68 | the saved states. | |
69 | ||
70 | stabilize | |
71 | : When run with the _stabilize_ command, metche turns a "testing | |
72 | state" into a "stable state". By default, it will use the last | |
73 | "testing state", but this can be overridden by giving a specific | |
74 | state as argument. | |
75 | ||
76 | cron | |
77 | : This command should not be called manually, but used from a | |
78 | cronjob. When called, it can perform various operations like: | |
79 | saving "unstable", "testing" or "stable" states as needed and | |
80 | sending reports and notification if configured to do so. This | |
81 | command does not support the `-h` option. | |
82 | ||
83 | FILES | |
84 | ===== | |
85 | ||
86 | `/etc/metche.conf` contains metche configuration. | |
87 | ||
88 | When configured to monitor one changelog, `CHANGELOG_FILE` (default: | |
89 | `/root/Changelog`). | |
90 | ||
91 | When configured to monitor multiple changelogs, | |
92 | `CHANGELOG_DIR/*/Changelog` (default: `/root/changelogs`). | |
93 | ||
94 | System states are saved in `BACKUP_DIR` (default: `/var/lib/metche`). | |
95 | ||
96 | SECURITY | |
97 | ======== | |
98 | ||
99 | metche is able to use GnuPG to encrypt the email it sends, but does | |
100 | not by default; just enable the `ENCRYPT_EMAIL` configuration option, | |
101 | and make sure `EMAIL_ADDRESS`' public key is in root's keyring, | |
102 | trusted enough to be used blindly by metche. If `EMAIL_ADDRESS` is an | |
103 | email alias or mailing-list's address, you probably want to use the | |
104 | `group` option in `/root/.gnupg/gpg.conf` so that metche reports are | |
105 | encrypted for every person subscribed to this alias or mailing-list; | |
106 | for more information, see `gpg(1)`. | |
107 | ||
108 | When `DO_DETAILS` is enabled and `ENCRYPT_EMAIL` is disabled, metche | |
109 | sends in _clear text email_ the changes made to the watched | |
110 | directory... either make sure that the `EXCLUDES` configuration | |
111 | variable prevents it to send sensitive information, or triple check | |
112 | that secure connections will be used end-to-end on the email path. If | |
113 | unsure, set `EMAIL_ADDRESS` configuration variable to a local mailbox. | |
114 | Please note that `EMAIL_ADDRESS` is not used for VServers: a | |
115 | VServer's report messages are sent to its root email address. | |
116 | ||
117 | metche stores, in `BACKUP_DIR` (default: `/var/lib/metche`), various | |
118 | backups of `WATCHED_DIR`. Make sure that this backup place is at least | |
119 | as secured as the source. | |
120 | ||
121 | BUGS | |
122 | ==== | |
123 | ||
124 | See [metche's ticket system] for known bugs, missing features, and the | |
125 | development road-map. | |
126 | ||
127 | [metche's ticket system]: https://0xacab.org/metche/metche/issues |