<p dir="ltr">I think that subnet would still be incorrect for what your describing. Your only using the 4th octet for host on those ranges.</p>
<div class="gmail_quote">On Apr 21, 2013 5:32 PM, "Rick Hornsby" <<a href="mailto:richardjhornsby@gmail.com">richardjhornsby@gmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
On Apr 21, 2013, at 11:43 , Rob Funk <<a href="mailto:rfunk@funknet.net">rfunk@funknet.net</a>> wrote:<br>
<br>
> On Friday, April 19, 2013 10:42:24 PM Rick Hornsby wrote:<br>
>> It has been a while since I've messed with Ubuntu. Wow have things<br>
>> changed. I'm a RHEL admin by day, but have been working on setting up<br>
>> Ubuntu (/etc/debian_version says wheezy/sid)<br>
><br>
> debian_version isn't as useful as /etc/os-release and /etc/lsb-release. On<br>
> an unfamiliar Linux system I usually do "cat /etc/*release", which also<br>
> catches redhat_release.<br>
<br>
Good call.<br>
<br>
rhornsby@archer:~$ cat /etc/*-release<br>
DISTRIB_ID=Ubuntu<br>
DISTRIB_RELEASE=12.10<br>
DISTRIB_CODENAME=quantal<br>
DISTRIB_DESCRIPTION="Ubuntu 12.10"<br>
NAME="Ubuntu"<br>
VERSION="12.10, Quantal Quetzal"<br>
ID=ubuntu<br>
ID_LIKE=debian<br>
PRETTY_NAME="Ubuntu quantal (12.10)"<br>
VERSION_ID="12.10"<br>
<br>
><br>
>> The way that things get started, stopped, and started on boot<br>
>> (update-rc.d instead of chkconfig?) seems to be one of the huge<br>
>> differences between RH and Ubuntu/Debian.<br>
><br>
> update-rc.d came from Debian, along with lots of other update-* commands. I<br>
> think it's useful to type update-TAB and look at all the options of OS parts<br>
> to update.<br>
><br>
> Howver, Ubuntu uses its own "Upstart" thing to start stuff on boot, though<br>
> it's backward-compatible with the old init stuff. I still tend to run<br>
> "/etc/init.d/whatever restart" instead of using the "service" command (which<br>
> I believe is also on Red Hat), since I always forget the order of arguments<br>
> to "service".<br>
<br>
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.<br>
<br>
rhornsby@archer:~$ /etc/init.d/isc-dhcp-server status<br>
Rather than invoking init scripts through /etc/init.d, use the service(8)<br>
utility, e.g. service isc-dhcp-server status<br>
<br>
Since the script you are attempting to invoke has been converted to an<br>
Upstart job, you may also use the status(8) utility, e.g. status isc-dhcp-server<br>
isc-dhcp-server start/running, process 1154<br>
rhornsby@archer:~$ status isc-dhcp-server<br>
isc-dhcp-server start/running, process 1154<br>
<br>
><br>
>> At the moment, I'm scratching my head on that front. I have bind9, dhcpd,<br>
>> and a nat script for setting up the MASQ all working fine sort of.<br>
>><br>
>> One thing I can't figure out right now is why the default route is getting<br>
>> set up incorrectly on boot:<br>
<br>
...<br>
<br>
>> This is /etc/network/interfaces:<br>
>><br>
>> # The loopback network interface<br>
>> auto lo<br>
>> iface lo inet loopback<br>
>><br>
>> # The primary network interface<br>
>> auto eth0<br>
>> iface eth0 inet dhcp<br>
>><br>
>> auto eth1<br>
>> iface eth1 inet static<br>
>> address 172.16.0.1<br>
>> netmask 255.255.254.0<br>
>> gateway 172.16.0.1<br>
><br>
> The default route is set to 172.16.0.1 because of the "gateway" line at the<br>
> end of /etc/network/interfaces. Get rid of that if you don't want that as a<br>
> default route.<br>
<br>
ah, durh. The clients pick up the route from the dhcpd server. thanks! this seems to have solved several issues.<br>
<br>
> Odd netmask you have there, btw.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
>> Despite telling bind that it should only listen on 172.16.0.1 and<br>
>> 127.0.0.1, the logs show that it is binding to 192.168.2.8 (the DHCP<br>
>> assigned address for eth0).<br>
>><br>
>> Apr 13 20:11:35 archer named[996]: listening on IPv4 interface eth0,<br>
>> 192.168.2.8#53<br>
><br>
> I'm not that familiar with bind9, but you didn't post any of its<br>
> configuration...<br>
<br>
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.<br>
<br>
> Are you sure it's being told not to bind to the eth0<br>
> address?<br>
<br>
Pretty sure:<br>
<br>
rhornsby@archer:~$ grep listen-on /etc/bind/named.conf.options<br>
listen-on-v6 { none; };<br>
listen-on { 127.0.0.1; 172.16.0.1; };<br>
<br>
rhornsby@archer:~$ grep internal /etc/bind/*<br>
/etc/bind/named.conf:acl internals { <a href="http://127.0.0.0/8" target="_blank">127.0.0.0/8</a>; <a href="http://172.16.0.0/23" target="_blank">172.16.0.0/23</a>; };<br>
/etc/bind/named.conf.options: allow-query { internals; };<br>
/etc/bind/named.conf.options: allow-recursion { internals; };<br>
<br>
<br>
>> I'm not even sure where to look at this point, because I'm so unfamiliar<br>
>> with this up-start stuff. Any ideas?<br>
><br>
> Upstart is irrelevant here. You still have scripts in /etc/init.d that you<br>
> may be able to follow, but the real issue is your configuration elsewhere.<br>
<br>
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.<br>
<br>
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:<br>
<br>
Apr 21 16:10:39 archer named[1080]: listening on IPv4 interface lo, 127.0.0.1#53<br>
Apr 21 16:10:39 archer named[1080]: listening on IPv4 interface eth1, 172.16.0.1#53<br>
<br>
<br>
<br>
<br>
_______________________________________________<br>
colug-432 mailing list<br>
<a href="mailto:colug-432@colug.net">colug-432@colug.net</a><br>
<a href="http://lists.colug.net/mailman/listinfo/colug-432" target="_blank">http://lists.colug.net/mailman/listinfo/colug-432</a><br>
</blockquote></div>