upstream/trunk: moved the FAQ from the README file to its own one
intrigeri
17 years ago
0 | ,------------------------------------------------------------------------------- | |
1 | | Frequently asked0 questions about metche | |
2 | `------------------------------------------------------------------------------- | |
3 | ||
4 | 1. How are the monitored Changelog files ($CHANGELOG_FILE or | |
5 | $CHANGELOG_DIR/*/Changelog) generated? | |
6 | ||
7 | With Emacs or Vim. They are written by *you*! They are an important | |
8 | part of the collective sysadmin process metche is supposed to simplify. | |
9 | ||
10 | 2. How is metche working, and what are the underlying concepts I have to | |
11 | understand? | |
12 | ||
13 | When called with the cron command line switch, metche verifies changes in | |
14 | the system state during the last $TESTING_TIME minutes. If any changes | |
15 | took place an "unstable state" is saved. Otherwise, a "testing state" is | |
16 | saved and a report is emailed to you. | |
17 | ||
18 | A mechanism exists to automatically turn a "testing state" into | |
19 | a "stable" one. See metche(8) for explanations. | |
20 | ||
21 | 3. How do I see the saved states list? | |
22 | ||
23 | Run "metche list". | |
24 | ||
25 | 4. I've broken my system, how can I see a report against a previous, system | |
26 | state, known as working? | |
27 | ||
28 | Run "metche report [{stable,testing,unstable}-YYYYMMDDHHMM]". | |
29 | If no saved state is specified, the most recently saved "testing state" | |
30 | is used as reference. | |
31 | ||
32 | 5. How do I create a "stable state" manually? | |
33 | ||
34 | Run "metche stabilize [testing-YYYYMMDDHHMM]". | |
35 | This turns the given "testing state", if specified, otherwise the one most | |
36 | recently saved, into a "stable state". | |
37 | ||
38 | 6. Why is metche filling my /var partition? | |
39 | ||
40 | First, metche needs to make backups of your "system state" in order to be | |
41 | able to provide you with changes reports. Whatever you do, metche *will* use | |
42 | some disk space (a few dozens megabytes on a typical server). Please note | |
43 | metche performs full, and not incremental, backups. | |
44 | ||
45 | But there are a few ways to limit the disk space metche uses. Here is | |
46 | the cookbook. | |
47 | ||
48 | a) Exclude some big files from the set monitored by metche. | |
49 | - Have a look to your metche backup files: | |
50 | # ls -l /var/lib/metche/*.tar.bz2 | |
51 | - If the average size for these files is greater than a few megabytes, | |
52 | you should investigate which file or directory (in $WATCHED_DIR) is | |
53 | guilty and use the EXCLUDES option to keep it out of metche's hands. | |
54 | ||
55 | b) Speed up the mechanism that automatically turns an "unstable state" into | |
56 | a "testing state", and a "testing state into a "stable" one. | |
57 | - First, let metche run for a while with its default TESTING_TIME and | |
58 | STABLE_TIME configuration values (the "for a while" meaning depends on | |
59 | how much nervous you get when you run 'df /var' every five minute; | |
60 | a few days is a bare minimum, a few weeks is better). | |
61 | - Then, have a look to the files metche has kept in $BACKUP_DIR; a simple | |
62 | 'metche list' is enough if you're not monitoring any VServer. | |
63 | - If there is a huge list of "unstable" but only few "testing" states, | |
64 | you can try lowering TESTING_TIME. If there are many more "testing" | |
65 | states than "stable" state, you can try lowering STABLE_TIME. | |
66 | It's better to only tweak one of these two parameters at a time. | |
67 | - Let metche run "for a while" again... and iterate. | |
68 | ||
69 | c) Still despaired? | |
70 | If this does not work for you, you might also have found a weird case that | |
71 | metche does not handle well, call it a bug or whatever you want; you | |
72 | should actually e-mail us (metche AT lists DOT riseup DOT net) the output | |
73 | of 'metche list', your configuration file (stripped from private | |
74 | information), and some information about the metche version you're running. |
4 | 4 | 1. Have a look at the REQUIREMENTS section in the README file. |
5 | 5 | 2. Copy the metche executable to /usr/local/sbin/ |
6 | 6 | 3. Copy the manpage (metche.8) to /usr/local/man/man8/ |
7 | 4. Read the README file and the manpage | |
7 | 4. Read the README file, the FAQ and the manpage | |
8 | 8 |
47 | 47 | Note: It is dangerous to use metche without reading the SECURITY section |
48 | 48 | of the manpage before. |
49 | 49 | |
50 | For further explanation of the way metche works, read the metche(8) manpage. | |
50 | For further explanation of the way metche works, read the metche(8) manpage and | |
51 | the FAQ file. | |
51 | 52 | |
52 | 53 | ,------------------------------------------------------------------------------- |
53 | 54 | | REQUIREMENTS |
117 | 118 | |
118 | 119 | Read the SECURITY section of metche(8). Really. |
119 | 120 | |
120 | ,------------------------------------------------------------------------------- | |
121 | | FAQ | |
122 | `------------------------------------------------------------------------------- | |
123 | ||
124 | 1. How are the monitored Changelog files ($CHANGELOG_FILE or | |
125 | $CHANGELOG_DIR/*/Changelog) generated? | |
126 | ||
127 | With Emacs or Vim. They are written by *you*! They are an important | |
128 | part of the collective sysadmin process metche is supposed to simplify. | |
129 | ||
130 | 2. How is metche working, and what are the underlying concepts I have to | |
131 | understand? | |
132 | ||
133 | When called with the cron command line switch, metche verifies changes in | |
134 | the system state during the last $TESTING_TIME minutes. If any changes | |
135 | took place an "unstable state" is saved. Otherwise, a "testing state" is | |
136 | saved and a report is emailed to you. | |
137 | ||
138 | A mechanism exists to automatically turn a "testing state" into | |
139 | a "stable" one. See metche(8) for explanations. | |
140 | ||
141 | 3. How do I see the saved states list? | |
142 | ||
143 | Run "metche list". | |
144 | ||
145 | 4. I've broken my system, how can I see a report against a previous, system | |
146 | state, known as working? | |
147 | ||
148 | Run "metche report [{stable,testing,unstable}-YYYYMMDDHHMM]". | |
149 | If no saved state is specified, the most recently saved "testing state" | |
150 | is used as reference. | |
151 | ||
152 | 5. How do I create a "stable state" manually? | |
153 | ||
154 | Run "metche stabilize [testing-YYYYMMDDHHMM]". | |
155 | This turns the given "testing state", if specified, otherwise the one most | |
156 | recently saved, into a "stable state". | |
157 | ||
158 | 6. Why is metche filling my /var partition? | |
159 | ||
160 | First, metche needs to make backups of your "system state" in order to be | |
161 | able to provide you with changes reports. Whatever you do, metche *will* use | |
162 | some disk space (a few dozens megabytes on a typical server). Please note | |
163 | metche performs full, and not incremental, backups. | |
164 | ||
165 | But there are a few ways to limit the disk space metche uses. Here is | |
166 | the cookbook. | |
167 | ||
168 | a) Exclude some big files from the set monitored by metche. | |
169 | - Have a look to your metche backup files: | |
170 | # ls -l /var/lib/metche/*.tar.bz2 | |
171 | - If the average size for these files is greater than a few megabytes, | |
172 | you should investigate which file or directory (in $WATCHED_DIR) is | |
173 | guilty and use the EXCLUDES option to keep it out of metche's hands. | |
174 | ||
175 | b) Speed up the mechanism that automatically turns an "unstable state" into | |
176 | a "testing state", and a "testing state into a "stable" one. | |
177 | - First, let metche run for a while with its default TESTING_TIME and | |
178 | STABLE_TIME configuration values (the "for a while" meaning depends on | |
179 | how much nervous you get when you run 'df /var' every five minute; | |
180 | a few days is a bare minimum, a few weeks is better). | |
181 | - Then, have a look to the files metche has kept in $BACKUP_DIR; a simple | |
182 | 'metche list' is enough if you're not monitoring any VServer. | |
183 | - If there is a huge list of "unstable" but only few "testing" states, | |
184 | you can try lowering TESTING_TIME. If there are many more "testing" | |
185 | states than "stable" state, you can try lowering STABLE_TIME. | |
186 | It's better to only tweak one of these two parameters at a time. | |
187 | - Let metche run "for a while" again... and iterate. | |
188 | ||
189 | c) Still despaired? | |
190 | If this does not work for you, you might also have found a weird case that | |
191 | metche does not handle well, call it a bug or whatever you want; you | |
192 | should actually e-mail us (metche AT lists DOT riseup DOT net) the output | |
193 | of 'metche list', your configuration file (stripped from private | |
194 | information), and some information about the metche version you're running. |