Lorin Hochstein's questions

Operating systems limit the length of a path of a Unix domain socket. How can I check whether a particular path is within that limit?

Or, to put it another way, how can I check the maximum permitted length of a path of a Unix domain socket, on a Linux or Mac OS X system?

My use case here is for SSH multiplexing: if the ControlPath is too long, then SSH multiplexing won't work since it creates a unix domain sockets. I want to be able to check for a valid control path without having to actually start an ssh session and look for the error message.

Is it possible to import an XML file into libvirt without having libvirt boot the virtual machine?

If I do:

virsh create centos63.xml

Then libvirt will import the XML file and immediately try to boot the image, and this isn't what I want.

(I have several scripts that take as argument a libvirt domain that corresponds to a VM that is not currently running, which is why I want to do this).

I ran into the oddest thing when trying to debug a networking issue with OpenStack. I was doing a ping test between virtual machines. The ICMP request packets only made it to the destination host if I did a "tcpdump" on the bridge interface on the node running nova-network, which forwards the packets. If I stopped doing a tcpdump on that interface, I no longer saw the requests reach the host.

In general, how/why would doing a tcpdump on a Linux bridge interface affect whether packets get forwarded?

I'd like to mount an NFS share from Windows 2012 using PowerShell and have this mount be visible in contexts other than the PowerShell session that invoked it. If I use the New-PSDrive command (cmdlet?), e.g.:

New-PSDrive Z -PsProvider FileSystem -Root \\10.40.1.1\export\isos

Then it will mount the NFS server to the Z drive, but I can't access this drive in, say, File Explorer.

Is there any solution that will you allow you to run GPU-accelerated OpenGL applications remotely, given:

• The remote machine is a Microsoft Windows server
• There is a 3D graphics card in the remote machine (e.g., NVIDIA, ATI)

In particular, is this possible over RDP using the Microsoft Remote desktop Client?

As far as I can tell Microsoft's RemoteFX technology only does 3D acceleration for DirectX, it doesn't 3D accelerate OpenGL. VirtualGL+VNC works for Linux, but there isn't a Windows port as far as I can tell.

I've statically configured the IP address of an interface on a server:

ip addr add 10.40.0.6/16 broadcast 10.40.255.255 dev eth1

If I try to ping a machine on the network (e.g., 10.40.0.1), it fails with "Destination Host Unreachable".

When the ping is running, if I do the following, I don't see any activity at all

tcpdump -i eth1 icmp

However, if I listen on the loopback interface instead:

tcpdump -i lo icmp

Then I see something like:

16:02:57.369632 IP 10.40.0.6 > 10.40.0.6: ICMP host 10.40.0.1 unreachable, length 92

My question is: why don't the ICMP packets show up as going out over the eth1 interface?

Edit:

# ip r ls
10.40.0.0/16 dev eth1 proto kernel scope link src 10.40.0.6

I'm running a KVM instance inside of OpenStack, and it isn't getting an IP address from the DHCP server.

Using tcpdump, I can see the request and reply packets on vnet0 of the compute host:

# tcpdump -i vnet0 -n port 67 or port 68
tcpdump: WARNING: vnet0: no IPv4 address assigned
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on vnet0, link-type EN10MB (Ethernet), capture size 65535 bytes
19:44:56.176727 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from fa:16:3e:46:f6:11, length 300
19:44:56.176785 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from fa:16:3e:46:f6:11, length 300
19:44:56.177315 IP 10.40.0.1.67 > 10.40.0.3.68: BOOTP/DHCP, Reply, length 319
19:45:02.179834 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from fa:16:3e:46:f6:11, length 300
19:45:02.179904 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from fa:16:3e:46:f6:11, length 300
19:45:02.180375 IP 10.40.0.1.67 > 10.40.0.3.68: BOOTP/DHCP, Reply, length 319

However, if I do the same thing on eth0 inside the KVM instance, I only see the request packets, not the reply packets. What would prevent the packets from making it from vnet0 of the host to eth0 of the guest?

My host is running Ubuntu 12.04 and my guest is running CentOS 6.3.

Note that I have added this rule in my iptables, but it doesn't resolve the issue:

-A POSTROUTING -p udp -m udp --dport 68 -j CHECKSUM --checksum-fill

The instance corresponds to vnet0 and is connected via br100:

# brctl show
bridge name bridge id       STP enabled interfaces
br100       8000.54781a8605f2   no      eth1
                            vnet0
                            vnet1
virbr0      8000.000000000000   yes

Here's the full iptables-save:

# Generated by iptables-save v1.4.12 on Tue Apr  2 19:47:27 2013
*nat
:PREROUTING ACCEPT [8323:2553683]
:INPUT ACCEPT [7993:2494942]
:OUTPUT ACCEPT [6158:461050]
:POSTROUTING ACCEPT [6455:511595]
:nova-compute-OUTPUT - [0:0]
:nova-compute-POSTROUTING - [0:0]
:nova-compute-PREROUTING - [0:0]
:nova-compute-float-snat - [0:0]
:nova-compute-snat - [0:0]
:nova-postrouting-bottom - [0:0]
-A PREROUTING -j nova-compute-PREROUTING
-A OUTPUT -j nova-compute-OUTPUT
-A POSTROUTING -j nova-compute-POSTROUTING
-A POSTROUTING -j nova-postrouting-bottom
-A POSTROUTING -s 192.168.122.0/24 ! -d 192.168.122.0/24 -p tcp -j MASQUERADE --to-ports 1024-65535
-A POSTROUTING -s 192.168.122.0/24 ! -d 192.168.122.0/24 -p udp -j MASQUERADE --to-ports 1024-65535
-A POSTROUTING -s 192.168.122.0/24 ! -d 192.168.122.0/24 -j MASQUERADE
-A nova-compute-snat -j nova-compute-float-snat
-A nova-postrouting-bottom -j nova-compute-snat
COMMIT
# Completed on Tue Apr  2 19:47:27 2013
# Generated by iptables-save v1.4.12 on Tue Apr  2 19:47:27 2013
*mangle
:PREROUTING ACCEPT [7969:5385812]
:INPUT ACCEPT [7905:5363718]
:FORWARD ACCEPT [158:48190]
:OUTPUT ACCEPT [6877:8647975]
:POSTROUTING ACCEPT [7035:8696165]
-A POSTROUTING -o virbr0 -p udp -m udp --dport 68 -j CHECKSUM --checksum-fill
-A POSTROUTING -p udp -m udp --dport 68 -j CHECKSUM --checksum-fill
COMMIT
# Completed on Tue Apr  2 19:47:27 2013
# Generated by iptables-save v1.4.12 on Tue Apr  2 19:47:27 2013
*filter
:INPUT ACCEPT [2196774:15856921923]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [2447201:1170227646]
:nova-compute-FORWARD - [0:0]
:nova-compute-INPUT - [0:0]
:nova-compute-OUTPUT - [0:0]
:nova-compute-inst-19 - [0:0]
:nova-compute-inst-20 - [0:0]
:nova-compute-local - [0:0]
:nova-compute-provider - [0:0]
:nova-compute-sg-fallback - [0:0]
:nova-filter-top - [0:0]
-A INPUT -j nova-compute-INPUT
-A INPUT -i virbr0 -p udp -m udp --dport 53 -j ACCEPT
-A INPUT -i virbr0 -p tcp -m tcp --dport 53 -j ACCEPT
-A INPUT -i virbr0 -p udp -m udp --dport 67 -j ACCEPT
-A INPUT -i virbr0 -p tcp -m tcp --dport 67 -j ACCEPT
-A FORWARD -j nova-filter-top
-A FORWARD -j nova-compute-FORWARD
-A FORWARD -d 192.168.122.0/24 -o virbr0 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -s 192.168.122.0/24 -i virbr0 -j ACCEPT
-A FORWARD -i virbr0 -o virbr0 -j ACCEPT
-A FORWARD -o virbr0 -j REJECT --reject-with icmp-port-unreachable
-A FORWARD -i virbr0 -j REJECT --reject-with icmp-port-unreachable
-A OUTPUT -j nova-filter-top
-A OUTPUT -j nova-compute-OUTPUT
-A nova-compute-FORWARD -i br100 -j ACCEPT
-A nova-compute-FORWARD -o br100 -j ACCEPT
-A nova-compute-inst-19 -m state --state INVALID -j DROP
-A nova-compute-inst-19 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A nova-compute-inst-19 -j nova-compute-provider
-A nova-compute-inst-19 -s 10.40.0.1/32 -p udp -m udp --sport 67 --dport 68 -j ACCEPT
-A nova-compute-inst-19 -s 10.40.0.0/16 -j ACCEPT
-A nova-compute-inst-19 -p tcp -m tcp --dport 22 -j ACCEPT
-A nova-compute-inst-19 -p icmp -j ACCEPT
-A nova-compute-inst-19 -j nova-compute-sg-fallback
-A nova-compute-inst-20 -m state --state INVALID -j DROP
-A nova-compute-inst-20 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A nova-compute-inst-20 -j nova-compute-provider
-A nova-compute-inst-20 -s 10.40.0.1/32 -p udp -m udp --sport 67 --dport 68 -j ACCEPT
-A nova-compute-inst-20 -s 10.40.0.0/16 -j ACCEPT
-A nova-compute-inst-20 -p tcp -m tcp --dport 22 -j ACCEPT
-A nova-compute-inst-20 -p icmp -j ACCEPT
-A nova-compute-inst-20 -j nova-compute-sg-fallback
-A nova-compute-local -d 10.40.0.3/32 -j nova-compute-inst-19
-A nova-compute-local -d 10.40.0.4/32 -j nova-compute-inst-20
-A nova-compute-sg-fallback -j DROP
-A nova-filter-top -j nova-compute-local
COMMIT
# Completed on Tue Apr  2 19:47:27 2013

Somebody answered my earlier question by describing how to create a new routing table with source policy routing:

echo 13 eth3 >> /etc/iproute2/rt_tables
ip route add default via 10.20.0.1 table eth3
ip rule add from 10.20.0.2 lookup eth3

How do I make those "ip" commands persist across a reboot? I assume that there's some appropriate lines to be added to /etc/network/interfaces. Is this the right away (adding "up" lines to the interface), or is there another way to do it?

iface eth3 inet static
    address 10.20.0.2
    netmask 255.255.255.0
    up ip route add default via 10.20.0.1 table eth3
    up ip rule add from 10.20.0.2 lookup eth3
    down ip rule del from 10.20.0.2 lookup eth3
    down ip route del default via 10.20.0.1 table eth3

(I'm on Ubuntu 12.04).

I have a multihomed Ubuntu server with a set of interfaces that includes:

eth2: 10.10.0.131/24
eth3: 10.20.0.2/24

The default interface is eth2, with a gateway of 10.10.0.1. Here's what the routing table looks like:

root@c220-1:~# netstat -rn
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
0.0.0.0         10.10.0.1       0.0.0.0         UG        0 0          0 eth2
10.10.0.0       0.0.0.0         255.255.255.0   U         0 0          0 eth2
10.20.0.0       0.0.0.0         255.255.255.0   U         0 0          0 eth3
10.30.0.0       0.0.0.0         255.255.255.0   U         0 0          0 eth0
10.40.0.0       0.0.0.0         255.255.0.0     U         0 0          0 eth1

From a separate network (192.168.3.5/24) I can reach this machine on the eth2 interface (the one with the default gateway), but not the eth3 interface. I can ping the eth3 interface from a router on the same network (10.20.0.1) without a problem.

If I ping 10.10.0.131 from 192.168.3.5, the packets reach the machine, but it doesn't send any replies:

c4:c8:80:90:22:eb > 73:10:73:e4:10:06, IPv4, length 98: 192.168.3.5 > 10.20.0.2: ICMP echo request, id 5451, seq 0, length 64
c4:c8:80:90:22:eb > 73:10:73:e4:10:06, IPv4, length 98: 192.168.3.5 > 10.20.0.2: ICMP echo request, id 5451, seq 1, length 64
c4:c8:80:90:22:eb > 73:10:73:e4:10:06, IPv4, length 98: 192.168.3.5 > 10.20.0.2: ICMP echo request, id 5451, seq 2, length 64
c4:c8:80:90:22:eb > 73:10:73:e4:10:06, IPv4, length 98: 192.168.3.5 > 10.20.0.2: ICMP echo request, id 5451, seq 3, length 64
c4:c8:80:90:22:eb > 73:10:73:e4:10:06, IPv4, length 98: 192.168.3.5 > 10.20.0.2: ICMP echo request, id 5451, seq 4, length 64
c4:c8:80:90:22:eb > 73:10:73:e4:10:06, IPv4, length 98: 192.168.3.5 > 10.20.0.2: ICMP echo request, id 5451, seq 5, length 64
c4:c8:80:90:22:eb > 73:10:73:e4:10:06, IPv4, length 98: 192.168.3.5 > 10.20.0.2: ICMP echo request, id 5451, seq 6, length 64
c4:c8:80:90:22:eb > 73:10:73:e4:10:06, IPv4, length 98: 192.168.3.5 > 10.20.0.2: ICMP echo request, id 5451, seq 7, length 64

If I ping from the router (10.20.0.1) on the same network, the server replies properly:

c4:c8:80:90:22:eb > 73:10:73:e4:10:06, IPv4, length 114: 10.20.0.1 > 10.20.0.2: ICMP echo request, id 28899, seq 2932, length 80
73:10:73:e4:10:06 > c4:c8:80:90:22:eb, IPv4, length 114: 10.20.0.2 > 10.20.0.1: ICMP echo reply, id 28899, seq 2932, length 80
c4:c8:80:90:22:eb > 73:10:73:e4:10:06, IPv4, length 114: 10.20.0.1 > 10.20.0.2: ICMP echo request, id 28899, seq 2932, length 80
73:10:73:e4:10:06 > c4:c8:80:90:22:eb, IPv4, length 114: 10.20.0.2 > 10.20.0.1: ICMP echo reply, id 28899, seq 2932, length 80
c4:c8:80:90:22:eb > 73:10:73:e4:10:06, IPv4, length 114: 10.20.0.1 > 10.20.0.2: ICMP echo request, id 28899, seq 2932, length 80
73:10:73:e4:10:06 > c4:c8:80:90:22:eb, IPv4, length 114: 10.20.0.2 > 10.20.0.1: ICMP echo reply, id 28899, seq 2932, length 80
c4:c8:80:90:22:eb > 73:10:73:e4:10:06, IPv4, length 114: 10.20.0.1 > 10.20.0.2: ICMP echo request, id 28899, seq 2932, length 80
73:10:73:e4:10:06 > c4:c8:80:90:22:eb, IPv4, length 114: 10.20.0.2 > 10.20.0.1: ICMP echo reply, id 28899, seq 2932, length 80
c4:c8:80:90:22:eb > 73:10:73:e4:10:06, IPv4, length 114: 10.20.0.1 > 10.20.0.2: ICMP echo request, id 28899, seq 2932, length 80
73:10:73:e4:10:06 > c4:c8:80:90:22:eb, IPv4, length 114: 10.20.0.2 > 10.20.0.1: ICMP echo reply, id 28899, seq 2932, length 80

Note that, as per the answer in this similar question, I have rp_filter off on all of the interfaces, but it doesn't resolve the issue:

$ for i in eth0 eth1 eth2 eth3 all default
> do
> cat /proc/sys/net/ipv4/conf/$i/rp_filter
> done
0
0
0
0
0
0

I'm trying to use a multi-VM vagrant environment as a testbed for deploying OpenStack, and I've run into a networking problem with trying to communicate from one VM, to a VM-inside-of-a-VM.

I have two Vagrant nodes, a cloud controller node and a compute node. I'm using host-only networking. My Vagrantfile looks like this:

Vagrant::Config.run do |config|

  config.vm.box = "precise64"

  config.vm.define :controller do |controller_config|
    controller_config.vm.network :hostonly, "192.168.206.130" # eth1
    controller_config.vm.network :hostonly, "192.168.100.130" # eth2
    controller_config.vm.host_name = "controller"
  end

  config.vm.define :compute1 do |compute1_config|
    compute1_config.vm.network :hostonly, "192.168.206.131" # eth1
    compute1_config.vm.network :hostonly, "192.168.100.131" # eth2
    compute1_config.vm.host_name = "compute1"
    compute1_config.vm.customize ["modifyvm", :id, "--memory", 1024]
  end
end

When I try to start up a (QEMU-based) VM, it boots successfully on compute1, and its virtual nic (vnet0) is connected via a bridge, br100:

root@compute1:~# brctl show 100
bridge name bridge id       STP enabled interfaces
br100       8000.08002798c6ef   no      eth2

                        vnet0

When the QEMU VM makes a request to the DHCP server (dnsmasq) running on controller, I can see the request reaches the controller because of the output on the syslog on the controller:

Aug  6 02:34:56 precise64 dnsmasq-dhcp[12042]: DHCPDISCOVER(br100) fa:16:3e:07:98:11 
Aug  6 02:34:56 precise64 dnsmasq-dhcp[12042]: DHCPOFFER(br100) 192.168.100.2 fa:16:3e:07:98:11 

However, the DHCPOFFER never makes it back to the VM running on compute1. If I watch the requests using tcpdump on the vboxnet3 interface on my host machine that runs Vagrant (Mac OS X), I can see both the requests and the replies

$ sudo tcpdump -i vboxnet3  -n port 67 or port 68
tcpdump: WARNING: vboxnet3: That device doesn't support promiscuous mode
(BIOCPROMISC: Operation not supported on socket)
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on vboxnet3, link-type EN10MB (Ethernet), capture size 65535 bytes
22:51:20.694040 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from fa:16:3e:07:98:11, length 280
22:51:20.694057 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from fa:16:3e:07:98:11, length 280
22:51:20.696047 IP 192.168.100.1.67 > 192.168.100.2.68: BOOTP/DHCP, Reply, length 311
22:51:23.700845 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from fa:16:3e:07:98:11, length 280
22:51:23.700876 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from fa:16:3e:07:98:11, length 280
22:51:23.701591 IP 192.168.100.1.67 > 192.168.100.2.68: BOOTP/DHCP, Reply, length 311
22:51:26.705978 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from fa:16:3e:07:98:11, length 280
22:51:26.705995 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from fa:16:3e:07:98:11, length 280
22:51:26.706527 IP 192.168.100.1.67 > 192.168.100.2.68: BOOTP/DHCP, Reply, length 311

But, if I tcpdump on eth2 on compute, I only see the requests, not the replies:

root@compute1:~# tcpdump -i eth2 -n port 67 or port 68
tcpdump: WARNING: eth2: no IPv4 address assigned
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth2, link-type EN10MB (Ethernet), capture size 65535 bytes
02:51:20.240672 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from fa:16:3e:07:98:11, length 280
02:51:23.249758 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from fa:16:3e:07:98:11, length 280
02:51:26.258281 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from fa:16:3e:07:98:11, length 280

At this point, I'm stuck. I'm not sure why the DHCP replies aren't making it to the compute node. Perhaps it has something to do with the configuration of the VirtualBox virtual switch/router?

Note that eth2 interfaces on both nodes have been set to promiscuous mode.

When I try to launch an instance with OpenStack, I get the following error in nova-compute.log:

(nova.rpc): TRACE: libvirtError: operation failed: domain 'instance-0000000a' already exists with uuid 5f81a7d2-1b0f-8c72-4e1e-377c275e9289

However, virsh doesn't show any domains:

$ sudo virsh list
 Id Name                 State
----------------------------------

Why isn't that domain showing up in virsh if it's there?

How do I tell Jenkins to run a specific project on a particular slave?

I've set up a Jenkins master node, and a slave node that I want to use for staging an application. But I can't figure out how to configure the project to run on the slave node I created.

I installed chef-client on a Linux node, and it seems to have successfully connected to my chef server. However, when I do: chef node list, it appears as "localhost".

Why doesn't chef pick up the proper name of the node? If I ask for more details, I see:

$ chef node show localhost
node Name:   localhost
Environment: _default
FQDN:        localhost
IP:          192.168.1.5
Run List:    
Roles:       
Recipes:     
Platform:    ubuntu 11.10

It has a proper domain name set up. For example, if I do: hostname, it returns "mynodename", not "localhost".

How is chef determining the name of the node? And why does it have the proper name showing in FQDN?

EDIT: In response to cjc below, here's some of the output from ohai | grep host:

(Note: this node is running on EC2)

"fqdn": "localhost",
"hostname": "mynodename",
"public_hostname": "ec2-...-.amazonaws.com",
"local_hostname": "ip-...ec2.internal",
"hostname": "ip-...ec2.internal",

Also, hostname -s is giving the expected output:

$ hostname -s
mynodename

I'm setting up a Jenkins server, to run under Tomcat behind Apache. I'm using virtual hosts with SSL using SNI so I can access it at https://jenkins.example.com, and serve something else on, say, http://www.example.com.

I've got it up and running, but when I click "Manage Jenkins", it tells me It appears your reverse proxy setup is broken.

Note that I'm using a self-signed SSL certificate, and jenkins.example.com is not the default virtual hosts.

The relevant apache config looks like this:

<VirtualHost *:80>
        ServerName jenkins.example.com
        Redirect / https://jenkins.example.com/
</VirtualHost>

<VirtualHost *:443>
  ServerName jenkins.example.com

  SSLEngine on

  SSLCertificateFile    /etc/ssl/certs/jenkins.example.com.crt
  SSLCertificateKeyFile /etc/ssl/private/jenkins.example.com.key

  <Location />
     AuthType Digest
     AuthName "Jenkins"
     AuthUserFile "/etc/htpasswords"
     Require valid-user
   </Location>

   ProxyRequests     Off
   ProxyPreserveHost On

   <Proxy http://localhost:8080*>
     Order deny,allow
       Allow from all
   </Proxy>

   ProxyPass         /  http://localhost:8080/
   ProxyPassReverse  /  http://localhost:8080/
   ProxyPassReverse  /  https://jenkins.example.com

</VirtualHost>

If I do:

curl --user "username:password" --digest -k https://jenkins.example.com/administrativeMonitor/hudson.diagnosis.ReverseProxySetupMonitor/test -L

Then I see the output:

<div/>

If I run wget with debug, then I see at that some point wget gets a pointer to http instead of https, not sure why that's happening or if it's related, but it does redirect properly:

---response begin---
HTTP/1.1 302 Moved Temporarily
Date: Tue, 17 Jan 2012 19:47:16 GMT
Server: Apache-Coyote/1.1
Location: http://jenkins.example.com/administrativeMonitor/hudson.diagnosis.ReverseProxySetupMonitor/test-for-reverse-proxy-setup
Content-Length: 0
Keep-Alive: timeout=15, max=99
Connection: Keep-Alive
Content-Type: text/plain

I'm running on Ubuntu 11.04, Apache 2.2.17, Tomcat 6.0.28, Jenkins 1.448.

I've installed a Python package using pip, which is a replacement for easy_install. How do I get a list of which installed files are associated with this package?

Basically, I'm looking for the Python package equivalent of

dpkg -L

or

rpm -ql

I've used IPMI before, but only on servers where the IPMI interface had a dedicated ethernet port. I've got an Ubuntu 10.04 server with two ethernet cards, which is supposed to have an IPMI interface on it (the motherboard is a Supermicro H8DMR-I2). From what I understand, the IPMI interface is piggybacking on one of the two NICs.

Is there any way I can tell which NIC the IPMI interface is piggybacking on? Using ipmitool I've tried to set the IP address on the IPMI interface for the subnet for eth0, and then the subnet for eth1, and it's never reachable.

(Can you even reach an IPMI interface from the same NIC it's piggybacking off of, or do you need to try connecting from a different machine on the network?)

Also, is there anything special I need to do to enable it? I can access the IPMI interface locally using "ipmitool".

Here are the firmware details:

# ipmitool mc info
Device ID                 : 34
Device Revision           : 1
Firmware Revision         : 1.50
IPMI Version              : 2.0
Manufacturer ID           : 10437
Manufacturer Name         : Peppercon AG
Product ID                : 4 (0x0004)
Product Name              : Unknown (0x4)
Device Available          : yes
Provides Device SDRs      : no
Additional Device Support :
    Sensor Device
    SDR Repository Device
    SEL Device
    FRU Inventory Device
    Chassis Device
Aux Firmware Rev Info     : 
    0x00
    0x00
    0x54
    0x20

When I reboot my Ubuntu 10.04 nodes, I'd like to be able to see the kernel boot messages when connecting to the IPMI interfaces using Serial Over LAN mode (ttyS0). What do I need to do to be able to redirect these messages to ttyS0?

Ideally, I'd like them to also still appear in the usual place (tty0, I think) for when I plug a monitor directly into the box.

I'm managing several Ubuntu 9.10 servers that NFS mount several folders (including /home). I'd like these folders to be mounted at boot time. I would like to have several entries in my /etc/fstab to accomplish this, e.g.

192.168.1.100:/home           /home           nfs     rw 0 0
192.168.1.100:/usr/ansys_inc  /ansys_inc      nfs     ro 0 0

Unfortunately, with this configuration, the servers usually (although not always) hang during the bootup sequence when trying to do the NFS mount.

if I comment out these fstab entries, reboot the machine, uncomment them and mount them manually using the shell, the folders mount cleanly.

I'm not sure how to go about debugging this problem. It seems like it has something to do with the boot sequence, that some relevant process hasn't been started by the time the OS tries to mount the folders.

When specifying an NFS mountpoint in /etc/fstab, what's the purpose of the addr option? For example:

192.168.1.5:/home         /home                   nfs     rw,addr=192.168.1.5 0 0

Sometimes my servers will show a high load average in the "top" program (e.g. load is ~10 on a 4-core machine), but the actual CPU usage isn't particularly high.

I assume the issue is that there are many I/O-intensive jobs running. Is there any easy way to identify these jobs that are causing the load, if their "%CPU" values in top aren't that high?