Digi and Dialogic Re-install
Rebuild the Dialogic and Digi drivers after the update of a kernel (5x versions).
This has been tested and used at multiple sites and undergone revisions, but -- as with everything -- is
subject to change. All of these items will be performed as full root (not a simple su that retains your
original user's $PATH). Make sure you have access to items in /sbin such as init and service.
You should read through this at least twice and pretend that you're doing the steps as you go in order to
become familiar with the steps. Although this was originally written in Microsoft Word, autocorrect and
autoformat have been turned off. The commands listed are able to be copied and pasted to a terminal
window without special characters coming through. It is assumed that the reader knows how to
perform basic commands, such as becoming root, copying files from one location to another, reading
command output, and so on.
Check the yum repo file(s) in advance and make sure that they're pointing to spokupdate.spok.com.
Make sure a "yum check-update" can connect and list updates. If it can't (and the server isn't blocked by
the customer's network policies), you may need to wait a few days.
CD000000384.iso contains the Dialogic installation software and needs to be uploaded in advance.
The upload process can take quite a long time, so do this well in advance of your planned rebuild, but not so
long as will set off the disk space alarms for days or weeks on end until it's removed. Put this in /u06/ISO.
If you put it somewhere else, change the mount command below accordingly.
Ensure that the servers to which you are re-applying drivers have enough free space to complete your
tasks. This is especially important for the ISO that contains the Dialogic drivers, which is 1.7G. You may
even find this ISO still on the servers sometimes in various locations, such as /home/amcom/PC, /isos,
<some person's name or initials>/ISOs, or any of various other names.
This document contains instructions for both Digi RealPort (dgrp) and Dialogic drivers. If you are using
this with a server that only has dgrp, skip the Dialogic items. If the server only has Dialogic, skip the dgrp
items. If it has neither, don't worry about it.
You should do the first section ("Prepare the Server for Reboot") before the kernel is updated, but if the
server has already been rebooted into the new kernel and Dialogic / Digi services are having issues, the
steps are the same.
### PREPARE THE SERVER FOR REBOOT ###
# Become root.
# Save the current date to a file (in root's home, it can get cleared if it's put in /tmp)
# in case the start-to-end range of these tasks crosses midnight.
export DATE=$( date '+%Y%m%d' )
echo ${DATE} > /root/rbdate
# Make a backup of the inittab and prepare one with the processes turned off.
\cp -a /etc/inittab /etc/inittab.${DATE}.on
\cp -a /etc/inittab /etc/inittab.${DATE}.off
# Set processes to off in our new .off file.
# TAP
sed -i "/tap_out/ s/respawn/off/" /etc/inittab.${DATE}.off
sed -i "/tap_in/ s/respawn/off/" /etc/inittab.${DATE}.off
# TNPP
sed -i "/tnpp_out/ s/respawn/off/" /etc/inittab.${DATE}.off
# VRU
# ( At the time of this writing, covers analog meet me, ucs, and main.
# If the server has a T1 card (channels B1T1, B1T2, etc; main_PRI.set
# for example), you will have to change those lines to "off" manually
# for now. You may want to double-check your inittab anyway since
# someone can call these .set files anything they want. This just
# handles the default. )
sed -i "/analog.set/ s/respawn/off/" /etc/inittab.${DATE}.off
# Other items that some sites may have:
sed -i "/music.set/ s/respawn/off/" /etc/inittab.${DATE}.off
sed -i "/voxmon2.set/ s/respawn/off/" /etc/inittab.${DATE}.off
sed -i "/net2q.set/ s/respawn/off/" /etc/inittab.${DATE}.off
# *** As stated above, you may have to check the inittab to see if there are other vru related processes,
# (for example, test lines or VAT channels that don't have the word "analog" in the set file). If the site
# has just T1 cards, then those would have to be done manually. This would also be a good time to see
# if there are any typographical errors (or "typos") in the inittab file (such as "resapwn" or "repsawn", and fix those.
# *** Why not do all paging processes? One certainly could, but only the dgrp and Dialogic drivers are
# affected by a kernel rebuild, so we don't "need" to turn off the network-based paging such as smtp
# and wctp. Don't do a global change of "respawn" to "off", or you'll end up changing the mingetty lines
# to "off" and won't be able to get back in to the server easily.
# Copy the "off" file to the main and init.
\cp -a /etc/inittab.${DATE}.off /etc/inittab
init Q
# *** Why init Q? telinit is softlinked to init. These are the same commands. q and Q are listed in the
# man page as equivalent. However, q is next to 1 on the keyboard! init 1 sets the server into single-
# user mode. init ! does nothing but print the usage syntax. Don't use init q. It has too much potential
# for things to go the way you don't want.
# If there is no VRU present, there may be ssp; If there is ssp but it's SIP based and not Dialogic,
# then you don't need to turn this off.
# You should know by this point how to tell if it's SIP or Dialogic, and the explanation is not within
# the scope of this document, so if you don't know, ask someone and do whatever you have to in order to
# remember it.
# Turn off sspd_agent and prevent the service from starting on boot.
service sspd_agent stop chkconfig --del sspd_agent
# Turn off dgrp and prevent the service from starting on boot.
service dgrp_ditty stop service dgrp_daemon stop chkconfig --del dgrp_ditty chkconfig --del dgrp_daemon
# Turn off Dialogic and prevent the service from starting on boot.
service ct_intel stop chkconfig --del ct_intel
# Copy the Dialogic and dgrp files.
export FOLDER=/u06/updates/${DATE}
mkdir -p ${FOLDER}/dialogic
cd /usr/dialogic
\cp -ar cfg ${FOLDER}/dialogic
\cp -ar data ${FOLDER}/dialogic
\cp -a /etc/dgrp.backing.store ${FOLDER}
# *** You shouldn't "need" the "data" folder above for sites with analog cards, but we want to
# make sure we have the files just in case. Copy the whole data folder, as the customer may have
# a customized parameter file (.prm) or a different one set in the dialogic.cfg than you expect
# (which may also be customized).
##### UPDATE THE KERNEL #####
# Update the kernel if it isn't already.
yum -y update kernel* --enablerepo=kernel
# *** The "update" option and "--enablerepo" flag / option are separate commands. If you skip the
# "kernel*" above, this will do both an update of everything in the main repository and the now-enabled
# (for this command run only) kernel repository. Ideally there should be no other updates pending,
# but if there are 5, 10, 50, 100... you will lose the time allotted to your update window waiting for these
# to finish. Items on which the kernel is dependent (and aren't updated) will update and install at
# this time; otherwise, the pending updates will download and install on their own as part of the
# normally running process, so don't worry about those.
##### REBOOT #####
# Boot into the new kernel.
reboot
# *** When installing a new kernel on a virtual machine, the server-image may fail to gain an IP address
# and VMWare Tools may fail to start. A server with a Dialogic card will not be virtual, but a VM may
# have dgrp installed (or not, but the purpose of this document is reinstallation of dgrp and Dialogic),
# so this situation might present itself. Like the Digi and Dialogic drivers, the drivers for vmtools are
# installed at the kernel level. The customer should be prepared to reinstall vmtools for the
# server-image. The following are instructions from vmware (2016).
# To reconfigure VMware Tools:
# Log in to the Linux virtual machine as the root user.
# Run the command:
/usr/bin/vmware-config-tools.pl
# Note: On ESXi 5.1 and later, selecting Yes at the prompt below will enable an automatic
# feature in VMware Tools that will search and install VMware kernel modules at the time
# of boot. This allows VMware Tools to install missing modules if there is a kernel upgrade
# or change:
# > VMware automatic kernel modules enables automatic building and
# > installation of VMware kernel modules at boot that are not already
# > present. This feature can be enabled/disabled by re-running vmware-config-tools.pl.
# > Would you like to enable VMware automatic kernel modules?
# *** At this point you have the new kernel loaded. This means that the drivers for the Dialogic and Digi
# products need to be reinstalled.
# Become root.
# Recreate the variables.
export DATE=$( cat /root/rbdate )
export FOLDER=/u06/updates/${DATE}
### DIGI REALPORT REINSTALL ###
# *** Re-install the Digi software via the following steps.
# Remove the dgrp drivers and reinstall.
rpm -e dgrp
cd /opt/amcom/staging
sh ./install-dgrp.sh
diff /etc/dgrp.backing.store ${FOLDER}/dgrp.backing.store
# *** The dgrp.backing.store files generally always match, but on the off-chance they don't,
# copy the copied file back to the real location.
# *** If the server has no Dialogic boards, skip the next part and go to the
# RE-ENABLE SERVICES AND PROCESSES section; however, if you disabled ssp before, re-enable it.
########################################
### DIALOGIC REINSTALL ###
# *** Re-install the Dialogic software via the following steps.
# Remove Dialogic packages.
/usr/dialogic/bin/dlguninstall.sh --silent
# *** The --backup option creates a tar.gz file in /tmp, but usually only has the rtflog files and a very few
# configuration files. We've backed everything up ourselves above, so we don't need to use this option.
# Remove the following so that the install creates the correct files when running a few steps from now.
\rm -r /usr/src/LiS \rm -r /usr/src/dialogic327
# Mount the image.
mount -t iso9660 -o ro,loop /u06/ISO/CD000000384.iso /media/cdrom
# *** "Why do I have to type this out? Doesn't the install script do this for me?"
# Well, first of all, you can just copy & paste. But to answer the question, no.
# The "mount" in the script doesn't pass the disc location.
# Install the software.
cd /opt/amcom/staging sh install-dialogic.sh 327
# *** Why take the extra step of cd'ing? Why not just run the file from the whole path? The script itself
# checks for specific files in the staging directory but references them as dot. So it will fail if you don't
# run it from that directory.
# *** Why "327"? 327 is the DIALOGIC_BUILD variable in the script which calls the following tgz file:
# ${CDROM_PATH}/lnx${DIALOGIC_VER}su_${DIALOGIC_BUILD}.tgz
# *** No need to umount the drive, the install script above did that for us.
# The Dialogic installation re-added the ct_intel service. We don't really want that started right
# away on the next boot, so disable it again.
chkconfig --del ct_intel
##### REBOOT #####
# Reboot so that the new changes are loaded.
reboot
# *** Now configure Dialogic and copy the files back from before.
# Become root.
# Recreate the variables.
export DATE=$( cat /root/rbdate )
export FOLDER=/u06/updates/${DATE}
# Configure Dialogic.
cd /usr/dialogic/bin ./config.sh
Follow these directions:
# Press "2" for Dialogic(R) Board Summary # At the Board Summary screen, verify the Thumb Wheel number of each board, # the status (should be C), and the board type. # Type "x" and press enter. # At the "Configuration is now complete" screen, press <enter>.
# Copy back Dialogic files.
\cp -ar ${FOLDER}/dialogic/cfg /usr/dialogic
\cp -ar ${FOLDER}/dialogic/data /usr/dialogic
# Source the environment configuration file.
. /etc/profile.d/ct_intel.sh
# Add back in Dialogic service and start. Make sure there are no errors when this service starts!
chkconfig --add ct_intel service ct_intel start
# Add back in the sspd_agent service if you had to remove it before.
chkconfig --add sspd_agent service sspd_agent start
### RE-ENABLE SERVICES AND PROCESSES ###
# If the server is using SIP for ssp and not Dialogic and you removed the sspd_agent service before,
# add back in the sspd_agent service. If you did this in the step directly above, don't do it again.
chkconfig --add sspd_agent service sspd_agent start
# *** The install-dgrp script already added the dgrp services back to the chkconfig list for you.
# Start the dgrp services (they may already be started from the earlier install).
# Make sure there are no errors when these services start!
service dgrp_daemon start service dgrp_ditty start
# Turn on the items you turned off at the beginning.
\cp -a /etc/inittab.${DATE}.on /etc/inittab
init Q
# Remove our date file.
\rm /root/rbdate
# The processes are now back on. You can watch the debug files in /home/amcom/debug (or ssp logs in
# /var/log/ssp/ssp and /var/log/ssp/ssp/vxi) and test the traffic at this point. If you really want to make
# a completely valid test of this...
reboot
# *** Are we done? As far as rebuilding the drivers, yes. But the older items and backups made of the
# inittab with the current date have been copied into the ${FOLDER} location (/u06/updates) for
# safe-keeping. Also, you may not want to keep the "data" folder in this location, especially if using
# analog lines.
#
# The customer should consider how much of this they want to keep and for how long they want to
# keep the files in these folders. Clean up as required.