It seems like every time guns are in the news someone misuses terminology, usually in the name of making something sound scary. I’m posting these here so I can refer back to this later.
- Semi-automatic = loads another round after a round is fired, requires a trigger pull for each shot. Basically any modern gun that’s not break-action, lever action, pump action, or revolver.
- Fully automatic = can fire multiple shots with one trigger pull
- Assault rifle = fully automatic rifle
- Assault weapon = anti-gun term made up to make semi-automatic weapons sound more scary
- Magazine = holds bullets
- Clip = holds your pen in your shirt pocket (mostly)
If you, like me, live in Gnome Terminal all day and have been frustrated with the recent color scheme changes (particularly, that that the active tab is nearly impossible to distinguish), you will probably find this handy. Worked great for me.
Highlighting the active tab in Gnome Terminal.
If you want to be able to pass VLANs along to your linux guests from a linux KVM host, there’s a trick.
The most common way is to create special bridges for each vlan you want to pass, but that’s a big pain. Such an approach is detailed here.
After a surprisingly large amount of searching, I came across this article, which details the first way, and then another — the way to trunk vlans to KVM guests. Here’s the key quote that made me understand what I needed to do:
The difference is that when subinterfaces are defined on eth0, as noted previously Linux will strip the vlan tag, but when defined on the bridge, the vlan tags are kept.
Basically, if you put the vlans on the ethernet device, the tags will get stripped and not pass through the bridge to the guests. If you put the vlans on the bridge, the tags get passed through to the guest. So, a brief example.
You make a bridge br0 with eth0 on the kvm host. You then set up your guest to use br0 as its network interface (eth0 in the guest). You’d expect at this point that vlan tags would be passed. They won’t. However, if you want to pass vlan 2 through to the guest, then you add vlan 2 to br0 on the host (host: br0.2). Then, you add vlan 2 to eth0 on the guest (eth0.2). Boom. The vlan tag 2 is being passed through to eth0.2 on the guest.
Thanks so much to David Vassallo for figuring this out and posting it on his blog. Here’s hoping I can amplify the signal to help future seekers of this information.
I bought some cheap Acer c710 chromebooks, used, off of eBay for WISP use. One as a loaner for customers complaining of speed problems, when we suspect their systems may be the culprit.
The other I’m testing as a field laptop for use in the WISP. We keep the management interfaces of our equipment on a separate VLAN (802.1q), and frequently need to access that VLAN in the field. I couldn’t find any information online about whether this is supported in Linux.
Once I got the chromebooks, I put one in developer mode, and found that the 8021q kernel module is already available. That’s good, because it means I can keep running ChromeOS and get VLAN tagging, I don’t have to install a full-blown Linux system.
Using crouton, it’s possible to add a vlan to the ethernet port, and configure it. Once that’s done, the crouton chroot can actually be exited and unmounted and the vlan will continue to function correctly until the device is rebooted.
Now I just need to figure out how to automate the process of setting up the normal vlan(s) I use.
I have a solar-powered communications tower site for my WISP running on the MPPT60 as listed in the title. That controller is way more charge controller than I needed for the site, and pricey too, but I bought that one because it has a built-in network-connected monitoring and management system.
Usually I just check the web interface to make sure everything is good. It can be a little flaky and today it stopped responding. I didn’t want to have to cut power to the device, maybe possible without taking down my tower equipment’s power for a few minutes, maybe not, and wanted to make sure it was still functioning correctly.
The solution for me, at least this time, was to connect to the device in MS View (it was still pinging), and right-click on the controller, then select ‘Properties’, then the ‘Control’ tab, and then select ‘Reset Communications Server’ and click ‘Force Coil On’.
A few minutes later I could access the web status page again. I hope this helps someone else because searching for this information turned up next to nothing.