r3dux.org

Every time I’d put my LMDE-running machine to sleep the wireless wouldn’t come up for maybe a minute or so, which isn’t ideal. This could be caused by a variety of conditions, but in my case it turned out that the IPv6 “Automatic” setting was trying to use IPv6 DHCP, and was waiting for this to time-out before accepting the IPv4 DHCP lease.

To change this behaviour, you can modify the IPv6 settings from Automatic to Ignore, like this:

If you’re not using Gnome Shell (like in the above screenshot), then maybe try modifying /etc/network/interfaces – really, it’ll depend on your Linux distro where the config is located.

Once IPv6 was disabled the IPv4 DHCP lease was accepted immediately on resume – and it could be the case that if you’ve got the same symptom that it’s caused by the same issue. Regardless, it’s certainly one of the easier things worth trying before you go looking into more involved solutions.

Source: https://bugzilla.redhat.com/show_bug.cgi?id=708450.

I added a couple of WordPress plugins the other day to tack on a little bit of extended functionality to the site, but things went badly, and some bizarre interactions between plugins meant that I couldn’t log in to the WordPress administration interface – it would just throw me back to the main site without even having the option to log in… As such, I couldn’t disable the plugins (because you need to be in the administration interface to do that!), so what the heck to do?

You might think to ssh in to the box and remove the plugins from the …/wp-content/plugins/ folder to disable them (as I did) – only this won’t work. What we really need to do is disable the plugins directly from the database – and luckily for us it’s a pretty simple process as long as we can ssh into the box!

Note: If you dont’ have ssh access to your server, you could always take the phpMyAdmin route to achieve the same goal through a web interface, but if the problem you have is related to being redirected all the time (like mine was) then the direct DB access way is really the only way to go!

Gaining SSH Access

If you’re running linux you’ve already got a ssh client built in, if you’re on Windows then you’ll probably want to get yourself a copy of PuTTY or such.

Assuming the IP address of your server is 1.2.3.4, then you can ssh to the box with:

ssh 1.2.3.4 -l <YOUR-USER-NAME>

In the above command the switch is “minus lower-case-L”, not “minus pipe-symbol” or anything, and if you’ve changed your ssh port away from the default of 22, then you can just add the switch -p , so if my ssh daemon was running on port 2233, and I wanted to log in as the user bob, I’d use:

ssh 1.2.3.4 -l bob -p 2233

Connect to MySQL

Once you’ve got a ssh connection to the server, the next thing you’ll want to do is connect to your database, with the following command:

mysql -u <MYSQL-USER-NAME> -p

So if I had a MySQL administrator called dbAdmin I’d use:

mysql -u dbAdmin -p

The -p switch on the end will prompt you to enter the password for your MySQL admin user account – don’t worry if you’ve forgotten the credentials you should use – they’ll be in your WordPress wp-config.php file, which is usually located in your www or htdocs root folder (on Linux this is usually /var/www).

Quick Tip: By placing your wp-config.php file in the web root it’s possible for it to be accessed by malicious types, but you don’t have to place it here! You can, in fact, move the file one level up so that it’s outside of the web-root and WordPress will still be able to find it, but scoundrels won’t! So if you’re running WordPress with all your files in /var/www/ just move the wp-config.php file up to /var/ and it’ll still work and be safer! You can do this from the ssh terminal with:

cd /var/www
mv wp-config.php ..

Manipulate the Database

Once you’ve got administrator access to MySQL you need to connect to your database (again, the database name will be in your wp-config.php file), so if we’d called our database myWebDB then we could connect to it through the MySQL command line interface with:

CONNECT myWebDB;

Once this has connected successfully, all you have to do to disable all plugins is issue the following command:

UPDATE wp_options SET option_value = 'a:0:{}' WHERE option_name = 'active_plugins';

That’s it! Attempt to access your site! Any plugins which were causing mayhem will now be disabled, and you can then add them back one-by-one until you find the combination that’s stuffing things up!

Cheers!

Props: Many thanks to Jeff Star of PerishablePress for his article Quickly Disable or Enable All WordPress Plugins via the Database which saved my bacon, and prompted me to write this quick guide.

I don’t do a lot of PC gaming these days, preferring more to just sling a disc in the 360 or PS3 to get my jollies without all the patch/driver hassle, but you’ve got to have a couple of linux games installed to vent the occasional blood-lust. With that in mind, I grabbed the latest version of ioquake3 earlier, and tried out a single player game, but no bots would join the match, and a look at the shell showed errors along the line of:

^1Error: file bots/default_c.c, line 2: file charsh” not found
^3Warning: couldn’t find skill 1 in bots/default_c.c
^1Error: file bots/default_c.c, line 2: file charsh” not found
^1Error: file bots/default_c.c, line 2: file charsh” not found
^1Error: file bots/default_c.c, line 2: file charsh” not found
^3Warning: couldn’t load any skill from bots/default_c.c
^1Error: file bots/kyonshi_c.c, line 2: file charsh” not found
^3Warning: couldn’t find skill 1 in bots/kyonshi_c.c

Apparently it’s only been an issue with the 64-bit version – but even the older version I had was showing the same problem (which I don’t quite get how) – anyways, I recompiled ioquake3 and it’s all fixed up – and thought that if anyone else was up against the same issue it might be useful to know how to fix it quickly and easily.

1.) Get the source

For this we need to have subversion installed to download the source trunk, if you do – great!, if not, run this first:

sudo apt-get install subversion

With subversion in place, from the command line create a folder with mkdir ioqcode or the like, go into it with cd ioqcode and then grab the source with:

svn co svn://svn.icculus.org/quake3/trunk ioquake3

2.) Build it

Go into the downloaded trunk code with cd ioquake3 and then build that bad-boy with this complex command:

make

Geez, linux is tech To be fair, you’ll need the sdl-dev packages installed (libsdl1.2-dev) and of course build-essential – I didn’t have to get any extra packages, it just built.

3.) Pick a place to stick it

Because I’m the only user of my laptop, I have a folder called Games in my home directory, so I just created ~/Games/ioquake3 and then copied all the files from the build/release-linux-x86_64 sub-folder (created when you successfully built ioquake using that complex make command – your folder won’t have _64 on the end if you built it on a 32-bit system) to ~/Games/ioquake3/, and then copied the pak0 to pak8.pk3 files from my original Windows install of Quake III into the baseq3 subfolder of the ioquake3 folder.

4.) Frag on!

Launch ioquake3.x86_64 and get your game on =D

I have absolutely no idea how they’ve got motion blur on the game (unless it’s applied post-game to the captured footage) – but it looks AWESOME! Want! If you know how they did it please feel free to smack me with the clue-stick in the comments! Cheers! =D

Update: It turns out they’re using the Excessive Plus mod in the video (which works fine with ioquake), still no clue about the motion blur though…

Another Update: Turns out this issue exists in the 64-bit version of OpenArena as well as ioquake3. I rebuilt openarena using the 0.81 version from the svn here – but still no dice with getting bots to spawn. Apparently the 32-bit version of OpenArena is unaffected.

I’m running Ubuntu 9.10 64-bit, and thought I’d have a look at some old LucasArts gems today – but the version of ScummVM taken from the repos wouldn’t play any sound. So I fixed it.

• The all-in-one complete fix:
  Fire up synaptic and install libsdl1.2debian-pulseaudio then reboot. Sound (i.e. voice, samples etc) and midi should work absolutely fine now. A potential problem with this fix is that it means you have to uninstall libsdl1.2debian-alsa, which it’s possible you might want to keep. This is the route I finally took, but if I find a bunch of apps are now without sound, I’ll update the post and try to find some other methods.

Oh, and if you loose all sound after this (YouTube, Totem etc), then you’ve probably got gstreamer set to use ALSA, but have now removed the sdl-alsa lib, so just run gstreamer-properties and point your audio output to PulseAudio Sound Server then log out then back in. Fixed.

Update: Although working yesterday, I found I had no sound in flash stuff today (YouTube vids etc), so I installed padevchooser from synaptic, which dragged in a couple of other pulseaudio bits and pieces, launched padevchooser, and then from the icon in the system tray (top-right in Gnome) I just selected Default for Default Server and Default Sink – closed then re-opened firefox and everything’s working again. I guess I didn’t come across this yesterday because I already had Firefox open and using flash (npviewer.bin) with the ALSA plugin already resident in memory and in use.

• The easy fix to get midi working using ALSA:
  Try running ScummVM from the terminal as pasuspender scummvm – if you can hear midi sound when you start a game, that’s half the battle.
• The slightly more involved midi fix:
  If the easy fix doesn’t work, grab yourself a midi file from somewhere (like this one) and play it from the terminal with timidity name-of-file.mid. If it plays, jolly good. If not, have you got timidity installed? If you have, and still can’t play a midi, read this.

  I’ll assume you can play a basic midi file from the terminal, but there’s no midi in ScummVM games (which was the situation I was in). So, first we need to find out where our midi ports are at – to do this, run the following line from the terminal: aconnect -o -l

  The output I get is:

  client 14: 'Midi Through' [type=kernel] 0 'Midi Through Port-0' client 128: 'TiMidity' [type=user] 0 'TiMidity port 0 ' 1 'TiMidity port 1 ' 2 'TiMidity port 2 ' 3 'TiMidity port 3 '

  Midi in ScummVM wants to play on ports 17 or 65 by default, but on my box we can see that port 128 (i.e. client 128) is where the user-land midi ports are at. So now we need to modify the ScummVM config file with that data. So open up the file ~/.scummvmrc with your text editor of choice and add the line alsa_port=128:0 (or whatever your user-land aconnect -o -l output is), or if the line already exists just amend it to point at your midi port.

Give ScummVM another go (from the terminal so you can see its output), point the Music driver device at ALSA or Timidity now, and you should at least get midi sound, and see something like the following in the terminal output:

Connected to Alsa sequencer client [128:0] ALSA client initialised [129:0]

Really though, I think the first option is the best, as I’ve not been able to get voice/samples working with anything other than installing the pulseaudio sdl library. I’ve just put the other options in incase you’ve a strong case against getting rid of libsdl1.2debian-alsa, and if I find there’s one in my case, I’ll come back and update things. But for now, I think I might have a crack at The Dig

Think 25% CPU usage is unacceptable for a software firewall? You’d be right.

Steps to fix:
- Ctrl + Shift + Right Click on Zone Alarm icon in the system tray and select Set debug level from the pop-up menu
- Set Debug Level to Off by clicking the appropriate radio button in the Set debug level window
- Click [OK]
- Restart Zone Alarm (i.e. quit then restart it)

Works on:
ZoneAlarm version:9.1.007.002
TrueVector version:9.1.007.002

Feel free to delete the stupendous amount of logging dirge left behind by Zone Alarm’s “writing phase” in C:\Windows\Internet Logs while you’re at it.