Create a Cisco CSM systemd Startup Service on Linux

If you are using Cisco's new linux-based Cisco Software Manager server, then you probably want to make sure there is a startup service for it. In this post, I'm going to focus on a systemd solution, not the older init system.

I'll assume that you've already installed the CSM server. For purposes of this post, I'll use /usr/local as it's location.

Getting started

If you're using a python virtual environment, then you'll need to explicitly tell the CSM server where your environment's python interpreter and gunicorn executable are. If anyone knows how to create the systemd service without having to do this, please share - because my attempts failed. If you aren't using a python virtual environment, you can skip to the next section where we create the systemd service.

 - Open /usr/local/csm/csmserver/csmserver in your editor.
 - Change the following line to include the absolute path to python in your virtual environment. Don't close the file yet.
# for Python interpreter
PYTHON="/usr/local/csm/csmserver/env/bin/python"
 - Within the same file, add a variable for gunicorn in the appropriate section. Don't close the file yet.
# for gunicorn
GUNICORN="/usr/local/csm/csmserver/env/bin/gunicorn"
 - In the 'function start_csmserver' and 'function start_secure_csmserver' sections, change each instance of 'gunicorn' to '$GUNICORN', to match our newly created variable. Then save and close the csmserver file.
$GUNICORN -w $WORKERS -b $LISTENING_IP:$PORT --timeout $TIMEOUT --log-file=- csmserver:app & $PYTHON csmdispatcher.py &

$GUNICORN -w $WORKERS -b $LISTENING_IP:$PORT --timeout $TIMEOUT --log-file=- --keyfile=$SSLKEY --certfile=$SSLCERT  csmserver:app & $PYTHON csmdispatcher.py &


Creating the systemd service

 - Create a new file in /usr/lib/systemd/system called csm.service
vi /usr/lib/systemd/system/csm.service

 - Add the following to the file. Save and close the file. Be sure to use the correct path, if different from /usr/local.
[Unit]
Description="Cisco Software Manager"

[Service]
WorkingDirectory=/usr/local/csm/csmserver
RemainAfterExit=yes
ExecStart=/usr/local/csm/csmserver/csmserver start
ExecStop=/usr/local/csm/csmserver/csmserver stop

[Install]
WantedBy=multi-user.target

 - Reload the systemd daemon and set the service to start at boot
systemctl daemon-reload
systemctl enable csm.service

 - Start the service. Be sure to verify that the service is active and that you can see the gunicorn and csmdispatcher.py processes.
systemctl start csm.service
systemctl status csm.service

Keep in mind that if you upgrade your CSM server in the future and you use a Python virtual environment, you'll need to go back in to the csmserver file and re-add the appropriate lines.

That should be all you need to create your systemd service for the Cisco Software Manager server!

CMD Windows Telnet Not Recognzied As Internal External Command

When you try to run telnet from a command prompt, it says 'telnet is not recognized as an internal or external command'.

If you're in a hurry to get this resolved: chances are you have this problem because you're trying to run telnet.exe from a 32bit version of cmd; or you haven't enabled telnet from the Add/Remove Windows Features in Control Panel. I'm going to focus on the first case.

Telnet (among other programs) can only be run from cmd when cmd is running in 64bit mode. You can start cmd in 64bit mode by doing a search (Window+Q, Window+R, or possibly Window+S). If you're using another program to start cmd or telnet, you need to make sure the program you run cmd or telnet from is 64bit.



I recently ran across a situation where I needed to use the Windows telnet client. As of right now, I'm using Windows 10. To make a long story short, the device I was trying to connect to didn't like Putty's telnet client, and it was causing issues.

Windows Telnet to the rescue... or so I thought. I already had the client installed, but for some reason when I ran telnet from cmd, it was saying that telnet is not recognized as an internal or external command.

When I did a directory listing inside of C:\windows\system32 from cmd, it wouldn't even list telnet.exe, even though I could see it in the windows explorer gui.

Every once in a while, I could get the telnet program to execute. After some troubleshooting, I realized that the only time it would run is when the cmd program was running in 64bit mode.

Now, my particular situation was that I was trying to run the telnet client via Bayden's Slickrun program (which is an excellent launcher program that you should check out). Sure enough, I had installed the 32bit version of SlickRun, not 64bit. So, when I was trying to run cmd or telnet from SlickRun, it was opening the 32bit version of cmd and erroring out.

If cmd is executed from a 64bit program, it'll run cmd in 64bit mode, otherwise it runs in 32bit mode...and you can't execute a lot of commands...including telnet.exe

In my case, I simply downloaded the 64bit version of SlickRun.

Hopefully this puts you on the right path to getting this resolved!

Creating an Ookla Netgauge systemd Startup Service on Linux

##########

UPDATE - 9/8/2017
If using the newer ooklaserver.sh installer (instead of netgauge_ooklaserver_install.sh), then make sure your ookla.service file has the following in the proper place.

[Service]
ExecStart=/usr/local/ookla/ooklaserver.sh start
ExecStop=/usr/local/ookla/ooklaserver.sh stop
PIDFile=/root/ookla/OoklaServer.pid

You can find out more about using the newer installer here:
https://support.ookla.com/hc/en-us/articles/234578528

#########


I recently installed Ookla's Netgauge product on CentOS 7, only to find out that the install doesn't create a systemd service and therefore the Ookla server daemon won't start at boot either.

Here are the easy steps you can take to fix the issue:

cd into your install directory. For me this is /usr/local/ookla

cd /usr/local/ookla
Now we need to change a few things within the netgauge_ooklaserver_install.sh script that is also used to start, stop and restart the daemon. Obviously, you can use your favorite editor; I'll stick with vi.

vi netgauge_ooklaserver_install.sh
At the top of the file, underneath the existing variables, add this one with the path to the install dir. (Note, there's already an INSTALL_DIR variable. If you'd like to just use that, rather than create a completely new one, then that's up to you. Just keep in mind that you'll need to use $INSTALL_DIR instead of $DIR_FULL, for the rest of these steps)

DIR_FULL="/usr/local/ookla"
Find the 'goto_speedtest_folder()' section and comment out the 'dir_full=`pwd`' variable, since we've already declared it up above. You will also need to find and replace $dir_full with $DIR_FULL on the next line.

goto_speedtest_folder() {
# determine if base install folder exists
#dir_full=`pwd`
dir_base=`basename $DIR_FULL`
Find the 'stop_if_running()' and 'start_if_not_running()' sections and add $DIR_FULL/ in front of every place that $PID_FILE exists. There should only be two in each section.

stop_if_running() {
if [ -f "$DIR_FULL/$PID_FILE" ]; then
daemon_pid=`cat $DIR_FULL/$PID_FILE`
start_if_not_running() {
if [ -f "$DIR_FULL/$PID_FILE" ]; then
daemon_pid=`cat $DIR_FULL/$PID_FILE`
Find the 'start()' section and add $DIR_FULL/ in front of every place that $PID_FILE and $DAEMON_FILE exists. There should be seven places where this needs changed. The only time you shouldn't be doing this is where the variable is part of a printf command. Also comment out the existing $dir_full=`pwd` line as we did above.

The additions will look like this after you're done:

"$DIR_FULL/$PID_FILE"
"$DIR_FULL/$DAEMON_FILE"
However, you won't be changing lines that start like this:

printf "Starting $DAEMON_FILE"
Now save the file.

Next we'll need to create the ookla service. cd to the /usr/lib/systemd/system directory and create the file.

cd /usr/lib/systemd/system
vi ookla.service
Now put this code into the file:

[Unit]
Description="OoklaServer"

[Service]
ExecStart=/usr/local/ookla/netgauge_ooklaserver_install.sh start
ExecStop=/usr/local/ookla/netgauge_ooklaserver_install.sh stop
PIDFile=/usr/local/ookla/OoklaServer.pid

[Install]
WantedBy=multi-user.target
Save the file and restart the systemd daemon.
systemd daemon-reload
To start the service at boot, type:

systemctl enable ookla
Now try to start the service.

systemctl start ookla
Now query the status of the ookla service:

systemctl status ookla
You should see something similar to the following. Notice that the 'Loaded' line says 'enabled', meaning that it is set to start on boot and ensure that it is running and active.

ookla.service - "OoklaServer"
Loaded: loaded (/usr/lib/systemd/system/ookla.service; enabled)
Active: active (running) since Tue 2015-08-18 14:39:22 EDT; 4s ago
Process: 4069 ExecStop=/usr/local/ookla/netgauge_ooklaserver_install.sh stop (code=exited, status=0/SUCCESS)
Main PID: 4123 (OoklaServer)
CGroup: /system.slice/ookla.service
ââ4123 ./usr/local/ookla/OoklaServer --daemon --pidfile=/usr/local/ookla/OoklaServer.pid

Aug 18 14:39:22 localhost systemd[1]: Starting "OoklaServer"...
Aug 18 14:39:22 localhost systemd[1]: Started "OoklaServer".
Aug 18 14:39:23 localhost netgauge_ooklaserver_install.sh[4120]: Starting OoklaServer
Aug 18 14:39:23 localhost netgauge_ooklaserver_install.sh[4120]: Daemon Started (4123)

CentOS 7 Teaming with VLANS

I'm not a Linux guru, but I wanted to share my experience (aka trouble) with implementing Linux Teaming for the first time. I'll also throw in some VLAN configuration on top of it.

After a quick Google search, I started off here. Seemed easy enough. Just like bonding (which I've done before), with some different statements in the ifcfg files.

Trouble was, it wasn't coming up correctly. The physical interfaces weren't being added to the team. After hours of troubleshooting, I decided to remove the line 'TYPE=ETHERNET' in the ifcfg-em1 and em2 files. Apparently it was conflicting with the 'DEVICETYPE=TeamPort' line; because after the change, the team and it's ports came up as expected!

Here are some quick config steps.

First, let's install teamd.

yum install teamd
Second, I'm not a big fan of NetworkManager, so let's remove it (or just disable if you'd like).

yum remove NetworkManager
OR

systemctl stop NetworkManager.service
systemctl disable NetworkManager.service
The VLAN module should be loaded by default, but you can double-check with the following command.

modprobe --first-time 8021q
And you should get this output:

modprobe: ERROR: could not insert '8021q': Module already in kernel
Now let's configure the main team interface. In our overall config, each vlan will have it's own IP address, so we don't configure any IP addresses on this interface. Obviously replace 'lacp' with whatever load-sharing/redundancy method you'll be using. Some people like to add "link_watch":{"name":"ethtool"} to the config as well; but that is the default, so we'll leave it out. Since we're doing lacp, ethtool is our only linkwatcher option anyway.

cd /etc/sysconfig/network-scripts
vi ifcfg-team0
DEVICE=team0
DEVICETYPE=Team
TEAM_CONFIG='{"runner":{"name":"lacp"}}'
ONBOOT=yes
BOOTPROTO=none
Let's configure each of the physical interfaces that will be used in the team. Remember, this is where we need to remove any line that says 'TYPE=ETHERNET'. The 'ONBOOT' parameter can be 'no'; as the main team0 interface will bring these ports up automatically.

vi ifcfg-interface

DEVICETYPE=TeamPort
TEAM_MASTER=team0
BOOTPROTO=none
ONBOOT=no
Now let's get each of the VLAN interfaces configured.

vi ifcfg-team0.vlan-id

DEVICE=team0.vlan-id
IPADDR=ip-address
NETMASK=subnet-mask
ONBOOT=static
VLAN=yes
Finally, restart the network. If this command throws an error, then just do a server reboot.

systemctl restart network
After networking is restarted, you can verify that the ports were successfully added to the team by using either of these commands:

teamnl team0 ports
teamdctl team0 state view