Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
dynamic dns
36 views
Skip to first unread message
Joe Rosevear
Jan 27, 2012, 12:45:09 AM1/27/12
to
Question:
vvv
What is a simple way in Slackware to set up the ability to
refer to other boxes in a DHCP-based network by hostname?
I don't expect to be able to do this:
host <hostname>
I understand that depends on the DNS.
But I would like to be able to do this
ssh <hostname> -l <username>
and
ping <hostname>
^^^
I was able to accomplish the above by using a service provided by
no-ip.com, but that seems like a lame thing to do. I'm considering
using fixed ip-addresses instead and depending on my /etc/hosts files
(will that work?), but that isn't my first wish.
I'm sort of baffled by how it works at my work place. (I guess I
should ask this question there...) At work I can do both of these:
host whiz
ssh whiz -l joe
I *did* put a line like this in /etc/rc.d/rc.inet1.conf in whiz
DHCP_HOSTNAME[0]="whiz"
but I don't know for sure that it was needed. I'll test it and report
back.
Any help with the question (at the beginning) and the subsequent
confusion would be appreciated!
-Joe
--
http://JosephRosevear.com
http://RosevearSoftware.com
vvv
What is a simple way in Slackware to set up the ability to
refer to other boxes in a DHCP-based network by hostname?
I don't expect to be able to do this:
host <hostname>
I understand that depends on the DNS.
But I would like to be able to do this
ssh <hostname> -l <username>
and
ping <hostname>
^^^
I was able to accomplish the above by using a service provided by
no-ip.com, but that seems like a lame thing to do. I'm considering
using fixed ip-addresses instead and depending on my /etc/hosts files
(will that work?), but that isn't my first wish.
I'm sort of baffled by how it works at my work place. (I guess I
should ask this question there...) At work I can do both of these:
host whiz
ssh whiz -l joe
I *did* put a line like this in /etc/rc.d/rc.inet1.conf in whiz
DHCP_HOSTNAME[0]="whiz"
but I don't know for sure that it was needed. I'll test it and report
back.
Any help with the question (at the beginning) and the subsequent
confusion would be appreciated!
-Joe
--
http://JosephRosevear.com
http://RosevearSoftware.com
Henrik Carlqvist
Jan 27, 2012, 3:11:39 AM1/27/12
to
Joe Rosevear <Joe_Ro...@localhost.invalid> wrote:
> What is a simple way in Slackware to set up the ability to
> refer to other boxes in a DHCP-based network by hostname?
I wouldn't say that it is simple, but the way to do it is to configure
> What is a simple way in Slackware to set up the ability to
> refer to other boxes in a DHCP-based network by hostname?
your DHCP server to perform dynamic updates of your DNS server. I did this
some months ago, looking at web pages like
http://www.semicomplete.com/articles/dynamic-dns-with-dhcp/
If I remember right I was not able to find all the information I needed in
a single web page, but the one above was one of the better pages.
> I don't expect to be able to do this:
>
> host <hostname>
functionality.
> I understand that depends on the DNS.
>
> But I would like to be able to do this
>
> ssh <hostname> -l <username>
>
> and
>
> ping <hostname>
> ^^^
able to do that.
> I was able to accomplish the above by using a service provided by
> no-ip.com, but that seems like a lame thing to do. I'm considering
> using fixed ip-addresses instead and depending on my /etc/hosts files
> (will that work?), but that isn't my first wish.
complete /etc/hosts on every machine you could use some catalog service
like NIS. I wouldn't say that configuring NIS is trivial, but IMHO it
would at least be easier than configuring dynamic DNS updates from dhcpd.
It is rather well described in the NIS Howto.
> I'm sort of baffled by how it works at my work place. (I guess I should
> ask this question there...) At work I can do both of these:
>
> host whiz
> ssh whiz -l joe
ssh 192.168.100.100 -l joe
However you would not be able to do "ssh whiz..." unless "host whiz" where
working.
> I *did* put a line like this in /etc/rc.d/rc.inet1.conf in whiz
>
> DHCP_HOSTNAME[0]="whiz"
>
> but I don't know for sure that it was needed. I'll test it and report
> back.
name whiz. The DHCP server then tells the DNS server about whiz and the IP
it gave whiz.
IMHO, in most configurations static IP addresses are to prefer.
Configuring DHCP and DNS servers with dynamic updating is a non trivial
task. Also, I would say that some of the point with DHCP is lost when it
relies on a correct configuration on the client machines.
I know that some MS Windows administrators still think that DHCP is a
great idea as they can use DHCP as a catalog service to provide
information like IP addresses to DNS servers. However, if you have plans
to change IP addresses of your DNS servers something is seriously broken
in your plan. Also, a catalog service which more or less requires a reboot
of every client to update the clients is not worth its name, only Windows
administrators consider reboots to be normal daily maintainance.
regards Henrik
--
The address in the header is only to prevent spam. My real address is:
hc123(at)poolhem.se Examples of addresses which go to spammers:
root@localhost postmaster@localhost
Sylvain Robitaille
Jan 27, 2012, 10:56:05 AM1/27/12
to
Joe Rosevear wrote:
>> What is a simple way in Slackware to set up the ability to
>> refer to other boxes in a DHCP-based network by hostname?
Look at dnsmasq, included on your installation CD (and perhaps already
>> What is a simple way in Slackware to set up the ability to
>> refer to other boxes in a DHCP-based network by hostname?
installed on your system). I've not used it myself, though, so you'll
likely have some reading to do, but my understanding is that it can
do exactly this (provide DHCP service that dynamically updates local
DNS service). That said, what you're looking to do, as Henrik Carlqvist
pointed out is *not* "simple". You need to understand how DNS and DHCP
work (or at least how to configure them), and you need to understand
what can go wrong if you don't configure things right.
>> I don't expect to be able to do this:
>>
>> host <hostname>
>>
>> I understand that depends on the DNS.
>>
>> But I would like to be able to do this
>>
>> ssh <hostname> -l <username>
>> and
>> ping <hostname>
You can't do the latter two unless the former works. The first thing
>>
>> But I would like to be able to do this
>>
>> ssh <hostname> -l <username>
>> and
>> ping <hostname>
your system will do when you type "ssh <hostname>" is exactly equivalent
to "host <hostname>", because that's how your system knows which other
system you want to ssh to. Computers "know" each other by IP address;
We know them by name.
>> I'm sort of baffled by how it works at my work place. ...
That's going to be a problem, because you need to understand how it
works, if you want to be sure you have it working right. Get experience
with DNS and DHCP first, then worry about combining them.
On Fri, 27 Jan 2012 09:11:39 +0100, Henrik Carlqvist wrote:
> Using fixed IPs is usually preferred for servers. Instead of having
> complete /etc/hosts on every machine you could use some catalog
> service like NIS.
If you have the DHCP server assign fixed addresses, you don't need
dynamic updating on the DNS.
> I wouldn't say that configuring NIS is trivial, but IMHO it would at
> least be easier than configuring dynamic DNS updates from dhcpd.
updates from DHCP.
>> I *did* put a line like this in /etc/rc.d/rc.inet1.conf in whiz
>>
>> DHCP_HOSTNAME[0]="whiz"
>
> That line makes the machine tell the DHCP server that it should have
> the name whiz. The DHCP server then tells the DNS server about whiz
> and the IP it gave whiz.
... assuming the OP's work place is indeed performing dynamic DNS
> That line makes the machine tell the DHCP server that it should have
> the name whiz. The DHCP server then tells the DNS server about whiz
> and the IP it gave whiz.
updates, yes. Another possibility is that they simply assign static
addressing from their DNS server, and manually update the DNS. That's
certainly much easier to setup, even if it implies continued human
intervention.
> ... I would say that some of the point with DHCP is lost when it
> relies on a correct configuration on the client machines.
Which part are you anticipating "relies on a correct configuration on
the client machines"? DHCP does configure more than the IP address of
the client, unless explicitly made not to.
> I know that some MS Windows administrators still think that DHCP is a
> great idea as they can use DHCP as a catalog service to provide
> information like IP addresses to DNS servers. However, if you have
> plans to change IP addresses of your DNS servers something is
> seriously broken in your plan.
DNS updated from DHCP, but I don't see how this is, nor do I see why
this notion would be limitted to Windows administrators. It isn't quite
accurate to state that DHCP can "provide information like IP addresses to
DNS servers," though. The DHCP server can be made to update IP address
to hostname correlation on the DNS server(s). The IP addresses are either
on your network (and resolved by your DNS server(s)) or they aren't.
The DHCP server sends the IP address(es) of the DNS resolver(s) to the
clients with each lease. If you're going to change the IP address(es) of
your resolver(s), simply update the DHCP server configuration accordingly.
Perhaps change one resolver at a time, to ensure continued service with
existing leases, but the plan can be made to work. DHCP indeed *is*
a good idea in a lot of (perhaps even "most"?) situations, and it can
even simplify configuration in an environment that uses static addressing.
--
----------------------------------------------------------------------
Sylvain Robitaille s...@encs.concordia.ca
Systems analyst / AITS Concordia University
Faculty of Engineering and Computer Science Montreal, Quebec, Canada
----------------------------------------------------------------------
Lew Pitcher
Jan 27, 2012, 12:37:55 PM1/27/12
to
On Friday 27 January 2012 00:45, in alt.os.linux.slackware,
DHCP server as well.
The DHCP server will give clients IP addresses on the network. These can be
IP addresses pulled randomly out of a pool, or they can be pre-assigned IP
addresses.
/If/ you are looking to map pre-assigned addresses, you can just update
your /etc/hosts file with the known IP addresses, and your choice of
hostname. Or, you can (if you have access to your DNS service) simply add
those pre-assigned addresses to the appropriate subnet and name database
files.
OTOH, if you are trying to map randomly assigned IP addresses (the norm in
DHCP systems) to hostnames, you have a bit larger problem. You will need to
alter the configuration of /both/ your DHCP server, /and/ your DNS server
to accomodate the name assignments.
On your DNS server (I'm using BIND 9 as an example), you will have to add an
update key, and permission rules that specify which systems can use it. In
my BIND 9 environment, where both DNS and DHCP servers run on the same
system, my named.conf file contains
key "rndc-key" {
algorithm hmac-md5;
secret "Grl6hpvDe08dgD2SBw05Kg==";
};
controls {
inet 127.0.0.1 port 953
allow { 127.0.0.1; } keys { "rndc-key"; };
};
The "rndc-key" stanza defines a secret key that automated processes must use
to authenticate that they are permitted to update the DNS. The "controls"
stanza defines which networks Bind will accept automated connections from.
Between these two stanzas, you define exactly which machines (services) can
update the DNS. This includes the machine that runs the DHCP server.
On the DHCP server, you now have to add in configuration that tells DHCP to
pass name change requests on to the DNS server. DHCP can query the client
system for it's preferred name, and can pass that name, or one coded in the
DHCP configuration onward to DNS for registration against the assigned IP
address. In DHCP 3.1 (the DHCP server I use), you do this
in /etc/dhcpd.conf. The configuration changes here look like:
key "rndc-key" {
algorithm hmac-md5;
secret "Grl6hpvDe08dgD2SBw05Kg==";
};
zone my.lan. {
primary 127.0.0.1;
key "rndc-key";
}
zone 100.168.192.in-addr.arpa. {
primary 127.0.0.1;
key "rndc-key";
}
ddns-domainname "my.lan";
ddns-update-style interim;
ddns-rev-domainname "in-addr.arpa";
get-lease-hostnames true;
option domain-name "my.lan";
option domain-name-servers 192.168.100.1
These tell DHCP to talk with BIND to register both the
hostname-to-IP-address and IP-address-to-hostname with DNS, and to allow
the DHCP client system to ask for a specific hostname.
HTH
--
Lew Pitcher
Joe_Ro...@localhost.invalid wrote:
> Question:
>
> vvv
> What is a simple way in Slackware to set up the ability to
> refer to other boxes in a DHCP-based network by hostname?
Well, this requires changes to your DNS services, and potentially to your
> Question:
>
> vvv
> What is a simple way in Slackware to set up the ability to
> refer to other boxes in a DHCP-based network by hostname?
DHCP server as well.
The DHCP server will give clients IP addresses on the network. These can be
IP addresses pulled randomly out of a pool, or they can be pre-assigned IP
addresses.
/If/ you are looking to map pre-assigned addresses, you can just update
your /etc/hosts file with the known IP addresses, and your choice of
hostname. Or, you can (if you have access to your DNS service) simply add
those pre-assigned addresses to the appropriate subnet and name database
files.
OTOH, if you are trying to map randomly assigned IP addresses (the norm in
DHCP systems) to hostnames, you have a bit larger problem. You will need to
alter the configuration of /both/ your DHCP server, /and/ your DNS server
to accomodate the name assignments.
On your DNS server (I'm using BIND 9 as an example), you will have to add an
update key, and permission rules that specify which systems can use it. In
my BIND 9 environment, where both DNS and DHCP servers run on the same
system, my named.conf file contains
key "rndc-key" {
algorithm hmac-md5;
secret "Grl6hpvDe08dgD2SBw05Kg==";
};
controls {
inet 127.0.0.1 port 953
allow { 127.0.0.1; } keys { "rndc-key"; };
};
The "rndc-key" stanza defines a secret key that automated processes must use
to authenticate that they are permitted to update the DNS. The "controls"
stanza defines which networks Bind will accept automated connections from.
Between these two stanzas, you define exactly which machines (services) can
update the DNS. This includes the machine that runs the DHCP server.
On the DHCP server, you now have to add in configuration that tells DHCP to
pass name change requests on to the DNS server. DHCP can query the client
system for it's preferred name, and can pass that name, or one coded in the
DHCP configuration onward to DNS for registration against the assigned IP
address. In DHCP 3.1 (the DHCP server I use), you do this
in /etc/dhcpd.conf. The configuration changes here look like:
key "rndc-key" {
algorithm hmac-md5;
secret "Grl6hpvDe08dgD2SBw05Kg==";
};
zone my.lan. {
primary 127.0.0.1;
key "rndc-key";
}
zone 100.168.192.in-addr.arpa. {
primary 127.0.0.1;
key "rndc-key";
}
ddns-domainname "my.lan";
ddns-update-style interim;
ddns-rev-domainname "in-addr.arpa";
get-lease-hostnames true;
option domain-name "my.lan";
option domain-name-servers 192.168.100.1
These tell DHCP to talk with BIND to register both the
hostname-to-IP-address and IP-address-to-hostname with DNS, and to allow
the DHCP client system to ask for a specific hostname.
HTH
--
Lew Pitcher
Henrik Carlqvist
Jan 27, 2012, 3:56:22 PM1/27/12
to
Sylvain Robitaille <s...@alcor.concordia.ca> wrote:
>> I wouldn't say that configuring NIS is trivial, but IMHO it would at
>> least be easier than configuring dynamic DNS updates from dhcpd.
>
> I wonder. I expect I'd disagree with you, but I've never done DNS
> updates from DHCP.
Even without dynamic updates of DNS I would still say that NIS is easier
>> I wouldn't say that configuring NIS is trivial, but IMHO it would at
>> least be easier than configuring dynamic DNS updates from dhcpd.
>
> I wonder. I expect I'd disagree with you, but I've never done DNS
> updates from DHCP.
to configure, and most of all; maintain. As I now have an envirinment
mixed with dynamic and static IP addresses I ended up using NIS for all
the static addresses and DHCP (of course) for the dynamic addresses.
Both the DHCP server and the NIS server (with a rather simple custom shell
script) then performs dynamic updates of the DNS server.
IMHO the format of the bind zone files are rather awkward compared to a
nis host map which is just as straigh forward as /etc/hosts.
But then again, I'm now comparing bind with NIS, you were suggesting
dnsmasq which I haven't tried. However, I do have some experience from
pdnsd which I think was a lot easier to setup than bind, but I don't
think it is possible to configure pdnsd to get dynamic updates.
>>> I *did* put a line like this in /etc/rc.d/rc.inet1.conf in whiz
>>>
>>> DHCP_HOSTNAME[0]="whiz"
>> ... I would say that some of the point with DHCP is lost when it relies
>> on a correct configuration on the client machines.
>
> Which part are you anticipating "relies on a correct configuration on
> the client machines"?
I was referring to setting DHCP_HOSTNAME on the client.
>> on a correct configuration on the client machines.
>
> Which part are you anticipating "relies on a correct configuration on
> the client machines"?
Yes, I know that you can configure your DHCP server not to rely on
DHCP_HOSTNAME and still have static IP addresses from mac addresses, but
then again you will rely on some configuration on the client which changes
if the client changes nic.
> DHCP does configure more than the IP address of
> the client, unless explicitly made not to.
NIS servers, NIS domains, ntp-servers, nntp-servers and whatever.
> The DHCP server sends the IP address(es) of the DNS resolver(s) to the
> clients with each lease. If you're going to change the IP address(es)
> of your resolver(s), simply update the DHCP server configuration
> accordingly. Perhaps change one resolver at a time, to ensure continued
> service with existing leases, but the plan can be made to work. DHCP
> indeed *is* a good idea in a lot of (perhaps even "most"?) situations,
> and it can even simplify configuration in an environment that uses
> static addressing.
IMHO it is also not the best solution to depend on a catalog service which
delays data to the clients with a lease time when there are other catalog
services which provide their data more or less instantly.
But most of all, if your network is built upon DHCP and you only have a
single non redundant DHCP server that DHCP server is yet another (IMHO
unnecessary) single point of failure. In the next thunderstorm when your
DHCP server refuses to start after the blackout you will not be able to
use your desktop to surf for a new PSU for you DHCP server. Your desktop
will not be able to see your home directory on your NAS and so on...
Sylvain Robitaille
Jan 27, 2012, 4:46:54 PM1/27/12
to
On Fri, 27 Jan 2012 21:56:22 +0100, Henrik Carlqvist wrote:
> ... then again, I'm now comparing bind with NIS, you were suggesting
dnsmasq incorporates functions of both DNS and DHCP, with a means to
have the latter update the former, plus it's included in the Slackware
distribution, so it seems to me it's likely as close to "simple" as
there is (if perhaps not as flexible as BIND and ISC dhcpd would be).
>>> ... I would say that some of the point with DHCP is lost when it relies
>>> on a correct configuration on the client machines.
>>
>> Which part are you anticipating "relies on a correct configuration on
>> the client machines"?
>
> I was referring to setting DHCP_HOSTNAME on the client.
Oh ... I doubt that's a requirement at all, so it certainly isn't a
strong argument that the possibility of doing so would negate the point
of using DHCP.
> Yes, I know that you can configure your DHCP server not to rely on
> DHCP_HOSTNAME and still have static IP addresses from mac addresses,
Exactly. In fact, as far as I know, that's *how* you get static
addresses (from a mapping against the MAC address). It would be an
error to have a DHCP server trust the client system's notion of what
its hostname is, and assign an IP address on that basis alone.
> but then again you will rely on some configuration on the client which
> changes if the client changes nic.
Yes, but then your configuration is in exactly one place: the DHCP
server. (modulo configuring also the DNS namespace, but that's not a
requirement for the client system to function on the network). That's
the point of using DHCP at all.
> I would still say that changing IP address of DNS servers is a bad
> idea.
I never argued against that. My argument was simply that a plan *can*
be devised that doesn't break just because clients are configured by
DHCP. Sometimes, even if it's a bad idea in general, you have to bite
the bullet and make that sort of change. That one actually is
relatively simple to work through without interrupting service.
> IMHO it is also not the best solution to depend on a catalog service
> which delays data to the clients with a lease time when there are
> other catalog services which provide their data more or less
> instantly.
I don't pay all that much attention to "catalog" services. I don't
see DHCP as such a service at all. The only option it sends back to
the client systems that must refer to servers by IP address is the DNS
resolver(s). All others it can refer to by name, so if you change the
IP address of any other servers, as long as you don't change the name,
the DNS will ensure the client gets the right address, within its own
time delay if the client already has that address cached. If you do
change the name, make sure the old name is still usable (via a cname,
for example) until any existing leases are renewed.
> But most of all, if your network is built upon DHCP and you only have
> a single non redundant DHCP server that DHCP server is yet another
> (IMHO unnecessary) single point of failure.
Yeah. Isn't that also true if you have a single NIS server? The
standard response to that would be "Don't Do That."
> In the next thunderstorm when your DHCP server refuses to start after
> the blackout you will not be able to use your desktop to surf for a
> new PSU for you DHCP server. Your desktop will not be able to see your
> home directory on your NAS and so on...
Not quite, in the absense of any response from a DHCP server, to a
DHCPDISCOVER, client systems can default to continuing to use their
last known lease (probably within some timeout period, I would expect).
Certainly that's been my own experience.
That said, why did the UPS fail?
> ... then again, I'm now comparing bind with NIS, you were suggesting
> dnsmasq which I haven't tried.
I've not tried it either. The OP asked for a "simple" method, and
dnsmasq incorporates functions of both DNS and DHCP, with a means to
have the latter update the former, plus it's included in the Slackware
distribution, so it seems to me it's likely as close to "simple" as
there is (if perhaps not as flexible as BIND and ISC dhcpd would be).
>>> ... I would say that some of the point with DHCP is lost when it relies
>>> on a correct configuration on the client machines.
>>
>> Which part are you anticipating "relies on a correct configuration on
>> the client machines"?
>
> I was referring to setting DHCP_HOSTNAME on the client.
strong argument that the possibility of doing so would negate the point
of using DHCP.
> Yes, I know that you can configure your DHCP server not to rely on
> DHCP_HOSTNAME and still have static IP addresses from mac addresses,
addresses (from a mapping against the MAC address). It would be an
error to have a DHCP server trust the client system's notion of what
its hostname is, and assign an IP address on that basis alone.
> but then again you will rely on some configuration on the client which
> changes if the client changes nic.
server. (modulo configuring also the DNS namespace, but that's not a
requirement for the client system to function on the network). That's
the point of using DHCP at all.
> I would still say that changing IP address of DNS servers is a bad
> idea.
be devised that doesn't break just because clients are configured by
DHCP. Sometimes, even if it's a bad idea in general, you have to bite
the bullet and make that sort of change. That one actually is
relatively simple to work through without interrupting service.
> IMHO it is also not the best solution to depend on a catalog service
> which delays data to the clients with a lease time when there are
> other catalog services which provide their data more or less
> instantly.
see DHCP as such a service at all. The only option it sends back to
the client systems that must refer to servers by IP address is the DNS
resolver(s). All others it can refer to by name, so if you change the
IP address of any other servers, as long as you don't change the name,
the DNS will ensure the client gets the right address, within its own
time delay if the client already has that address cached. If you do
change the name, make sure the old name is still usable (via a cname,
for example) until any existing leases are renewed.
> But most of all, if your network is built upon DHCP and you only have
> a single non redundant DHCP server that DHCP server is yet another
> (IMHO unnecessary) single point of failure.
standard response to that would be "Don't Do That."
> In the next thunderstorm when your DHCP server refuses to start after
> the blackout you will not be able to use your desktop to surf for a
> new PSU for you DHCP server. Your desktop will not be able to see your
> home directory on your NAS and so on...
DHCPDISCOVER, client systems can default to continuing to use their
last known lease (probably within some timeout period, I would expect).
Certainly that's been my own experience.
That said, why did the UPS fail?
Joe Rosevear
Jan 28, 2012, 3:44:40 AM1/28/12
to
Henrik Carlqvist <Henrik.C...@deadspam.com> wrote:
> Joe Rosevear <Joe_Ro...@localhost.invalid> wrote:
>> What is a simple way in Slackware to set up the ability to
>> refer to other boxes in a DHCP-based network by hostname?
>
> I wouldn't say that it is simple, but the way to do it is to configure
> your DHCP server to perform dynamic updates of your DNS server. I did this
> some months ago, looking at web pages like
> http://www.semicomplete.com/articles/dynamic-dns-with-dhcp/
>
> If I remember right I was not able to find all the information I needed in
> a single web page, but the one above was one of the better pages.
Wow. You did it! I came across that same web page in my searches to
> Joe Rosevear <Joe_Ro...@localhost.invalid> wrote:
>> What is a simple way in Slackware to set up the ability to
>> refer to other boxes in a DHCP-based network by hostname?
>
> I wouldn't say that it is simple, but the way to do it is to configure
> your DHCP server to perform dynamic updates of your DNS server. I did this
> some months ago, looking at web pages like
> http://www.semicomplete.com/articles/dynamic-dns-with-dhcp/
>
> If I remember right I was not able to find all the information I needed in
> a single web page, but the one above was one of the better pages.
understand this matter, but only now do I feel that the curtain of
confusion has lifted.
>> I don't expect to be able to do this:
>>
>> host <hostname>
>
> You don't? Translating from a hostname to IP address is really basic
> functionality.
>> I understand that depends on the DNS.
>>
>> But I would like to be able to do this
>>
>> ssh <hostname> -l <username>
>>
>> and
>>
>> ping <hostname>
>> ^^^
>
> Unless the mechanisms for translating hostname to ip works you will not be
> able to do that.
a way that doesn't support "host <hostname>". I mentioned using
/etc/hosts. It looks like an attractive method now that I have seen
the alternatives, and it seems to support my needs. This is practical,
because my network at home is very small.
Some of my boxes travel between work and home. At home I will
configure my dhcp server's dhcpd.conf to assign fixed IPs to them by
MAC address. The corresponding hostnames will be given in /etc/hosts
files that I will manually keep synchronized. At work the
DHCP_HOSTNAME assignment in each rc.inet1.conf will provide the
hostname that the DHCP server will pass on to the DNS.
So, I think I understand now. Thank you for explaining how it worked.
>> I was able to accomplish the above by using a service provided by
>> no-ip.com, but that seems like a lame thing to do. I'm considering
>> using fixed ip-addresses instead and depending on my /etc/hosts files
>> (will that work?), but that isn't my first wish.
suggested that I use DHCP to assign fixed IP addresses. I didn't know
that I could do that. I'm still learning how to configure a DHCP
server.
> Using fixed IPs is usually preferred for servers. Instead of having
> complete /etc/hosts on every machine you could use some catalog service
> like NIS. I wouldn't say that configuring NIS is trivial, but IMHO it
> would at least be easier than configuring dynamic DNS updates from dhcpd.
> It is rather well described in the NIS Howto.
although for now my network is small enough that I can do without it.
>> I'm sort of baffled by how it works at my work place. (I guess I should
>> ask this question there...) At work I can do both of these:
>>
>> host whiz
>> ssh whiz -l joe
>
> If whiz has the address 192.168.100.100 you are also able to do
>
> ssh 192.168.100.100 -l joe
>
> However you would not be able to do "ssh whiz..." unless "host whiz" where
> working.
>
>> I *did* put a line like this in /etc/rc.d/rc.inet1.conf in whiz
>>
>> DHCP_HOSTNAME[0]="whiz"
>>
>> but I don't know for sure that it was needed. I'll test it and report
>> back.
DHCP_HOSTNAME[0]="spark"
and ran "/etc/rc.d/rc.inet1 restart". Then I tried "host whiz" and
"host spark" alternately. It took about a minute or two for "host
whiz" to stop working and "host spark" to start working.
So what happens if I choose a hostname that is already in use? I
didn't try that test, although I did discover that these work:
host bob
host fred
They don't refer to my box, rather to some unknown boxes in our rather
large network.
> That line makes the machine tell the DHCP server that it should have the
> name whiz. The DHCP server then tells the DNS server about whiz and the IP
> it gave whiz.
> IMHO, in most configurations static IP addresses are to prefer.
> Configuring DHCP and DNS servers with dynamic updating is a non trivial
> task. Also, I would say that some of the point with DHCP is lost when it
> relies on a correct configuration on the client machines.
the boxes I wish to reference by hostname.
> I know that some MS Windows administrators still think that DHCP is a
> great idea as they can use DHCP as a catalog service to provide
> information like IP addresses to DNS servers. However, if you have plans
> to change IP addresses of your DNS servers something is seriously broken
> in your plan. Also, a catalog service which more or less requires a reboot
> of every client to update the clients is not worth its name, only Windows
> administrators consider reboots to be normal daily maintainance.
>
> regards Henrik
Joe Rosevear
Jan 28, 2012, 4:19:39 AM1/28/12
to
Sylvain Robitaille <s...@alcor.concordia.ca> wrote:
> Joe Rosevear wrote:
>
>>> What is a simple way in Slackware to set up the ability to
>>> refer to other boxes in a DHCP-based network by hostname?
>
> Look at dnsmasq, included on your installation CD (and perhaps already
> installed on your system). I've not used it myself, though, so you'll
> likely have some reading to do, but my understanding is that it can
> do exactly this (provide DHCP service that dynamically updates local
> DNS service). That said, what you're looking to do, as Henrik Carlqvist
> pointed out is *not* "simple". You need to understand how DNS and DHCP
> work (or at least how to configure them), and you need to understand
> what can go wrong if you don't configure things right.
Right. It doesn't sound at all simple. So, I'll pass on dynamic
> Joe Rosevear wrote:
>
>>> What is a simple way in Slackware to set up the ability to
>>> refer to other boxes in a DHCP-based network by hostname?
>
> Look at dnsmasq, included on your installation CD (and perhaps already
> installed on your system). I've not used it myself, though, so you'll
> likely have some reading to do, but my understanding is that it can
> do exactly this (provide DHCP service that dynamically updates local
> DNS service). That said, what you're looking to do, as Henrik Carlqvist
> pointed out is *not* "simple". You need to understand how DNS and DHCP
> work (or at least how to configure them), and you need to understand
> what can go wrong if you don't configure things right.
updates for now. I don't think that I need such a thing, rather I'll
use fixed IP addresses defined by my DHCP server. I'll get my host
name ip address associations from /etc/hosts files. See my reply to
Henrik.
Thanks though for mentioning dnsmasq. I didn't know that it existed or
that it had such capabilities.
>
>>> I don't expect to be able to do this:
>>>
>>> host <hostname>
>>>
>>> I understand that depends on the DNS.
>>>
>>> But I would like to be able to do this
>>>
>>> ssh <hostname> -l <username>
>>> and
>>> ping <hostname>
>
> You can't do the latter two unless the former works.
addresses and hostnames does not seem to be enough to enable "host
<hosthame>" to work. Yet, perhaps it will meet my needs.
>The first thing your system will do when you type "ssh <hostname>" is
> exactly equivalent to "host <hostname>", because that's how your
> system knows which other system you want to ssh to. Computers "know"
> each other by IP address; We know them by name.
>
>>> I'm sort of baffled by how it works at my work place. ...
>
> That's going to be a problem, because you need to understand how it
> works, if you want to be sure you have it working right. Get experience
> with DNS and DHCP first, then worry about combining them.
> On Fri, 27 Jan 2012 09:11:39 +0100, Henrik Carlqvist wrote:
>
>> Using fixed IPs is usually preferred for servers. Instead of having
>> complete /etc/hosts on every machine you could use some catalog
>> service like NIS.
>
> Or DNS, which arguably is easier (or at least more widely understood).
> If you have the DHCP server assign fixed addresses, you don't need
> dynamic updating on the DNS.
addresses. Thank you, Sylvain!
>
>> I wouldn't say that configuring NIS is trivial, but IMHO it would at
>> least be easier than configuring dynamic DNS updates from dhcpd.
>
> I wonder. I expect I'd disagree with you, but I've never done DNS
> updates from DHCP.
>
>>> I *did* put a line like this in /etc/rc.d/rc.inet1.conf in whiz
>>>
>>> DHCP_HOSTNAME[0]="whiz"
>>> ...
>>
>> That line makes the machine tell the DHCP server that it should have
>> the name whiz. The DHCP server then tells the DNS server about whiz
>> and the IP it gave whiz.
>
> ... assuming the OP's work place is indeed performing dynamic DNS
> updates, yes. Another possibility is that they simply assign static
> addressing from their DNS server, and manually update the DNS. That's
> certainly much easier to setup, even if it implies continued human
> intervention.
It may not be easier, but it seems the IT people where I work have done
>> I wouldn't say that configuring NIS is trivial, but IMHO it would at
>> least be easier than configuring dynamic DNS updates from dhcpd.
>
> I wonder. I expect I'd disagree with you, but I've never done DNS
> updates from DHCP.
>
>>> I *did* put a line like this in /etc/rc.d/rc.inet1.conf in whiz
>>>
>>> DHCP_HOSTNAME[0]="whiz"
>>> ...
>>
>> That line makes the machine tell the DHCP server that it should have
>> the name whiz. The DHCP server then tells the DNS server about whiz
>> and the IP it gave whiz.
>
> ... assuming the OP's work place is indeed performing dynamic DNS
> updates, yes. Another possibility is that they simply assign static
> addressing from their DNS server, and manually update the DNS. That's
> certainly much easier to setup, even if it implies continued human
> intervention.
it anyway. See the reply I made to Henrik. In it I describe a test
that I made. It seemed to show that the network where I work has
dynamic DNS updates.
>> ... I would say that some of the point with DHCP is lost when it
>> relies on a correct configuration on the client machines.
>
> Which part are you anticipating "relies on a correct configuration on
> the client machines"? DHCP does configure more than the IP address of
> the client, unless explicitly made not to.
rc.inet1.conf file in my Linux box to provide the hostname part of the
hostname ip address association?
>> I know that some MS Windows administrators still think that DHCP is a
>> great idea as they can use DHCP as a catalog service to provide
>> information like IP addresses to DNS servers. However, if you have
>> plans to change IP addresses of your DNS servers something is
>> seriously broken in your plan.
>
> Really? I'm not a Windows administrator, and I've never setup dynamic
> DNS updated from DHCP, but I don't see how this is, nor do I see why
> this notion would be limitted to Windows administrators.
> It isn't quite accurate to state that DHCP can "provide information
> like IP addresses to DNS servers," though. The DHCP server can be
> made to update IP address to hostname correlation on the DNS
> server(s). The IP addresses are either on your network (and resolved
> by your DNS server(s)) or they aren't.
>
> The DHCP server sends the IP address(es) of the DNS resolver(s) to the
> clients with each lease. If you're going to change the IP address(es) of
> your resolver(s), simply update the DHCP server configuration accordingly.
> Perhaps change one resolver at a time, to ensure continued service with
> existing leases, but the plan can be made to work. DHCP indeed *is*
> a good idea in a lot of (perhaps even "most"?) situations, and it can
> even simplify configuration in an environment that uses static addressing.
Joe Rosevear
Jan 28, 2012, 4:32:48 AM1/28/12
to
Lew Pitcher <lpit...@teksavvy.com> wrote:
> On Friday 27 January 2012 00:45, in alt.os.linux.slackware,
> Joe_Ro...@localhost.invalid wrote:
>
>> Question:
>>
>> vvv
>> What is a simple way in Slackware to set up the ability to
>> refer to other boxes in a DHCP-based network by hostname?
>
> Well, this requires changes to your DNS services, and potentially to your
> DHCP server as well.
>
> The DHCP server will give clients IP addresses on the network. These can be
> IP addresses pulled randomly out of a pool, or they can be pre-assigned IP
> addresses.
Thanks for explaining this. It was a helpful bit of information.
> On Friday 27 January 2012 00:45, in alt.os.linux.slackware,
> Joe_Ro...@localhost.invalid wrote:
>
>> Question:
>>
>> vvv
>> What is a simple way in Slackware to set up the ability to
>> refer to other boxes in a DHCP-based network by hostname?
>
> Well, this requires changes to your DNS services, and potentially to your
> DHCP server as well.
>
> The DHCP server will give clients IP addresses on the network. These can be
> IP addresses pulled randomly out of a pool, or they can be pre-assigned IP
> addresses.
> /If/ you are looking to map pre-assigned addresses, you can just update
> your /etc/hosts file with the known IP addresses, and your choice of
> hostname. Or, you can (if you have access to your DNS service) simply add
> those pre-assigned addresses to the appropriate subnet and name database
> files.
what you suggest here and work with my /etc/hosts files.
My thoughts parallel yours, Lew. I did think about setting up a DNS
and supplying it with information to make the association between names
and IP addresses. Perhaps I will return to that line of thought
sometime. I got more than a little confused trying to set up the DNS.
All I wanted to do with the DNS was to associate names and IP
addresses, yet the subject matter was so broad I couldn't see how to do
that one thing amid all the other things that a DNS does.
> OTOH, if you are trying to map randomly assigned IP addresses (the norm in
> DHCP systems) to hostnames, you have a bit larger problem. You will need to
> alter the configuration of /both/ your DHCP server, /and/ your DNS server
> to accomodate the name assignments.
Thanks for your help.
Henrik Carlqvist
Jan 28, 2012, 7:16:13 AM1/28/12
to
Joe Rosevear <Joe_Ro...@localhost.invalid> wrote:
>>> I don't expect to be able to do this:
>>>
>>> host <hostname>
>>
>>
> Henrik Carlqvist <Henrik.C...@deadspam.com> wrote:
>> You don't? Translating from a hostname to IP address is really basic
>> functionality.
>>> I don't expect to be able to do this:
>>>
>>> host <hostname>
>>
>>
> Henrik Carlqvist <Henrik.C...@deadspam.com> wrote:
>> You don't? Translating from a hostname to IP address is really basic
>> functionality.
> I found a solution. I suppose I am translating hostname to ip, but in a
> way that doesn't support "host <hostname>". I mentioned using
> /etc/hosts.
Whoops, you are right. I thought that the host command were using the
> way that doesn't support "host <hostname>". I mentioned using
> /etc/hosts.
different options set in /etc/nsswitch.conf, but host is only using DNS.
Sorry about the confusion.
> Some of my boxes travel between work and home.
of moving box is usually not a server that other machines in the net
depend upon.
> At home I will configure my dhcp server's dhcpd.conf to assign fixed IPs
> to them by MAC address.
range and reserve another address range for clients who configure their
own static IPs.
> The corresponding hostnames will be given in /etc/hosts files that I
> will manually keep synchronized.
those few /etc/hosts files updated than configuring a NIS server.
> I'm still learning how to configure a DHCP server.
server for these rather simple requirements. However, if you would like to
trade some of this work setting up a DHCP server against some future work
each time you move your computer between different network you have yet
another option: wicd
With wicd you can easily switch between different networks. Wicd is
included in the extra directory in the Slackware installation. With a drop
down menu you can choose between different networks and have different
settings for different networks. This way you can use dhcp at work and
static IP addresses without any dhcp server at home.
Wicd is not a good soluiton for all boxes, I would not install it on a
server as you don't get connected to the network until a user has logged
in and selected network. However, for this kind of moving boxes it might
be a good solution. Wicd works both with wired and wireless networks. Even
if you choose to use a dhcp server at home you might find wicd useful if
you sometimes also move your boxes to other networks.
> I ran a test at work. I changed the above line to
>
> DHCP_HOSTNAME[0]="spark"
> So what happens if I choose a hostname that is already in use?
Yep, that is the interesting part. Some of the advantages with a centrally
administrated network configuration using DHCP is lost when you still rely
on the clients to be correctly configured.
I haven't tried it and I really don't know what happens if a machine asks
for a DHCP_HOSTNAME that is already in use by another machine. I guess
that one of the following will happen:
1) The new machine will not get any IP-address
2) The new machine will get an IP address, but will not get any
hostname in the network.
3) The new machine will get an IP address and the wanted name, the old
machine will no longher have any hostname in the network.
Henrik Carlqvist
Jan 28, 2012, 7:38:07 AM1/28/12
to
Sylvain Robitaille <s...@alcor.concordia.ca> wrote:
>> I was referring to setting DHCP_HOSTNAME on the client.
> Oh ... I doubt that's a requirement at all, so it certainly isn't a
> strong argument that the possibility of doing so would negate the point
> of using DHCP.
No, you are right that clients does not have to give their wanted name.
>> I was referring to setting DHCP_HOSTNAME on the client.
> Oh ... I doubt that's a requirement at all, so it certainly isn't a
> strong argument that the possibility of doing so would negate the point
> of using DHCP.
But still, what is the point of dhcp in a network with static addresses?
>> but then again you will rely on some configuration on the client which
>> changes if the client changes nic.
>
> Yes, but then your configuration is in exactly one place: the DHCP
> server. (modulo configuring also the DNS namespace, but that's not a
> requirement for the client system to function on the network). That's
> the point of using DHCP at all.
on a dhcp server when you might just as well configure static addresses on
each client without having to care about MAC-addresses which might change
when some machine upgrades or replaces the NIC?
> The only option it sends back to the client systems that must refer to
> servers by IP address is the DNS resolver(s). All others it can refer
> to by name, so if you change the IP address of any other servers, as
> long as you don't change the name, the DNS will ensure the client gets
> the right address, within its own time delay if the client already has
> that address cached. If you do change the name, make sure the old name
> is still usable (via a cname, for example) until any existing leases are
> renewed.
have mechanisms to distribute packages with security updates, new software
and configuration for you clients. Why not simply use that mechanism to
roll out a new /etc/resolv.conf to your clients? Then you will most likely
get better control of how and when things happen than if you rely on some
lease time which started at some more or less random point in time.
>> But most of all, if your network is built upon DHCP and you only have a
>> single non redundant DHCP server that DHCP server is yet another (IMHO
>> unnecessary) single point of failure.
>
> Yeah. Isn't that also true if you have a single NIS server? The
> standard response to that would be "Don't Do That."
NIS slave(s) as backup for your NIS master is easier than configuring
redundant dhcp servers. My guess is also that it is a lot more common with
networks depending on a single dhcp server than networks with only a
single NIS master.
> Not quite, in the absense of any response from a DHCP server, to a
> DHCPDISCOVER, client systems can default to continuing to use their last
> known lease (probably within some timeout period, I would expect).
> Certainly that's been my own experience.
previos lease also after a reboot?
> That said, why did the UPS fail?
blackouts that last for maybe an hour your UPS will in best case help your
machines to do a clean shutdown.
Kees Theunissen
Jan 28, 2012, 1:08:20 PM1/28/12
to
Joe Rosevear wrote:
>>>> I don't expect to be able to do this:
>>>>
>>>> host<hostname>
>>>>
>>>> I understand that depends on the DNS.
>>>>
>>>> But I would like to be able to do this
>>>>
>>>> ssh<hostname> -l<username>
>>>> and
>>>> ping<hostname>
>>
>> You can't do the latter two unless the former works.
>
> Ah, but can I? Use of /etc/hosts do define the associations between ip
> addresses and hostnames does not seem to be enough to enable "host
> <hosthame>" to work. Yet, perhaps it will meet my needs.
"host" is a DNS testing utility. It won't look in /etc/hosts like the
>>>> I don't expect to be able to do this:
>>>>
>>>> host<hostname>
>>>>
>>>> I understand that depends on the DNS.
>>>>
>>>> But I would like to be able to do this
>>>>
>>>> ssh<hostname> -l<username>
>>>> and
>>>> ping<hostname>
>>
>> You can't do the latter two unless the former works.
>
> Ah, but can I? Use of /etc/hosts do define the associations between ip
> addresses and hostnames does not seem to be enough to enable "host
> <hosthame>" to work. Yet, perhaps it will meet my needs.
resolver libraries do (if configured in /etc/nsswitch.conf to do so).
The "getent" utility _does_ use the resolver libraries and can be used
to query /etc/hosts or DNS.
Try: getent hosts <hostname>
and: getent hosts <ip-number>
with private <hostname>'s and <ip-number>'s from your /etc/hosts file
and with values from the public DNS. They should all resolve.
Regards,
Kees.
--
Kees Theunissen.
Kees Theunissen
Jan 28, 2012, 1:41:12 PM1/28/12
to
number in such a case but doesn't update the DNS. (Your option 2.)
See the dhcpd.conf(5) manpage:
The client's fully-qualified domain name, derived as we have
described, is used as the name on which an "A" record will be
stored. The A record will contain the IP address that the client
was assigned in its lease. If there is already an A record with
the same name in the DNS server, no update of either the A or PTR
records will occur - this prevents a client from claiming that
its hostname is the name of some network server. For example,
if you have a fileserver called "fs.sneedville.edu", and the
client claims its hostname is "fs", no DNS update will be done
for that client, and an error message will be logged.
Joe Rosevear
Jan 28, 2012, 2:00:01 PM1/28/12
to
Henrik Carlqvist <Henrik.C...@deadspam.com> wrote:
> Joe Rosevear <Joe_Ro...@localhost.invalid> wrote:
[snip]
> Joe Rosevear <Joe_Ro...@localhost.invalid> wrote:
>> Some of my boxes travel between work and home.
>
> If so that might be a good reason to use dhcp for those boxes. This kind
> of moving box is usually not a server that other machines in the net
> depend upon.
>> At home I will configure my dhcp server's dhcpd.conf to assign fixed IPs
>> to them by MAC address.
>
> That sounds like a good plan. It is possible to use dhcp for some address
> range and reserve another address range for clients who configure their
> own static IPs.
[snip]
>> I'm still learning how to configure a DHCP server.
>
> I think that we will be able to guide you on how to configure a DHCP
> server for these rather simple requirements.
IP addresses:
http://www.yolinux.com/TUTORIALS/DHCP-Server.html
I found it by searching in Google on:
dhcpd.conf host fixed-address
I ended up using this in my dhcpd.conf:
vvv
subnet 10.0.0.0 netmask 255.255.255.0 {
range 10.0.0.10 10.0.0.100;
range 10.0.0.150 10.0.0.200;
}
host jango {
next-server jango.<domain>;
hardware ethernet <jango's MAC address>;
fixed-address 10.0.0.10;
}
host COM-109 {
next-server COM-109.<domain>;
hardware ethernet <COM-109's MAC address>;
fixed-address 10.0.0.11;
}
^^^
Perhaps I'll change it to use 10.0.0.101 and 10.0.0.102? It seems the
configuration I have expects the 10-100 range to be dynamically
assigned. Is there a problem with violating that? Or benefits to
keeping them separated?
This reveals my level of mis-understanding. I'm willing to try things
and learn.
> However, if you would like to trade some of this work setting up a
> DHCP server against some future work each time you move your computer
> between different network you have yet another option: wicd
what I'm doing.
[snip]
>> I ran a test at work. I changed the above line to
>>
>> DHCP_HOSTNAME[0]="spark"
>
>> So what happens if I choose a hostname that is already in use?
>
> Yep, that is the interesting part. Some of the advantages with a centrally
> administrated network configuration using DHCP is lost when you still rely
> on the clients to be correctly configured.
>
> I haven't tried it and I really don't know what happens if a machine asks
> for a DHCP_HOSTNAME that is already in use by another machine. I guess
> that one of the following will happen:
>
> 1) The new machine will not get any IP-address
> 2) The new machine will get an IP address, but will not get any
> hostname in the network.
> 3) The new machine will get an IP address and the wanted name, the old
> machine will no longher have any hostname in the network.
> regards Henrik
Thanks again for your help.
Kees Theunissen
Jan 28, 2012, 2:13:58 PM1/28/12
to
Henrik Carlqvist wrote:
> But still, what is the point of dhcp in a network with static addresses?
Speaking for myself:
> But still, what is the point of dhcp in a network with static addresses?
1) I strongly prefer static addresses because they are static.
With static addresses you don't need to correlate your dhcp logs with
firewall logs for instance if you're analyzing network traffic.
2) There are lots of reasons why I want or need to use dhcp, at least
for some of the devices in my network. The presence of mobile devices
like laptops is just one of those reasons.
Using dhcp with static addresses combines the benefits of both.
Kees Theunissen
Jan 28, 2012, 2:41:03 PM1/28/12
to
Joe Rosevear wrote:
> I am having some success. I found an article about how to do add fixed
> IP addresses:
>
> http://www.yolinux.com/TUTORIALS/DHCP-Server.html
>
> I found it by searching in Google on:
>
> dhcpd.conf host fixed-address
>
> I ended up using this in my dhcpd.conf:
>
> vvv
> subnet 10.0.0.0 netmask 255.255.255.0 {
> range 10.0.0.10 10.0.0.100;
> range 10.0.0.150 10.0.0.200;
> }
>
> host jango {
> next-server jango.<domain>;
> hardware ethernet<jango's MAC address>;
> fixed-address 10.0.0.10;
> }
>
> host COM-109 {
> next-server COM-109.<domain>;
> hardware ethernet<COM-109's MAC address>;
> fixed-address 10.0.0.11;
> }
> ^^^
You don't need -nor want- those "next-server" lines.
> I am having some success. I found an article about how to do add fixed
> IP addresses:
>
> http://www.yolinux.com/TUTORIALS/DHCP-Server.html
>
> I found it by searching in Google on:
>
> dhcpd.conf host fixed-address
>
> I ended up using this in my dhcpd.conf:
>
> vvv
> subnet 10.0.0.0 netmask 255.255.255.0 {
> range 10.0.0.10 10.0.0.100;
> range 10.0.0.150 10.0.0.200;
> }
>
> host jango {
> next-server jango.<domain>;
> hardware ethernet<jango's MAC address>;
> fixed-address 10.0.0.10;
> }
>
> host COM-109 {
> next-server COM-109.<domain>;
> hardware ethernet<COM-109's MAC address>;
> fixed-address 10.0.0.11;
> }
> ^^^
The next-server statement is used in bootp configurations to specify the
server from which the client should load his boot image. And in such
configurations you should also specify the boot image file.
You don't need this for a dhcp client.
Helmut Hullen
Jan 28, 2012, 4:05:00 PM1/28/12
to
Hallo, Joe,
Du meintest am 28.01.12:
> I ended up using this in my dhcpd.conf:
> vvv
> subnet 10.0.0.0 netmask 255.255.255.0 {
> range 10.0.0.10 10.0.0.100;
> range 10.0.0.150 10.0.0.200;
> }
> host jango {
> next-server jango.<domain>;
> hardware ethernet <jango's MAC address>;
> fixed-address 10.0.0.10;
> }
> host COM-109 {
> next-server COM-109.<domain>;
> hardware ethernet <COM-109's MAC address>;
> fixed-address 10.0.0.11;
> }
> ^^^
I'm not sure having understood DHCP and these quasistatic addresses. But
I suppose that these quasistatic addresses must not belong to the
"range".
The simpliest way in your example may be starting the first range at
10.0.0.20 and not at 10.0.0.10
And I suppose that "next server" has a completely other purpose. You
should delete these entries in the two host paragraphs.
Viele Gruesse
Helmut
"Ubuntu" - an African word, meaning "Slackware is too hard for me".
Du meintest am 28.01.12:
> I ended up using this in my dhcpd.conf:
> vvv
> subnet 10.0.0.0 netmask 255.255.255.0 {
> range 10.0.0.10 10.0.0.100;
> range 10.0.0.150 10.0.0.200;
> }
> host jango {
> next-server jango.<domain>;
> hardware ethernet <jango's MAC address>;
> fixed-address 10.0.0.10;
> }
> host COM-109 {
> next-server COM-109.<domain>;
> hardware ethernet <COM-109's MAC address>;
> fixed-address 10.0.0.11;
> }
> ^^^
I suppose that these quasistatic addresses must not belong to the
"range".
The simpliest way in your example may be starting the first range at
10.0.0.20 and not at 10.0.0.10
And I suppose that "next server" has a completely other purpose. You
should delete these entries in the two host paragraphs.
Viele Gruesse
Helmut
"Ubuntu" - an African word, meaning "Slackware is too hard for me".
Kees Theunissen
Jan 28, 2012, 5:33:29 PM1/28/12
to
Helmut Hullen wrote:
> Hallo, Joe,
>
> Du meintest am 28.01.12:
>
>> I ended up using this in my dhcpd.conf:
>
>> vvv
>> subnet 10.0.0.0 netmask 255.255.255.0 {
>> range 10.0.0.10 10.0.0.100;
>> range 10.0.0.150 10.0.0.200;
>> }
>
>> host jango {
>> next-server jango.<domain>;
>> hardware ethernet<jango's MAC address>;
>> fixed-address 10.0.0.10;
>> }
>
>> host COM-109 {
>> next-server COM-109.<domain>;
>> hardware ethernet<COM-109's MAC address>;
>> fixed-address 10.0.0.11;
>> }
>> ^^^
>
> I'm not sure having understood DHCP and these quasistatic addresses. But
> I suppose that these quasistatic addresses must not belong to the
> "range".
> The simpliest way in your example may be starting the first range at
> 10.0.0.20 and not at 10.0.0.10
Seems you're right.
> Hallo, Joe,
>
> Du meintest am 28.01.12:
>
>> I ended up using this in my dhcpd.conf:
>
>> vvv
>> subnet 10.0.0.0 netmask 255.255.255.0 {
>> range 10.0.0.10 10.0.0.100;
>> range 10.0.0.150 10.0.0.200;
>> }
>
>> host jango {
>> next-server jango.<domain>;
>> hardware ethernet<jango's MAC address>;
>> fixed-address 10.0.0.10;
>> }
>
>> host COM-109 {
>> next-server COM-109.<domain>;
>> hardware ethernet<COM-109's MAC address>;
>> fixed-address 10.0.0.11;
>> }
>> ^^^
>
> I'm not sure having understood DHCP and these quasistatic addresses. But
> I suppose that these quasistatic addresses must not belong to the
> "range".
> The simpliest way in your example may be starting the first range at
> 10.0.0.20 and not at 10.0.0.10
When I saw this I first thought that fixed addresses would be excluded
automatically from the dynamic range. But the dhcpd.conf(5) manpage
mentions such exclusions only for IPv6 addresses.
Some googling confirms that dynamic IPv4 ranges must not overlap
fixed IPv4 address declarations.
Henrik Carlqvist
Jan 28, 2012, 6:07:41 PM1/28/12
to
Kees Theunissen <theu...@rijnh.nl> wrote:
though it is not bullet proof. Things would still bail out if a bad client
for for the first time claimed a name which rightfully would belong to a
server booted later.
That said, nor are static addresses configured on each client bullet proof
in any way. I know what can happen when someone configures his client with
a static IP that belongs to another machine. I even know from experience
what happens if someone configures his client to have the same IP address
as the first DNS server in that network :-). No, I wasn't the one who
misconfigured that client...
> Henrik Carlqvist wrote:
>> I guess that one of the following will happen:
>> I guess that one of the following will happen:
> isc-dhcpd-4.2.1-P1 (bundled with slackware 13.37) just assigns an IP
> number in such a case but doesn't update the DNS. (Your option 2.)
> See the dhcpd.conf(5) manpage:
Thanks for clearing this out! This seems like the safest option to me even
> number in such a case but doesn't update the DNS. (Your option 2.)
> See the dhcpd.conf(5) manpage:
though it is not bullet proof. Things would still bail out if a bad client
for for the first time claimed a name which rightfully would belong to a
server booted later.
That said, nor are static addresses configured on each client bullet proof
in any way. I know what can happen when someone configures his client with
a static IP that belongs to another machine. I even know from experience
what happens if someone configures his client to have the same IP address
as the first DNS server in that network :-). No, I wasn't the one who
misconfigured that client...
Henrik Carlqvist
Jan 28, 2012, 6:17:17 PM1/28/12
to
Kees Theunissen <theu...@rijnh.nl> wrote:
> Henrik Carlqvist wrote:
>
>> But still, what is the point of dhcp in a network with static addresses?
>
> Speaking for myself:
> 1) I strongly prefer static addresses because they are static.
> With static addresses you don't need to correlate your dhcp logs with
> firewall logs for instance if you're analyzing network traffic.
Yes, I think that we both agree that static addresses are to prefer for
> Henrik Carlqvist wrote:
>
>> But still, what is the point of dhcp in a network with static addresses?
>
> Speaking for myself:
> 1) I strongly prefer static addresses because they are static.
> With static addresses you don't need to correlate your dhcp logs with
> firewall logs for instance if you're analyzing network traffic.
server functions in the network that other clients in the network depend
upon.
> 2) There are lots of reasons why I want or need to use dhcp, at least
> for some of the devices in my network. The presence of mobile devices
> like laptops is just one of those reasons.
> Using dhcp with static addresses combines the benefits of both.
your dhcp server get its address from the dhcp daemon? Does your gateway
get its address from the dhcp server?
I agree dhcp is useful for situations like pxe booting and laptops moving
between different wireless networks. However, I might be oldfasioned, but
I still prefer static addresses configured on each host in the network for
any host that others in the network depend upon in any way. This includes
not only routers, DNS servers, NFS servers and NIS servers but also even
all stationary workstations as users might ssh into them from the network.
Joe Rosevear
Jan 28, 2012, 11:14:46 PM1/28/12
to
Kees Theunissen <theu...@rijnh.nl> wrote:
> Joe Rosevear wrote:
[snip]
>> host COM-109 {
>> next-server COM-109.<domain>;
>> hardware ethernet<COM-109's MAC address>;
>> fixed-address 10.0.0.11;
>> }
>> ^^^
>
> You don't need -nor want- those "next-server" lines.
> The next-server statement is used in bootp configurations to specify the
> server from which the client should load his boot image. And in such
> configurations you should also specify the boot image file.
> You don't need this for a dhcp client.
>
>
> Regards,
>
> Kees.
Thanks!
> Joe Rosevear wrote:
[snip]
>> host COM-109 {
>> next-server COM-109.<domain>;
>> hardware ethernet<COM-109's MAC address>;
>> fixed-address 10.0.0.11;
>> }
>> ^^^
>
> You don't need -nor want- those "next-server" lines.
> The next-server statement is used in bootp configurations to specify the
> server from which the client should load his boot image. And in such
> configurations you should also specify the boot image file.
> You don't need this for a dhcp client.
>
>
> Regards,
>
> Kees.
Joe Rosevear
Jan 28, 2012, 11:17:47 PM1/28/12
to
[snip]
> I'm not sure having understood DHCP and these quasistatic addresses. But
> I suppose that these quasistatic addresses must not belong to the
> "range".
> The simpliest way in your example may be starting the first range at
> 10.0.0.20 and not at 10.0.0.10
>
> And I suppose that "next server" has a completely other purpose. You
> should delete these entries in the two host paragraphs.
>
> Viele Gruesse
> Helmut
Good advice. Thank you!
> I'm not sure having understood DHCP and these quasistatic addresses. But
> I suppose that these quasistatic addresses must not belong to the
> "range".
> The simpliest way in your example may be starting the first range at
> 10.0.0.20 and not at 10.0.0.10
>
> And I suppose that "next server" has a completely other purpose. You
> should delete these entries in the two host paragraphs.
>
> Viele Gruesse
> Helmut
Joe Rosevear
Jan 28, 2012, 11:20:44 PM1/28/12
to
Kees Theunissen <theu...@rijnh.nl> wrote:
[snip]
> "host" is a DNS testing utility. It won't look in /etc/hosts like the
> resolver libraries do (if configured in /etc/nsswitch.conf to do so).
>
> The "getent" utility _does_ use the resolver libraries and can be used
> to query /etc/hosts or DNS.
>
> Try: getent hosts <hostname>
> and: getent hosts <ip-number>
> with private <hostname>'s and <ip-number>'s from your /etc/hosts file
> and with values from the public DNS. They should all resolve.
>
>
> Regards,
>
> Kees.
Thank you, Kees. Most interesting.
[snip]
> "host" is a DNS testing utility. It won't look in /etc/hosts like the
> resolver libraries do (if configured in /etc/nsswitch.conf to do so).
>
> The "getent" utility _does_ use the resolver libraries and can be used
> to query /etc/hosts or DNS.
>
> Try: getent hosts <hostname>
> and: getent hosts <ip-number>
> with private <hostname>'s and <ip-number>'s from your /etc/hosts file
> and with values from the public DNS. They should all resolve.
>
>
> Regards,
>
> Kees.
Helmut Hullen
Jan 29, 2012, 1:56:00 AM1/29/12
to
Hallo, Henrik,
Du meintest am 29.01.12:
[...]
>> 2) There are lots of reasons why I want or need to use dhcp, at
>> least for some of the devices in my network. The presence of
>> mobile devices like laptops is just one of those reasons.
>> Using dhcp with static addresses combines the benefits of both.
> But do you really want to use dhcp for all your static addresses?
> Does your dhcp server get its address from the dhcp daemon? Does your
> gateway get its address from the dhcp server?
> I agree dhcp is useful for situations like pxe booting and laptops
> moving between different wireless networks. However, I might be
> oldfasioned, but I still prefer static addresses configured on each
> host in the network for any host that others in the network depend
> upon in any way.
"That depends!"
I've just updated a school with about 6 computer rooms and about 180
computers in these and some other rooms.
Giving each computer its individual fixed IP address (by the computer's
registry (MS) or by YAST or ...) would produce much work.
In those cases it's a great help for the administrator using the
quasistatic addresses defined by a DHCP list (ISC-DHCP or dnsmasq-DHCP).
Ok - some machines (few machines) have fixed addresses.
Du meintest am 29.01.12:
[...]
>> 2) There are lots of reasons why I want or need to use dhcp, at
>> least for some of the devices in my network. The presence of
>> mobile devices like laptops is just one of those reasons.
>> Using dhcp with static addresses combines the benefits of both.
> But do you really want to use dhcp for all your static addresses?
> Does your dhcp server get its address from the dhcp daemon? Does your
> gateway get its address from the dhcp server?
> I agree dhcp is useful for situations like pxe booting and laptops
> moving between different wireless networks. However, I might be
> oldfasioned, but I still prefer static addresses configured on each
> host in the network for any host that others in the network depend
> upon in any way.
I've just updated a school with about 6 computer rooms and about 180
computers in these and some other rooms.
Giving each computer its individual fixed IP address (by the computer's
registry (MS) or by YAST or ...) would produce much work.
In those cases it's a great help for the administrator using the
quasistatic addresses defined by a DHCP list (ISC-DHCP or dnsmasq-DHCP).
Ok - some machines (few machines) have fixed addresses.
Martin
Jan 29, 2012, 5:42:45 AM1/29/12
to
Henrik Carlqvist wrote:
> But do you really want to use dhcp for all your static addresses?
just an additional thought: i found that setting up a mixed access scenario
> But do you really want to use dhcp for all your static addresses?
to LAN or WLAN (whichever is present) using wicd-client from /etc/rc.d/rc.M
works much better if the static IP address is assigned by dhcpd rather than
/etc/rc.d/rc.inet1.conf. The result is the same.
Martin
Henrik Carlqvist
Jan 29, 2012, 7:32:56 AM1/29/12
to
Hel...@Hullen.de (Helmut Hullen) wrote:
> Hallo, Henrik,
> Du meintest am 29.01.12:
> Hallo, Henrik,
> Du meintest am 29.01.12:
>> I agree dhcp is useful for situations like pxe booting and laptops
>> moving between different wireless networks. However, I might be
>> oldfasioned, but I still prefer static addresses configured on each
>> host in the network for any host that others in the network depend
>> upon in any way.
>
> "That depends!"
Yes, it does. There are situations where dhcp is very useful and there are
>> moving between different wireless networks. However, I might be
>> oldfasioned, but I still prefer static addresses configured on each
>> host in the network for any host that others in the network depend
>> upon in any way.
>
> "That depends!"
other situations where dhcp IMHO causes more trouble than gain.
> I've just updated a school with about 6 computer rooms and about 180
> computers in these and some other rooms.
>
> Giving each computer its individual fixed IP address (by the computer's
> registry (MS) or by YAST or ...) would produce much work.
going to ssh into them and those clients will probably not even share any
CIFS disks. Client A does not care about the hostname or IP address of
client B and Client A does not even care if Client B is powered up or
shutdown. In a situation like that dhcp is very useful as you can easily
add or remove clients from the network.
Of course also a Linux PC can play the role of a desktop client that
nobody else in the network cares about, so dhcp is still useful in a
situation like that.
> Ok - some machines (few machines) have fixed addresses.
Do you configure them like I prefer to do with the addresses configured on
the server from a reserved address range not provided by the dhcp server?
Or do you configure them as Sylvain prefer, asking the dhcp server to get
their own static IP address? Why did you prefer your method of choice?
Henrik Carlqvist
Jan 29, 2012, 7:36:46 AM1/29/12
to
that you actively have to choose which network configuration to use from
wicd. With dhcp you don't have to do that.
Did you find any other difference?
Helmut Hullen
Jan 29, 2012, 8:17:00 AM1/29/12
to
Hallo, Henrik,
Du meintest am 29.01.12:
Du meintest am 29.01.12:
>> I've just updated a school with about 6 computer rooms and about 180
>> computers in these and some other rooms.
[...]
>> computers in these and some other rooms.
>> Ok - some machines (few machines) have fixed addresses.
> But those servers with fixed addresses, how do they get their
> addresses?
> Do you configure them like I prefer to do with the addresses
> configured on the server from a reserved address range not provided
> by the dhcp server?
Net 192.168.0.0
The (biggest) server has 192.168.0.1
Additional "servers" with additional functions have addresses in the
range 192.168.0.2 - 192.168.0.19
Clients for privileged users (Chief, secretary, ...) have fixed
addresses (filled in on the client) in the range 192.168.0.20 -
192.168.0.39.
The computer rooms have quasistatic addresses (defined by lists for the
DHCP server) p.e. in the range 192.168.0.40 - 192.168.0.69.
And the "free" DHCP range goes (p.e.) from 192.168.0.220 to
192.168.0.249, it's for such machines like private laptops or
smartphones.
> Or do you configure them as Sylvain prefer,
> asking the dhcp server to get their own static IP address? Why did
> you prefer your method of choice?
It makes installing a bundle of machines for a computer room much
easier, and it allows the administrator to see in which room a special
machine may be located.
And it allows such crap like blocking WAN access (more precisely:
surfing) for all machines in one room with a very simple squid ACL.
Kees Theunissen
Jan 29, 2012, 12:52:32 PM1/29/12
to
Henrik Carlqvist wrote:
> But do you really want to use dhcp for all your static addresses? Does
> your dhcp server get its address from the dhcp daemon? Does your gateway
> get its address from the dhcp server?
No of course not. There always will be some devices that need to be
> But do you really want to use dhcp for all your static addresses? Does
> your dhcp server get its address from the dhcp daemon? Does your gateway
> get its address from the dhcp server?
able to boot fast and independent of any other device after a power
outage. Think about routers, storage devices (SAN, NAS), DNS servers,
DHCP servers, the physical servers hosting your virtual systems, ...
In short: the whole vital infrastructure the rest of your network relies
upon. Those devices MUST be configured locally with static parameters,
otherwise you risk a situation where every device is waiting for some
other device when recovering from a power outage.
In practice we configure all our servers locally, and we will keep it
that way. All our laptops use DHCP but without dynamic DNS updates.
(I'm talking about the DNS as seen from the internet. The inside view
of the DNS is a different story)
Our non mobile workstations don't use DHCP, but that might change in
future.
In our setup we need to duplicate some address/hostname information
in the configs of both DNS and DHCP (duplicated work and an extra
opportunity to make errors). Dynamic updates of the DNS would be an
improvement here. But once you start using dynamic DNS updates you
can't edit the zone file anymore by hand. So with dynamic updates
you might want to bring as much devices as possible under DHCP control
-even with static address assignments- and use tools like "nsupdate"
to maintain the registration of the rest of your devices in DNS.
> I agree dhcp is useful for situations like pxe booting and laptops moving
> between different wireless networks. However, I might be oldfasioned, but
> I still prefer static addresses configured on each host in the network for
> any host that others in the network depend upon in any way. This includes
> not only routers, DNS servers, NFS servers and NIS servers but also even
> all stationary workstations as users might ssh into them from the network.
static addresses too.
This is going to be off-topic I'm afraid but I would like to mention a
very special usage case of static DHCP we have.
We are a physics lab. Our network is split in several vlans and each
vlan has its own subnet. We have subnets with public IP numbers and
subnets with private numbers. We don't run NAT so devices on the
private subnets/vlans can't communicate with the internet.
We have a firewall in front of the network and between the vlans where
needed. We have a general rule that all networked equipment -not being
a server, a workstation or a laptop- belongs in a private vlan/subnet.
A lot of test and measurement equipment is moved frequently between
different experiments or between an experiment and a technician's
working place. Our vlans are configured dynamically in order to support
moving around the equipment.
As soon as a network connection is made our switches start monitoring
the traffic. The MAC-address of the very first package will be used to
configure the ethernet port of the switch in the proper vlan.
We use DHCP with all test and measurement equipment to enforce some
initial network traffic. Without DHCP some devices would -after power
on- just start waiting for inbound traffic. And that traffic would
never come because the port on the switch would still be configured
in the default "guests" vlan - without connection to the lab.
I'm afraid that we're hijacking the OP's thread, and as I said above:
this is off-topic for this list. Sorry for that.
Henrik Carlqvist
Jan 29, 2012, 1:29:55 PM1/29/12
to
Hel...@Hullen.de (Helmut Hullen) wrote:
> As shown: "that depends!"
Yep, that was a very good answer. There are different situations when
different choices are to prefer. Thanks for sharing your experience on
this!
> As shown: "that depends!"
Yep, that was a very good answer. There are different situations when
different choices are to prefer. Thanks for sharing your experience on
this!
Henrik Carlqvist
Jan 29, 2012, 1:39:08 PM1/29/12
to
Kees Theunissen <theu...@rijnh.nl> wrote:
> But once you start using dynamic DNS updates you can't edit the zone
> file anymore by hand. So with dynamic updates you might want to bring as
> much devices as possible under DHCP control -even with static address
> assignments- and use tools like "nsupdate" to maintain the registration
> of the rest of your devices in DNS.
That was why I wrote a simple script for my NIS server to update the DNS
> But once you start using dynamic DNS updates you can't edit the zone
> file anymore by hand. So with dynamic updates you might want to bring as
> much devices as possible under DHCP control -even with static address
> assignments- and use tools like "nsupdate" to maintain the registration
> of the rest of your devices in DNS.
server using nsupdate each time the hosts nis maps are updated. All the
static IP addresses are handled by the NIS master (version controlled by
CVS) and all the dynamic addresses are handled by the dhcp server using
DHCP_HOSTNAME to update DNS.
> I'm afraid that we're hijacking the OP's thread, and as I said above:
> this is off-topic for this list. Sorry for that.
mind that we keep discussiong the pros and cons of dynamic and static
addressws with or without dhcp.
Loki Harfagr
Jan 29, 2012, 2:06:52 PM1/29/12
to
Sun, 29 Jan 2012 19:39:08 +0100, Henrik Carlqvist did cat :
>> I'm afraid that we're hijacking the OP's thread, and as I said above:
>> this is off-topic for this list. Sorry for that.
>
> I think that the OP got his questions answered and hope that he doesn't
> mind that we keep discussiong the pros and cons of dynamic and static
> addressws with or without dhcp.
>
> regards Henrik
ya-ya and walking this way may lead to the sudden attack of the
60 foot oneliner surfer from hell creeping terror from outer space.
(and if that was not enough it'll subsequently fire up another
stooge buggering post from the DanCer again (it may stop
when he'll have overcome his coming out though ;D)
--
no .sigfile no cry
>> I'm afraid that we're hijacking the OP's thread, and as I said above:
>> this is off-topic for this list. Sorry for that.
>
> I think that the OP got his questions answered and hope that he doesn't
> mind that we keep discussiong the pros and cons of dynamic and static
> addressws with or without dhcp.
>
> regards Henrik
60 foot oneliner surfer from hell creeping terror from outer space.
(and if that was not enough it'll subsequently fire up another
stooge buggering post from the DanCer again (it may stop
when he'll have overcome his coming out though ;D)
--
no .sigfile no cry
Joe Rosevear
Jan 29, 2012, 6:51:56 PM1/29/12
to
> I'm afraid that we're hijacking the OP's thread, and as I said above:
> this is off-topic for this list. Sorry for that.
Go for it!
> this is off-topic for this list. Sorry for that.
As another poster has suggested, I am in fact done here. Done but not
gone, as I am following the interesting discussion.
Thanks again for the help!
> Regards,
>
> Kees.
Sylvain Robitaille
Jan 30, 2012, 2:08:03 AM1/30/12
to
On Sat, 28 Jan 2012 13:38:07 +0100, Henrik Carlqvist wrote:
> ... what is the point of dhcp in a network with static addresses?
Scale up the picture you appear to have, to a network where you don't
manage (or own) all of the computers being connected to it. Not all are
"plain clients", though most probably are, but there are plenty of
situations where even plain clients can have fixed addresses (they're
plain, but not mobile, for example, so will always be connected to the
same network segment). The systems might come and go frequently, and
they might undergo various OS upgrades over time. Using DHCP permits
the network admin(s) to configure an address for each system once, and
the individual system admins need not repeatedly request assistance with
that aspect when they do upgrade or reconfigure, etc.
> But what is the point of maintiaining a list of IP- and MAC-address
> pairs on a dhcp server when you might just as well configure static
> addresses on each client ...
See above. "you" might not be controlling all the client systems. DHCP
permits you to maintain control of their network configurations (and as
mentioned already in an earlier post), to push changes to that
configuration without needing to otherwise have any control over those
clients).
> ... without having to care about MAC-addresses which might change when
That's relatively minor, as it's quite infrequent.
> .... You most likely already have mechanisms to distribute packages
client systems.
> Yes, it is true also for NIS servers. However I would say that
> configuring NIS slave(s) as backup for your NIS master is easier than
> configuring redundant dhcp servers.
I can't say. My experience with NIS is minimal ("functional
experience", but not setting it up), although I *have* successfully run
a fail-over pair of DHCP servers.
> My guess is also that it is a lot more common with networks depending
> on a single dhcp server than networks with only a single NIS master.
"Don't Do That". Just because it's common doesn't mean it's the way it
should be done.
> Ok, fortunately I have no experience from this. Do they remember their
> previos lease also after a reboot?
Cached in a temporary file, if my own memory doesn't fail me.
> A UPS is great to protect against spikes and brownouts. However, at
> blackouts that last for maybe an hour your UPS will in best case help
> your machines to do a clean shutdown.
Scale up ... If power fails in my home network, and I have a dependancy
on sequence for my personal computers to come up, I'll just make sure to
boot them in that order, and reboot any that came up before their time.
On a network that small, I didn't even bother with DHCP until I started
having multiple mobile devices, plus some fancy new "appliances" that
can be networked too.
If power fails at work, a generator kicks in.
--
----------------------------------------------------------------------
Sylvain Robitaille s...@encs.concordia.ca
Systems analyst / AITS Concordia University
Faculty of Engineering and Computer Science Montreal, Quebec, Canada
----------------------------------------------------------------------
> ... what is the point of dhcp in a network with static addresses?
Scale up the picture you appear to have, to a network where you don't
manage (or own) all of the computers being connected to it. Not all are
"plain clients", though most probably are, but there are plenty of
situations where even plain clients can have fixed addresses (they're
plain, but not mobile, for example, so will always be connected to the
same network segment). The systems might come and go frequently, and
they might undergo various OS upgrades over time. Using DHCP permits
the network admin(s) to configure an address for each system once, and
the individual system admins need not repeatedly request assistance with
that aspect when they do upgrade or reconfigure, etc.
> But what is the point of maintiaining a list of IP- and MAC-address
> pairs on a dhcp server when you might just as well configure static
See above. "you" might not be controlling all the client systems. DHCP
permits you to maintain control of their network configurations (and as
mentioned already in an earlier post), to push changes to that
configuration without needing to otherwise have any control over those
clients).
> ... without having to care about MAC-addresses which might change when
> some machine upgrades or replaces the NIC?
Yes, changing NICs adds a step to updating the DHCP configuration.
That's relatively minor, as it's quite infrequent.
> .... You most likely already have mechanisms to distribute packages
> with security updates, new software and configuration for you clients.
> Why not simply use that mechanism to roll out a new /etc/resolv.conf
> to your clients?
In my world, you don't have control over all (or even most) of the
> Why not simply use that mechanism to roll out a new /etc/resolv.conf
> to your clients?
client systems.
> Yes, it is true also for NIS servers. However I would say that
> configuring NIS slave(s) as backup for your NIS master is easier than
> configuring redundant dhcp servers.
experience", but not setting it up), although I *have* successfully run
a fail-over pair of DHCP servers.
> My guess is also that it is a lot more common with networks depending
> on a single dhcp server than networks with only a single NIS master.
should be done.
> Ok, fortunately I have no experience from this. Do they remember their
> previos lease also after a reboot?
> A UPS is great to protect against spikes and brownouts. However, at
> blackouts that last for maybe an hour your UPS will in best case help
> your machines to do a clean shutdown.
on sequence for my personal computers to come up, I'll just make sure to
boot them in that order, and reboot any that came up before their time.
On a network that small, I didn't even bother with DHCP until I started
having multiple mobile devices, plus some fancy new "appliances" that
can be networked too.
If power fails at work, a generator kicks in.
--
----------------------------------------------------------------------
Sylvain Robitaille s...@encs.concordia.ca
Systems analyst / AITS Concordia University
Faculty of Engineering and Computer Science Montreal, Quebec, Canada
----------------------------------------------------------------------
Sylvain Robitaille
Jan 30, 2012, 2:10:45 AM1/30/12
to
On 28 Jan 2012 09:19:39 GMT, Joe Rosevear wrote:
>>>> I don't expect to be able to do this:
>>>>
>>>> host <hostname>
>>>>
>>>> I understand that depends on the DNS.
>>>>
>>>> But I would like to be able to do this
>>>>
>>>> ssh <hostname> -l <username>
>>>> and
>>>> ping <hostname>
>>
>> You can't do the latter two unless the former works.
>
> Ah, but can I? Use of /etc/hosts do define the associations between ip
> addresses and hostnames does not seem to be enough to enable "host
> <hosthame>" to work. Yet, perhaps it will meet my needs.
My fault here ... I overlooked that the "host" command does not check
>>>> I don't expect to be able to do this:
>>>>
>>>> host <hostname>
>>>>
>>>> I understand that depends on the DNS.
>>>>
>>>> But I would like to be able to do this
>>>>
>>>> ssh <hostname> -l <username>
>>>> and
>>>> ping <hostname>
>>
>> You can't do the latter two unless the former works.
>
> Ah, but can I? Use of /etc/hosts do define the associations between ip
> addresses and hostnames does not seem to be enough to enable "host
> <hosthame>" to work. Yet, perhaps it will meet my needs.
the /etc/hosts file.
Sylvain Robitaille
Jan 30, 2012, 2:18:15 AM1/30/12
to
On Sun, 29 Jan 2012 13:32:56 +0100, Henrik Carlqvist wrote:
> But those servers with fixed addresses, how do they get their
> addresses?
>
> Do you configure them like I prefer to do with the addresses
> configured on the server from a reserved address range not provided by
> the dhcp server? Or do you configure them as Sylvain prefer, asking
> the dhcp server to get their own static IP address? ...
> But those servers with fixed addresses, how do they get their
> addresses?
>
> Do you configure them like I prefer to do with the addresses
> configured on the server from a reserved address range not provided by
> the dhcp server? Or do you configure them as Sylvain prefer, asking
Obviously you need some infrastructure systems (conceptually a "few",
but the exact number will depend on individual installations) with
locally assigned fixed addresses. Beyond that, even with "server" type
systems that have fixed addresses, there can be benefits to using DHCP.
These won't be seen in all situations, of course, but that doesn't mean
they don't exist. The smaller and simpler the network, the less likely
it'll benefit from DHCP.
Lew Pitcher
Jan 30, 2012, 12:33:35 PM1/30/12
to
On Monday 30 January 2012 02:08, in alt.os.linux.slackware,
an "IP address assignment" service.
DHCP can supply the initial OS to a client, thus permitting workstations to
have little or no hard-disk. DHCP can provide the address of the default
route, the address of the DNS server, the network name, and other network
configuration information so that your neighbour system can be on a
different network or have a different environment than you have.
So, "what is the point of dhcp in a network with static addresses"?
Well, I can have my 10.0.1.1 server boot the exact same Ubuntu install off
the network as my 10.0.1.2 server does. I can have my 10.1.0.0/16 network
isolated from the rest of my systems, so that strange wifi devices can
connect without compromising security. I can offer my 10.0.1.3 router a
different route than my 10.0.1.1 machine gets. And, I can centralize the
controls on all this so that I don't have to travel to access each machine
to do so.
--
Lew Pitcher
s...@alcor.concordia.ca wrote:
> On Sat, 28 Jan 2012 13:38:07 +0100, Henrik Carlqvist wrote:
>
>> ... what is the point of dhcp in a network with static addresses?
>
> Scale up the picture you appear to have, to a network where you don't
> manage (or own) all of the computers being connected to it. Not all are
> "plain clients", though most probably are, but there are plenty of
> situations where even plain clients can have fixed addresses (they're
> plain, but not mobile, for example, so will always be connected to the
> same network segment). The systems might come and go frequently, and
> they might undergo various OS upgrades over time. Using DHCP permits
> the network admin(s) to configure an address for each system once, and
> the individual system admins need not repeatedly request assistance with
> that aspect when they do upgrade or reconfigure, etc.
Also remember that DHCP, like BOOTP before it, provides more than just
> On Sat, 28 Jan 2012 13:38:07 +0100, Henrik Carlqvist wrote:
>
>> ... what is the point of dhcp in a network with static addresses?
>
> Scale up the picture you appear to have, to a network where you don't
> manage (or own) all of the computers being connected to it. Not all are
> "plain clients", though most probably are, but there are plenty of
> situations where even plain clients can have fixed addresses (they're
> plain, but not mobile, for example, so will always be connected to the
> same network segment). The systems might come and go frequently, and
> they might undergo various OS upgrades over time. Using DHCP permits
> the network admin(s) to configure an address for each system once, and
> the individual system admins need not repeatedly request assistance with
> that aspect when they do upgrade or reconfigure, etc.
an "IP address assignment" service.
DHCP can supply the initial OS to a client, thus permitting workstations to
have little or no hard-disk. DHCP can provide the address of the default
route, the address of the DNS server, the network name, and other network
configuration information so that your neighbour system can be on a
different network or have a different environment than you have.
So, "what is the point of dhcp in a network with static addresses"?
Well, I can have my 10.0.1.1 server boot the exact same Ubuntu install off
the network as my 10.0.1.2 server does. I can have my 10.1.0.0/16 network
isolated from the rest of my systems, so that strange wifi devices can
connect without compromising security. I can offer my 10.0.1.3 router a
different route than my 10.0.1.1 machine gets. And, I can centralize the
controls on all this so that I don't have to travel to access each machine
to do so.
--
Lew Pitcher
Martin
Jan 30, 2012, 1:45:34 PM1/30/12
to
Henrik Carlqvist wrote:
> Martin <n...@spam.invalid> wrote:
>
>> Henrik Carlqvist wrote:
>>
>>> But do you really want to use dhcp for all your static addresses?
>>
>> just an additional thought: i found that setting up a mixed access
>> scenario to LAN or WLAN (whichever is present) using wicd-client from
>> /etc/rc.d/rc.M works much better if the static IP address is assigned by
>> dhcpd rather than /etc/rc.d/rc.inet1.conf. The result is the same.
>
> To me the only known drawback of having the fixed address set by wicd is
> that you actively have to choose which network configuration to use from
> wicd. With dhcp you don't have to do that.
>
> Did you find any other difference?
>
> regards Henrik
As far as a wicd-based solution is concerned I would agree that you named
> Martin <n...@spam.invalid> wrote:
>
>> Henrik Carlqvist wrote:
>>
>>> But do you really want to use dhcp for all your static addresses?
>>
>> just an additional thought: i found that setting up a mixed access
>> scenario to LAN or WLAN (whichever is present) using wicd-client from
>> /etc/rc.d/rc.M works much better if the static IP address is assigned by
>> dhcpd rather than /etc/rc.d/rc.inet1.conf. The result is the same.
>
> To me the only known drawback of having the fixed address set by wicd is
> that you actively have to choose which network configuration to use from
> wicd. With dhcp you don't have to do that.
>
> Did you find any other difference?
>
> regards Henrik
the one big difference. The consequence of using wicd only is profound,
though: The user is required to select the appropriate configuration, and
can only do so once the machine is up and he is logged in.
The dhcp-based solution works automagically once booted in run level 3.
There is nothing to do for non-technical users (like wifes).
Initially I tried a rc.inet1.conf-based solution, but that one requires
modifications and the occasional call of a script. It is totally unsuitable
for non-technical users.
Martin
Henrik Carlqvist
Jan 30, 2012, 4:58:32 PM1/30/12
to
Sylvain Robitaille <s...@alcor.concordia.ca> wrote:
> On Sat, 28 Jan 2012 13:38:07 +0100, Henrik Carlqvist wrote:
>> ... what is the point of dhcp in a network with static addresses?
> Scale up the picture you appear to have, to a network where you don't
> manage (or own) all of the computers being connected to it.
It might be a little ironic that I at work admin computers at 3 different
> On Sat, 28 Jan 2012 13:38:07 +0100, Henrik Carlqvist wrote:
>> ... what is the point of dhcp in a network with static addresses?
> Scale up the picture you appear to have, to a network where you don't
> manage (or own) all of the computers being connected to it.
subnets. At two of those subnets all my machines have locally static
configured addresses even though I am only responsible for and in control
of a minor part of the machines.
At the third subnet I do manage all the machines, that is where some
machines use dhcp.
> The systems might come and go frequently, and they might undergo various
> OS upgrades over time. Using DHCP permits the network admin(s) to
> configure an address for each system once, and the individual system
> admins need not repeatedly request assistance with that aspect when they
> do upgrade or reconfigure, etc.
really prefer to have a pool of hostnames with ip-adresses to use for
local configurations of my machines.
If a machine that previously has been running Windows shall be upgraded to
Linux we want to give it another hostname indicating that it is running
Linux instead of Windows. Having a handful of unused hostnames together
with ip-adresses to pick from really makes life a lot easier for me.
> Yes, changing NICs adds a step to updating the DHCP configuration.
> That's relatively minor, as it's quite infrequent.
However, in my experience, when someone wants a new machine to be
configured they want it up and running _now_, or even better some hours
ago... Also in my unfortunate experience when adding a request to our
helpdesk I know that the time until my request has been fulfilled might
take anything between half an hour and half a year no matter how simple it
is. Yep, that is the drawback of working in a big organisation. Things
does not allways move that fast... The more you are able to do all by
yourself the better.
> In my world, you don't have control over all (or even most) of the
> client systems.
organisations that might not differ so much, but we have different roles
in those organisations. You seem to be the man responsible for the network
and the dhcp server. I am the man responsible for only a few of the
servers and workstations.
> If power fails at work, a generator kicks in.
bullet proof. Capacitors on motherboards will start leaking, CPU-fans will
stop running and PSUs will stop working. That is when redundant servers
really comes in.
Sylvain Robitaille
Jan 31, 2012, 1:03:30 AM1/31/12
to
On Mon, 30 Jan 2012 22:58:32 +0100, Henrik Carlqvist wrote:
> ... You seem to be the man responsible for the network and the dhcp
> server. ...
Not where I am now, though I've been there (in a group responsible for
the network).
> ... You seem to be the man responsible for the network and the dhcp
> server. ...
Not where I am now, though I've been there (in a group responsible for
the network).
Helmut Hullen
Jan 31, 2012, 2:46:00 AM1/31/12
to
Hallo, Henrik,
Du meintest am 30.01.12:
> If a machine that previously has been running Windows shall be
> upgraded to Linux we want to give it another hostname indicating that
> it is running Linux instead of Windows. Having a handful of unused
> hostnames together with ip-adresses to pick from really makes life a
> lot easier for me.
Under "dnsmasq" it's only a simple change in the "dhcp-host=..." entry
...
And under ISC-DHCP it's a similar simple change. You can do it all on
the server, you don't need to touch any client.
One of my next jobs in a school is to move 2 rooms from net 192.168.0.0
to 192.168.1.0 - it also requests only a very simple "search and
replace" in the server's configuration file.
And perhaps (we'll try) an "ipconfig /renew" on the (windows) clients -
windows seems to store the DHCP addresses somewhere in its registry.
Crap.
Du meintest am 30.01.12:
> If a machine that previously has been running Windows shall be
> upgraded to Linux we want to give it another hostname indicating that
> it is running Linux instead of Windows. Having a handful of unused
> hostnames together with ip-adresses to pick from really makes life a
> lot easier for me.
...
And under ISC-DHCP it's a similar simple change. You can do it all on
the server, you don't need to touch any client.
One of my next jobs in a school is to move 2 rooms from net 192.168.0.0
to 192.168.1.0 - it also requests only a very simple "search and
replace" in the server's configuration file.
And perhaps (we'll try) an "ipconfig /renew" on the (windows) clients -
windows seems to store the DHCP addresses somewhere in its registry.
Crap.
Eef Hartman
Jan 31, 2012, 4:25:05 AM1/31/12
to
Sylvain Robitaille <s...@alcor.concordia.ca> wrote:
> You can't do the latter two unless the former works. The first thing
> your system will do when you type "ssh <hostname>" is exactly equivalent
> to "host <hostname>", because that's how your system knows which other
> system you want to ssh to.
Not quite: if you setup dhcp to give out always the SAME IP-addresses
(based on MAC-address, which used to be called bootp protocol) you can
use the local /etc/hosts file to handle name-to-ip conversions (but
NOT the other way).
The command "host" will then NOT work as it's fully DNS oriented, but
"ssh hostname" will, if /etc/nsswitch.conf contains the line
hosts: files
(optional with "dns" behind it, but files MUST be first).
--
******************************************************************
** Eef Hartman, Delft University of Technology, dept. SSC/ICT **
** e-mail: E.J.M....@tudelft.nl - phone: +31-15-27 82525 **
******************************************************************
> You can't do the latter two unless the former works. The first thing
> your system will do when you type "ssh <hostname>" is exactly equivalent
> to "host <hostname>", because that's how your system knows which other
> system you want to ssh to.
Not quite: if you setup dhcp to give out always the SAME IP-addresses
(based on MAC-address, which used to be called bootp protocol) you can
use the local /etc/hosts file to handle name-to-ip conversions (but
NOT the other way).
The command "host" will then NOT work as it's fully DNS oriented, but
"ssh hostname" will, if /etc/nsswitch.conf contains the line
hosts: files
(optional with "dns" behind it, but files MUST be first).
--
******************************************************************
** Eef Hartman, Delft University of Technology, dept. SSC/ICT **
** e-mail: E.J.M....@tudelft.nl - phone: +31-15-27 82525 **
******************************************************************
Sylvain Robitaille
Jan 31, 2012, 10:19:55 AM1/31/12
to
On Tue, 31 Jan 2012 10:25:05 +0100, Eef Hartman wrote:
> ...
> The command "host" will then NOT work as it's fully DNS oriented, ...
Yes. Acknowledged in
Message-ID: <slrnjicgj...@charlotte.encs.concordia.ca>
> ...
> The command "host" will then NOT work as it's fully DNS oriented, ...
Yes. Acknowledged in
Message-ID: <slrnjicgj...@charlotte.encs.concordia.ca>
Henrik Carlqvist
Jan 31, 2012, 2:54:50 PM1/31/12
to
Hel...@Hullen.de (Helmut Hullen) wrote:
>> Having a handful of unused hostnames together with ip-adresses to pick
>> from really makes life a lot easier for me.
>
> Under "dnsmasq" it's only a simple change in the "dhcp-host=..." entry
> ...
> And under ISC-DHCP it's a similar simple change. You can do it all on
> the server, you don't need to touch any client.
Yes, it is simple if you have root access to the dhcp server. But if you,
>> Having a handful of unused hostnames together with ip-adresses to pick
>> from really makes life a lot easier for me.
>
> Under "dnsmasq" it's only a simple change in the "dhcp-host=..." entry
> ...
> And under ISC-DHCP it's a similar simple change. You can do it all on
> the server, you don't need to touch any client.
like me on some subnets do not have access to the dhcp server you might
also prefer to use static addresses locally configured on the hosts you
manage?
Fritz Wuehler
Feb 5, 2012, 3:56:14 AM2/5/12
to
> What is a simple way in Slackware to set up the ability to
> refer to other boxes in a DHCP-based network by hostname?
/etc/hosts
>
> I don't expect to be able to do this:
>
> host <hostname>
In my tests it doesn't work meaning it doesn't go to /etc/hosts first. If it
did it would work but alas it goes outside first.
>
> I understand that depends on the DNS.
>
> But I would like to be able to do this
>
> ssh <hostname> -l <username>
>
> and
>
> ping <hostname>
Absolutely.
/etc/hosts
192.168.0.10 fileserver myfileserver.myimaginarydomain.com
192.168.0.11 webserver mywebserver.myimaginarydomain.com
192.168.0.12 devlinux devserver.myimaginarydomain.com
ssh user@devlinux
or
http://mywebserver.myimaginarydomain.com
will both work
> I was able to accomplish the above by using a service provided by
> no-ip.com, but that seems like a lame thing to do. I'm considering
> using fixed ip-addresses instead and depending on my /etc/hosts files
> (will that work?), but that isn't my first wish.
That (/etc/hosts) is the easiest, best way to do this on your own
network. Otherwise you will have to run dhcp servers and/or use dynamic ip
for everything. If your router supports it all you have to do is use the mac
of the machine to give it a fixed IP on your network.
> DHCP_HOSTNAME[0]="whiz"
That may only work if you have a DHCP server, which is not necessary for
most small networks that are not serving clients outside the local
network. It will only get you so far, because nobody outside your LAN could
ever resolve your host name just based on that.
> Any help with the question (at the beginning) and the subsequent
> confusion would be appreciated!
There ya go!
> refer to other boxes in a DHCP-based network by hostname?
/etc/hosts
>
> I don't expect to be able to do this:
>
> host <hostname>
did it would work but alas it goes outside first.
>
> I understand that depends on the DNS.
>
> But I would like to be able to do this
>
> ssh <hostname> -l <username>
>
> and
>
> ping <hostname>
/etc/hosts
192.168.0.10 fileserver myfileserver.myimaginarydomain.com
192.168.0.11 webserver mywebserver.myimaginarydomain.com
192.168.0.12 devlinux devserver.myimaginarydomain.com
ssh user@devlinux
or
http://mywebserver.myimaginarydomain.com
will both work
> I was able to accomplish the above by using a service provided by
> no-ip.com, but that seems like a lame thing to do. I'm considering
> using fixed ip-addresses instead and depending on my /etc/hosts files
> (will that work?), but that isn't my first wish.
That (/etc/hosts) is the easiest, best way to do this on your own
network. Otherwise you will have to run dhcp servers and/or use dynamic ip
for everything. If your router supports it all you have to do is use the mac
of the machine to give it a fixed IP on your network.
> DHCP_HOSTNAME[0]="whiz"
That may only work if you have a DHCP server, which is not necessary for
most small networks that are not serving clients outside the local
network. It will only get you so far, because nobody outside your LAN could
ever resolve your host name just based on that.
> Any help with the question (at the beginning) and the subsequent
> confusion would be appreciated!
There ya go!
Ralph Spitzner
Feb 5, 2012, 7:13:43 AM2/5/12
to
Fritz Wuehler wrote:
>> What is a simple way in Slackware to set up the ability to
>> refer to other boxes in a DHCP-based network by hostname?
>
> /etc/hosts
bash-4.1# cat /etc/host.conf
>> What is a simple way in Slackware to set up the ability to
>> refer to other boxes in a DHCP-based network by hostname?
>
> /etc/hosts
order hosts, bind
multi on
This is where you lay down tha way things are supposed
to work.
-rasp
--
RTMPDump & ffmpeg are your friends..
-icke
Eef Hartman
Feb 6, 2012, 4:07:01 AM2/6/12
to
Fritz Wuehler <fr...@spamexpire-201202.rodent.frell.theremailer.net> wrote:
> In my tests it doesn't work meaning it doesn't go to /etc/hosts first. If it
> did it would work but alas it goes outside first.
Actually the "host", "dig" and "nslookup" commands are DNS _only_
> In my tests it doesn't work meaning it doesn't go to /etc/hosts first. If it
> did it would work but alas it goes outside first.
(they belong to the "bind" package), so they never will use /etc/hosts
at all!
Fritz Wuehler
Feb 6, 2012, 6:07:53 AM2/6/12
to
> Actually the "host", "dig" and "nslookup" commands are DNS _only_
> (they belong to the "bind" package), so they never will use /etc/hosts
> at all!
Ah snap! Thanks Eef. I did not know that.
> (they belong to the "bind" package), so they never will use /etc/hosts
> at all!
Joe Rosevear
Feb 10, 2012, 2:15:40 AM2/10/12
to
Fritz Wuehler <fr...@spamexpire-201202.rodent.frell.theremailer.net> wrote:
>> What is a simple way in Slackware to set up the ability to
>> refer to other boxes in a DHCP-based network by hostname?
>
> /etc/hosts
Great! That was my conclusion also.
>> What is a simple way in Slackware to set up the ability to
>> refer to other boxes in a DHCP-based network by hostname?
>
> /etc/hosts
>
>>
>> I don't expect to be able to do this:
>>
>> host <hostname>
>
> In my tests it doesn't work meaning it doesn't go to /etc/hosts first. If it
> did it would work but alas it goes outside first.
>
>>
>> I understand that depends on the DNS.
>>
>> But I would like to be able to do this
>>
>> ssh <hostname> -l <username>
>>
>> and
>>
>> ping <hostname>
>
> Absolutely.
>
> /etc/hosts
>
> 192.168.0.10 fileserver myfileserver.myimaginarydomain.com
> 192.168.0.11 webserver mywebserver.myimaginarydomain.com
> 192.168.0.12 devlinux devserver.myimaginarydomain.com
>
> ssh user@devlinux
ssh devlinux -l user
>
> or
>
> http://mywebserver.myimaginarydomain.com
>
> will both work
>
>> I was able to accomplish the above by using a service provided by
>> no-ip.com, but that seems like a lame thing to do. I'm considering
>> using fixed ip-addresses instead and depending on my /etc/hosts files
>> (will that work?), but that isn't my first wish.
>
> That (/etc/hosts) is the easiest, best way to do this on your own
> network. Otherwise you will have to run dhcp servers and/or use dynamic ip
> for everything. If your router supports it all you have to do is use the mac
> of the machine to give it a fixed IP on your network.
>
>
>> DHCP_HOSTNAME[0]="whiz"
>
> That may only work if you have a DHCP server, which is not necessary for
> most small networks that are not serving clients outside the local
> network. It will only get you so far, because nobody outside your LAN could
> ever resolve your host name just based on that.
above (DHCP_HOSTNAME[0]="whiz"), but that's OK. It does a good job of
providing an IP address for guest (my son and my wife) boxes in my
network.
>
>> Any help with the question (at the beginning) and the subsequent
>> confusion would be appreciated!
>
> There ya go!
0 new messages