[colug-432] Ubuntu … is not Redhat
Rick Hornsby
richardjhornsby at gmail.com
Mon Apr 22 17:46:49 EDT 2013
On Mon, Apr 22, 2013 at 12:44 AM, FiL Farris <philipfarris at gmail.com> wrote:
> I think that subnet would still be incorrect for what your describing.
> Your only using the 4th octet for host on those ranges.
>
Not sure I'm following. It seems right:
mac-rh022215:~ rh022215$ ipcalc 172.16.0.1/255.255.254.0
Address: 172.16.0.1 10101100.00010000.0000000 0.00000001
Netmask: 255.255.254.0 = 23 11111111.11111111.1111111 0.00000000
Wildcard: 0.0.1.255 00000000.00000000.0000000 1.11111111
=>
Network: 172.16.0.0/23 10101100.00010000.0000000 0.00000000
HostMin: 172.16.0.1 10101100.00010000.0000000 0.00000001
HostMax: 172.16.1.254 10101100.00010000.0000000 1.11111110
Broadcast: 172.16.1.255 10101100.00010000.0000000 1.11111111
Hosts/Net: 510 Class B, Private Internet
> 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
>>
>
> _______________________________________________
> 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/74a57fbb/attachment.html
More information about the colug-432
mailing list