Wednesday, 18 November 2020

Vertiv Avocent ACS800 / ACS8000 Series LTE Dongle / Modem Setup

Forewarning: The below is not officially supported and should not be used in a production environment. It's here to simply demonstrate that it's possible to configure 'unsupported' LTE modems on Avocent units.

Since there is next to no documentation for this I thought I'd provide some (hopefully) useful information for anyone else trying to get a LTE modem / dongle setup with the unit.

Firstly ensure you are running the latest firmware as more recent Linux kernels have greatly improved support for LTE modems.

For this exercise I am using a 'D-Link DWM-222 4G LTE USB Adapter'

We'll need to set the 'Moderate' security profile (System >> Security >> Security Profile) firstly (as we'll need root access over SSH)

Firstly define the APN for our mobile operator (Smarty Mobile in this case):

echo "APN=mob.asm.net" >/etc/qmi-network.conf

Ensure 802.3 is set:

qmicli -d /dev/cdc-wdm0 --wda-set-data-format=802-3

Start the modem driver:

qmi-network /dev/cdc-wdm0 start

Ensure the interface is automatically started and the cdc-wdm interface is started before bringing the interface up:

vi /etc/network/interfaces

auto lo eth0 eth2 wwan0

iface wwan0 inet dhcp

        pre-up /usr/bin/qmi-network /dev/cdc-wdm0 start

If the interface does not come up automatically despite 'auto wwan0' being set you can create startup script instead:

vi /etc/init.d/S99lteconfig

sleep 15

echo "Bringing up LTE interface..."

/sbin/ifup wwan0

/sbin/ip route add 0.0.0.0/0 dev wwan0

chmod 755 /etc/init.d/S99lteconfig

ln -s /etc/init.d/S99lteconfig /etc/rcS.d/S99lteconfig

Restart the device and check whether the interface has come up:

ip addr

Lastly ensure we put the 'Security Profile' back to 'Secure' mode.

Saturday, 22 August 2020

Recovering from a replication failure in a MariaDB Master/Master replication setup

For the purposes of this post I'll assume we are working with two MariaDB servers that have been configured to perform master/master replication and one of them has failed. In this case Server01 is healthy while Server02 has stop replicating.

We need to firstly ensure that no queries are hitting Server02 / the failed server - this will typically be a case of stopping services / blocking network access to services that hit it. e.g. stopping httpd.

We'll also want to ensure replication is stopped on the failed server (Server02):

SERVER02> stop slave;

Now on Server01 / the working server issue:

SERVER01> stop slave;

SERVER01> flush tables with read lock; (This will temporarily stop it updating)

SERVER01> show master status;

We'll make a note of the above command - it should read something like:

File: mysql-bin.123456

Position 123

Binlog_Do_DB: <replicated_database>

Then on Server01 / the working server take a backup of the database:

SERVER01> mysqldump -u<username> -p --lock-tables --databases <database-name[s]> > export.sql

and on Server02 / the failed server - restore the backup:

SERVER02> mysql -u root -p < export.sql

Now on Server01 / the working server issue the following command to start processing changes again:

SERVER01> UNLOCK TABLES;

Then on Server02 / the failed server issue the following to repoint the logs (use the information above we recorded from Server01):

SERVER02> CHANGE MASTER TO master_log_file='mysql-bin.xxxxxx', master_log_pos=yy;

SERVER02> START SLAVE;

To verify we can issue:

SERVER02> show slave status \G

Now we need to do the reverse by ensuring Server01 / working server replicates from Server02 / failed server. On Server02 issue:

SERVER02> show master status \G

Record the output again.

Now on Server01 / the working server set the logs:

SERVER01> CHANGE MASTER TO master_log_file='mysql-bin.xxxxxx', master_log_pos=yy;

SERVER01> START SLAVE;

and then to verify replication issue:

SERVER01> SHOW SLAVE STATUS \G

Finally reverse anything you performed at the start to block comms with Server02 / the bad server e.g. start services, update firewall etc.


Friday, 10 July 2020

Monday, 16 March 2020

Invoking sysprep (Generalising a Windows install) on AWS EC2

  1. From the Windows Start menu:
    For Windows Server 2008 through Windows Server 2012 R2, open EC2ConfigService Settings, and then choose the Image tab.
    For Windows Server 2016 or later, open EC2 Launch Settings.
  2. For Administrator Password, choose Random.
  3. Choose Shutdown with Sysprep.
  4. Choose Yes.
    Note: You must retrieve the new password from the EC2 console at the next service start.

Friday, 13 March 2020

Instruct AWS EC2 'User Data' to be invoked on startup (Server 2016+)

When launching Amazon EC2 images 'user-data' (effectively a bootstrapper) is invoked on first launch. However if you create a custom AMI from one of these images you'll need to run the following to ensure user data is invoked (as the task that invokes it gets disabled prior) with:

C:\ProgramData\Amazon\EC2-Windows\Launch\Scripts\InitializeInstance.ps1 –Schedule

Shutdown the instance and then create AMI again.

Sunday, 1 March 2020

Quick Start: Upgrading Juniper SRX Devices

Once you've obtained the relevant firmware from Juniper you can either download it via https:

file copy https://cdn.juniper.net/software/junos/XX/XX.tgz /tmp XX.tgz

or alternatively if you need to download it from a named routing instance you'll need to download it over ftp firstly:

ftp routing-instance <instance-name> <ftp-host>

start shell
md5 /tmp/<firmware>.tgz

request system software add validate /tmp/<firmware>.tgz

The system will then extract the firmware and reboot immediately.

To verify the Junos firmware version after reload issue:

show version

Tuesday, 18 February 2020

[Solved] Snort: ERROR: Can't initialize DAQ pfring (-1) -

I came across this error after performing a regular system update on CentOS 7. Although it's a rather generic looking error message it turned out to be quite a trivial problem.

The pfring driver (provided by daq_pfring) had been compiled against the latest kernel version - however for whatever reason an older kernel was being loaded by default by the bootloader.

This can be evidenced by running:

uname -r

and a rpm -qa | grep kernel

To correct this issue:

grub2-set-default 0 # presuming menu item 0 is the kernel you want listed in: /boot/efi/EFI/centos/grub.cfg (which is usually the case.)

and then confirm with:

grub2-editenv list

Restart the machine and then check the kernel / test snort again:

shutdown -r now

sudo service snort status