[colug-432] Ubuntu … is not Redhat
FiL Farris
philipfarris at gmail.com
Mon Apr 22 18:30:05 EDT 2013
I apologize for any confusion. I had only glanced over it and when I saw
the ranges you provided for ip's to be assigned I thought class C (you were
only using .2 - .254 in both segments ).
Thats what I get for thinking :)
FiL
On Mon, Apr 22, 2013 at 5:46 PM, Rick Hornsby <richardjhornsby at gmail.com>wrote:
>
>
>
> 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
>>
>>
>
> _______________________________________________
> 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/cd75e652/attachment.html
More information about the colug-432
mailing list