GStreamer Codec Install Gone Bad, Part Two?

Tonight, while tracking down an issue with another video file that wouldn't play in Ubuntu 8.04, but would in anything else -- I discovered yet-another-quirk about the Fluendo codec megabundle, this time with the H.264 codec.

Attempting to play a movie on a fresh installation of Ubuntu 8.04, in Totem with the fluendo codecs installed brought up a black screen with a properties dialog that looked like:



By fresh -- I mean fresh, this box was a demo to show a new user how easy multimedia was (after successfully demonstrating how easy the printer was to set up using CUPS), it has only got the standard installation of Ubuntu, no multiverse, no universe -- infact, the only thing we'd done (aside from installing the foomatic printer drivers and configuring ufw to do basic firewalling) was install the binary codecs in the .gstreamer-0.10/plugins/ directory, as directed by the instructions.

By new user -- I mean someone who is planning on updating from Windows 98 to something for the first time, has enough computing power to run a non-Microsoft based operating environment, but not enough to run Vista and has heard enough people rabbit on about how good it could be to finally bite the bullet.

So, having hit the wall -- I fired up Totem from the command line using: totem --gst-debug-level=2 (which outputs minimal debug spew to the console) and found:

** Message: Error: File "/home/paul/.gstreamer-0.10/plugins/libmch264dec.so.7.4.0.20778" could not be used.
fluh264dec.c(414): gst_fluh264dec_setup (): /play/decodebin1/fluh264dec0:
Could not open module: libstdc++.so.5: cannot open shared object file: No such file or directory

After hunting around, the libstdc++5 package from the universe repository was installed, Totem was restarted and now happily displays the file correctly, albeit with a major visual issue when you use the arrow-keys to rewind the movie, but that's a story for another day.



Unfortunately, there's no documentation on the website, or in the tarball that tells you about needing to install older, relatively unsupported libraries to get something to play, hence this post.

I just hope the next version is compiled against something slightly more recent, so it works out of the box in future.

Customising the GNOME Screenshot Application

Circa GNOME 2.20, the screenshot application became simplified -- it now just takes the screenshot of your entire desktop, with borders and asks you to save it somewhere.

What happens if you'd like to take a screenshot of a specific window, or remove the borders, or add a drop-shadow, or do any sort of resizing?

You can make a custom launcher for it. Luckily, none of the backend settings were removed, the user interface was just tided up.

First, right-click on your desktop and select 'Create Launcher' from the menu, which should take you to the configuration screen -- consisting of four boxes you will need to fill in.

In the Application drop-down box, make sure: Application is selected.

In the Name text-box, you enter the name of the launcher, Take Screenshot is a good choice, but you can call this anything you want.

In the Application text-box, you need to add the program with the options you need, you can select from:

--delay=X -- Delays the screenshot for X seconds after you double-click the link, very handy if you need to take shots of a menu bar or dialogue.
--window -- Takes a shot of the current window instead of the entire desktop.
--border-effect=X -- Takes a unmodified screenshot if you use 'none', adds a 2 pixel drop-shadow if you use 'shadow' or a 1 pixel black border if you use 'border'.
--window -- Takes a shot of the current window instead of the entire desktop.

The Comment text-box is optional, it offers you the ability to make a longer description of the launcher if you highlight it on the desktop, because of the options we've used above, we'll call it: Takes Screenshot of the current window after 10 seconds.

When you are finished, your launcher screen should look like the one below:



Click on the OK button when you're happy with your settings -- and the launcher should appear somewhere on your desktop.

OpenSSL Vulnerability for Ubuntu 6.06 LTS

Had a phone-call earlier about this as well as a few e-mails since DSA 1571-1 appeared, so i thought i'd post this here in order to respond to multiple birds with one stone.

Servers that run Ubuntu 6.06 LTS in it's default configuration (or it's LAMP configuration) are not vulnerable to the OpenSSL problem, because they are running OpenSSL 0.9.7, not 0.9.8c-1, which is the first version to exhibit the bug.

Systems which are running any of the following releases are vulnerable to this bug:

• Ubuntu 7.04 (Feisty)


• Ubuntu 7.10 (Gutsy)


• Ubuntu 8.04 LTS (Hardy)


• Ubuntu “Intrepid Ibex” (development): libssl <= 0.9.8g-8


• Debian 4.0 (etch) (see corresponding Debian security advisory)

This is not mean that you shouldn't check your users keys -- if you've got users who use affected versions of Debian or Ubuntu (above), you should use the dowkd.pl script available here (GPG key) with the user option to scan your servers for users who have potentially compromised keys.

You can scan the local server using:

perl dowkd.pl host localhost

... and local users with keys using:

perl dowkd.pl user

If you see something like:

/home/[username]/.ssh/id_dsa.pub:1: weak key

You should re-generate keys for that user, using:

ssh-keygen -t [rsa/dsa] -b [1024/2048/4096]

... depending on your individual security needs.

note: If you see:

/home/[username]/.ssh/id_dsa.pub:1: 2048 bits DSA key not recommended

You are not necessarily vulnerable, there's nothing wrong with using 2048-bit DSA keys, as longer key lengths provide better security at the cost of decreased performance.

note II: Using a blank passphrase for your public key is strongly discouraged -- if a would-be-intruder can just press the ENTER key to enter your machine, what security is a public key?

(The most-used analogy I have for passphrase-less SSH keys is: 'A public key with a passphrase is like a door with a lock -- without one, it's just a door.)

Blank Text Area in Zen-Cart?

Have you ever been editing a product description, or a category title in Zen-Cart and had the field go blank?

Since updating a bunch of older 1.2.x stores to 1.3.x, I have -- and customers don't like data entry at the best of times, let alone when you have to tell them to edit it down to less than 200 characters and try inputting all again, rather than just editing out the excess characters.

So i've spent the day tracking down a solution, which happens to be via the javascript counters for the various products.

If we look at /includes/modules/pages/product_info/jscript_textarea_counter.js

Line 8-10 states:

if (excesschars > 0) {
field.value = field.value.substring(0, excesschars);
alert("Error:\n\n- You are only allowed to enter up to"+maxchars+" characters.");

If you change that to read:

if (excesschars > 0) {
field.value = field.value.substring(0, maxchars);
alert("Error:\n\n- You are only allowed to enter up to"+maxchars+" characters.");

You'll find you get the error, rather than the field going blank -- because it gives the user the ability to then edit what they've typed, it's a much better solution to the problem.

note: If you use "Free Shipping" for any of your products, you should also apply this fix to the /includes/modules/pages/product_free_shipping_info/jscript_textarea_counter.js file (the files are identical).