funcptr - Linux

Cobbler with CentOS 7 failure to boot/kickstart

2015-07-08T19:54:43+00:00

Over the past week I've been working on building out an instance of Cobbler and testing some of the provisioning that it is able to do. One of the operating systems that I wanted to deploy is CentOS 7.</p>

After I imported the system into cobbler, it correctly showed up in the pxelinux boot menu and it would happily load the kernel and the initrd, however after initial bootup it would throw the following error message:</p>

dracut-initqueue[867]: Warning: Could not boot.</span></span>
dracut-initqueue[867]: Warning: /dev/root does not exist</span></span>
</span>
         Starting Dracut Emergency Shell...</span></span>
Warning: /dev/root does not exist</span></span>
</span>
Generating "/run/initramfs/rdsosreport.txt"</span></span>
</span>
</span>
Entering emergency mode. Exit the shell to continue.</span></span>
Type "journalctl" to view the system logs.</span></span>
You might want to save "/run/initramfs/rdsosreport.txt" to a USB stick or /boot</span></span>
after mounting them and attach it to a bug report</span></span></code></pre>
After that it gives you a root shell.</p>
Some Google searching led me to an mailing list post for Cobbler</a> where
someone mentioned that adding ksdevice=link</code> to the Cobbler profile allowed
the system to boot without issues.</p>
However before I just implement a change I want to know why that fixes the
issue, so I searched Google for "kickstart ksdevice" and found Red Hat's
documentation on starting a kickstart</a>. Searching that page for "ksdevice"
led me to this section:</p>

ksdevice=<device></code></p>
The installation program uses this network device to connect to the network. You can specify the device in one of five ways:</p>

the device name of the interface, for example, eth0</code></li>
the MAC address of the interface, for example, 00:12:34:56:78:9a</code></li>
the keyword link</code>, which specifies the first interface with its link in the up state</li>
the keyword bootif</code>, which uses the MAC address that pxelinux set in the
BOOTIF variable. Set IPAPPEND 2 in your pxelinux.cfg file to have pxelinux
set the BOOTIF variable.</li>
the keyword ibft</code>, which uses the MAC address of the interface specified by iBFT</li>
</ul>
For example, consider a system connected to an NFS server through the eth1
device. To perform a kickstart installation on this system using a kickstart
file from the NFS server, you would use the command ks=nfs:<server>:/<path> ksdevice=eth1</code> at the boot: prompt.</p>
</blockquote>
While ksdevice=link</code> would work for some of the machines I am deploying, it
wouldn't work for most since they have multiple interfaces and each one of
those interfaces would have link, what I really wanted was ksdevice=bootif</code>,
which is the most sensible default.</p>
So I modified the profile with ksdevice=link</code> just to test, and that worked
without issues, so then I modified the profile and added ksdevice=link</code>, and
this failed.</p>
I figured I should check the pxelinux.cfg/default</code> file that Cobbler generates
upon issuing a cobbler sync</code> and verify that ksdevice=bootif</code> is actually
listed correctly.</p>
What I found was this:</p>
LABEL CentOS-7.1-x86_64</span></span>
        kernel /images/CentOS-7.1-x86_64/vmlinuz</span></span>
        MENU LABEL CentOS-7.1-x86_64</span></span>
        append initrd=/images/CentOS-7.1-x86_64/initrd.img ksdevice=${net0/mac} lang=  kssendmac text  ks=http://10.10.10.1/cblr/svc/op/ks/profile/CentOS-7.1-x86_64</span></span>
        ipappend 2</span></span></code></pre>
This has a ksdevice=${net0/mac}</code> which is not what I had put in the profile,
overwriting ksdevice</code> in the profile with ksdevice=link</code> did correctly put
that into the pxelinux.cfg/default</code> file, so Cobbler was overwriting my change
somehow.</p>
A quick search of ${net0/mac}</code> led me to a page about gPXE commandline
items</a> that contained the same variable. At which point I remembered that in
Cobbler you set up your profile to be gPXE enabled or not. The default when you
import an image is to enable gPXE support.</p>
cobbler profile report  --name=CentOS-7.1-x86_64</span></span>
</span>
Name                           : CentOS-7.1-x86_64</span></span>
TFTP Boot Files                : {}</span></span>
Comment                        : </span></span>
DHCP Tag                       : default</span></span>
Distribution                   : CentOS-7.1-x86_64</span></span>
Enable gPXE?                   : True</span></span>
Enable PXE Menu?               : 1</span></span>
[...]</span></span></code></pre>
So let's modify the profile to disable gPXE support:</p>
cobbler</span> profile edit</span> --name=CentOS-7.1-x86_64 --enable-gpxe=False</span></span>
cobbler</span> sync</span></span></code></pre>
Verify that the change was made:</p>
cobbler profile report  --name=CentOS-7.1-x86_64</span></span>
</span>
[...]</span></span>
Enable gPXE?                   : False</span></span>
[...]</span></span></code></pre>
Then let's take a look at our pxelinux.cfg/default</code> file and make sure that it
looks correct:</p>
LABEL CentOS-7.1-x86_64</span></span>
        kernel /images/CentOS-7.1-x86_64/vmlinuz</span></span>
        MENU LABEL CentOS-7.1-x86_64</span></span>
        append initrd=/images/CentOS-7.1-x86_64/initrd.img ksdevice=bootif lang=  kssendmac text  ks=http://10.10.10.1/cblr/svc/op/ks/profile/CentOS-7.1-x86_64</span></span>
        ipappend 2</span></span></code></pre>
This time our ksdevice is correctly set. Upon rebooting my PXE booted server it
picked up the correct interface, made a DHCP request and kickstarted the server
using the provided kickstart file, and installation completed successfully.</p>
So unless you chain-boot gPXE from pxelinux by default, make sure that your
profiles are not set to be gPXE enabled if you want to use them directly from
the pxelinux menu.</p>
While researching more about this article, I found a blog post by Vlad Ionescu
about PXE installing RHEL 7 from Cobbler</a> where he suggests disabling
ksdevice</code> entirely and adding an extra inst.repo</code> variable to the kernel
command line, however on older versions of CentOS 7 and Red Hat Enterprise
Linux 7 there is a bug report</a> that shows that an empty ksdevice</code> could
cause anaconda to crash, and setting a manual inst.repo</code> for every profile
seems like overkill when just disabling gPXE for the profile also solves the
problem.</p>



Neutron L3 agent with multiple provider networks
2014-09-29T18:11:00+00:00
Due to requirements outside of my control, there was a requirement to run
multiple "provider" networks each with each providing their own floating
address pool from a single network node, I wanted to do this as simply as
possible using a single l3 agent rather than having to figure out how to get
systemd to start multiple with different configuration files.</p>
Currently I've installed and configured an OpenStack instance that looks like
this:</p>
+---------------------+</span></span>
|                     |</span></span>
|                  +--+----+</span></span>
|                  |       |</span></span>
|      +-----------+-+  +--+----------+</span></span>
|      | Compute     |  | Compute     |</span></span>
|      |     01      |  |     02      |</span></span>
|      +------+------+  +-----+-------+</span></span>
|             |               |</span></span>
|             |               +----------+</span></span>
|             +------------+--+          |</span></span>
|                          |             |</span></span>
| +-------------+    +-----+-------+     |</span></span>
| | Controller  |    |   Network   |     |</span></span>
| |             |    |             |     +---+  Tenant Networks (vlan tagged) (vlan ID's 350 - 400)</span></span>
| +-----+----+--+    +------+----+-+</span></span>
|       |    |              |    |</span></span>
|       |    |              |    +-----------+  Floating Networks (vlan tagged) (vlan ID's 340 - 349)</span></span>
|       |    |              |</span></span>
|       |    |              |</span></span>
+------------+--------------+----------------+  Management Network (10.5.2.0/25)</span></span>
        |</span></span>
        |</span></span>
        +------------------------------------+  External API Network (10.5.2.128/25)</span></span></code></pre>
There are two compute nodes, a controller node that runs all of the API
services, and a network node that is strictly used for providing network
functions (routers, load balancers, firewalls, all that fun stuff!).</p>
There are two flat networks that provide the following:</p>

External API access</li>
A management network that OpenStack uses internally to communicate between
instances and to manage it, which is not accessible from the other three
networks.</li>
</ol>
The other two networks are both vlan tagged:</p>

Tenant networks, with the possibility of 50 vlan ID's</li>
Floating networks, with existing vlan ID's for existing networks</li>
</ol>
Since the OpenStack Icehouse release, the l3 agent has supported the ability to
use the Open vSwitch configuration to specify how traffic should be routed
rather than statically defining that a single l3 agent routes certain traffic
to a single Linux bridge. Setting this up is fairly simple if you follow the
documentation, with one caveat, variables you think would be defined to no
value, actually have a value and thus need to be explicitly zeroed out.</p>
On the network node</h2>
First, we need to configure the l3 agent, so let's set some extra variables in
/etc/neutron/l3-agent.ini</code>:</p>
gateway_external_network_id</span> =</span></span>
external_network_bridge</span> =</span></span></code></pre>
It is important that these two are set, not left commented out, unfortunately
when commented out they have some defaults set and it will fail to work, so
explicitly setting them to blank will fix that issue.</p>
Next, we need to set up our Open vSwitch configuration. In
/etc/neutron/plugin.ini</code> the following needs to be configured:</p>

bridge_mappings</code></li>
network_vlan_ranges</code></li>
</ul>
Note, that these may already be configured, in which case there is nothing left
to do. Mine currently looks like this:</p>
bridge_mappings</span> = tenant1:br-tnt,provider1:br-ex</span></span></code></pre>
This basically specifies that any networks created under "provider name"
tenant1</code> are going to be mapped to the Open vSwitch bridge br-tnt</code> and any
networks with "provider name" provider1</code> will be mapped to br-ex</code>.</p>
br-tnt</code> is mapped to my tenant network and on the switch has vlan ID's 350 -
400 assigned, and br-ex</code> has vlan ID's 340 - 349 assigned.</p>
Following the above knowledge, my network_vlan_ranges</code> is configured as such:</p>
network_vlan_ranges</span> = tenant1:350:400,provider1:340:349</span></span></code></pre>
Make sure to restart all neutron services:</p>
openstack-service</span> restart neutron</span></span></code></pre>On the controller (where neutron-server</code> lives)</h2>
On the controller we just need to make sure that our network_vlan_ranges</code>
matches what is on the network node, with one exception, we do not list our
provider1</code> vlan ranges since we don't want to make those available to
accidentally be assigned when a regular tenant creates a new network.</p>
So our configuration should list:</p>
network_vlan_ranges</span> = tenant1:350:400</span></span></code></pre>
Make sure that all neutron services are restarted:</p>
openstack-service</span> restart neutron</span></span></code></pre>Create the Neutron networks</h2>
Now, as an administrative user we need to create the provider networks.</p>
source</span> ~/keystonerc_admin</span></span>
</span>
neutron</span> net-create</span> "</span>192.168.1.0/24-floating</span>"</span> \</span></span>
    --router:external</span> True</span> \</span></span>
    --provider:network_type</span> vlan</span> \</span></span>
    --provider:physical_network</span> provider1</span> \</span></span>
    --provider:segmentation_id</span> 340</span></span>
</span>
neutron</span> net-create</span> "</span>192.168.2.0/24-floating</span>"</span> \</span></span>
    --router:external</span> True</span> \</span></span>
    --provider:network_type</span> vlan</span> \</span></span>
    --provider:physical_network</span> provider1</span> \</span></span>
    --provider:segmentation_id</span> 341</span></span></code></pre>
Notice how we've created two networks, given them each individual names (I like
to use the name of the network they are going to be used for) and have been
attached to the provider1</code>. Note that provider1</code> is completely
administratively defined, and could just as well have been physnet1</code>, so long
as it is consistent across all of the configuration files.</p>
Now let's create subnets on this network:</p>
neutron</span> subnet-create</span> "</span>192.168.1.0/24-floating</span>"</span> 192.168.1.0/24</span> \</span></span>
    --allocation-pool</span> start=192.168.1.4,end=</span>192.168.1.254 \</span></span>
    --disable-dhcp --gateway</span> 192.168.1.1</span></span>
</span>
neutron</span> subnet-create</span> "</span>192.168.2.0/24-floating</span>"</span> 192.168.2.0/24</span> \</span></span>
    --allocation-pool</span> start=192.168.2.4,end=</span>192.168.2.254 \</span></span>
    --disable-dhcp --gateway</span> 192.168.2.1</span></span></code></pre>
Now that these networks are defined, you should be able to have tenants create
routers and set their gateways to either of these new networks by selecting
from the drop-down in Horizon or by calling neutron router-gateway-set <router id> <network id></code> on the command line.</p>
The l3 agent will automatically configure and set up the router as required on
the network node, and traffic will flow to either vlan 340 or vlan 341 as
defined above depending on what floating network the user uses as a gateway.</p>
This drastically simplifies the configuration of multiple floating IP networks
since no longer is there a requirement to start up and configure multiple l3
agents each with their own network ID configured. This makes configuration less
brittle and easier to maintain over time.</p>


OpenStack resizing of instances
2014-09-29T17:10:00+00:00
One thing that is not always adequately explained in the OpenStack
documentation is how exactly instance resizing works, and what is required,
especially while using KVM as the virtualisation provider, with multiple
compute nodes.</p>
You might find something similiar to the following in your logs, and no good
documentation on how to fix it.</p>
ERROR nova.compute.manager [req-7cb1c029-beb4-4905-a9d9-62d488540eda f542d1b5afeb4908b8b132c4486f9fa8 c2bfab5ad24642359f43cdff9bb00047] [instance: 99736f90-db0f-4cba-8f44-a73a603eee0b] Setting instance vm_state to ERROR</span></span>
TRACE nova.compute.manager [instance: 99736f90-db0f-4cba-8f44-a73a603eee0b] Traceback (most recent call last):</span></span>
TRACE nova.compute.manager [instance: 99736f90-db0f-4cba-8f44-a73a603eee0b]   File "/usr/lib/python2.7/site-packages/nova/compute/manager.py", line 5596, in _error_out_instance_on_exception</span></span>
TRACE nova.compute.manager [instance: 99736f90-db0f-4cba-8f44-a73a603eee0b]     yield</span></span>
TRACE nova.compute.manager [instance: 99736f90-db0f-4cba-8f44-a73a603eee0b]   File "/usr/lib/python2.7/site-packages/nova/compute/manager.py", line 3459, in resize_instance</span></span>
TRACE nova.compute.manager [instance: 99736f90-db0f-4cba-8f44-a73a603eee0b]     block_device_info)</span></span>
TRACE nova.compute.manager [instance: 99736f90-db0f-4cba-8f44-a73a603eee0b]   File "/usr/lib/python2.7/site-packages/nova/virt/libvirt/driver.py", line 4980, in migrate_disk_and_power_off</span></span>
TRACE nova.compute.manager [instance: 99736f90-db0f-4cba-8f44-a73a603eee0b]     utils.execute('ssh', dest, 'mkdir', '-p', inst_base)</span></span>
TRACE nova.compute.manager [instance: 99736f90-db0f-4cba-8f44-a73a603eee0b]   File "/usr/lib/python2.7/site-packages/nova/utils.py", line 165, in execute</span></span>
TRACE nova.compute.manager [instance: 99736f90-db0f-4cba-8f44-a73a603eee0b]     return processutils.execute(*cmd, **kwargs)</span></span>
TRACE nova.compute.manager [instance: 99736f90-db0f-4cba-8f44-a73a603eee0b]   File "/usr/lib/python2.7/site-packages/nova/openstack/common/processutils.py", line 193, in execute</span></span>
TRACE nova.compute.manager [instance: 99736f90-db0f-4cba-8f44-a73a603eee0b]     cmd=' '.join(cmd))</span></span>
TRACE nova.compute.manager [instance: 99736f90-db0f-4cba-8f44-a73a603eee0b] ProcessExecutionError: Unexpected error while running command.</span></span>
TRACE nova.compute.manager [instance: 99736f90-db0f-4cba-8f44-a73a603eee0b] Command: ssh 10.5.2.20 mkdir -p /var/lib/nova/instances/99736f90-db0f-4cba-8f44-a73a603eee0b</span></span>
TRACE nova.compute.manager [instance: 99736f90-db0f-4cba-8f44-a73a603eee0b] Exit code: 255</span></span>
TRACE nova.compute.manager [instance: 99736f90-db0f-4cba-8f44-a73a603eee0b] Stdout: ''</span></span>
TRACE nova.compute.manager [instance: 99736f90-db0f-4cba-8f44-a73a603eee0b] Stderr: 'Host key verification failed.\r\n'</span></span>
TRACE nova.compute.manager [instance: 99736f90-db0f-4cba-8f44-a73a603eee0b] </span></span>
ERROR oslo.messaging.rpc.dispatcher [-] Exception during message handling: Unexpected error while running command.</span></span>
Command: ssh 10.5.2.20 mkdir -p /var/lib/nova/instances/99736f90-db0f-4cba-8f44-a73a603eee0b</span></span>
Exit code: 255</span></span>
Stdout: ''</span></span>
Stderr: 'Host key verification failed.\r\n'</span></span></code></pre>
When OpenStack's nova is instructed to resize an instance it will also change
the host it is running on, almost never will it schedule the instance on the
same host and do the resize on the same host it already exists. There is a
configuration flag to change this, however in my case I would rather the
scheduler be run again, especially if the instance size is changing
drastically. During the resize process, the node where the instance is
currently running will use SSH to connect to the instance where the resized
instance will live, and copy over the instance and associated files.</p>
There are a couple of assumptions I will be making:</p>

Your nova</code>, and qemu</code> user both have the same UID on all compute nodes</li>
The path for your instances is the same on all of your compute nodes</li>
</ol>
Configure the nova user</h2>
First things first, let's make sure our nova</code> user has an appropriate shell set:</p>
cat</span> /etc/passwd</span> |</span> grep</span> nova</span></span></code></pre>
Verify that the last entry is /bin/bash</code>.</p>
If not, let's modify the user and make it so:</p>
usermod</span> -s</span> /bin/bash nova</span></span></code></pre>Generate SSH key and configuration</h2>
After doing this the next steps are all run as the nova</code> user.</p>
su</span> - nova</span></span></code></pre>
We need to generate an SSH key:</p>
ssh-keygen</span> -t</span> rsa</span></span></code></pre>
Follow the directions, and save the key WITHOUT a passphrase.</p>
Next up we need to configure SSH to not do host key verification, unless you
want to manually SSH to all compute nodes that exist and accept the key (and
continue to do so for each new compute node you add).</p>
cat</span> <<</span> EOF</span> ></span> ~/.ssh/config</span></span>
Host *</span></span>
    StrictHostKeyChecking no</span></span>
    UserKnownHostsFile=/dev/null</span></span>
EOF</span></span></code></pre>
Next we need to make sure we copy the the contents of id_rsa.pub</code> to
authorized_keys</code> and set the mode on it correctly.</p>
cat</span> ~/.ssh/id_rsa.pub</span> ></span> .ssh/authorized_keys</span></span>
chmod</span> 600</span> .ssh/authorized_keys</span></span></code></pre>
This should be all the configuration for SSH you need to do. Now comes the
import part, you will need to tar up and copy the ~nova/.ssh</code> directory to
every single compute node you have provisioned. This way all compute nodes will
be able to SSH to the remote host to run the commands required to copy an
instance over, and resize it.</p>
Reset state on existing ERROR'ed instances</h2>
If you have any instances that are currently in the ERROR</code> state due to a
failed resize, you will be able to issue the following command to reset the
state back to running and try again:</p>
nova</span> reset-state</span> --active</span> <</span>ID of instanc</span>e</span>></span></span></code></pre>
This will start the instance, and you will be able to once again issue the
resize command to resize the instance.</p>


IPv6 -- getaddrinfo() and bind() ordering with V6ONLY
2012-08-07T22:39:56+00:00
Recently I ran into an issue that took me a while to sort out, and it is
regarding inconsistent behaviour on various OS's with regards to IPv6 sockets
(AF_INET6</code></a>1</a></sup>) and calling bind(2)</code></a> after getting the
results back from getaddrinfo(3)</code></a>.</p>
A call to getaddrinfo()</code> with the hints set to AF_UNSPEC</code></a> in ai_family</code>
and AI_PASSIVE</code></a> in ai_flags</code> will return to us 1 or more results that we
can bind()</code> to. Sample code for that looks like this:</p>
struct</span> addrinfo hints,</span> *</span>addrlist;</span></span>
</span>
memset</span>(</span>&</span>hints</span>,</span> 0</span>,</span> sizeof</span>(hints));</span></span>
</span>
// Ask for TCP</span></span>
hints.ai_socktype </span>=</span> SOCK_STREAM;</span></span>
</span>
// Any family works for us ...</span></span>
hints.ai_family </span>=</span> AF_UNSPEC;</span></span>
</span>
// Set some hints</span></span>
hints.ai_flags </span>=</span> </span></span>
    AI_PASSIVE    </span>|</span> // We want to use this with bind</span></span>
    AI_ADDRCONFIG;</span>  // Only return IPv4 or IPv6 if they are configured</span></span>
</span>
int</span> rv;</span></span>
</span>
if</span> ((rv </span>=</span> getaddrinfo</span>(</span>0</span>,</span> "</span>7020</span>"</span>,</span> &</span>hints</span>,</span> &</span>addrlist</span>))</span> !=</span> 0</span>) {</span></span>
    fprintf</span>(stderr,</span> "</span>getaddrinfo: </span>%s</span>"</span>,</span> gai_strerror</span>(rv))</span>;</span></span>
    return</span> 1</span>;</span></span>
}</span></span>
</span>
// Use the list in *addrlist</span></span>
for</span> (addr </span>=</span> addrlist; addr </span>!=</span> 0</span>; addr </span>=</span> addr</span>-</span>></span>ai_next) {</span></span>
    // use *addr as appropriate</span></span>
}</span></span>
</span>
// Clean up the memory from getaddrinfo()</span></span>
freeaddrinfo</span>(addrlist);</span></span></code></pre>
On Linux there are two entries returned when the host it is run on has both
IPv4 and IPv6 enabled. An AF_INET</code> which was followed by an AF_INET6</code>. Now,
it is not said that you are required to use all of the results that are
returned, but if you want to listen on all address families it is off course
suggested.</p>
Following the steps below for each of the returned results should result in
having 1 or more different sockets that are bound to a single port.</p>

Create the socket()</li>
Set any socket options you want (SO_REUSEADDR</code> for example)</li>
Then bind() the socket</li>
After that call listen() (followed off course by accept() on the socket)</li>
</ol>
Only for some unknown reason (and errno</code> is no help) bind()</code> fails when you
get to the AF_INET6</code>, which was returned second. Searching online as to why
the bind would fail doesn't give you any good results and the thing that is
even worse is that if you run the same code on another platform such as
FreeBSD</a>, OpenIndiana</a> or Mac OS X</a> no such failure exists. However
I started suspecting something was up when I started looking at the output from
netstat -lan | grep 7020</code> on Mac OS X. Where 7020 is the port I passed into
getaddrinfo()</code>.</p>
tcp46      0      0  *.7020                 *.*  LISTEN     </span></span>
tcp4       0      0  *.7020                 *.*  LISTEN </span></span></code></pre>
Wait a minute ... one of the sockets is on both IPv4 and on IPv6. Some more
time spent searching the internet I came across RFC 3493 section 5.3</a>,
which is titled "IPV6_V6ONLY</code> option for AF_INET6</code> Sockets".</p>

As stated in section <3.7 Compatibility with IPv4 Nodes>, AF_INET6</code> sockets
may be used for both IPv4 and IPv6 communications.  Some applications may
want to restrict their use of an AF_INET6</code> socket to IPv6 communications
only.</p>
</blockquote>
This was going down the right route, so I changed my code so that in the steps
listed above in number 2 I added the following code if the socket type is
AF_INET6</code>:</p>
if</span> (</span>setsockopt</span>(sockfd, IPPROTO_IPV6, IPV6_V6ONLY,</span> &</span>yes</span>,</span> sizeof</span>(</span>int</span>))</span> ==</span> -</span>1</span>) {</span></span>
    close</span>(sockfd)</span>;</span></span>
    fprintf</span>(stderr,</span> "</span>setsockopt: </span>%s</span> IPV6_V6ONLY</span>\n</span>"</span>,</span> strerror</span>(errno))</span>;</span></span>
    continue</span>;</span></span>
}</span></span></code></pre>
The RFC 3493 section 5.3 also states that this option should be turned off by
default, which means that all IPv6 sockets can also communicate over IPv4. Thus
technically setting the option manually in code the best way to fix the issue.
FreeBSD has had this feature turned on (as in IPv6 sockets can only communicate
with IPv6 and NOT IPv4) since 5.x.</p>
The biggest issue is that the remaining operating systems (OS X and
OpenIndiana) don't have the same behaviour as Linux which makes troubleshooting
this issue more difficult than it should be. The issue is that the RFC doesn't
specify what exactly the operating should do when it encounters a request to
bind to the same port on IPv4 and IPv6. The only place where I have found this
documented is in "IPv6 Network Programming"</a> under "Tips in IPv6
Programming" chapter 4, section 4, appropriately titled "bind(2) Ordering and
Conflicts".</p>

If you get a bind()</code> error when attempting to bind to an AF_INET6</code> socket
please make sure that you set the socket option IPV6_V6ONLY</code> on the AF_INET6</code>
socket. The default as required by RFC 3493 is to have that option be off. The
default is wrong, and the RFC should have been more specific regarding what the
right behaviour is when attempting to bind on an AF_INET6</code> socket when already
bound on an AF_INET</code> while IPV6_V6ONLY</code> is set to false.</p>
The full code that I used for testing, along with a little bit more information
is available as a gist on github</a>.</p>



The old BSD style socket()</code></a> called for defines
starting with PF_</code> such as PF_INET</code> and PF_INET6</code> with the PF</code> standing for
protocol family. POSIX starts them with AF_</code>, and calls them an address
family. On almost every operating system PF_INET</code> is the same as AF_INET</code>. If
the define doesn't exist you can always create it. ↩</a></p>
</li>
</ol>
</section>