Pages

cli remote management of ESXi virtual machines over ssh

One of the ways to manage ESXi virtual machines is through vim-cmd commands. You can look at a quick tutorial of the command here.

Let's say there are a multitude of ESXi servers in your environment and you'd like to manage some virtual machines through cli.
One way to do this is to run vim-cmd commands over ssh. For example, I have 2 ESXis named in the example esxi1 and esxi2. On both of them I have one VM:
~$ ssh root@esxi1.localdomain "vim-cmd vmsvc/getallvms"
Vmid             Name                                         File                                  Guest OS       Version             Annotation
7      Linux                       [datastore1] Linux/Linux.vmx                                 debian6_64Guest    vmx-08

~$ ssh root@esxi2.localdomain "vim-cmd vmsvc/getallvms"
Password: 
Vmid           Name                                      File                                  Guest OS        Version             Annotation
13     VSRX                   [datastore1] VSRX/VSRX.vmx                                   otherGuest          vmx-09    VSRX OVF Template
So, this works fine and nice and actually there's nothing special about it. It's just running remote commands over ssh.

If you'd like to make things more easy, you can use ssh public key authentication for the remote esxi hosts (no need to type in the password every time you want to run a command).
I wrote some bash functions to make it even easier (to remember) and shorter to type.
This is what I have among other functions and things in my .bashrc file:
function start_vm () { ssh root@${1}.localdomain "vim-cmd vmsvc/power.on" "$2";}
function stop_vm () { ssh root@${1}.localdomain "vim-cmd vmsvc/power.off" "$2";}
function reboot_vm () { ssh root@${1}.localdomain "vim-cmd vmsvc/power.reboot" "$2";}
function getallvm () { ssh root@${1}.localdomain "vim-cmd vmsvc/getallvms" ;}
function powerstate_vm () { ssh root@${1}.localdomain "vim-cmd vmsvc/power.getstate" "$2";}
function getnetwrorks () { ssh root@${1}.localdomain "vim-cmd vmsvc/get.networks" "$2";}

How to remove Juniper ethernet encapsulation from pcap packet capture

When capturing packets on a Junos device, the output packet capture will include a Juniper ethernet header.
Example of such capture:


tcpdump -c1 -nvvr capture.pcap

reading from file JTAC.pcap, link-type JUNIPER_ETHER (Juniper Ethernet)

14:58:06.569634

 Juniper PCAP Flags [Ext], PCAP Extension(s) total length 16

   Device Media Type Extension TLV #3, length 1, value Ethernet (1)

   Logical Interface Encapsulation Extension TLV #6, length 1, value Ethernet (14)

   Device Interface Index Extension TLV #1, length 2, value 149

   Logical Interface Index Extension TLV #4, length 4, value 872

 -----original packet-----

     ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.128.123.19 tell 10.128.123.254, length 28

To remove this header we need to chop the pcap [-C]  (in my case the first 22 bytes) , adjust the frame length [-L] and specify that the new frame type [-T] (ethernet in my case). I am using editcap version 1.12.1 and the default output type for the new pcap is pcapng. As I can see there's a problem when converting with this output type, so I am using libpcap as the output type.


editcap -C22 -L -F libpcap -T ether capture.pcap cap_libpcap.pcap


As you can see the Juniper ethernet header is  gone.


tcpdump -c1 -nvvr cap_libpcap.pcap

reading from file cap_libpcap.pcap, link-type EN10MB (Ethernet)

14:58:06.569634 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.128.123.19 tell 10.128.123.254, length 28

Recovering corrupted gzip files. gzip: compressed_file.gz: unexpected end of file


A tool to recover gzip corrupted compressed files is gzrecover. This comes with in the recovery toolkit package gzrt.

$gzip -d compressed_file.gz
gzip: compressed_file.gz: unexpected end of file

$file compressed_file.gz
compressed_file.gz: gzip compressed data, from Unix

$gzrecover compressed_file.gz
$ls compressed_file*
compressed_file.gz compressed_file.recovered

ssh tunnels set up and port forwarding

SSH tunnels allow you to forward a local TCP port to a remote machine and vice versa. The tunnel option is available in many ssh clients. I will give the example here on how to create SSH tunnels with putty and the openssh-client.
I will consider in the below that we want to access the SERVER on port 80 (http server).

Scenario 1. SSH tunnel setup with local port forwarding.


The SSH tunnel is shown with the red arrow. In order to access the SERVER through the ssh tunnel the connection will have to be made on the CLIENT's local forwarded port (2000 in the example). The traffic between the CLIENT and SSH-HELPER is encrypted by ssh, the traffic between the SSH-HELPER and the SERVER is not encrypted.

SSH tunnel  is set up on the CLIENT:
openssh-client:

ssh -L *:2000:server:80 ssh-helper

The '*' before the local port to be forwarded 2000 denotes that the port 2000 should be listening on all available interfaces on the client. This goes according to the openssh-client configuration.
putty:

The tunnel configuration is done under Connection - SSH - Tunnels. Source port is the local port, destination is where the connection will be forwarded after exiting the SSH tunnel.
After you specify source port and destination, you need to click "Add" for the configuration to take effect.
If you want to access the remote server from other hosts, make sure you check the box  "Local ports accept connections from other hosts", otherwise the port 2000 will be opened only for the loopback address (127.0.0.1)

Linux gnome add menu and desktop entry for applications


Users can create shortcuts for an application to appear in menus, desktop,  etc. by creating a .desktop file. This desktop file contains a listings of configuration for the application. In order for your desktop environment to "see" this file, this .desktop file will have to be placed either in /usr/share/applications - for system wide applications - or in ~/.local/share/applications - if the application should be available for a single user

Once the file is placed in this location the desktop uses this file to:


  • put the application in the Main Menu
  • list the application in the Run Application... dialog
  • create appropriate launchers in the menu or on the desktop.
  • associate the name and description of the application.
  • use the appropriate icon.
  • recognize the MIME types it supports for opening files.
Here's an example of a desktop file I have created for tinyCA application. I am running Debian Jessie and this application does not come with a any menu entries or desktop shortcut.

$ cat ~/.local/share/applications/tinyca2.desktop

[Desktop Entry]
Version=1.0
Type=Application
Name=TinyCA Certificate Authority
NoDisplay=false
Categories=Network;
Icon=security-low
Exec=/usr/bin/tinyca2
Terminal=false
Comment=TinyCA2 certificate authority
The entries one by one:

[Desktop Entry] - identifies the group name to which the desktop entry belongs. A group is name is enclosed in [ ] and there can be more than one group in a desktop file. [Desktop Entry] group is required by the basic desktop file entry
Version - version of the desktop entry specification. This field is not required

Connect Evolution email client to Exchange office365 server

Evolution is a personal information management application that provides integrated mail, calendaring and address book functionality.
To connect to office365 exchange you will need the evolution program and the evolution-ews plugin.

Installation:
% sudo apt-get install evolution evolution-ews
Account setup:
1. Obtain the information about your domain's office365 servers.
To find the exchange web services URL based on the verified answer on this office365 post:
-Logon to your e-mail account using Outlook Web App (OWA).
-Click Options > See All Options > Account > My Account > Settings for POP, IMAP, and SMTP access.
-In the list of entries, locate the server name. And the URL of exchange web service for your mailbox is the URL: "https://" + "Server name" + "/EWS/Exchange.amsx".
So, in my case the Exchange Web Services URL is https://outlook.office365.com/EWS/Exchange.asmx

2. In the evolution wizard enter the details.

Installing Debian wheezy from USB over serial console


I wanted to install Debian wheezy on a machine without a video card and no CDROM. I had a 1GB USB and I tried initially the easy way, as described in https://www.debian.org/releases/stable/amd64/ch04s03.html.en#usb-copy-isohybrid by just copying the cd image to my /dev/sda (USB stick) but I did not got any output on the console. I copied the iso file to another linux machine, mounted it as a loop device, made modifications in the isolinux.cfg file to redirect everything on the console, by adding the kernel parameters to look like below and then recreated the iso file but that still did not output anything on the serial console.

 isolinux.cfg
serial 0 9600
default install
prompt 0
timeout 100
label install
  kernel install.amd/vmlinuz
  append console=ttyS0,9600n8 initrd=/install.amd/initrd.gz --quiet
So I gave this up quite easy, and I took another approach. What I did next I followed the flexible way, as described in the debian documentation, but with some changes: 1/ I set up 2 partitions on the USB disk (/dev/sda in this example), both FAT16 (e code in fdisk), both 500MB and set the bootable flag on /dev/sda1 2/ pretty much followed the documentation and setup fat16 on /dev/sda1 and /dev/sda2:
mkdosfs /dev/sda1
mkdosfs /dev/sda2
3/ I installed the MBR on /dev/sda
install-mbr /dev/sda
4/ Installed the syslinux bootloader on /dev/sda1
syslinux /dev/sda1
5/ Copy the kernel and the initial ram image on /dev/sda1. This is done by mounting /dev/sda1 on let's say /mnt and the copying from the netinst cd vmlinuz and initrd.gz from the folder install.amd/ to /mnt (where I have /dev/sda1 mounted). Then I have created the syslinux.cfg file on /mnt according to the documentation and added the entries:

How to identify top traffic speakers with wireshark conversations

Among other very useful and interesting things that wireshark can show in a packet capture, it can also display the top traffic conversations based on various criteria such as IP addresses, L2 ethernet addresses, IPv6 address or L4 information.

The conversation list is available from the Statistics -> Conversations menu.


Below an example taken showing the top bps rate (B->A direction) for the TCP protocol, where A and B are the endpoints identified by IP and TCP port number 

ssh keepalives and tcp keepalives in openssh

The SSH connection can be kept alive either with SSH keepalive packets (encrypted) or with TCP keepalive packets. This allows also to detect hanging sessions and disconnect the hanging client/server when a connection has become inactive.

On a open SSH server, to control the SSH keepalive packets the parameters are:
ClientAliveCountMax 3 (default)
ClientAliveInterval 0 (default) - means the SSH keepalive packets will not be sent by the server

Replaying packets with tcpreplay

Tcpreplay is a suite of tools that allows editing and replaying previously captured traffic in libpcap format. This can come handy in many situations, one common use is traffic pattern based behavior re-creation in a lab environment.
Tcpreplay suite comes with the following tools:
  • tcpprep - multi-pass pcap file pre-processor which determines packets as client or server and creates cache files used by tcpreplay and tcprewrite
  • tcprewrite - pcap file editor which rewrites TCP/IP and Layer 2 packet headers
  • tcpreplay - replays pcap files at arbitrary speeds onto the network
  • tcpliveplay - Replays network traffic stored in a pcap file on live networks using new TCP connections
  • tcpreplay-edit - replays; edits pcap files at arbitrary speeds onto the network
  • tcpbridge - bridge two network segments with the power of tcprewrite
  • tcpcapinfo - raw pcap file decoder and debugger
To exemplify the use of tcpreplay, let's say we have the following setup:
Now in this setup we're interested in how our DUT device (Device Under Test) is reacting given a specific traffic pattern that is let's say very specific to this environment. I will assume the DUT is a Layer 3 device.