Posted by gmendoza on June 14, 2007 under Tech Tips | 
WARNING! THIS POST HAS BEEN MARKED AS OUTDATED!
While there may be useful information still contained within the article, there may be other more relevant articles out on the Internet. Please pay close attention to version numbers of software that this article refers to. If you're not careful, you could break your system if you do not understand what you are doing. If you would like to see this article updated, please contact the site administrator using the Contact page. Thanks!
Update: 04/22/2009
The following post is pretty outdated, and while it’s still relevant, I do not use Gnomad2 any more. I prefer other applications such as Banshee, Rythmbox, and Amarok. Banshee is by far my favorite because of it’s simplicity, clean interface and album art support. KDE users will probably prefer Amarok, and Rhythmbox is by far the simplest. All of these devices have MTP and iPod support, and are available in virtually every distribution repository.
Original Post:
If you would like to get your Creative Zen V Plus or related portable music player working in Ubuntu 7.04 and above, you’re in luck!
All you need is “Gnomad2″ (please see updated notes at the top of this post) as the graphical front end to your players music and playlists, and several libraries that are installed as dependencies (i.e. libmtp5). MTP stands for Microsoft Transfer Protocol, and libmtp5 is the key component to making this work.
As of this writing, the Creative Zen V Plus was not added to the libmtp5 udev rules file. This means that you would need root privileges to run Gnomad2, unless you changed the default permissions. No worries… correcting this is very easy to do.
1. First, install “Gnomad2″. The required dependencies will be installed by default.
sudo apt-get install gnomad2
2. To allow access to the Zen player using your normal user account, you must specify which permissions the device should have applied to it. These permissions can be set easily in a file supplied with the libmtp5 package. Edit the file as shown below.
sudo gedit /etc/udev/rules.d/65-libmtp.rules
Simply add the following and save your changes:
# Creative Zen V Plus
SYSFS{idVendor}=="041e", SYSFS{idProduct}=="4152", SYMLINK+="libmtp-%k", MODE="666"
Note: You may need to verify that the “idProduct” variable matches your device Product ID. To obtain this information perform an “lsusb” after plugging in the Zen player. The output will look like the following:
sudo lsusb
Bus 005 Device 007: ID 041e:4152 Creative Technology, Ltd
<snipped for brevity>
In the above example, “041e” represend the Vendor ID (Creative), and the second number to the right, “4152” is your Product ID (Zen V Plus). If your device is different, simply change the values accordingly.
3. Re-plug your Zen player and wait for it to fully initialize to it’s final on-screen display. Start Gnomad2, and have some fun!
For more information on how to use Gnomad2, check out their website: http://gnomad2.sourceforge.net/
Posted by gmendoza on June 5, 2007 under Tech Tips |
If you’re not going to use tapes, CD’s, DVD’s, or other form of attached media for storing your backups, you’re more than likely going to use some form of a remote network storage repository. There are many ways to ship your *nix backups across a network to a remote file system. Using SSH (and its related tools) is among the most popular methods for this delivery process as it can be relatively fast, free, secure, and very flexible.
In the following examples, I’ll show you three ways to ship an archived folder to a remote SSH server.
Method 1: Secure Copy
Using ‘scp’, (secure copy), one can take any existing file and deliver it to an SSH server. This means that you can create a backup, store it temporarily to your “local” file system, and copy the file across the network.
In this example, one backs up a folder in their home directory called “myfiles” using tar and gzip compression, and then copies the resulting archive using scp to a folder called /archives on a remote SSH server.
$ tar -czvpf myfiles.tar.gz ~/myfiles
$ scp myfiles.tar.gz user@sshserver:/archives/
$ rm myfiles.tar.gz
Cool stuff, but the downside is two-fold:
(1) If your backup is larger than the available space on your local file system, this method obviously won’t work;
(2) If your backup is large, the entire process takes a little longer than you might find convenient, since you have to first create the backup, and then copy it across the network.
A better solution would be to start sending the backup during the file creation process, which leads us to to the next two methods.
Method 2: Concatenate to SSH
SSH can read from STDIN and print results to STDOUT, which means one can concatenate any type of “input” to a remote SSH server. For example, you could redirect the output of ‘tar’ using the following syntax:
$ tar czpvf - ~/myfiles | ssh user@sshserver "cat > /archives/myfiles.tar.gz"
As you can see, with a single command, you can both create and deliver the backup at the same time. The backup process does not take up any space on the local file system. Wicked cool!
There is however yet another way to accomplish this task as shown in the next section.
Method 3: Write to an SSH File System (SSHFS)
For those of you not familiar with SSHFS, this is a file system client based on SFTP and FUSE. This client allows you to mount any remote SSH server to a local empty directory, just as you would with other devices like CD/ROM’s, floppies, usb sticks, etc. What’s also great about this client is that it requires no server side modification. It’s resource friendly, and sending data is just as fast as any other SSH file transfer.
In Ubuntu 7.04, the fuse kernel module and utilities are installed by default, and sshfs is available in the repositories.
Once you have sshfs installed and working, the following example mounts the remote “/archives” directory to the local “~/temp-mount” folder, and then places the backup directly in the mounted file system. The file is transported across the network during the write process.
$ mkdir ~/temp-mount
$ sshfs user@sshserver:/archives ~/temp-mount
$ tar -czvpf ~/temp-mount/myfiles.tar.gz ~/myfiles
To unmount the directory,
$ fusermount -u ~/mnt
Conclusion:
As you can see, using SSH for the delivery of your backups can make your life a whole lot easier. A suggested practice would be to use DSA/RSA public key authentication for making SSH connections. This way, you don’t have rely on passwords every time the SSH client is used, which makes sense when applying any of the above examples to an automated process such as Crontab, or At.
Posted by gmendoza on June 3, 2007 under Tech Tips |
If you ever need to work with a large file and wish you could split it into smaller pieces, you’ll be pleased to know that it’s extremely easy to do in Linux. You can use the “split” utility that comes standard with most *nix variations. Lets take a look at a couple easy examples.
To create a test file to work with, the following will create one that’s exactly 100 megabytes. Note, I am using ‘dd’ with /dev/urandom to demonstrate that the results of the split and reassembly are completely accurate. This will be accomplished via md5 hash comparisons at the end of this process.
$ dd if=/dev/urandom of=testfile bs=1k count=102400
102400+0 records in
102400+0 records out
104857600 bytes (105 MB) copied, 23.2982 seconds, 4.5 MB/s
$ ls -lh testfile
-rw-r--r-- 1 gmendoza gmendoza 100M 2007-06-03 22:45 testfile
To split the file into five 20MB files, use the split command as shown below. Note, I am producing five files with a new naming convention of “splitfiles”.
$ split -b 20971520 -d testfile splitfiles
Verify by listing all files that begin with “splitfiles”. Below, you see the new files with the appropriate sequence numbers as a result of the split command.
$ ls -l splitfiles*
-rw-r--r-- 1 gmendoza gmendoza 20971520 2007-06-03 22:47 splitfiles00
-rw-r--r-- 1 gmendoza gmendoza 20971520 2007-06-03 22:47 splitfiles01
-rw-r--r-- 1 gmendoza gmendoza 20971520 2007-06-03 22:47 splitfiles02
-rw-r--r-- 1 gmendoza gmendoza 20971520 2007-06-03 22:47 splitfiles03
-rw-r--r-- 1 gmendoza gmendoza 20971520 2007-06-03 22:47 splitfiles04
To reassemble the smaller files back to their original state, concatenate them together using a simple redirect.
$ cat splitfile* > newtestfile
… and list again to show your handy work…
$ ls -lh newtestfile
-rw-r--r-- 1 gmendoza gmendoza 100M 2007-06-03 22:52 newtestfile
As proof that both the original and newly reassembled files are exactly the same, check the results of a cryptographic md5 hash:
$ md5sum testfile newtestfile
54a07d5011ca893eddfab29960a7f232 testfile
54a07d5011ca893eddfab29960a7f232 newtestfile
Cool stuff.
