Hello,
I have some servers in DMZ, wtih one interface for management (eth1), and one for the applications (eth0).
I can only access to the management interface, but the default route is on eth0, so the node[‘ipaddress’] points to eth0.
How could I modify the ipaddress, or use another workaround to use " knife ssh ‘name:dmzserver’ … " ?
you can specify the attribute that knife should get the ip address from with -a, so knife ssh 'name:dmzserver' -a network.interfaces.eth1.addresses.first should work for you
Swap eth0 and eth1 ? For most systems, this is pretty easy to do by either swapping the cables and reconfiguring the host’s network addresses, or by editing manually the network configuration tools on the server.
There are other approaches, including split DNS so that from the chef control environment you’re using, DNS resolves to the relevant system hostnames and not relying on IP based access.
Or: set up split DNS for the management server, so that all nodes have an internal IP address seen from your designated chef management server, the one you use to run these commands from for internal access.
Thank you for your replies.
First, I have to explain more about these nodes.
They are redhat virtual servers on vmware.
I can’t modify the network parameters, eth0 is the default route and eth1 is my management interface.
The node has an official hostname and an alias for the management interface.
For my example I called “servername” the official hostname, IP 10.2.2.2 configured on eth0, the default route.
The management hostname “management-hostname”, IP 10.5.5.5.5 on eth1
I found a first caveat :
after the bootstrap the node had an empty FQDN:
chefserver$>knife node show management-hostname
Node Name: management-hostname
Environment: _default
FQDN:
IP: 10.2.2.2
Run List:
Roles:
Recipes:
Platform: redhat 7.3
Bootstrap with -VV returned me:
DEBUG: Plugin Hostname: ran 'hostname --fqdn' and returned 1
DEBUG: Plugin Hostname: hostname --fqdn returned an empty string twice and will not be set.
indeed, logged on the server I had :
servername#>hostname --fqdn
hostname: Name or service not known
I fixed this problem modifying a line in /etc/nsswitch.conf :
hosts: files dns myhostname
And now it’s ok ;
#>hostname --fqdn
servername.xx.yy.zzz
After a new bootstrap I have my attributes set :
chefserver$>knife node show management-hostname
Node Name: management-hostname
Environment: _default
FQDN: servername.xx.yy.zzz
IP: 10.2.2.2
Run List:
Roles:
Recipes:
Platform: redhat 7.3
Tags:
However…
chefserver$>knife -VV ssh "name:management-hostname" -a network.interfaces.eth1.addresses.first
[... All seems Ok ...]
DEBUG: Chef::HTTP calling Chef::HTTP::JSONInput#handle_response
DEBUG: Decompressing gzip response
DEBUG: Chef::HTTP calling Chef::HTTP::CookieManager#handle_response
DEBUG: Chef::HTTP calling Chef::HTTP::JSONOutput#handle_response
DEBUG: Using node attribute network.interfaces.eth1.addresses.first:
FATAL: 1 node found, but does not have the required attribute to establish the connection. Try setting another attribute to open the connection using --attribute.
Extracts from knife node show -l management-hostname :
network:
default_gateway: 10.2.2.1
default_interface: eth0
interfaces:
eth0:
addresses:
00:50:02:02:02:02:
family: lladdr
10.2.2.2:
[...]
eth1:
addresses:
00:50:56:55:55:55:
family: lladdr
10.5.5.5:
[...]
routes:
destination: my_chefserver_IP/24
family: inet
via: 10.5.5.5
[...]
state: up
transceiver: internal
type: eth
Sorry for my long post, but I’m stuck here.
Is it possible to force the FQDN and the IP attributes without changing the server configuration ?
Or another way ?
For information and to avoid wrong tracks, ssh configuration works well :
chefserver$>ssh management-hostname "chef-client -v"
Chef: 13.2.20The system hostname for a Red Hat based server is set in the scripts in /etc/sysconfig/network-scripts/, and by the NetworkManager tools if those are installed. NetworkManager is NOT YOUR FRIEND for servers, it provides a stack of tools more suitable to laptops and wireless networks with VPN setups. If possible, simply remove all the NetworkManager rpm’s on such a server.
That said: The “HOSTNAME” is set in /etc/sysconfig/network-scripts, and set from there at boot time. If the hostname starts out as “localhost.localdomain”, DHCP is then asked to set the hostname. If that doesn’t work, /etc/hosts is checked, and then DNS. So if you want a stable hostname, and you’d like it to be tied to the back end connection name, you need to set the hostname to point to whatever DNS or your other systems think the backend connection is in /etc/sysconfig/network, and set it in /etc/hosts or in DNS to resolve a valid IP address with that hostname.
Now, me? I use this cookbook: https://github.com/nkadel-skyhook/nkadel-chef-hosts . It’s very simple, it can be preprogrammed with arbitrary internal values based on a role, it sets up the entire /etc/hosts, and doesn’t rely on the line-by-line addition common to the “hostsfile” cookbook.
If what you need is for your local system to connect to the back end network port, well, you’ve a choice this way. Set the FQDN of the host to be the back end connection, or play with the DNS or /etc/hosts in your box that you connect from to automatically connect to the back end address. That’s what split DNS would be for, to present the back end addresses to hosts that are on the back end and use DNS there.
Thanks for the help, I finaly found something that works ;
temporarily set the hostname to the administrative name :
servername#>hostname management-hostname
bootstrap
chefserver$>knife bootstrap management-hostname [...]
set the real hostname back :
servername#>hostname servername
Now we can see that the ip is the real server’s ip , and the fqdn is our management’s hostname.
chefserver$>knife node show management-hostname
Node Name: management-hostname
Environment: _default
FQDN: management-hostname.xx.yy.zzz
IP: 10.2.2.2
And now I can run recipes. I hope it will not raise antother problems in the future. What do you think ?