So I just installed a new Ubuntu 16.04 Xenial box with MariaDB 10.0 and phpMyAdmin but for some reason just can’t login as root user via phpMyAdmin, although it works via the shell. Turn’s out MariaDB enabled the unix_socket plugin-in for the root user, preventing phpMyAdmin from working out of the box like it does with native MySQL. So much for drop-in replacement – figuring that one out was quite frustrating…
Here’s how you disable it:
echo "update user set plugin='' where User='root'; flush privileges;" | mysql --defaults-file=/etc/mysql/debian.cnf mysql
I have a couple older HP ProLiant DL360 Gen 6 and Gen 7 Server I want to use as virtual machine hosts with some PCIe devices mapped through to the guests running there, let’s say so they can directly access the Fibre Channel ports on the host or whatnot. Here’s how to do it (running Ubuntu 14.04 LTS that is, YMMV with other distributions):
Edit your /etc/default/grub and add the intel_iommu=on boot option, it should look something like this (serial console for ILO enabled as well)
# /etc/modules: kernel modules to load at boot time.
# This file contains the names of kernel modules that should be loaded
# at boot time, one per line. Lines beginning with "#" are ignored.
# Parameters can be specified after the module name.
Create a file like /etc/modprobe.d/vfio.conf setting the allow_unsafe_interrupts option for the vfio module.
Otherwise you’ll get an error when trying to start a VM with a PCI device passed through: “failed to set iommu for container: Operation not permitted”
Apparently the IOMMU interrupt remapping is kinda broken on this platform.
Reboot your server and create a VM with one of your PCIe adapters passed through – it should show up just like if was a native device on a real, physical server.
I recently got a used Cisco WIP 310 VoIP phone for fairly cheap and figured it would be nice to have a wireless handset as well. Or so I thought… because the thing still had it’s original firmware installed and turned out to be fucking useless. Couldn’t even get it to find my wireless network, let alone login or do anything but crash randomly.
Let’s see if there’s a new firmware available… great, it is! 5.0.13 as compared to 5.0.11 that was installed. But of course the firmware update via the supplied updater program didn’t work either. Manually copied the file to the handset and rebooted, came up with 5.0.11 again. Great…
So, long story short – here’s the way I finally managed to update it. Hope it helps someone else:
Set up an open wireless network. For some reason the handset just wouldn’t work with my WPA2 secured network. You’ll need this only for the update procedure.
In the wireless settings, change the IP configuration from DHCP to some static address on your network. Because for some reason DHCP didn’t work either…
Now try to connect your WIP 310 to the network. It may take a couple of tries and/or reboots. Don’t ask me why, but eventually it did connect and I could ping the device.
Open up the IP-Address of your phone in a web browser. Make sure the webserver is enabled: Settings -> Misc Settings -> Enable Web Server
Go to ‘Admin Login’ on the upper right corner. On the ‘Ext 1’ tab set ‘Line Enable’ to ‘no’ and on the ‘Provisioning’ make sure ‘Upgrade Enable’ is set to yes
Now for the magic… Extract the firmware image from the ZIP file and upload it to some Webserver. Make sure you can reach that server from your open wireless network so your phone can access that file.
Schedule a firmware update via your browser: Go to http://your-phone-ip-address/admin/upgrade?http://your-server/path-to/wip310-5.0.13-04-26-2010.img
You’ll get a message that the phone will update the firmware when idle. Wait a minute or two, maybe watch the Logfile on your webserver in case you have access. Eventually you’ll see a request by a client identifying as “Cisco/WIP310-5.0.11(10301355) (YOUR-PHONES-SERIAL)” or something like that.
Wait for your phone to reboot. Reload the Admin Page in your browser to make sure it’s updated to 5.0.13
After that, you’ll notice the GUI on your phone looks a little different as well. And most importantly… it finally works. It also works with WPA2, hidden SSID networks and whatnot. It still has some bugs registering on some SIP servers. Even though it sometimes works, every now and then you’ll get a not registered error message. To fix that, take a look at the supplied PDF with the release notes. It tells you to change a couple settings:
On the ‘SIP’ tab look for SIP Timer Values, the SIP T1 timer need to be changed from 0.5 to 2
Also on the ‘SIP’ tab look for Response Status Code Handling, the Retry Reg RSC value needs to be set to 401
Now got to the ‘Ext 1’ tab, set ‘Line Enable’ to yes again and enter your SIP settings to login to your SIP service.
After all that is done, the phone finally appears to be working the way it’s supposed to.
Can’t get the cover on your Husqvarna chainsaw back on after working on your chain? Chances are you forgot to disengage the chain brake before removing the cover (it probably didn’t come off quite that easy, remember?) and now you’re stuck with a chainsaw you can’t reassemble without getting the chain stuck…
There are quitea fewvideos on YouTube with different methods on how to fix this, but most of them aren’t exactly easy or risk-free (it’s a quite strong coil with a lot of energy stored) and take way longer than they need to. Apparently Husqvarna even has a dedicated tool to do this… Well, here’s an easy 5-10 second fix that worked just fine for me on a Husky 135, once I figured out what the problem was:
With the cover, blade and chain removed – move the brake handle forward into the “engaged” position.
Put the cover in place and wiggle it (and the brake handle) a bit so the star-like metal piece slips into place, aligned with the notches on the brake handle.
With everything aligned, pull the handle carefully back to disengage the brake, using the handle as a lever exactly the way you’d normally use it when working with your chainsaw. You’ll hear it click in place.
Remove the cover again, attach the bar and put on the chain. Put the cover back on the way it’s supposed to work: without much resistance at all.
No disassembly of the brake required and certainly no special tool, only takes a couple seconds. Possibly even works without removing the bar and chain, though I haven’t tried it that way.
After spending the last couple hours trying to figure out why the event console wasn’t showing up in my manually upgraded OMD/check_mk install (that is OMD 1.2 w/ check_mk 1.2.4p5 upgraded to 1.2.6b10) even though mkeventd is running – here’s what you got to do: manually copy the files from your check_mk source directory into the install director. The setup script does everything else for your, except that.
rsync -av web/* ~/local/share/check_mk/web/
sending incremental file list
sent 210,421 bytes received 346 bytes 421,534.00 bytes/sec
total size is 209,125 speedup is 0.99
That’s it. WATO should now show the event console again and things like rule based notification will also work.