Candela is a small team with a lot of code, and a lot of customers want new features! Do you enjoy the adventures of WiFi, networking, and Linux? We are looking for people who can program in C++, Java, or Python. We’re looking for people in the vicinity of Bellingham, WA.
Read more about jobs at Candela Technologies.
Getting remote X applications displaying on your CentOS desktop used not to be difficult. X11 remote connections are typically governed by the -listen tcp or -nolisten tcp arguments to X or Xorg server running your desktop. It’s not sufficient to just run xhost + from a terminal on your desktop, you have to edit a display manager configuration file and start a new X session (log out, log in again).
sudo systemctl stop firewalld sudo systemctl disable firewalld sudo systemctl mask firewalld sudo systemctl daemon-reload
If you ssh from desktop1 to server2, you probably have X11 forwarding happening already. This uses implied port forwarding through ssh for port 5900 to localhost:5010 usually. This is why when you type $ echo $DISPLAY you will likely see localhost:10 as your new display. By default, many X11 based programs take a -d host:display.number argument. Use this to avoid testing out the ssh local X forwarding. You want to use xhost + from your desktop first, of course:
desktop1$ xhost + access control disabled, clients can connect from any host desktop1$ ssh server2 server2$ echo $DISPLAY localhost:10 server2$ xterm -d desktop1:0.0
Updated: The files you want to edit if you’re running lightdm include:
1) /usr/share/lightdm/lightdm.conf.d/50-xserver-command.conf
[Seat:*] xserver-command=X -core -listen tcp
2) /etc/lightdm/lightdm.conf
This file probably won’t exist, you may create it if it is missing.
[Seat:*] xserver-allow-tcp=true xserver-command=X -listen tcp
Then run $ sudo systemctl restart lightdm
When you log in again, check that no -nolisten tcp arguments are present in the X command line. Multiple -listen tcp arguments are fine.
$ pgrep X | xargs ps -lfwwwp
Then edit /etc/gdm/custom.conf
You want to add this line to [security] stanza:
DisallowTCP=false
And allow a listen tcp argument to the [xdmcp] stanza:
ServerArguments=-listen tcp
A full configuration looks like:
# GDM configuration [daemon] [security] DisallowTCP=false [xdmcp] ServerArguments=-listen tcp [chooser] [debug] #Enable=true
Log out of your CentOS desktop session, and log in again. Open a terminal and run:
$ xhost +
You can check the efficacy of that by looking at the arguments X was started with:
$ pgrep X | xargs ps -lfwwwp
$ sudo yum install tigervnc $ vncviewer 192.168.1.101:1
$ sudo yum install freerdp $ xfreerdp 192.168.1.101
Remote X connections have been out of fashion for many years, and the default is to not allow connections for security reasons. If you are running equipment in an isolated environment, you should feel safe doing this.
Many SuperMicro motherboards have IPMI features that have a dual-port feature. The first two Ethernet ports on the motherboard are capable of serving the IPMI function.
If the dedicated IPMI port is not cabled, IPMI will be served off the LAN1 port (which is predictably the MGT port on LANforge machines).
Turning off IPMI is often not possible, but turning off the IPMI port DHCP is possible. There are two ways of doing this, and you might not even need to reboot your server if your IPMI driver is included in the Linux distribution you are using.
You might have either the ipmiutils or the ipmitool package available, maybe both. Both are probably going to rely on the same drivers, however.
# install $ sudo yum install ipmiutil # show configuration $ sudo ipmiutil lan -c # disable the LAN feature (if desired) $ sudo ipmiutil lan -d # or set a fixed IP: $ ipmiutil lan -e -I 0.0.0.0
Setting the address of 0.0.0.0 sometimes is a shortcut for disabling the IPMI LAN features. Or you can set a normal non-routable address like 192.168.0.251. (Refer to this post.)
Similar commands are listed for IPMITool on this post. The “lan set 1” phrase refers to “IPMI Device 1.”
$ sudo ipmitool lan set 1 ipsrc static $ sudo ipmitool lan set 1 ipaddr 192.168.0.251 $ sudo ipmitool lan set 1 netmask 255.255.255.0 $ sudo ipmitool lan set 1 defgw ipaddr 192.168.0.1
We might have a motherboard that isn’t in the driver set for these tools. This is how you’d know:
In this scenario, we need to reboot and press DEL to get into the BIOS. You will likely never see two motherboards with exactly the same BIOS screen layout…but just look for IPMI and you’ll likely get to screens that look like this:
Advanced screen 
Advanced – IPMI Configuration
IPMI LAN Configuration
We can verify that this is the MAC address we’re seeing traffic from using tcpdump. Let’s also gather the MAC addresses because we’ll want those as a reference when looking at our tcpdump data.
Now we can craft a tcpdump that will show useful things:
tcpdump -eni eth1 \
ether host 00:25:90:01:66:0a \
or ether host 00:25:90:01:66:0b \
or ether host 00:25:90:01:8a:ef
And we’ll see results like this:
17:35:07.814819 00:25:90:01:8a:ef > Broadcast, ethertype IPv4 (0x0800), length 590: 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:25:90:01:8a:ef, length 548 17:35:10.874561 00:25:90:01:8a:ef > Broadcast, ethertype IPv4 (0x0800), length 590: 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:25:90:01:8a:ef, length 548 17:35:13.945135 00:25:90:01:8a:ef > Broadcast, ethertype IPv4 (0x0800), length 590: 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:25:90:01:8a:ef, length 548
Clearly, we’re getting getting DHCP broadcasts from that port. After setting the IPMI IP in the BIOS to 0.0.0.0, those broadcasts stop.
Network Testing and Emulation 