Processors, graphics cards, solid state drives and much more is all in this section of the site!
While iterating through an issue with our Ruckus SmartZone (with Ruckus R510 Access Points) controllers I was looking for a way to see when the Access Points had applied the new configuration; lone behold it’s quite easily done through both the CLI and the GUI.
Anyone who has used the new SmartZone controllers will know all too well that’s it’s not the fastest GUI to work with – thus if you have the option I’d suggest you go with the CLI method which is very responsive (and much more consistent!).
Via the CLI
Via the GUI
So over the last few hours I’ve been making some config changes to our Eaton UPS Network Management Cards that require the magical ‘Reset Communication’ button to be pushed in the web interface (one day I must get the management software!). To help speed up the process (or at least know when I should reload the page) I timed the process; so as more of a reference to myself than anything else the results are…
Web interface will respond and provide an authentication prompt: About 2 minutes 10 seconds after button push
Web interface will display all UPS data: About 2 minutes and 30 seconds after button push
After a great many years since Custom RemoteFX RDS Farm it’s time for something new! After much discussion and looking at the working practices at my current place of work we’ve decided to go all in with RDS and to support that we’ve got 3 new servers to run it on.
2x 1U rack mounts to go in our main server room with 1x tower for our DR room.
Photos below and more details to follow!
While provisioning some new Ruckus R510 WAPs onto our SmartZone 100 (220.127.116.11.675) we’ve had a number of cases where the WAPs will reboot for their firmware update but will not proceed beyond that point. In particular the PWR and CTL lights stay lit but the radio lights do not come on at all.
Looking in Access Points > Affected WAP > More > Tunnel Diagnostics (we’re using AP tunnelling) I note errors along the lines of
ifconfig: gre1: error fetching interface information: Device not found
cat: can’t open ‘/proc/rksgre/gre1/stats’: No such file or directory
cat: can’t open ‘/proc/rksgre/gre1/cache’: No such file or directory
cat: can’t open ‘/proc/rksgre/gre1/cfg’: No such file or directory
cat: can’t open ‘/sys/kernel/debug/qca-nss-drv/stats/*’: No such file or directory
The solution thus far has been pretty simple – factory reset the WAP by pressing and holding the RESET button in the back for 6+ seconds. It’ll go through a process of about 5-10 minutes and thus far have been coming back in a functional state.
Normally the little 8 (well 10 if you include the ‘uplink’ ports) port switches we buy end up under a desk or on a shelf but for a one off we’ve got one going in a comms cabinet. Quite luckily the HPE Aruba 2530-8G come with the ears in the box to do this (I recall seeing some models of switches with this being an additional item or needing a special shelf).
You’ll still need a place to keep the power supply but that’s nothing a few cable ties can’t sort!
Today I had the pleasure of presenting at the Oxford ICTF Conference on Multi-Factor Authentication and Password Stores with Smart Cards and YubiKeys, the video recording is online now here – https://youtu.be/WGtCxS2YFNA and the presentation can be downloaded through the link below.
Presentation.pdf (5.5 MiB, 137 hits)
Yes! Yes it they do!
In preparing for a presentation to some peers in the wider IT community tomorrow I have access to some YubiKey Neo authentication keys; in doing some extra reading up on the keys I thought – I wonder if these work with the MIFARE readers (note that these are MIFARE readers not the proprietary Paxton only readers) that are part of our Door Access Control system.
Lone behold they do; in the revision of the keys we have it’s a NXP MIFARE Classic 1k chip.
Recently I was inspired to take on some more information about routing and the associated protocols. To help support that I’ve gone and bought a Mikrotik RouterBoard hAP ac from Amazon (along with a RouterBoard hAP Lite). I hope to kick out a few blog posts on it along with my learning points over the next few days/weeks.
In the meantime enjoy the photos!
If you have ever seen this post Server Room – The latest you will notice we have a pretty awesome HPE Aruba 5400R zl2 Core Switch; however (at least until now), I’ve been yet to find a really simple guide which shows the best way to reboot the management modules following a firmware update.
So after much research and a live firmware update this morning (last time round I just reloaded both management modules at the same time) I’m going to go with the following plan.
- Update the firmware (wait a few minutes for the firmware to copy from the primary to the secondary module – this is automatic)
- Reboot the standby module using the boot standby command (and wait a few minutes)
- Confirm that the standby module is now running the new firmware with show redundancy
- Failover from the active to the standby module – this caused a few seconds of downtime in my environment
- Once the failover is complete the previously active module will now also be running the new firmware
For easy copy and paste see the commands on GitHub below along with the screenshot sequence which shows you how this will look on a switch running the 16.x branch firmware.