Posts Tagged Linux
By default, CrashPlan backs up everything in your home folder including all hidden directories (directories starting with a dot (.). This would include some directories your probably don’t want backed up, such as ~/.local/share/Trash (your trash) and a bunch of other hidden directories.
Fortunately CrashPlan’s file exclusion feature includes a way to specify exclusions by regular expression. Simply go to Settings > Backup and next to Filename Exclusions click the configure button.
Check the box for Regular Expression and enter this:
Click the plus sign, then ok, then save again.
That will exclude all the dotted directories from your backups.
Have any filename exclusions that you use on your backups? Feel free to share your rationale in the comments below!
So today I was using smbmount to mount a network share from my Synology DiskStation to my Linux PC when I noticed a rather annoying file permissions issue that I couldn’t seem to fix. Why am I using smbmount and not Gnome’s GUI to mount? Because I need root to have access to the file system as well so that CrashPlan can back up to it.
Here’s what happened:
First, I mounted the share (as root):
smbmount //diskstation/mike /mnt/mynas -o credentials=/home/mike/mike.cred,uid=mike,gid=mike
(For more information on the smbmount or the mount.cifs credentials file, see the Ubuntu manpage for mount.cifs)
That worked great, except for when I do this (as root)…
ls -ld /mnt/mynas
… I get the following output:
drwxrwxrwx 17 mike mike 0 2011-05-20 09:25 mynas
I sure didn’t want the directory world-writable. So I tried specifying
dir_mode as both
0755 using the following (as root):
smbmount //diskstation/mike /mnt/mynas -o credentials=/home/mike/mike.cred,uid=mike,gid=mike,file_mode=0755,dir_mode=0755
Then I checked it:
ls -ld /mnt/mynas
… and got:
drwxrwxrwx 17 mike mike 0 2011-05-20 09:25 mynas
That didn’t do anything at all to help. Why? Because as it turns out the DiskStation is using a Samba server with CIFS extensions and is passing the permissions to smbmount (mount.cifs). The
dir_mode options are ignored if the remote server is using CIFS extensions.
If the server does not support the CIFS Unix extensions this overrides the default file mode.
If the server does not support the CIFS Unix extensions this overrides the default mode for directories.
Source: Ubuntu manpages.
So there’s a couple of options here. First, I could set it to mount somewhere inside /home/mike, which would generally protect it. But I’d really like to know what’s up with the file permissions. So I did a little more Google-fu.
As it turns out, the CIFS extensions on the DiskStation can be disabled, all it takes is to edit a file. Lepoulpe posted on the Synology forums the following edit:
you can disable “unix extensions” in the ds106’s samba server. To achieve this, you need to add the folowing line in the [global] section of /usr/syno/etc/smb.conf :
So, I SSH’d into my DiskStation as root (should be the same password as ‘admin’ if you’re having trouble) and used the vi editor to make the edit. Afterwards, I restarted samba on the DiskStation by doing this:
Then I remounted the Samba share as root…
smbmount //diskstation/mike /mnt/mynas -o credentials=/home/mike/mike.cred,uid=mike,gid=mike,file_mode=0750,dir_mode=0750
… and checked the permissions:
ls -ld /mnt/mynas
… and got the following output:
drwxr-x--- 17 mike mike 0 2011-05-20 09:25 mynas
So now I have /mnt/mynas mounted to my share on the DiskStation. If I wanted it to mount on boot, I could add something like the following to /etc/fstab:
//diskstation/mike /mnt/mynas smbfs auto,credentials=/home/mike/mike.cred,uid=mike,gid=mike,dir_mode=0750,file_mode=0750,user 0 0
Questions about my method? Have any feedback or alternate methods to share? Please feel free to do so in the comments below. Thank you!
For about a week now I’ve been wrestling with implementing a system where CrashPlan would backup to my network drive. I ran into a really bit problem: When you mount a network location in Gnome using the GUI (gvfs), root can’t access it. Since the CrashPlan engine runs at root, it makes the network location unusable as a backup destination.
After a while of working on different ways to solve this rather large hurdle, I came up with the idea of simply mounting the network location using smbmount (mount.cifs). After some testing and tweaking, I was able to get it successfully working and added an entry to fstab to have it mount at boot time. I chose /mnt/mynas as the mount point.
See Synology DiskStation and Samba mount permissions for my method of getting it mounted with the correct file permissions.
Once it was set to mount at boot-time, I can now open the CrashPlan client and set /mnt/mynas as a destination folder, and now I have both local and off-site backups!
Feel free to share your thoughts and/or feedback in the comments below!
Every now and then I’ll run into an issue with a website’s uploader. They ask me to upload a picture, but then when I click their upload button, none of my pictures appear in the dialog. After troubleshooting for a few, it turns out that they’re limiting file masks to [*.jpg, *.jpeg, *.bmp, *.png] etc. But — because I copied my pictures over from a windows installation, they have all-capital file extensions. Linux uses a case-sensitive file system, so it regards these as different. Renaming a file to a lowercase extension [*.jpg] caused it to show up in the dialog which is what I wanted — but manually renaming thousands of pictures in dozens of directories was out of the question.
I could have written a bash script to do the renaming in a few minutes but I found something better — convmv. This simple utility makes filename conversions / renaming a breeze. By default, it runs in ‘test’ mode so that you can see what will happen before it does the job.
For my case, I needed to rename all the files to lowercase, so I used:
convmv --lower *
That showed me a verbose listing of everything it would do (test mode). However, I wanted to do the entire Pictures folder and everything under it. The new command from my Pictures folder became:
convmv --lower -r *
To get it to actually do the job, I had to specify
--notest as well.
convmv --lower -r --notest *
It did it’s work within seconds and everything was lowercase. In my opinion, much easier and better than a bash script.
Convmv has plenty of other options, so next time you need to do filename conversion, check it out.
Questions, comments, feedback? Please share in the comments below. Thank you.
Occasionally you may need to check to see if you’re running 32-bit or 64-bit Linux installation, such as when you’re installing third-party software and they offer 64-bit specific versions.
Fortunately, there’s a very easy way to tell. Simply open a terminal and run the following command:
You’ll receive one of the following as output:
i386 indicates 32-bit.
x86_64 indicates 64-bit.
Note that this only states what OS version you’re running, and not necessary the capabilities of the hardware — such can be the case if you installed 32-bit Linux on 64-bit hardware.
If you want to find out if your processor actually supports the 64-bit instruction set (‘long mode’), run the following:
cat /proc/cpuinfo | grep lm
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 popcnt lahf_lm arat dts tpr_shadow vnmi flexpriority ept vpid
The ‘lm’ in the flags indicates 64-bit support. Without it, the processor is certainly 32-bit.
For the security-minded, or anyone who simply wants to be able to exchange secure, encrypted email quickly and easily, GNOME offers a really user-friendly way to generate and manage PGP/GPG keys. This program is located at System > Preferences > Passwords and Encryption Keys. [Natty/Unity: System Settings > Passwords and Encryption Keys]
You can make a new key by going to File > New… > PGP Key. This guide explains some of the basic key management functions in this application.
Fill in the name, email, and an optional comment. PGP is considered a network of trust, so etiquette states you should use your common legal name (shortened versions are ok) and your primary email address (unless you have a reason to do otherwise). If you frequently go by a nickname, enter that in the comment field.
If you’re interested in the advanced options, you can change them by dropping down “Advanced Key Options.” I’m not going to go too much in to what the various options are, but here’s a quick run-down:
Encryption Type: RSA is generally considered stronger and overall a better choice than DSA. Choose “sign only” if you’re using this as a signing key, and not an encryption key. Only select that option if you know what you’re doing.
Key Strength (bits): The higher the number, the stronger the encryption, but the longer it takes.
Expiration Date: Set this if you want your key to expire at a predefined date/time, or set to never expire. Expiration keys can still decrypt messages, but no new messages can be encrypted to them.
After choosing your options, you’ll be prompted to enter your key pass phrase. DO NOT FORGET IT! Your key will be completely unusable (and you will be unable to revoke it) if you forget the pass phrase. On the same token, avoid making it too easy or guessable.
Next, the key will be generated. This could take a while depending on the key size and the speed of your computer.
Once your key is generated, your public keyring and private keyring will be stored in
~/.gnupg — NEVER distribute your private keyring (
secring.pgp). This is the decryption segment of your keyring.
Next, some more exploration through the Passwords and Encryption Keys application.
Right-clicking on a key gives you the following options, which I’ll explain briefly.
Properties: Here is where you can change your passphrase, add a photo, view your key’s fingerprint, and edit the expiration date and trust level.
Export: This is where you can export your public key for distribution to others (this is the portion of the key that you DO share). By selecting export, you will export an “ASCII-armored” file that can be pasted in email, etc.
Copy: Similiar to export, Copy copies your “ASCII-armored” public key to the clipboard. Makes it easier to post in email, web page, etc.
Delete: This deletes the key. Make sure this is what you want to do!
Sign Key: This is a core part of the key-sharing portion of PGP/GPG. This “signs” the key, using your key. This applies your signature to the key, explicitly stating that you trust the key to some degree. Once you’ve signed the key, you should export the key and send it back to the originator so they can begin distributing it with your signature attached.
So how do you sign a friend’s key?
First, have them export it and send it to you. Next, drag-and-drop the file into the Passwords and Encryption Keys window. It will appear under the Other Keys tab. Once the key has appeared, just right-click on it and click ‘Sign…’ Follow the prompts. Don’t forget to export the key and return it to the sender after you’ve signed it! Work this process in reverse for getting a friend to sign your key. Drag/drop the updated keys back into your key manager to add the new signatures. To verify signatures are present, double-click on the key and look at the Names and Signatures tab.
That’s a quick run-down of the key management functions.
Questions, comments, and feedback about key management are welcome and appreciated. Note that key management may be different in the Unity interface, which is shipped with Ubuntu Natty.
I just installed Ubuntu 10.10 (Maverick Meerkat) on to a Dell Vostro 1000. (Yea, yea, I know Natty is just around the corner). During the installation I dropped the terminal box down — ‘cus I’m like that — and noticed the following messages spamming the terminal log:
Apr 20 14:17:59 Vostro-1000 kernel: [ 2.814838] atkbd serio0: Unknown key pressed (translated set 2, code 0x8d on isa0060/serio0). Apr 20 14:17:59 Vostro-1000 kernel: [ 2.814844] atkbd serio0: Use 'setkeycodes e00d ' to make it known.
Unplugging the laptop’s AC adapter caused it to throw the same event, this time with code e06e.
After some research, it looks like various model laptops throw odd keycodes in response to AC adapter/battery events. The Dell Vostro 1000 seems to be the one that comes up the most in searches, but the Dell Latitude 131L (which is based on the same design / hardware) is mentioned in Launchpad bug #549741, which is specific to this issue. The Inspiron 1501 is mentioned in Redhat bug #454131.
There’s also the issue of the specific keycodes that are thrown. Myself, I saw e00d and e06e. The author at DezzaNet mentions e055 as well.
So how to get rid of these messages?
The two bug reports referenced above mention removing and replacing the battery while the system is on. However, that may not work in all cases. There’s another way to get rid of the messages, and that’s mapping the keycode to the NULL character.
To do this at every bootup, edit the /etc/rc.local file and add lines like the following above the
exit 0 statement:
setkeycodes e00d 255
Repeat for each keycode you will to null out.
Questions, comments, feedback regarding this? Feel free to share in the comments below. Thank you!
With recent Linux distributions (based on the 2.6.28 kernel) the Ext4 file system is considered stable and provides many improvements over Ext3.
Ubuntu systems running 9.04 (Jaunty Jackalope) had the option to format Ext4 during install time, but Ext3 was the default until 10.04 (Lucid Lynx). However, it’s possible (and fairly easy) to upgrade Ext3 to Ext4 in-place and without reformatting or reinstalling. Nice, huh?
The following guide is based heavily off the Ubuntu documentation, which some added steps and clarification. If you’re going to do this, use your head and make sure you have backups of your important data before you start, just in case. Also, don’t skip any steps, and double-check yourself along the way. A typo could ruin your day.
Zero – Before you start
Verify your kernel version by running
uname -r. Make sure it is 2.6.28 or higher. If it is not, STOP. Upgrade your kernel before attempting to proceed.
Also, check that you’re currently using Ext3 — this would be pointless if you’re already running ext4 — by using the mount command. You should see something like the following:
/dev/sda1 on / type ext3
This shows ext3 as the current filesystem type.
One – Turn off any automatic updating
Go to System > Administration > Update Manager. Click Settings and set Automatic Updates to Only notify about available updates. You want to make sure that the system doesn’t start applying an update halfway through this and give you the potential worst-case of an unbootable system.
Two – Prepare to load the Ext4 driver
Ext4 is backwards compatible with Ext3, which makes this update process as easy as it is. We’ll start by telling the system to load the Ext4 driver instead of the Ext3 driver at boot. This will allow the system to boot and run normally for the steps that follow.
Edit the file /etc/fstab in your favorite text editor.
gksu gedit /etc/fstab will do fine. Change any references for disks that you plan to convert from Ext3 to Ext4. Take a look at the example:
# /etc/fstab: static file system information. # # proc /proc proc defaults 0 0 # /dev/sda1 UUID=327c1819-14e1-4b96-b9d2-d5e55e50f1ae / ext3 defaults,errors=remount-ro,relatime 0 1 # /dev/sda5 UUID=900e39f2-ad49-42ee-a7f5-8e6807d6b35b none swap sw 0 0 /dev/scd0 /media/cdrom0 udf,iso9660 user,noauto 0 0
The above example shows an Ext3 filesystem on
/dev/sda1. I’ll use
/dev/sda1 as the file system for the rest of the guide for clarity. So, change
ext4 in the above file and save it.
shutdown -r now )
Three – Update the filesystem options
After rebooting, the kernel will be using the Ext4 filesystem driver, even though your filesystem on disk is still natively ext3. That’s what you want, you’ll be making the actual changes to the filesystem soon.
Now, run the following command to make the changes to your filesystem that adds the Ext4 features:
sudo tune2fs -O extents,uninit_bg,dir_index /dev/sda1
Note: There’s no spaces after the comma-separated options. Copy/paste if you’re not sure.
/dev/sda1, like I stated above. Change it if it’s not correct for you, or if you’re doing multiple filesystems, run it for each one.
Reboot again (
shutdown -r now )
Four – Take a deep breath
Due to the changes that tune2fs made on your filesystem, when you reboot you’re going to get the message
“Errors were detected on your filesystem, press ‘F’ to fix…” or something similiar. Press F and let it do it’s thing.
You may get the following error as well (I did):
The disk drive for for /tmp is not ready yet or not present. Continue to wait or ...
Just wait patiently. You’re waiting for the changes to finish on the currently-processing filesystem, and it’s just telling you that it’s trying to mount or access /tmp and it’s having trouble, due to the currently-running process.
After a few minutes (depending on the size of your partitions and the amount of data on them), everything will go back to normal and you’ll be able to log in again.
There’s just a few more steps.
Five – Reinstall grub
Run the following command to reinstall grub. Note that the partition number is omitted from the device path — this is intentional and correct.
sudo grub-install /dev/sda
You should get a message indicating the operation was successful.
If you are upgrading from 8.04 LTS to 10.04 LTS, you will need to install grub2 as soon as possible, as grub1 is not Ext4-aware. (Users running 9.04 are not affected by this.)
sudo apt-get install grub2
Once it’s done, no more reboots are really necessary, though you can always reboot to make sure grub actually reinstalled correctly. Files written from now on will be written with full Ext4 structures. You can also turn automatic updates back on at this point.
You can verify all the filesystem features are set by running:
sudo tune2fs -l /dev/sda | grep features
This is the list of ext4 features you should have set:
Filesystem features: has_journal ext_attr resize_inode dir_index filetype needs_recovery extent sparse_super large_file uninit_bg
If you’re missing one or more features, go back to step three above and check that you entered the command correctly.
Questions, comments, and feedback are welcome, as always.
Today, Royal Pingdom posted a somewhat-surprising blog entry that shows that the iPad alone, not any other iOS device like the iPhone or iPod touch, is used more than Linux computers.
Why is this only somewhat surprising? There’s plenty of reasons:
The positive about the Apple devices:
The iPhone and iPod Touch set the stage with — and raised the bar on — user friendliness in portable devices. The iPod was the device that some would argue re-made Apple. It quickly took over the portable media player market and set the new de-facto standard for what to expect in a music player: Lots of storage, and a simple, user-friendly interface. With the iPod Classic, new features brought even higher expectations. The iPod Touch and iPhone sealed the deal for Apple (and some would argue dealt AT&T a blow to the knees).
When the iPad arrived, it ran off the same iOS that the iPod touch did, which brought a familiar look and feel to iOS users. Drawing from the same App Store ensured that users would experience Apple’s touted “There’s an app for that” experience. In addition, the iPad pioneered the tablet experience to the mass market. Behind it’s launch, Android and Blackberry have struggled to gain market share.
The comparison to Linux:
When you compare the Apple iPad to the Linux market, it’s little surprise that the iPad comes ahead. Even the more popular Linux distros like Red Hat and Ubuntu, although moving ahead in leaps and bounds, still suffer their shortcomings with user friendliness and ease-of-use. Hardware quirks and incompatibilities often get the better of inexperienced users, who turn back to Windows or Mac for that lacking bit of hardware support.
Additionally, there aren’t many computer manufacturers who will sell systems with Linux pre-installed for an out-of-the-box experience. While Dell has sold systems with Linux pre-installed, and has sold select system with no OS, there’s a distinct bias in the new-sales model towards Windows. Why? Money. Microsoft pays the OEMs a commission for new-system sales with Windows pre-installed. On top of that, there’s less work for the OEMs to make sure that hardware works as expected. System76 has started picking up the pre-installed Linux market, selling systems with Ubuntu pre-installed, but the price is arguably higher than a system from another vendor, and I can’t speak to the warranty or support.
Don’t get me wrong, I’m a Linux user and I love it. But I’m not blind to the fact that it has it’s shortcomings — although Red Hat and Ubuntu have really worked towards making everything work as it should, and making the user experience the best possible. Linux also runs on a wider-range (and a more inexpensive range) of hardware than Apple OS. Also, you can’t ignore that this study has a big of a flaw in it: This only compared stats between iPod and mainstream Linux (desktops and laptops) — two completely different device platforms.
Apples to apples or apples to oranges? Do the numbers even mean anything at all? What are your thoughts?
I’ve been using VirtualBox for my Windows XP VM when I’m in linux to get a handle on those Windows apps that I absolutely need, and to sometimes address a piece of hardware that otherwise won’t work. One of the biggest issues I’ve had is a distinct lack of VirtualBox to address my BlackBerry — I absolutely must use my Windows hard drive to do it.
VMWare Workstation seems to overcome whatever shortfall exists in VirtualBox to address it, and I’m happy to say, it works quite well. However, now I have this VirtualBox hard drive image with all my software already installed, and I want to boot it in VMWare. How to convert it?
Fortunately, the VBoxManage utility of VirtualBox can actually convert a VirtualBox vdi image to the vmdk format used by VMWare. It can do it rather easily, as well.
The command format is:
VBoxManage clonehd | [--format VDI|VMDK|VHD|RAW|] [--variant Standard,Fixed,Split2G,Stream,ESX] [--existing]
"c:Program FilesOracleVirtualBoxVBoxManage.exe" clonehd "Win XP.vdi" xp.vmdk --format vmdk --variant standard
Absolute path to VBoxManage is necessary unless it’s in the Windows $PATH.
VBoxManage clonehd "Win XP.vdi" xp.vmdk --format vmdk --variant standard
Successful run gets this output:
0%...10%...20%...30%...40%...50%...60%...70%...80%...90%...100% Clone hard disk created in format 'vmdk'. UUID: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
Next, open VMWare and select Create a new virtual machine
Select “I will install the operating system later”
Make your OS selection about the OS that’s currently on the vmdk you will be using. (The guest OS, not the host OS).
Later on, you will have the option to use an existing vmdk image as your virtual hard drive. Do so.
You should now be able to finish setup and boot your converted disk image.
Note that creating a new machine and using an existing hard drive image is not a feature of VMWare Player. Workstation or another product is required. However, JoVa has shared a great workaround:
Since my tip for VMWare Player is not very clear on what to do exactly, I have the following, easy steps that you can follow, right after you started VMWare Player.
1) Select: Create new Virtual Machine
2) Select Guest Operating OS “Microsoft Windows” and select the version you have (for example “Windows XP Professional”)
3) Click “Next” and give a the virtual machine a name, for example “XP-pro”.
4) Click “Next” set the maximum disk size to the size of your actual virtual machine (important!)
5) Click “Next”and click “Finish”. The VM is created
6) Copy your VM (the .vmdk file) over the created (empty) .vmdk (e.g. xp-pro.vmdk)
7) Play the virtual machine
Questions, comments, or feedback is appreciated, as always.