Quick Config: Install ClamAV & configure a daily scan on CentOS 6

I’m pretty well versed in the ways of Anti-Virus in Windows but I’ve wanted to get an AV engine installed on my Linux boxes for a while now. In looking around I’ve found a tried and true option in ClamAV and after a few stops and starts was able to get something usable. I’d still like to figure out how to have it send me a report by e-mail if it finds something but that’s for another day; I don’t have enough Linux in my environment to necessitate me putting the time in for that.

So with that here’s how to quickly get started.

Step 0: If not already there, install the EPEL repository

Step 1: Install ClamAV

Step 2: Perform the 1st update of ClamAV definitions (this will happen daily by default afterwards)

Step 3: Enable and Start Services

Step 4: Configure Daily Cron Job

I chose to have it scan the whole system and only report infected files, you may want to do differently

Enter the following:

Note the -i option tells it to only return infected files, the -r tells it to recursively search. You may want to add the –remove option as well to remove files that are seen as infected.

Step 6: Make Cron Job Executable

You can then kick of a manual scan if you’d like using

That’s it! pretty simple and all of your output will be logged daily to the /var/log/clamav/daily_clamscan.log file for review.

3 steps to really reset a Cisco 7900 Phone

Recently had some issues with one of our phones at the office and you know how it goes, reboot it. What you may not know is that there are different levels of “reboot” for the 7900 series phones, each of which are a little more pervasive. In this post I’ll outline how to go about performing these 3 ways to reset your desk phone to cure what may or may not be ailing you.

I. The Simple Reset

Sure you could go into ccmadmin and hit the reset button but that doesn’t work as well if you are standing right in front of it.  A quick reset can be performed by doing the following directly from the device

  1. Hit the settings button on the device
  2. Hit **#** on the keypad
  3. You should then see the screen display the “Resetting…” message followed by a reboot

II. Configuration Erase

When you boot your 7900 series IP phone as part of the boot sequence it reaches out to your Publisher’s TFTP server to grab a copy of either its specific configuration file or if none exist the default configuration file. Once this occurs it is stored locally to allow for quicker subsequent reboots. From time to time this locally cached copy will get gummed up and it is necessary to erase it and have it download a fresh copy. To do this the steps are

  1. Hit the settings button on the device
  2. Hit the **# buttons in order, afterwards you will see “Settings Unlocked!” display on the screen and a “More” soft button appear on the screen
  3. Hit the “More” soft button followed by the “Erase” soft button.
  4. You should then see the screen display the “Resetting…” message followed by a reboot

III. Factory Reset

This is the big daddy, if neither of the previous fixes worked then this process will erase not only the configuration but any firmware updates you have pushed to it as well, resulting in a phone as fresh as when it left the factory from a software perspective. To perform this process do the following steps:

  1. Unplug the power cable and/or the switch cable if using PoE
  2. Plug the device back in, pressing and holding the “#” key before the Speaker button flashes on and off
  3. Continue to hold the # button until each line button flashes on and off in sequence (amber).
  4. Next release the # and in order hit 123456789*0#
  5. After the sequence is done correctly the line buttons will flash red and then the phone will reboot.
  6. The phone will go through multiple reboot processes as various firmware loads and configuration files are downloaded.
  7. Do not remove power in any way until the reset process is completed in its entirety. You will know that this is done when the phone either correctly registers to CUCM or display the “Registering…” message on the screen.

That’s it, if you’ve made it this far without fixing your issue then you either need to get back in CUCM and check you configurations of the device or contact TAC for a replacement device.

Unsupported Configuration when using VUM for a Major Upgrade

I’ve recently been working on getting my environment upgraded from vSphere 5.1 to 5.5. Last week I replaced one vCenter server with a clean install and upgraded another, in process implementing home brewed certificates thanks in no small part to Derek Seaman’s excellent SSL toolkit and tutorials. With that done and nice and clean this week I turned towards getting the ESX hosts updated. Like all right thinking folks, I typically like to use vSphere Update Manager for this task in a vCenter supported environment.

The first host went very well and was up and patched without issue. After that the wheels fell off for the other two. I was continuously getting “Unsupported configuration” when I would try to scan the host, if I tried to push through and Remediate it would fail with “Software or system configuration of host <hostnamehere> is incompatible. Check scan results for details.” Nice error messages right? I tried a few things, reinstalling the management agents via VMware KB 1031919, rebooting the host, etc. After no luck there I logged a case with VMware where we began trying to find more information in the vua.log and verifying the correct fdm agent is installed via the esxcli software vib list | grep fdm command. In the end we were able to find my issue but I’ll be honest the documentation and logging in this scenario is pretty bad.

When Veeam Backup & Replication creates a vPowerNFS share, mounting your backup datastore as an addressable datastore to your host that is added in at least one way as a series of lines in the /etc/vmware/esx.conf file as shown below:

 

tasks-and-events-outputThis is great except as I’ve moved from Veeam server to Veeam server with different names and I dismounted and removed the different datastores from the hosts the old lines of config weren’t removed from esx.conf.  Further after finally seeing the “Error in ESX configuration file (esx.conf)” we got lead down the rabbit hole of the preprocessing of a VUM upgrade. Evidently one of the first steps (at the 12% mark of the remediate task in my case) is to run a variant of the esxcfg-info CLI command which in my case was producing this:

scan-afterwhere backupserver.domain.local was the name of an old Veeam server we had used. When the unfiltered esxcfg-info command it would begin listing but would eventually bomb with the same error.

After seeing the command output I opened up the esx.conf file with vi, found the offending lines of configuration and removed them. After saving the file I was able to scan the host again and the scan reported the host as being non-compliant instead of incompatible, just what we were looking for.  A remediation then was successful and I was back in business. One item of note if you find yourself wanting to try this yourself is make sure you take a backup of the esx.conf file as a miss step here could result in production datastore being unavailable. For those not too familar with Linux style commands you can do this easily with

original-errorConclusion

In the end what I do know is that the act of adding a NFS datastore to an ESX host and then later removing it both from ESXi configuration as well as the underlying DNS zone is what caused the blocking of my upgrade. Now what I don’t know if this is due to it being programmatically added by Veeam and then manually removed at a later date or if this is a situation that is common to the use of NFS datastores in general.  More importantly, it would be great if VMware would work on how it is reporting such configuration issues. Even taking me out of the equation, if it takes your own Support Engineer 1.5 hours to track it down it isn’t documented enough.

Updating the Code of a ipbase Licensed Cisco Catalyst 3750X Switch Stack

Here in the office the Access Layer of our switching infrastructure is handled completely with a 7 unit stack of Cisco 3750X switches.  There is no need for these to do any routing other than intervlan so when purchased 3 years ago we just ordered the IP Base licensing level.  Well from what I can tell there is a universal code base and a licensed feature level of each code revision.  The universal naming convention looks like c3750e-universalk9-mz.122-55.SE1 while the ipbase looks like  c3750e-ipbasek9-mz.150-2.SE6.  What I found is that I do not have the ability to download the universal code of later releases due to my licensing level and possibly the lack of SmartNet I keep on these, but I do have access to the ipbase code.  When attempting to update the code on this stack I was presented with the error


After some searching I found reference to others trying to go from IP Base to Advanced IP Services code having to put the /allow-feature-upgrade switch on the archive download-sw code in order to allow the upgrade as well as it seems a downgrade.  Evidently this feature came about with IOS version 12.2(35).  Now the upgrade progressed and I have happy little upgrades switches.


Another note about this upgrade I found in the official release notes is any upgrade from 15.0(2)SE to later will result in a microcode upgrade which when unmitigated will lead to an exceptionally long restart of the switch.  You can mitigate this either by using the /force-ucode-reload parameter when downloading the code to the devices or by using the archive download-sw /upgrade-ucode privileged EXEC mode command afterwards.

Allowing Supervisors to Modify Skill Levels in UCCX 9

Since we installed Cisco’s Call Manager Express call center system a couple of years ago I could set my watch by the requests from our group of supervisors to modify the skill level of our various agents for the various Customer Service Queues (CSQs).  Generally at the same time they will request access to do this themselves.  Imagine my excitement when UCCX 9 was released and one of the features was a mobile browser application called, creatively, Mobile Skill Manager to do just that.  Further you can imagine my chagrin when after upgrading we quickly realized that the app doesn’t work particularly well at this point, either in a mobile browser or through any of the major standard browsers.

So to twitter I went trying to find a way to make this happen and lo and behold I found the answer within the System Parameters of UCCX.  Start by logging into the web interface and look in System> System Parameters.  Then under the Application Parameters section you will find an option called “Supervisor Access.”  By default this will be set to No Access to Teams, and if you want to provide access you will need to choose one of the other two options depending on  your need, Access to All Teams or Access to Supervisor’s Teams only.  For us we chose the former because we are a relatively small call center where all the Supervisors cross train.

uccx9-after-screenshotSo what does this do?  Changing this setting allows Supervisors access to a subset of the menu when they log in with their own credentials at the /appadmin web link, specifically it allwos them access to the RmCm Subsystem which controls the various settings related to CSQs, Resources (Agents), and Skills.  You may want to provide this access with a little guidance because with this they will be able to create and delete CSQs, Skills and Resources as well and most likely you won’t want them to do this.

While I am happy to have this option, I believe we can do it better.  In a perfect world this the base functionality would be built into the Supervisor Desktop application or the new Finesse web interface, with a capability to turn access on and off.  Further I’ve heard tale of an IP service application being developed by CTI Logic to allow desktop phone access to perform this task.  Both of those would be extremely nice to have as less interfaces for the user to know is always a good thing.