Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.debian.user > #164584
| From | Reco <recoverym4n@gmail.com> |
|---|---|
| Newsgroups | linux.debian.user |
| Subject | Re: BIND problem |
| Date | 2016-02-23 22:50 +0100 |
| Message-ID | <r5t0f-2Ub-19@gated-at.bofh.it> (permalink) |
| References | (8 earlier) <r5csq-8gx-13@gated-at.bofh.it> <r5gPo-2MH-5@gated-at.bofh.it> <r5mL7-7at-13@gated-at.bofh.it> <r5nxv-7tJ-5@gated-at.bofh.it> <r5sGS-2L7-3@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
On Tue, 23 Feb 2016 14:04:52 -0700 Glenn English <ghe@srv.slsware.net> wrote: > > > On Feb 23, 2016, at 8:56 AM, Reco <recoverym4n@gmail.com> wrote: > > > > First things first, unless someone deliberately customized > > it, /etc/rc.local should contain exactly one meaningful line - 'exit > > 0'. > > It does. See below. > > > Your result shows entirely different thing though. > > Well, I just asked egrep to look for the string 'rc.local' anywhere in a filename in /etc. And it found what look to me like a couple hidden mozilla files. In the list of names, not in the execution of the files. '-r' flag forced grep to do a different thing - take a contents of /etc, discard it, and *then* search your current working dir (which happened to be /root) recursively (and case-insensitive) for 'rc.local'. Any other way you'd see /etc/rc.local in the result of grep. > > A simple 'cat /etc/rc.local' would be even better. > > root@log:~# cat /etc/rc.local > #!/bin/sh -e > # > # rc.local > # > # This script is executed at the end of each multiuser runlevel. > # Make sure that the script will "exit 0" on success or any other > # value on error. > # > # In order to enable or disable this script just change the execution > # bits. > # > # By default this script does nothing. > > exit 0 Nothing unusual, but: > > But, that's assuming > > that you can trust your current kernel and userland (see above). > > Are you saying it would be worthwhile to compare my kernel modules to those in a live CD? Or is that considered overkill and probably not necessary? Why, it's worth a shot. But doing it by hand would be counter-productive. They have invented 'debsums' for cases like this, after all. A small howto follows: 1) Boot from LiveCD. 2) Mount hosts' root and /var (if it's a different filesystem) somewhere. Something like this: mount -o ro,noexec /dev/sda1 /mnt mount -o ro,noexec /dev/sda2 /mnt/var 3) Run LiveCD's debsums like this: debsums -r /mnt -d /mnt/var/lib/dpkg -c It's important that you should run LiveCD's debsums, not hosts' one. 4) Check for any kernel module out of place like this: find /mnt/lib/modules -type f | xargs dpkg --root=/mnt -S 5) And, while you're at it, check for real contents of /etc/rc.local, and for /etc/ld.so.preload. Reco
Back to linux.debian.user | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
BIND problem Glenn English <ghe@srv.slsware.net> - 2016-02-22 11:00 +0100
Re: BIND problem Reco <recoverym4n@gmail.com> - 2016-02-22 11:20 +0100
Re: BIND problem Glenn English <ghe@srv.slsware.net> - 2016-02-22 21:30 +0100
Re: BIND problem Reco <recoverym4n@gmail.com> - 2016-02-22 22:00 +0100
Re: BIND problem Glenn English <ghe@srv.slsware.net> - 2016-02-22 23:00 +0100
Re: BIND problem Reco <recoverym4n@gmail.com> - 2016-02-22 23:20 +0100
Re: BIND problem Reco <recoverym4n@gmail.com> - 2016-02-23 00:00 +0100
Re: BIND problem Glenn English <ghe@srv.slsware.net> - 2016-02-23 05:10 +0100
Re: BIND problem Reco <recoverym4n@gmail.com> - 2016-02-23 09:50 +0100
Re: BIND problem Glenn English <ghe@srv.slsware.net> - 2016-02-23 16:10 +0100
Re: BIND problem Reco <recoverym4n@gmail.com> - 2016-02-23 17:00 +0100
Re: BIND problem Glenn English <ghe@srv.slsware.net> - 2016-02-23 22:30 +0100
Re: BIND problem Reco <recoverym4n@gmail.com> - 2016-02-23 22:50 +0100
Re: BIND problem Glenn English <ghe@srv.slsware.net> - 2016-02-24 05:20 +0100
Re: BIND problem Glenn English <ghe@srv.slsware.net> - 2016-02-23 00:00 +0100
csiph-web