Using yum to download a package and all it's associated dependencies

This tutorial will demonstrate how to do a download-only of a package and all of it's dependancies.

To elaborate - I recently installed Fedora 29 on a Macbook, but unfortunately there was no native support for the WLAN driver.

However it was available from RPMFusion - packaged under 'akmod-wl' - however downloading this and all of it's dependancies would have taken a long time - so instead we can use plugin for yum called 'yum-downloadonly':

yum install yum-downloadonly

We can then issue something like follows to download the required packages on a working computer which is running Fedora 29 (though ensure it is running exactly the same minor version as well!):

sudo yum install --downloadonly --downloaddir=/tmp akmod-wl

However this is not ideal largely due to the fact that it will download all required packages that the system needs. If some of these packages are already installed on the system they will be omitted.

So instead I came up with the idea of quickly building a jail with the basic packages to get yum up and running (this would mimic the newly installed OS):

mkdir -p /chroot/fedora29/var/lib/rpm

rpm --root /chroot/fedora29 --initdb

yumdownloader --destdir=/var/tmp fedora-release
cd /var/tmp
rpm --root /chroot/fedora29 -ivh --nodeps fedora-release*rpm

sudo yum install --installroot=/chroot/fedora29 --downloadonly --downloaddir=/tmp akmod-wl

Then copy everything from the temp folder onto the new workstation and issue:

rpm -i *

Generating a new UUID for XFS/EXT2/3/4 filesystems

Although very rare there will be circumstances were you encounter duplicate filesystem UUIDs.

Upon mounting one e.g.:

mount -t auto /dev/sdb1

mount: wrong fs type, bad option, bad superblock on /dev/sdb1

Tailing dmesg provides the clue as to what has gone wrong:

[ 1103.580854] XFS (xvdp1): Filesystem has duplicate UUID xxxxxx-yyyyyy-zzzzz-aaaa-bbbbbbbbbbb - can't mount

So we'll need to change the UUID of one of disks - to do this with an XFS filesystem we can use:

xfs_admin -U generate /dev/sdb1

and with the EXT family we can use:

uuidgen

<generated UUID>

tune2fs /dev/xvdp1 -U <generated UUID>

Finally attempt to remount:

mount -t auto /dev/sdb1

Checking switch port bandwidth utilisation with SNMP / Nagios

In order to monitor port bandwidth utilization on Cisco switches via SNMP we'll firstly need to install a plugin from the Nagios Exchange called 'iftraffic2':

Download and install the plugin:

cd /usr/local/nagios/libexec
curl https://exchange.nagios.org/components/com_mtree/attachment.php?link_id=1720&cf_id=24 -O check_iftraffic
chmod +x check_iftraffic

The usage for the plugin is as follows:

./check_iftraffic -H <hostname> -C <community-string> -r -i <interface-name> -b <interface-capacity> -u <interface-unit> -w <warning-limit-percentage> -c <critical-limit-percentage>

We'll need to obtain the interface name of the interface we wish to poll - we can use snmpwalk to do this for us:

yum -y install net-snmp-utils
snmpwalk -v 2c -c <community-string> <hostname> 1.3.6.1.2.1.2.2.1.2

> IF-MIB::ifDescr.67 = STRING: Port-channel1
> IF-MIB::ifDescr.68 = STRING: Port-channel2
> IF-MIB::ifDescr.69 = STRING: Port-channel3
> IF-MIB::ifDescr.70 = STRING: Port-channel4
...

Note: '1.3.6.1.2.1.2.2.1.2' is the OID for interface descriptions - more information can be found here.

We'll also need the interface capacity:

snmpwalk -v 2c -c <community-string> <hostname> 1.3.6.1.2.1.2.2.1.5

> IF-MIB::ifSpeed.67 = Gauge32: 2000000000
> IF-MIB::ifSpeed.68 = Gauge32: 2000000000
> IF-MIB::ifSpeed.69 = Gauge32: 2000000000
> IF-MIB::ifSpeed.70 = Gauge32: 2000000000

Now note that the OID '1.3.6.1.2.1.2.2.1.5' returns the interface capacity in bits per second - so we'll need to convert this to gigabits per second (as the plugin doesn't support bits per second) - so we do:

2000000000 / 1000000000 = 2 (Gigabits)

For this example we'll use 'Port-channel1' - so the plugin would be executed as follows:

./check_iftraffic -H <hostname> -C <community-string> -r -i Port-channel1 -b 2 -u g -w 70 -c 85

The -b switch specifies our 2 Gbps and the -u switch instructs the plugin that we are giving the measurements in Gigabits.

If successfull you should have something like the following:

> Total RX Bytes: 1000.00 MB, Total TX Bytes: 2000.00 MB<br>Average Traffic: 5.75 MB/s (2.2%) in, 1.48 MB/s (0.6%) out| inUsage=2.2,50,70 outUsage=0.6,50,70 inAbsolut=10000000 outAbsolut=20000000

Now we simply need to setup the respective command and service definitions in nagios e.g.:

### commands.conf

# check switch port bandwidth
define command{
    command_name check_bandwidth
    command_line /usr/local/nagios/libexec/check_iftraffic -H $HOSTADDRESS$ -C $ARG1$ -r -i $ARG2$ -b $ARG3$ -u g -w 50 -c 70
}

### switches.conf

define service{
    use generic-service
    host_name SWITCH-STACK
    service_description HHSVRSTK Uplink: Bandwidth Utilization
    check_command check_bandwidth!<community-string>!Port-channel1!2
    normal_check_interval 1
    retry_check_interval 1
}

Setup Nagios Core for SNMP traps with snmptrapd and snmptt

We'll firstly need to download and execute the installer script from Nagios.com:

sudo yum -y install bzip2

cd /tmp
wget https://assets.nagios.com/downloads/nagiosxi/scripts/NagiosXI-SNMPTrap-setup.sh
sh ./NagiosXI-SNMPTrap-setup.sh

This will install and setup snmptrapd and snmptt while ensuring the firewall is configured properly (udp/162 - however you may wish to lock this down further)

We'll then need to add our MIB's - for this example I'll be using a combination of SG200/300 switches and so will download the MIB's from:

https://software.cisco.com/download/home/284645417/type/283965836/release/1.4.1.03

In the commerical version of Nagios you can add these with ease through the GUI - however if you (like me) are using Core you'll need to use the addmib tool:

cd /tmp
unzip MIBs_Sx200_v1.4.1.03.zip
cd MIBs_Sx200_v1.4.1.03
mkdir /usr/share/snmp/mibs/Cisco-SG200-300
mv *.mib /usr/share/snmp/mibs/Cisco-SG200-300

and add them with:

find /usr/share/snmp/mibs/Cisco-SG200-300 -maxdepth 1 -type f -exec addmib {} \;

We can now send a test trap with:

snmptrap -v 2c -c public localhost '' linkUp ifDescr s eth0 ifAdminStatus i 1 ifOperStatus i 1

You should now see this logged to /var/log/snmptt/snmpttunknown.log

However this wasn't the case for me - everything I was sending was being dropped / didn't show up in the snmptt log. After inspecting the service log for snmptrapd I quickly noticed the following warning:

Mar 11 14:51:33 host.internal snmptrapd[2752]: NET-SNMP version 5.7.2
Mar 11 14:51:33 host.internal systemd[1]: Started Simple Network Management Protocol (SNMP) Trap Daemon..
Mar 11 15:31:28 host.internal snmptrapd[2752]: No access configuration - dropping trap.
Mar 11 15:31:41 host.internal snmptrapd[2752]: No access configuration - dropping trap.

This behaviour is expected by default - as the snmptrapd team decided (wisely) to utilize authentication for incoming SNMP traps - however oddly this shouldn't have been an issue since the installer script from nagios added 'disableAuthorization yes' to '/etc/snmp/snmptrapd.conf' - however after reloading the service all was well - so I can only imagine the config had been added and the service did not reload / restart as intended.

tailing /var/log/snmptt/snmptt.log shows:

Mon Mar 11 16:03:56 2019 .1.3.6.1.6.3.1.1.5.4 Normal "Status Events" localhost - A linkUp trap signifies that the SNMP entity, acting in an eth0 up up

NOTE: Unknown MIB's will be sent to /var/log/snmptt/snmpttunknown.log

You'll also notice that in the nagios logs the following warning:

'Warning:  Passive check result was received for service 'SNMP Traps' on host 'localhost', but the service could not be found!'

So it looks like snmptt is successfully sending the information to nagios - however nagios does not know what to do with it!

We'll proceed by defining the service it's trying to submit data for:

define service {
  name SNMP Traps
  service_description SNMP Traps
  active_checks_enabled 1 ; Active service checks are enabled
  passive_checks_enabled 1 ; Passive service checks are enabled/accepted
  parallelize_check 1 ; Active service checks should be parallelized
  process_perf_data 0
  obsess_over_service 0 ; We should obsess over this service (if necessary)
  check_freshness 0 ; Default is to NOT check service 'freshness'
  notifications_enabled 1 ; Service notifications are enabled
  event_handler_enabled 1 ; Service event handler is enabled
  flap_detection_enabled 1 ; Flap detection is enabled
  process_perf_data 1 ; Process performance data
  retain_status_information 1 ;
  retain_nonstatus_information 1 ;
  check_command check-host-alive ;
  is_volatile 1
  check_period 24x7
  max_check_attempts 1
  normal_check_interval 1
  retry_check_interval 1
  notification_interval 120
  notification_period 24x7
  notification_options w,u,c,r
  contacts contact1,contact2
  register 0
}

define service {
  use SNMP Traps
  host_name localhost
  service_description TRAP
  check_interval 120
}

We can then test the serviced is working correctly with:

/usr/local/nagios/libexec/eventhandlers/submit_check_result localhost TRAP 2 "TESTING"

The changes should now be reflected on the nagios check status.

The next step is to load the relevant MIB files so we can translates the O.I.D's. In this tutorial we will be checking link status of a port so we'll need 'IF-MIB..txt' (which should come as part of the default installation - if not see here: http://www.net-snmp.org/docs/mibs/IF-MIB.txt)

We'll proceed by generating the snmptt.conf with:

rm -rf /etc/snmp/snmptt.conf
snmpttconvertmib --in=/usr/share/snmp/mibs/IF-MIB.txt --out=/etc/snmp/snmptt.conf --exec='/usr/local/nagios/libexec/eventhandlers/submit_check_result $r TRAP 2'

Open up the snmptt.conf file and ensure that the EXEC line for EVENT 'linkUp' returns 0 opposed to '2' and leave EVENT 'linkDown' as it is.

and reload the service with:

sudo service snmptt reload

We can then test it with: snmptrap -v 2c -c public localhost '' linkDown ifDescr s fa0/1 ifAdminStatus i 0 ifOperStatus i 0

and then check it reverts with:

snmptrap -v 2c -c public localhost '' linkUp ifDescr s fa0/1 ifAdminStatus i 0 ifOperStatus i 0

Setting up NPS / RADIUS for use with a Cisco 2960X

Below is a sample configuration to get up and running with Radius:

2960X Configuration

conf t
radius server <server-name>
address ipv4 <server-ip>
key <shared-secret>

aaa new-model # create new aaa model
aaa authentication login default group radius local-case # allow radius and local user authentication by default
aaa authorization exec default group radius local-case if-authenticated #  allow radius and local user authorisation by default

aaa accounting system default start-stop group radius # only account for radius

umasks: Ensuring httpd / apache is assigning the appropriate permissions on files / directories

I came across an issue the other day where the user httpd was running as was part of group that had been assigned permissions to the www root. Typically the user httpd runs under will be the owner of these files and directories and as a result will almost always have adequate permissions to read, write and execute. However in this case because it was part of a group instead the default umask setting of 022 was preventing the httpd user from writing to the files.

The umask can be worked out as follows - for example a umask of 002:

Directories: 777 - 002 = 775

Files: 666 - 002 = 664

i.e. the owner and group are able to read, write and execute directories and everyone else can only read and execute them. While the owner and group can write, write files and everyone else can only read them.

In order to apply these to httpd we can simply add the following line under the service stanza in /lib/systemd/system/httpd.service:

vim /lib/systemd/system/httpd.service

[Service]
...
UMask = 0002

and finally ensure httpd is restarted with:

sudo systemctl daemon-reload
sudo systemctl httpd restart