Digitivity » Power User

How to Rename Files as Lowercase in Ubuntu Linux Recursively

Digitivity — Sun, 27 Dec 2009 21:08:38 +0000

Some reasons you might want to lowercase your filenames include:

1. Most webservers are case-sensitive. Because of this, most websites stick to the rule of having all files in a single case, namely lower.

2. If you’re using the command line to manipulate files, it’s easier when all the files are lower case. It’s a lot faster to type in all one case.

But it’s too time consuming to rename each file individually, so here are a few ways to rename. These are adapted from the commandlinefu website. (But the commands there have some bugs, so keep reading here.)

Renaming all the files in the current directory from uppercase to lowercase

rename 'y/A-Z/a-z/' *

This uses the rename script which is included with Perl, which in turn uses Perl’s rename function.

Most Linuxes and Unixes include Perl these days, including most web hosts. It’s easier and more succint than the alternatives.

Renaming all files from uppercase to lowercase in the current and subdirectories recursively

The way to do this is to feed rename a list of all files in the current directory and its subdirectories:

find . -type f -print0 | xargs -0 rename 'y/A-Z/a-z/'

Here’s what it means:

find prints a list of all files in the current and all subdirectories, recursively. -type f means only print the names of files, and not directories.

The | takes the output of the first command and sends it as input to the second command.

xargs takes the input (which is a list of files) and executes rename once for every filename, while appending the filename to the end of the rename command.

Normally, find puts a newline between each filename. But since a file’s name can also contain newlines, you make find delimit the filenames with a null character (ASCII 0). You do this by specifying the -print0 option. But you also have to tell xargs not to view newlines or spaces as filename delimiters, but rather only the null character. You do that with the -0 option.

Renaming files to lowercase without using Perl

Occasionally, you might not have access to Perl.

In such cases, you can use straight POSIX shell commands:

find . -type f|while read f; do mv "$f" "$(echo $f|tr '[:upper:]' '[:lower:]')"; done

This is an alernative that’s faster:

find . -type f -execdir sh -c 'mv "'{}'" "$(echo '{}'|tr '[:upper:]' '[:lower:]')"' \;

How to Log in to a Webserver Without a Password Using SSH Public Keys on Ubuntu

Digitivity — Fri, 25 Dec 2009 17:13:08 +0000

You can avoid the annoyance of typing in your password every time you want to log in to your webserver (or other computer) by using public keys with SSH.

What Is SSH?

SSH is the Secure Shell protocol, which is a way for two computers to talk to one another without anybody being able to decode what is being said even if the interloper were able to access the raw network communications between the two computers. This is similar to the way web browsers use SSL (Secure Sockets Layer) to talk with e-commerce and other secure websites.

SSH is mostly used for shell access (typing commands for a remote server to execute) and for authenticating SFTP (Secure FTP), which allows downloading and uploading files to and from remote computers.

Password Annoyances

Usually, you’ll type in a username and password to authenticate yourself to the remote computer. But that gets boring real quick. Often you’ll be tempted to set an easy password, just to make it easier to type in again and again. Yet that’ll obviously decrease your security.

Add in the fact that many SSH clients tend to get stuck or boot you out if you don’t continuously use the connection, and that means plenty of password-retyping.

Solution: SSH Public Keys

The answer is SSH public-key based encryption. Public-key based encryption relies on two pieces of information: One, a secret and private key which you keep in a secure location (i.e., your home directory), and the other, a public key which you place anywhere you want to log in to.

The key is actually a long number, but it’s usually expressed as a series of number and letters when written to your hard drive.

I won’t go into the details of public/private key encryption here, but let it suffice to say that the remote server, encrypts a some data with your public key. The only way to decrypt that data would be if you had the private key, which your local computer does. After it does the decryption, the remote computer is able to trust that you are really you.

Passwordless Login

OK, since the only thing you need to log in to a remote computer is a private key, you don’t need to enter the password associated with your remote username. Hence, you’ve achieved passwordless login.

Now, since the private key can be used to log in to any one of your remote accounts, you might want to protect it. You can specify what is called a “passphrase” for it at the time your create your private key. That might seem slightly paradoxical, since having to enter a passphrase for your private key instead of a password for your remote server doesn’t seem like an improvement.

There are ways to have a passphrase, and also not have to enter it in again and again, but that’ll be the subject of another post. For now, anyway, if your personal computer is secure, and you want things to be easy, just don’t specify a passphrase.

Creating a Private Key

To start using SSH public key encryption, you need to create a private key.

Note: be sure SSH is installed for your operating system. It will usually be installed by default on Ubuntu (and just about any other Linux/Unix based system).

To create a private key, use the ssh-keygen program. Type ssh-keygen in a terminal:

js@buntu910wd:~$ ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/home/js/.ssh/id_rsa):

When prompted for which file you want to save the key in, just press Enter for the default.

If you want to have passwordless logins, don’t enter a passphrase when prompted. Just press Enter twice:

Enter passphrase (empty for no passphrase):
Enter same passphrase again:

ssh-keygen creates the key and then tells you where it saved it:

Your identification has been saved in /home/js/.ssh/id_rsa.
Your public key has been saved in /home/js/.ssh/id_rsa.pub.

Your public and private keys are saved in a hidden folder called .ssh in your home directory. The ssh-keygen program sets permissions to allow only yourself to read the private key, but if you want to be sure, just do an ls -l:

js@buntu910wd:~/.ssh$ ls -l
total 12
-rw------- 1 js js 1675 2009-12-25 16:29 id_rsa
-rw-r--r-- 1 js js  395 2009-12-25 16:29 id_rsa.pub
-rw-r--r-- 1 js js 2210 2009-11-27 19:07 known_hosts

Note: id_rsa is the private key. Guard it well. If someone is able to copy that key, he will be able to log in to any of your remote accounts.

id_rsa.pub is the public key. No one can log in to your remote accounts just by having your public key, but there’s no reason to spread it around, either.

Installing the Public Key

To use your public and private keys, you have to install the public key on each remote server you want to access without a password.

The way that SSH works by default, it looks for public keys in a file called authorized_keys in the .ssh directory. The public keys are are just long sequences of text in a single line.

You can have more than one key in an authorized_keys file (for yourself, or to allow others to log on).

If you’re setting up SSH keys for the first time, you probably won’t have an authorized_keys file on your remote server. So you can just copy the file that contains the public key to a new file calle authorized_keys:

cp .ssh/id_rsa.pub ~/authorized_keys

Then upload the authorized_keys file to the remote computer’s .ssh directory. If you don’t have a .ssh directory on the remote computer, create one:

mkdir ~/.ssh

Important: Be sure you upload your public key, and not the private key. The public key has a “.pub” file extension.

Then, set the permissions on the authorized_keys file to allow only your account access to the file:

chmod 600 ~/.ssh/authorized_keys

Log in Without a Password

Now go to a terminal and log in to your account:

ssh johnsmith@example.com

If all goes well, ssh shouldn’t ask you for your password, like so:

js@buntu910wd:~$ ssh johnsmith@example.com
johnsmith@example.com's password:

Since sftp uses the same authentication mechanism as ssh, you can use the sftp program without passwords, as well.

Summary

Create a private/public key pair with ssh-keygen.
Copy the id_rsa.pub file to authorized_keys.
Upload the authorized_keys file to the .ssh directory in your home folder on the remote server.
Set permissions to only allow your user to access the key files.

RedHat Relents on Fedora Software Installation Policy

Digitivity — Sat, 21 Nov 2009 17:48:17 +0000

I talked yesterday on how RedHat made a change to Fedora 12 to allow normal users to install any piece of (signed) software from the Fedora repositories without a root password. Slashdot reports that RedHat reversed the policy after an onslaught of community criticism. Owen Taylor (longtime employee of RedHat) made what seems to me to be quite a balanced statement of the situation.

Basically, he said that, instead of asking for the root password every time the user wants to do something out of the ordinary, it’s better to define what users can do what, and let them do it. Teaching users to enter their root password all the time just sets them up to give the root password to a possibly malicious program.

This had been discussed as part of an overall framework for PolicyKit (a granular permissions system for Linux), along with a GUI for setting what users and groups can do what. What happened in Fedore 12 was the the maintainer (Richard Hughes) went ahead and made the policy change allowing for user software installation without the GUI being ready.

So now RedHat has decided to make the user enter the root password when installing software in this release. In future releases, the other PolicyKit elements will be present, thereby allowing some changes in the software installation policy.

This is actually a balanced approach, and I think this’ll actually be better for both security and user experience in future Fedora (and other Linux) distributions.

RedHat’s Fedora 12 Lets Users Install Software Without Root with PolicyKit

Digitivity — Thu, 19 Nov 2009 17:44:53 +0000

The latest version of RedHat’s Fedora Linux distribution features the ability for users to install software packages without having root privileges. On the one hand, RedHat employees are saying this is only due changes upstream from PolicyKit, but on the other hand, those same employees defended the decision saying that turning off this ability requires only a trivial change by administrators.

This sparked a melee on Slashdot, which reported on the situation, with most posters arguing vigorously for not allowing the PolicyKit changes. Basically, allowing users to install any and all packages (even if they are signed) opens up the possibility of many attacks and problems, not all of which can be foreseen, but that’s the point: The Unix philosophy has always been to give the least amount of privilege necessary to do the job. But RedHat’s Richard Hughes disagrees:

I don’t particularly care how UNIX has always worked. Looking at the use-case and the things people are trying to do this seemed the best default. Admins can trivially change the default on machines if they wish.

User dedded expressed the outrage from users:

This is not only a huge change from previous Fedora behavior, it’s contrary to every other version of Linux or Unix with which I’m familiar (and VMS, and comment #72 makes the claim for OSX). And it wasn’t announced.

Some of the early comments in this bug are disturbing in a breaks-the-trust kind of way. Comment #8 is just rude. Comments #14 and #15 try to shut the bug down without discussion. Comment #9 claims that admins can “trivially change the default”. But this “trivial” change apparently involves a new command (there’s no pklalockdown on my F11 system) with an obscure switch, or six lines of obscure configuration in an equally obscure location (five subdirectories deep!). (Why is system configuration under /var and not /etc?) And a subsequent comment claims the pklalockdown option goes away in the next polkit release.

The fact that the change wasn’t announced seems to add to the feeling of many in the community that Fedora is nothing more than a testing ground for RedHat, and RedHat doesn’t really care for a good user experience in each release of the distribution.

Dreamvue: A Desktop App to Manage Your Dreamhost Account

Digitivity — Mon, 01 Jun 2009 03:42:11 +0000

Dreamhost recently (within the last few months) released a remote API to manipulate accounts and get account information. They’re holding a contest for the best apps using the API.

Digitivity.org presents Dreamvue, the Desktop Dreamhost Management App.

Click the picture for more info.

Dreamvue Dreamhost Desktop Management Application

How to synchronize audio and video in VLC

Digitivity — Mon, 08 Sep 2008 17:15:46 +0000

Sometimes, a video’s audio isn’t synchronized with video for some reason or another. To sync audio and video on the fly in VLC:

In VLC 0.9.4: press Ctrl+k to increase delay, and Ctrl+l to decrease delay.
In VLC 0.8.6: press k to increase delay, and j to decrease delay. That’s without holding Ctrl.

If you decrease delay below 0, you will then be, in effect, delaying the video.

Each press of the key combinations changes delay by 50 ms.

How to Serve Your WordPress Blog from the Root Directory If It’s Installed in a Subdirectory

Digitivity — Thu, 10 Jul 2008 13:56:18 +0000

If your blog is the main point of focus for your website, you probably want to it serve your pages when a user hits the root of your website, such as:

http://example.com/

But, for the sake of keeping your root directory organized on your webserver, you might not want to install WordPress in that directory. Rather, you might want to install WordPress in subdirectory, such as “blog”.

Edit the .htaccess file

Open the file named “.htaccess” in the root directory. Or create one if it doesn’t exist. Add the following to it:
# BEGIN WordPress RewriteEngine On RewriteBase / RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d RewriteRule . /index.php [L] # END WordPress

Create an index.php file

Create a file in the root directory called “index.php”. Assuming your WordPress is installed at the /blog subdirectory, add the following to the file:
define('WP_USE_THEMES', true); require('./blog/wp-blog-header.php'); ?>

Change the blog URL in WordPress options

How to Play a Quicktime Movie That Isn’t Playing in Your Browser

Digitivity — Mon, 07 Jul 2008 16:08:25 +0000

Even though Flash FLV movies have become something of an Internet standard, some sites persist in presenting movies in Quicktime format. Here’s how to view them if you have trouble playing them in your browser.

Reasons Quicktime movies might not play in your browser might include:

You don’t have the latest Quicktime plugin installed.
You don’t care to launch the Quicktime plugin.

I usually skip embedded Quicktime movies just because the plugin is so heavy. It takes a while to start up, and it takes up additional memory after it’s done. This is unlike the Flash plugin, which is always loaded since it’s needed for so many websites.

So what I do is just do a “View Source” on the page (View: Page Source in Firefox). Then I search for the Quicktime movie URL. You can do this by searching for the text string “.mov”. An example would be:

Just get the URL:

http://www.colorguides.net/movies/pantone_solid_colors_movie.mov

Take it and paste it into VLC at the File: Open dialog.
Of course, this means that you need to have VLC installed, but you should already have it installed.