JDPFu.com 2025

Sometimes you have the solution and don’t realize it. I’ve been using ccextractor for years – at least 4, probably longer, to pull Closed Captions from recorded TV and convert them into SRT files before including them in MKV containers. For years, I knew how to get CC1 and CC2 out – the ccextractor help was clear on that. However, there was no mention of CC3 or CC4 – which is where the English captions are placed by a popular Spanish language TV network.

I love how software is very interconnected these days – NOT.

This morning I needed some information about yard tonics that I know is here and discovered that the sidebar for the blog wasn’t working correctly. There was an error message, so no RSS, search, topics, categories, etc… I haven’t changed anything in the setup for months. Normal fixing steps:

• restart typo – no joy.
• restart the VM – no joy.
• check the logs for an easy answer – nothing.
• log into the admin interface and play around with the sidebar a little – that simply showed that all but the “static” plugin was broken AND that the drag-n-drop interface to manage sidebars was broken too.
• switch to a different browser and see all the same issues.
  Ok, so I think it is some remote javascript library causing the problems. I open the source for a page and see that only local javascript is used – I remember now, I didn’t like that remote code would run on my site, so I made a local copy. That’s why the first time you visit here, the page loads slow. Regardless, that’s not the issue.

Google – nobody else is reporting this problem since 2006 under IE6. I am definitely not running IE6 here.

There is a newer version of the code. With all the local tweaks, installing a new version can be a hassle. I’ve been meaning to move this VM to a different 12.04 host anyway … now is as good a time as any – plus it rained today.

In a few hours, this blog should be running on a new physical box, under a different hypervisor, the first VM in my long planned migration. I’d hoped to switch from KVM to LXC for this VM to use fewer system resources, but I’m not prepared for that today.

Wish me luck!

I still need to find that tonic recipe too. Got it, thanks to google again.

Over the last few days we had an outage here. A UPS used by the network infrastructure failed and nobody could physically get to it until sometime yesterday. Actually, nobody could trouble shoot the problem to know what actually caused the lack of connectivity.

Around here, we don’t have many failures and certainly not many failures that impact public-facing services for more than a few minutes. Sometimes the blog software is a little flaky and crashes, but since we are running a few instances behind a load balancer, the service shouldn’t be completely unavailable and should auto-restart if all instances fail. Overnight when we take backups, it is just easier to take down all instances of the blog for a few minutes, do the backup, then bring them back up. It takes just a few minutes – not a big deal in the middle of the night. Yes, there are other ways to do this in a non-impacting way.

Remember, this is a non-income-generating blog – like a front door to a small business. It is expected, but doesn’t make any money.

Perhaps a few readers would like to know more details?

Every few days or weeks, I look at the logs for this blog. It is out of interest only, since there aren’t any ads here and I don’t get paid to run the site or make the content. At the beginning of a new month, the referrer list can be interesting. Often those links are from UbuntuForums or Lifehacker or other websites where I’ve left relevant links back here. A few friendly websites also link back like My Linux Rig and even Wikipedia and WikiBooks.

I try to avoid ranting here and post articles when I’ve found a solution, not just a place to complain.

Today I need a timer/alarm app. These are common on Maemo, Android and I suspect other portable devices. I need finer control than a minute, so a calendar or cron entry aren’t viable solutions.

This seems like a very common need for users – get my attention in 2 or 12 or 55.3 minutes. That’s what I need too. It needs to be second accurate and should be built-into the clock app in a dock.

• cooking timers
• phone call reminder – suppose you want to be exactly on-time for a job phone interview?
• switch task reminder

You get the idea.

I prefer LTS Ubuntu releases because they come with 5 years of support – patches. They are usually a little more stable as well. The downside is that after about 18 months, developers usually stop developing for the older LTS release so new programs do not work on these older releases. For most desktop users, that is a huge negative and they will migrate to a non-LTS release. That’s find if you have 1 or 2 machines to maintain. That does not work when you have 10 or 2000 machines to maintain.

I’m excited about Ubuntu 12.04. My 8.04 and 10.04 servers AND desktops are feeling a little old, out of date, even with the weekly patching. 8.04 server is still supported and receives patches from Canonical. Most of the servers running here are still running 8.04 Ubuntu LTS which will be under support for another year.

It is time to migrate from 8.04 to 12.04. Thankfully, I have some time, about a year to make it happen. When it comes to servers, caution is best. Unplanned downtime is the enemy.

Below are my first impressions of a test install using VirtualBox. I do this just to become familiar with any changes to the installer and to check out the new install options. This install will probably last a week.

Ok, let’s get started.

Here’s a guy who accidentally cause over $1000 in charges on his cloud server by telling a google service about it. Google decided to download the data – all of the data – every hour with hundreds of crawlers. Nice.

Be careful out there. Some google services and many generic web crawlers do not honor the robots.txt.

It is no secret that I use rdiff-backup here, extensively. I’m a shell sort of person and like to automate things in shell scripts.

GUI Tools

Not everyone loves CLI/shell computing like I do. A few people won’t look at a solution that doesn’t include a GUI. Good news, JBackpack is a GUI for rdiff-backup. I haven’t tried it myself, but will at some point.

More Ways to Leverage rdiff-backup

For me, rdiff-backup is the right mix of capabilities and simplicity, so I’m excited that this brings another way to get more people to check it out.

Negatives

To me, there is a negative side to this tool – it is written in Java. That is enough that I’ll never install it on my machines, but I will on other peoples computers. Personally, I avoid Java programs and try to avoid having java runtimes installed on my systems over security concerns.

Enjoy.

• UbuntuGeek Article
• Other GUI interfaces

There are many different types of passwords. Some are for a financial institution and others are for blog comment websites and others are for your email accounts. Not all of these need to be 100% secure, but it would be easier if they were. If someone gets into a blog or forum account, so what, provided you have different passwords for each login. Good password management works. OTOH, if they get into your primary email account, that will provide access to almost every other account, including financial ones, with just a little effort. It would be best if there aren’t any breaches for these sensitive accounts – either through password cracking or other back-end cracks that we hear about weekly. That’s the ideal world. Reality is a little different.

The problem isn’t just about cracking your passwords today. The smarter cracker will retain your encrypted data/packets so they might be decrypted/cracked in the future. Yes, we need to protect our sensitive data not just for today, but for the next 20-40 years when 256-bit encryption will be trivial to crack. Perhaps protecting it for our lifetime is the best practice?

So, what can we do to minimize the future risks?

Password Managers

I love KeePassX and the cross-platform versions of this password manager, so I try to always use a long, complex, random, generated password for most of my needs. Sometimes a website limits the complexity to only 20 characters or just letters and numbers, significantly reducing the strength of the crypto alphabet. To counter act those limitations, I’ll try to use a nonsensical userid too. There are lots of other uses for a password manager that might be useful.

All this is stored inside a KeePassX database and automatically replicated to 4-10 different systems daily. The actual number changes since not all of them are always available. It is also backed up on many of these systems daily with 30 or 90 or 365 day versions available. The DB will not be lost. I would be sad if it became corrupted on my main system that I consider read-write, but any of the read-only versions are good enough too, if something bad happens.

High Value Targets

With all this data stored inside a file, that means my cracking just that 1 file, everything important to me can be known. It is a very high-value target. Lots of people do this with their password databases too. They trust the strength of the encryption as the only protection.

Future Cracking

That is a false sense of security. Here’s why. Just because some encryption cannot be cracked today, that doesn’t mean it can’t be cracked in 5 or 10 or 15 or 30 years. Anyone with a copy of the old file can crack it years later and gain access to sensitive data or passwords. It has been reported that the NSA has been recording SSL data packets on the internet for years – not because they can crack the crypto today, but for when they can crack it, then all that traffic will become available.

Keeping It Safe

There is no way to keep the data safe once it gets out, even if encrypted. At some point in the future, our 4096 AES encrypted data will be as easy to crack as anything encrypted with ROT13 is today. The point is that any current encryption will be trivial to crack in the future. Count on that. Here are a few steps to limit your exposure. You’ve probably heard most of them before:

• Use the strongest encryption possible.
• Use the longest keys/passwords possible, everywhere, not just for important data.
• Change your high-value passwords periodically, annually is probably often enough, unless there is a breach.
• Follow good password creation practices – which has been written about everywhere recently. There is no substitute for length.
• Try to prevent leaks of your passwords and password manager DB – don’t tempt fate.
• Other Techniques for Secure Passwords

About Future Cracking

Any encrypted packet, file, whatever-data, is only as secure as the crypto, passphrase, AND lack of access to the raw data can make it for your lifetime. In the future, we must assume that all our current state-of-the-art encryption will be cracked and the currently protected content will be available.

I use to offer my KeePass-database to anyone to show how confident I was in the crypto. That was stupid. Fortunately, nobody ever took a copy … unless it was on a USB flash drive I was sharing and they grabbed it without my knowledge. I can’t think of any of those people who are likely to spend more than a few hours on the file before deleting it. I could be wrong.

The file was also stored on a smart phone that was brazenly stolen during a recent trip overseas. It is out there now and forever. The smart phone had been reset to factory settings the day before the theft, SIM removed and the external SDHC memory was removed, my google account was not connected to the phone, but doing all that doesn’t remove all the data stored on the internal SDHC media. Some data is left behind, including my KeePassX database and a few photos. Of course, I had a strong passphrase on the DB, the phone was locked, but still, the general data on the device, not encrypted, could be recovered. I am not panicked about this, but I will be changing all the passwords over the next few months just to be certain. Obviously, the passphrase for KeePass has been changed too.

A little old, but perhaps you missed it too?

We’re all busy, so if you didn’t read the EUL from your Apple device(s) or software, the End User License , Richard Dreyfus has been kind enough to read it aloud for us.

I like this 4th Effective Until part as read with a German-English accent to make things clear.

Until Terminated without notice!