Categories

Sean's Blag Posts

We’ve recently decided to supplement the temperature monitoring provided by the UPS units in our IDFs with Raspberry Pis and DHT22s. There’s a nice article on setting them up to pipe data into Zabbix, the monitoring system we use at work, so this is incredibly useful to us.

We use CentOS here, so converting from Raspbian to CentOS wasn’t too tricky, although the Zabbix agent is only available in the un-official, un-QAed armv7hl EPEL repository. Again, nothing too tough here. Not something I’d want on a critical system, perhaps, but if the agent stops working, at least we’ll get alerts. 😉

The problem arose when I went to install Puppet, which we use for long-term configuration maintenance. It turns out that the CentOS 7 OS repository for armv7hl doesn’t include Ruby, which Puppet requires. Now, I’m currently trying to rebuild a Ruby 2.3 RPM on the Raspberry Pi so that I can get Puppet installed. Will post updates here (including a link to the RPM) once I get it figured out.

At work, we’re currently evaluating oVirt as a replacement for our VMware infrastructure. We had evaluated it around 3.5 and found it wanting, but the 4.0 release led us to reevaluate. I found the setup process a little lacking, but once setup correctly, it works delightfully well.

Setting up the First Host

Storage Configuration

Shared storage is required to setup oVirt. This can be an NFS share from your first host, but separate storage is highly recommended. In my setup, I used an NFS share from an illumos box we have laying around. Ensure that the NFS shares for oVirt are owned by 36:36 (vdsm).

For the rest of the post, I will assume that your hosts have at least two NICs: one for management and VM traffic and another for storage traffic.

Installation Process

Grab a copy of the oVirt Node ISO and begin installing it on the first host.

The installation process is very similar to CentOS 7. Configure the hostname and assign an IP address to the first network interface. Assign a root password and don’t bother creating a user.

Once the installation completes, reboot the host.

Hosted Engine Setup

In oVirt parlance, the “Engine” is the component that manages the hosts, much like vCenter or XenCenter. A Hosted Engine is when you run the Engine as a VM.

SSH into the first host and install the latest ovirt-engine-appliance package, which can be found here.

Edit /etc/hosts and add entries for this host, as well as the oVirt Engine we will be setting up. This step is crucial, as name resolution is required to complete the setup and oVirt will drop your current DNS servers when it creates the bridge interface during Hosted Engine setup.

Open a web browser and login to the Cockpit page on the oVirt host (https://<<IP_ADDRESS>>:9090/). Login as root and click on the Networking link, then the add VLAN button. Set the Parent Interface as the second NIC, likely enp2s0f1, and the VLAN ID as your SAN. Assign the new VLAN interface an IP address on that VLAN, ignore IPv6 traffic, connect automatically, and enable the interface.

Making Tokens

I use RPTools’ TokenTool (specifically version b27) to create (N)PC tokens from the character’s portrait. The tool is fairly simple:

Extract the zip file and double-click on ‘tokentool-1.0.b27.jar’

After a moment, the tool’s window will launch.

Drag-and-drop the character’s portrait onto the black portion of the window.

Size and position the image.

Click-and-drag the image to reposition.

Use the arrow buttons on the right to size the image. Double-arrows are for large size changes; single-arrows are for smaller changes.

Using the dropdown box, select the ring for the token

Personally, I use circles for PCs and hexagons for NPCs, but this is entirely up to you.

Under the file menu, select Save Token and save the new token where you want it.

Upload to Roll20

???

Profit

Using Tokens in Game

Now that your tokens have been created, you need to use them. Drop them onto the Object/Token layer, click on it, then on the gear to edit it.

Ensure that the “Represents Character” box has the right character selected. This is based on character sheets in the journal.

The “Name” field will show up in the Turn Tracker and on their nameplate, if you show it. I like to use first names or the name the character is known by here, especially if the character is using an assumed name.

Ensure that the dropdown box for “Bar 1” is set to hp. This will automatically populate with current HP / max HP from the character’s sheet.

You can add other bars, if desired, but I find them to not be terribly useful.

To ensure all players can see the health bar (a good, non-meta way of sharing how messed up a fellow character is at-a-glance), click on the “See” checkbox for Bar 1.

Ensure the “Has Sight” checkbox is checked, especially if you plan on using Dynamic Lighting.

This is also where you’d set what light the player emits.

For a torch, enter 40 in the first box (entirety of light) and 20 in the second box (where the bright light transitions to dim). You should check the “All Players See Light” box, as it’s a torch and that’s how light works.

For darkvision, enter the range of their darkvision in the first box (60, usually) and -5 in the second box, so that all of the light is dim. Ensure that “All Players See Light” is unchecked, as no one else has access to that player’s darkvision.

For blindness, you cannot just uncheck the Has Sight box, as the player would be able to move through your light obstructions. What you should do, is set the token’s angle of vision to 0 degrees. This way, the player is blind, but is still stopped when they bump into doors or walls.

Save the changes to the token.

Now, on the edit the character in the journal, select the token, then click on the “Use Selected Token” button. This will make it so that all of the settings you’ve applied to the token will be used whenever the player drops their token onto the map.

Building NPC Character Sheets

Coming Soon

Basic Dynamic Lighting

There’s a lot of differing information about what the proper cabling for connecting Cisco/HP/whatever network gear to an ACS console server. I’ve seen everything from straight-through to rollover to a modified version of straight-through. However, Avocent provided the correct version and I’ve verified that it works.

There seems to be a lack of information (that isn’t misinformation) on how to upgrade the firmware on Quanta LB4M switches. Posts abound containing warnings about bricking your switch. Likely, these people attempted some XMODEM transfer that was not needed. All you need is a TFTP server, which can even be running on your local computer.

Grab a copy of the firmware from Jared’s site (or my mirror: 1.1.0.8 / 1.0.2.17). I used lb4m.1.1.0.8.bin as it’s the latest and seems to be the most featureful, although I’m still trying to locate a copy of the release notes for each version.

Make that file available via your TFTP server and ensure that your switch can see your TFTP server (ping should do nicely). I’ll assume that your TFTP server is on 192.168.1.100, so if it isn’t replace that with the IP you’re using. Once your switch can see the TFTP server, it’s time to begin.

The LB4M has two firmware slots: image1 and image2. You’ll need to determine which is currently active, as you cannot download firmware to the active slot.

This shows that we need to download the firmware into image2, as image1 is the currently loaded firmware. We do that with the following command:

(Switching) #copy tftp://192.168.1.100/lb4m.1.1.0.8.bin image2

Select ‘y’ at the prompt of “Are you sure you want to start?” and the transfer will begin. It will take a few minutes, but should complete without issue, assuming your TFTP server is reachable and working properly. If all goes well, you’ll see the following: