[colug-432] Ubuntu … is not Redhat

Mon Apr 22 01:44:04 EDT 2013

I think that subnet would still be incorrect for what your describing.
Your only using the 4th octet for host on those ranges.
On Apr 21, 2013 5:32 PM, "Rick Hornsby" <richardjhornsby at gmail.com> wrote:

>
> On Apr 21, 2013, at 11:43 , Rob Funk <rfunk at funknet.net> wrote:
>
> > On Friday, April 19, 2013 10:42:24 PM Rick Hornsby wrote:
> >> It has been a while since I've messed with Ubuntu.  Wow have things
> >> changed.  I'm a RHEL admin by day, but have been working on setting up
> >> Ubuntu (/etc/debian_version says wheezy/sid)
> >
> > debian_version isn't as useful as /etc/os-release and /etc/lsb-release.
> On
> > an unfamiliar Linux system I usually do "cat /etc/*release", which also
> > catches redhat_release.
>
> Good call.
>
> rhornsby at archer:~$ cat /etc/*-release
> DISTRIB_ID=Ubuntu
> DISTRIB_RELEASE=12.10
> DISTRIB_CODENAME=quantal
> DISTRIB_DESCRIPTION="Ubuntu 12.10"
> NAME="Ubuntu"
> VERSION="12.10, Quantal Quetzal"
> ID=ubuntu
> ID_LIKE=debian
> PRETTY_NAME="Ubuntu quantal (12.10)"
> VERSION_ID="12.10"
>
> >
> >>  The way that things get started, stopped, and started on boot
> >> (update-rc.d instead of chkconfig?) seems to be one of the huge
> >> differences between RH and Ubuntu/Debian.
> >
> > update-rc.d came from Debian, along with lots of other update-*
> commands. I
> > think it's useful to type update-TAB and look at all the options of OS
> parts
> > to update.
> >
> > Howver, Ubuntu uses its own "Upstart" thing to start stuff on boot,
> though
> > it's backward-compatible with the old init stuff. I still tend to run
> > "/etc/init.d/whatever restart" instead of using the "service" command
> (which
> > I believe is also on Red Hat), since I always forget the order of
> arguments
> > to "service".
>
> Yeah, supposedly using 'service' is better because it can pick up any
> environment that is needed, but other than the annoying messages about not
> using the init.d script directly, I've ever found service to be any better.
>  Like you, I forget the order of arguments.
>
> rhornsby at archer:~$ /etc/init.d/isc-dhcp-server status
>         Rather than invoking init scripts through /etc/init.d, use the
> service(8)
>         utility, e.g. service isc-dhcp-server status
>
>         Since the script you are attempting to invoke has been converted
> to an
>         Upstart job, you may also use the status(8) utility, e.g. status
> isc-dhcp-server
>         isc-dhcp-server start/running, process 1154
>         rhornsby at archer:~$ status isc-dhcp-server
>         isc-dhcp-server start/running, process 1154
>
> >
> >> At the moment, I'm scratching my head on that front.  I have bind9,
> dhcpd,
> >> and a nat script for setting up the MASQ all working fine sort of.
> >>
> >> One thing I can't figure out right now is why the default route is
> getting
> >> set up incorrectly on boot:
>
> ...
>
> >> This is /etc/network/interfaces:
> >>
> >> # The loopback network interface
> >> auto lo
> >> iface lo inet loopback
> >>
> >> # The primary network interface
> >> auto eth0
> >> iface eth0 inet dhcp
> >>
> >> auto eth1
> >> iface eth1 inet static
> >>        address 172.16.0.1
> >>        netmask 255.255.254.0
> >>        gateway 172.16.0.1
> >
> > The default route is set to 172.16.0.1 because of the "gateway" line at
> the
> > end of /etc/network/interfaces. Get rid of that if you don't want that
> as a
> > default route.
>
> ah, durh.  The clients pick up the route from the dhcpd server.  thanks!
>  this seems to have solved several issues.
>
> > Odd netmask you have there, btw.
>
> The netmask is to support using 172.16.0.2-172.16.0.254 as the static IP
> assignments (host {} blocks in dhcpd.conf), and to have the dynamically
> assigned addresses 172.16.1.2-172.16.1.254.
>
> Do I really need that many IP addresses?  No.  The most I've ever used at
> home at once was probably 25 or so, when a bunch of family was here with
> all of their phones and iPods, and iPads, etc.  I could divide them up into
> 172.16.0.10-.99 and 172.16.0.100-.254 and use a mask of 255.255.255.0.
>
> One of the problems with using the 172.16 block is accidentally
> transposing it into 127. and turning the .16. into .168. (as in
> 192.168.etc).  That alone has almost made me go back to the 192.168 range.
>
> >> Despite telling bind that it should only listen on 172.16.0.1 and
> >> 127.0.0.1, the logs show that it is binding to 192.168.2.8 (the DHCP
> >> assigned address for eth0).
> >>
> >> Apr 13 20:11:35 archer named[996]: listening on IPv4 interface eth0,
> >> 192.168.2.8#53
> >
> > I'm not that familiar with bind9, but you didn't post any of its
> > configuration...
>
> There doesn't seem to be a way to bind it to an interface like eth0
> directly, only to an address.  If it is in the manpage, I've missed it.
>
> > Are you sure it's being told not to bind to the eth0
> > address?
>
> Pretty sure:
>
> rhornsby at archer:~$ grep listen-on /etc/bind/named.conf.options
>         listen-on-v6 { none; };
>         listen-on { 127.0.0.1; 172.16.0.1; };
>
> rhornsby at archer:~$ grep internal /etc/bind/*
> /etc/bind/named.conf:acl internals {  127.0.0.0/8; 172.16.0.0/23; };
> /etc/bind/named.conf.options:   allow-query { internals; };
> /etc/bind/named.conf.options:   allow-recursion { internals; };
>
>
> >> I'm not even sure where to look at this point, because I'm so unfamiliar
> >> with this up-start stuff.  Any ideas?
> >
> > Upstart is irrelevant here. You still have scripts in /etc/init.d that
> you
> > may be able to follow, but the real issue is your configuration
> elsewhere.
>
> It definitely does seem really odd that bind would start before all the
> ethernet interfaces were up.  Which makes me think that something is not
> necessarily wrong with bind, but rather with how the interfaces are being
> initialized.
>
> After fixing the gateway issue, it appears to have resolved nearly all of
> the other problems.  One thing that bind kept complaining about during boot
> was that it couldn't get to the outside world.  It doesn't seem to be
> complaining about that now (which makes sense why it could reach the
> internet now.), and it seems to be able to bind properly like it should:
>
> Apr 21 16:10:39 archer named[1080]: listening on IPv4 interface lo,
> 127.0.0.1#53
> Apr 21 16:10:39 archer named[1080]: listening on IPv4 interface eth1,
> 172.16.0.1#53
>
>
>
>
> _______________________________________________
> colug-432 mailing list
> colug-432 at colug.net
> http://lists.colug.net/mailman/listinfo/colug-432
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.colug.net/pipermail/colug-432/attachments/20130422/22b2d41c/attachment-0001.html 