| 2 | |
| 3 | == {{{mondoarchive}}} on Red Hat/EL running BIND ({{{/proc}}} also mounted in chroot) == |
| 4 | |
| 5 | This is just a TIP from my observations on:[[BR]] |
| 6 | Red Hat/EL AS v4.4 running bind-9.2.4-16.EL4[[BR]] |
| 7 | It may hold true for other versions of Red Hat as well as Fedora. |
| 8 | |
| 9 | The {{{named}}} (bind) runs in a ''chroot'' environment, and as part of its |
| 10 | startup script there is a: |
| 11 | {{{ |
| 12 | mount --bind /proc /var/named/chroot/proc |
| 13 | }}} |
| 14 | which means (as described in man mount): |
| 15 | {{{ |
| 16 | Since Linux 2.4.0 it is possible to remount part of the file |
| 17 | hierarchy somewhere else. The call is |
| 18 | mount --bind olddir newdir |
| 19 | After this call the same contents is accessible in two places. |
| 20 | }}} |
| 21 | As a result you have this (edited from {{{df -ha}}}): |
| 22 | {{{ |
| 23 | Filesystem Size Used Avail Use% Mounted on |
| 24 | ...[snip]... |
| 25 | none 0 0 0 - /proc |
| 26 | ...[snip]... |
| 27 | /proc 0 0 0 - /var/named/chroot/proc |
| 28 | ...[snip]... |
| 29 | }}} |
| 30 | |
| 31 | Yes, {{{/proc}}} is mounted in two places, and there's no announcement to |
| 32 | that effect -- it is not immediately obvious! You gotta look for it. |
| 33 | And that extra mount is not automatically excluded by {{{mondoarchive}}}. |
| 34 | |
| 35 | What this means is that if you {{{mondoarchive}}} the system without |
| 36 | excluding that chroot area ({{{/var/named/chroot/proc}}}) you will be |
| 37 | including it ({{{/proc}}}) in your backup. |
| 38 | [[BR]] |
| 39 | (Or you could stop named and: {{{umount /var/named/chroot/proc}}}.) |
| 40 | |
| 41 | In any case, the further gotcha is that if you get the |
| 42 | {{{/var/named/chroot/proc}}} in the backup, it's going to be created when |
| 43 | you boot/run {{{mondorestore}}}. |
| 44 | If you booted the {{{mondorestore}}} (CD/DVD) for a system |
| 45 | recovery, you need to keep in mind: |
| 46 | * the {{{named}}} will not be running; therefore, |
| 47 | * the startup script ({{{/etc/init.d/named}}}) will ''not'' have done the "{{{mount --bind /proc /var/named/chroot/proc}}}", which means |
| 48 | * you will create that whole filesystem as ''real'' files/directories in {{{/var/named/chroot/proc}}}. |
| 49 | [[BR]] |
| 50 | Of course, when the |
| 51 | {{{named}}} startup script is run it should go ahead and do the |
| 52 | "{{{mount --bind}}}" |
| 53 | over the top of the junk, but stuff like that just makes me |
| 54 | nervous. |
| 55 | |
| 56 | ''ANYWAY'', I just thought I'd drop this observation out there for |
| 57 | whomever might be interested. |
| 58 | |
| 59 | I suspect that such a thing might be the case on other stuff that runs |
| 60 | in chroot jail. Maybe it is also true for other non-RH distributions, |
| 61 | too? |
| 62 | |
| 63 | Just something to be aware of. |
| 64 | [[BR]] |
| 65 | The moral is: |
| 66 | ''Check your mounts before you do your backup!'' |
| 67 | |