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
Recently I had to factory-reset a Juniper EX2200 switch for which the password got lost. No big deal one would assume: Connect the console cable to the switch, plug in a USB-to-serial adapter since neither my notebook nor my desktop come with a serial port anymore, reset the switch and press space when the boot messages scroll by…
… except they don’t. Which is funny, because the serial connection itself worked fine just a minute ago – I just had no way of logging in. Reset the switch again, nothing. Wait a couple minutes… and the switch is completely fired up, except I still don’t get any output on the serial port. Detach the USB adapter, hook it up again, press some keys and there’s the login. Try the Reset again, same thing happens. And so on…
Apparently, the only way I get output is to attach the serial line after the switch powered on. Well, ok then – connect the line the second after the switch got power. Apparently that’s to fast. Plug it in a couple seconds later, apparently that’s to slow since the switch is already booting the kernel and you’ll have to press space at the bootloader before that. Let’s try something in between… doesn’t work either, only gets garbage output and doesn’t accept my input, since apparently that’s not the right time either. Goddamn, WTF? How hard can it be to watch the switch boot? Strange thing is, I haven’t had any problems with that cheap-ass adapter and other devices so far.
An hour (and about a dozen or two resets) later I decided to fuck it and grab an old HP Server I have laying around for testing spare-hardware… it still has a serial port. Hook it up to a screen, keyboard, connect the serial line there and boot an OS from USB. Guess what? The Juniper bootloader shows up just fine, no matter what. It’s just my fucking retarded USB serial adapter thingy which craps out for some reason or another.
# press spacebar when prompted
loader> boot -s
root@switch01# set system root-authentication plain-text-password
# enter some password like juniper1
Reboot the system [y/n] y
Done. In about two minutes or so, if it wasn’t for my stupid serial adapter, which turned it into an two almost hour ordeal.
Cloudflare just rolled out their Universal SSL enabling pretty much any site to use SSL without any associated costs – which is pretty awesome…
But when using it on one of my test-sites, it turned out the site looks pretty much broken. Apparently WordPress doesn’t yet use protocol relative URLs, so CSS, JS etc. may still have a http:// prefix, causing some browsers not to load that content over an insecure channel. Furthermore, trying to access the WordPress dashboard results in an infinite loop, since the request from Cloudflare to your server is still HTTP and handled accordingly by WordPress.
The quick way to fix this is to simply add a few lines to woud wp-config.php
if(isset($_SERVER['HTTP_CF_VISITOR']) && strpos($_SERVER['HTTP_CF_VISITOR'], 'https')) $_SERVER['HTTPS']='on';
And maybe install some kind of HTTPS plugin to get rid of the mixed-content warnings due to residual http:// content from other plugins.
Kind of a hilarious bug, really… I recently installed another Ubuntu 14.04 server running inside a KVM with a rather fast storage backend, therefore the system apparently boots just a tiny bit faster than my other images have in the past. Problem is, apparently that slows down the boot process as init thinks something must be crashing and decides to respawn it for good measure…
[ 2.311174] input: ImExPS/2 Generic Explorer Mouse as /devices/platform/i8042/serio1/input/input3
[ 2.811553] init: plymouth-upstart-bridge main process (191) terminated with status 1
[ 2.812789] init: plymouth-upstart-bridge main process ended, respawning
[ 2.874117] init: plymouth-upstart-bridge main process (210) terminated with status 1
[ 2.875167] init: plymouth-upstart-bridge main process ended, respawning
[ 2.904155] init: plymouth-upstart-bridge main process (217) terminated with status 1
[ 2.905289] init: plymouth-upstart-bridge main process ended, respawning
[ 2.928618] init: plymouth-upstart-bridge main process (221) terminated with status 1
[ 2.929713] init: plymouth-upstart-bridge main process ended, respawning
[ 49.975826] Adding 2093052k swap on /dev/mapper/[...]
Yep, that’s right – 47 seconds waiting and idling, doing nothing when the image could have booted in a fraction of that time.
To fix it, simply add a sleep 2 to your /etc/init/plymouth-upstart-bridge.conf
stop on (stopping plymouth
or stopping plymouth-shutdown)
Init won’t freak out anymore and starts the image as it’s supposed to:
[ 1.225045] random: lvm urandom read with 16 bits of entropy available
[ 1.281118] bio: create slab <bio-1> at 1
[ 1.370262] EXT4-fs (dm-0): mounted filesystem with ordered data mode. Opts: (null)
[ 1.684687] tsc: Refined TSC clocksource calibration: 2500.001 MHz
[ 2.153550] Adding 2093052k swap on /dev/mapper/[....]-swap_1. Priority:-1 extents:1 across:2093052k FS
[ 2.169332] EXT4-fs (dm-0): re-mounted. Opts: errors=remount-ro
[ 2.190451] input: ImExPS/2 Generic Explorer Mouse as /devices/platform/i8042/serio1/input/input3
[ 2.408937] EXT4-fs (vda1): mounting ext2 file system using the ext4 subsystem
[ 2.417990] EXT4-fs (vda1): mounted filesystem without journal. Opts: (null)
[ 3.316769] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[ 3.316778] IPv6: ADDRCONF(NETDEV_UP): eth1: link is not ready
[ 3.495345] FS-Cache: Loaded
After upgrading one of my HP ProLiant servers to Ubuntu 12.04 LTS (better late than never) the check_hpasm Nagios plugin broke, resulting in no regular checks of the internal arrays being performed.
Apparently that’s a known bug with the hpacucli utility doing the actual checks, which can’t uname returning a 3.x kernel version. You can manually fix this by running it like this:
setarch x86_64 --uname-2.6 [[program] [program arguments]]
setarch x86_64 --uname-2.6 hpacucli ctrl all show
Therefore a quick and dirty fix for check_hpasm would be to open up /usr/lib/nagios/plugins/check_hpasm and go to the part that reads:
if [ -x "$hpacucli" ]; then
for i in config status
$hpacucli ctrl all show $i | while read line
printf "%s %s\n" $i "$line"
and replace the line (553 in my case) calling hpacucli with:
/usr/bin/setarch x86_64 --uname-2.6 $hpacucli ctrl all show $i | while read line
Worked just fine for me.
After re-installing the Google apps package (gapps-jb-20130301-signed.zip) on my CM10.1 phone, Google Play stopped working and didn’t let my install any new apps or update existing ones. To fix the Error[RPC:S-5:AEC-0] you’ll have to:
Go to the system settings -> delete your Google account -> add it again and let your Android sync
Don’t worry, you won’t lose any of your data by doing that.
After updating my Ubuntu desktop to a more recent release (12.04 / Precise Pangolin), my rarely used Canon Pixma MP190 stopped working. Not completely, but in a rather annoying way: Printing a single page works fine, but printing multiple pages / copies causes the printer to hang. Hard. As in, you have to pull the power plug to reset it, as no button will do anything anymore.
Apparently there was a bug introduced with CUPS a while ago, or rather a change in behavior of CUPS which triggers a bug in the printer Firmware. Took me a couple hours to find and had me on the brink of throwing out the whole printer.
And it looks like it affects quite a few other USB printers as well: Epson NX130, Canon i550, i560, ip4200, ip4300, ip5200, MP180, MP160, MP210, MP450, MP500, MP520, …
To save you from reading through all the comments: Till Kamppeter came up with a workaround that worked perfectly for me and others.
In a terminal window, run the command
lpadmin -p -o usb-unidir-default=true
with being the name of your printer as displayed
by the "lpstat -p" command.
Now turn off and turn on your printer, then try to print several jobs.
After that I was able to print a couple hundred envelopes without a hitch.