Saturday, November 19. 2011
Gnome-Shell Extensions
Some weeks ago I realized that gnome-shell and all gnome3 packages were ready to be installed in my wheezy box. Cos I were (and I still am) very busy with a project I am involved, I decided not to upgrade my system at that moment. I had heard such bad comments about this new version that I felt afraid about the change (I was very comfortable with my old desktop). But I have always been a loyal gnome user so the previous weekend my new gnome3/gnome-shell environment was installed, tested and customized.
Obviously the bad comments about the new version are justified in the big differences between both versions. In my opinion plain gnome 3.0 (current version in wheezy), though very eye-candy, is very very restrictive and unproductive in its use. Lots of clicks are wasted to do the same thing you previously did in just one. This annoying fact is very related to the lost of many applets I usually managed (virtual desktop management, menus, launchers, window selector, weather,...), which made your life easier. But finally I discovered that gnome-shell introduces a new idea: gnome shell extensions. The gnome-shell uses extensions in a very similar way than firefox does but, right now, there is not a trusted gnome extension repository or a extension manager application (easy installation, auto-update and so on). But it is clear for me that it is planned for the near future.
I spent short time studying how extensions work and finally I realized they are a very good idea. From a technical view a extension consists in some JSON (configuration), JavaScript (code) and CSS (aspect) files (all HTML standards which is a good thing, at least for me). I am sure that you will can easily replace anything you did in gnome2 with a suitable extension in gnome3 but, as always, nowadays all this stuff is quite immature. One important aspect is that these extensions can also be installed in your ~/.local directory (you do not need packages from your linux distribution, although it is sure that some basic extensions will be installed by default in all distros, check this debian bug for example).
In order to configure gnome-shell and its extensions you better install gnome-tweak-tool application. But you always can do all configuration using typical gsettings command or dconf-editor application (utilities to manage the gnome configuration in general). So once I had understood new gnome-shell stuff I installed the following extensions to be comfortable with my new desktop:
Standard gnome-shell-extensions
Gnome itself has a collection of extensions (these are the ones that I think, at least, are going to be in any linux distro by default). I installed two of them:
- dock: Shows a dock-style task switcher on the right side of the screen (it replaces my typical launchers and window selectors). Next version 3.2 adds configuration properties for changing the default position and auto-hiding.
- user-theme: Loads a shell theme from ~/.themes/<name>/gnome-shell (I like to customize my desktop ).
The installation process is the following:
Get the source from GIT:
$ git clone git://git.gnome.org/gnome-shell-extensions
Go to tag gnome 3.0.2 (version of my current wheezy gnome-shell):
$ cd gnome-shell-extensions/ $ git checkout 3.0.2
Autogen, make and install them (only the two extensions):
$ ./autogen.sh --prefix=$HOME/.local --enable-extensions="user-theme dock" $ make $ make install
Right now there is a bug in glib-2.0 that it does not take into account extended schemas you have in your ~/.local/share/glib-2.0/schemas directory. So you have to copy the new schemas from there to the global directory and compile them:
$ cd ~/.local/share/glib-2.0/schemas/ $ sudo cp org.gnome.shell.extensions.dock.gschema.xml \ org.gnome.shell.extensions.user-theme.gschema.xml /usr/share/glib-2.0/schemas/ $ sudo glib-compile-schemas /usr/share/glib-2.0/schemas/
- All the themes for gnome3 (GTK, window manager or gnome-shell itself) can be download from gnome-look.org. They are installed as always inside ~/.themes and ~/.icons directories. Use gnome-tweak-tool to change any theme.
gnome-shell-weather-extension
Another applet I used to add to my gnome2 panel was the weather applet. An equivalent extension is the gnome-shell-weather-extension done by Simon Legner but it nowadays does not have several locations like the old applet . The installation is more or less the same:
Clone the repository with git (branch 3.0):
$ git clone -b gnome3.0 https://github.com/simon04/gnome-shell-extension-weather
Install:
$ cd gnome-shell-extension-weather/ $ ./autogen.sh --prefix=$HOME/.local $ make $ make install
Because of the commented glib2 bug you need to include the schemas globally:
$ cd ~/.local/share/glib-2.0/schemas $ sudo cp org.gnome.shell.extensions.weather.gschema.xml /usr/share/glib-2.0/schemas/ $ sudo glib-compile-schemas /usr/share/glib-2.0/schemas/
Then you need to set the city for the weather, in my case Madrid. I did it via gsettings (you can also use dconf-editor):
$ gsettings set org.gnome.shell.extensions.weather woeid "'766273'"
gnome-shell-workspace-indicator
Finally workspaces in default gnome3 needs too many clicks for me (I change working workspace very often to waste time doing that). So I installed another extension that adds workspace selection in gnome-shell toolbar. This extension has been incorporated to default gnome-shell extensions in latest version 3.2 (but it does not exist in the 3.0.2/wheezy version I installed in the first point).
The installation is pretty the same:
Clone the sources:
$ git clone git://github.com/erick2red/shell-extensions.git
Generate and install:
$ cd shell-extensions/ $ ./autogen.sh --prefix=$HOME/.local --enable-extensions="workspace-indicator" $ make $ make install
Installation of the schemas:
$ cd schemas/ $ sudo cp org.gnome.shell.extensions.workspace-indicator.gschema.xml \ /usr/share/glib-2.0/schemas/ $ sudo glib-compile-schemas /usr/share/glib-2.0/schemas/
I prefer wide indicator (with wide indicator you see Workspace 1 instead of the concise 1 you get with default configuration):
$ gettings set org.gnome.shell.extensions.workspace-indicator \ wide-indicator true
I tried to be comfortable but with the least number of extensions. Think you have to re-add them every time you upgrade gnome-shell version (until there was a better solution: a gnome extension manager infraestructure, distro provided extensions or whatever). My desktop currently has the following aspect.
I have written this entry because, as I commented before, I will need to update my extensions when a new version of the gnome-shell arrives (3.2 for example). I hope that shortly some extension management will come to gnome3 and all this stuff will be automatically done (as firefox does), but right now extensions need to be installed manually. There are a lot of them scattered throughout the internet and there are also several links which comment the must-have ones (for example this, this or this). Installation can be independent of the linux distribution (although some basic extensions will come by default for sure). I have only installed four extensions in my desktop: user-theme support, dock, weather and workspace. You can enable or disable extensions and customize them via gnome-tweak-tool (coarse-grained changes) and gsettings or dconf-editor (fine-grained configuration).
Finally I got the conclusion that gnome3 and its extensions are a brilliant idea. I think that, with a proper management and repository, its future is awesome but right now gnome3 falls a bit short. In my opinion that is the reason for all the bad comments and the negative impression of many users.
Long life gnome3!
Tuesday, August 16. 2011
Backing Up Data Into an Encrypted External Disk
Today entry deals with a common and usually annoying task, backing up your laptop, so this time the post is going to be more useful for me than for anybody else. Last week my company gave me a 2TB USB 3.0 disk to make backups of my laptop data. But there is a requirement, the backup File System should be encrypted. As always there is an absolutely clear procedure to make all the task in Windows but not in Linux or Mac. Besides the procedure involves a closed source program (a McAfee application) to encrypt the external disk. In my opinion the requirements have never to mention particular applications and only guarantee the final goal. I can understand that a lot of custom solutions would be a mess for the company (to recover data when a employee leaves the company or whatever) but, please, at least think about all the OSes and provide a step by step procedure for all of them (Windows, Mac and Linux).
The mate that gave me the disk finally told me that, as I use Linux, I did not have to encrypt the disk. But searching for information over the Internet (I knew nothing about disk encryption before) I realized that this task would not be very difficult. I found two good pages: 7 Steps To An Encrypted Partition (local or removable disk) and Setting up an encrypted volume on an external hard drive on CentOS. I also found a video of how to install Debian on a encrypted root file system (this task has nothing to do with the backup but I think it will be the next requirement for my laptop). So I finally decided to encrypt the disk anyways. This entry summarizes the setup for the two tasks using Debian, encrypting the disk and performing the backup.
-
Step 1. The first step is configuring the partitions inside the disk. I will use two partitions, one encrypted (for the backup and confidential or customer data) and other not (for general use). The first time I plugged the disk my Debian box recognized it as /dev/sdb, so from here the /dev/sdb1 will be the encrypted and /dev/sdb2 the normal partition.
# fdisk /dev/sdb
I deleted the FAT32 partition the disk came with and created two new ones. First partition (/dev/sdb1) of 1TB:
Partition number (1-4, default 1): Using default value 1 First sector (2048-3907029167, default 2048): Using default value 2048 Last sector, +sectors or +size{K,M,G} (2048-3907029167, default 3907029167): +1024G
And the second one (/dev/sdb2) with the rest of the disk:
Partition number (1-4, default 2): Using default value 2 First sector (2147485696-3907029167, default 2147485696): Using default value 2147485696 Last sector, +sectors or +size{K,M,G} (2147485696-3907029167, default 3907029167): Using default value 3907029167
After saving the changes the disk presents the following two partitions:
# fdisk -l /dev/sdb Disk /dev/sdb: 2000.4 GB, 2000398934016 bytes 255 heads, 63 sectors/track, 243201 cylinders, total 3907029168 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0xee7a7a06 Device Boot Start End Blocks Id System /dev/sdb1 2048 2147485695 1073741824 83 Linux /dev/sdb2 2147485696 3907029167 879771736 83 Linux
-
Step 2. It seems that for encrypted devices it is compulsory to write some random data in the partition (it is easier to decrypt a blank initialized disk). For this step there are various options (see the links I presented before) but I finally executed the badblocks command:
# badblocks -c 10240 -s -t random -v -w /dev/sdb1
Take care, in my 1TB partition this step took hours (my disk is giving around 26MB/s write rate).
-
Step 3. Now it is time to create the encrypted file system in the /dev/sdb1 disk partition. The method used in Linux to encrypt File Systems uses the dm-crypt kernel module and creates a virtual device below /dev/mapper (it is a kind of wrapper over the real /dev/sdb1 but encrypting the data before writing on disk).
First of all the package for the management command needs to be installed, the module has to be loaded in the kernel and added to the /etc/modules file (modules in this file are loaded at boot time).
# apt-get install cryptsetup # modprobe dm-crypt # echo "dm-crypt" >> /etc/modules
Once the module is in place the new encrypted mapper is created above /dev/sdb1. I have used default values and normal password setup (it is also possible to use a key file instead of a password, see this archlinux page for more information about this).
# cryptsetup luksFormat -v -y /dev/sdb1 WARNING! ======== This will overwrite data on /dev/sdb1 irrevocably. Are you sure? (Type uppercase yes): YES Enter LUKS passphrase: Verify passphrase: Command successful.
The default cypher is aes-cbc-essiv:sha256, sha1 for password hashing and 256 for key size (all this values can be changed using -c, -h and -s options of the command respectively). This is the summary for my device.
# cryptsetup luksDump /dev/sdb1 LUKS header information for /dev/sdb1 Version: 1 Cipher name: aes Cipher mode: cbc-essiv:sha256 Hash spec: sha1 Payload offset: 4096 MK bits: 256 UUID: ff088328-138a-4ca7-aa0a-5cbdd2064ce8 Key Slot 0: ENABLED Key Slot 1: DISABLED Key Slot 2: DISABLED Key Slot 3: DISABLED Key Slot 4: DISABLED Key Slot 5: DISABLED Key Slot 6: DISABLED Key Slot 7: DISABLED
Finally the new encrypted device is opened with backup name (the password is requested at this point).
# cryptsetup luksOpen /dev/sdb1 backup Enter passphrase for /dev/sdb1:
After the luksOpen a /dev/mapper/backup device is ready to be initialized and used.
-
Step 4. I have decided to use the new btrfs file system. The reason is that this next generation file system manages some nice features like on the fly compression and snapshots, encryption and some synchronization integration are also planned (see the project ideas). Obviously compression will save some space in the disk and snapshots let us create some backup copies with a minimal cost in terms of time and space (my idea is backing up data and maintaining some snapshots of the backups).
The btrfs module is currently marked as experimental in my 3.0.0 Debian kernel but its web page claims that since 2.6.31 only forward compatible disk format changes are planned. In order to create the FS the tools package has to be installed before.
# apt-get install btrfs-tools
Now the FS is made with BACKUP name.
# mkfs.btrfs -L BACKUP /dev/mapper/backup WARNING! - Btrfs Btrfs v0.19 IS EXPERIMENTAL WARNING! - see http://btrfs.wiki.kernel.org before using fs created label BACKUP on /dev/mapper/backup nodesize 4096 leafsize 4096 sectorsize 4096 size 1024.00GB Btrfs Btrfs v0.19
The new FS is mounted for testing and its owner changed to my common user.
# mount /dev/mapper/backup /mnt # df -h /mnt Filesystem Size Used Avail Use% Mounted on /dev/mapper/backup 1008G 200M 957G 1% /mnt # chown ricky:ricky /mnt
At this point the FS can be unmounted and closed. I will never mount the partition again manually, the idea is that gnome mounts it automatically (password is requested as soon as LUKS FS is detected).
# umount /mnt # cryptsetup luksClose /dev/mapper/backup
-
Step 5. Now it is time to think about the backup. The easiest way to backup some directories in Linux is using the rsync utility. This application is a powerful, fast and versatile file copying tool which supports local and remote (ssh for example) copies. The idea for the backup is the following:
- When the external USB disk is plugged gnome mounts them (both partitions) automatically. For the encrypted file system the password is requested. Inside the root mount point a backup script is located, just clicking on it and running it the backup is started. Gnome automounter mounts the FS with default options. That is the reason I finally decided not to use the compression option of btrfs (UDEV is used for the automatic mount, and perhaps a new UDEV rule can be used to change the default behavior but I preferred not to complicate the solution).
- This script called backup-system-gksudo.sh is a simple script that just opens a new gnome-terminal executing gksudo (gnome graphical sudo) over the real backup script backup-system.sh (btrfs command needs root access).
- The backup-system.sh script reads a local and hidden configuration file called .backup-config. This file has some general variables like the directory to maintain in sync (usually it would be / directory but, in my case, /home is where all my data are placed), number of snapshots to maintain, directory for host backups, file for excluded dirs,...
- First the script creates a new btrfs sub-volume for the specified box (this way the same disk can hold backups for several boxes). The volume is placed in host-backup/$(hostname) directory (the first directory name is customizable via the configuration file). If the volume already exists this step is just skipped.
- After that the script continues executing the rsync command. The command is called with the following options:
rsync -a --delete -v --stats --progress \ --exclude-from="${dirName}/${EXCLUDED_DIRS_FILE}" \ "${SOURCE_BACKUP_DIR}" "${hostDirName}"
With this execution the SOURCE_BACKUP_DIR is in sync against the external and encrypted btrfs volume. The -a options is for archive mode, --delete option removes files deleted in the source directory, and -v, --stats and --progress options are for showing some information while copying. The --exclude-from option let us exclude some directories from the copy, the pattern file is defined inside the configuration (in my case this var points to a .exclude-dirs file that contains entries like videos or comics which are huge directories I do not like to backup). This step can take hours the first time but it is quite fast when only changes are sent. - When the rsync command finishes a btrfs snapshot is taken. This snapshot is located at the same level of the host sub-volume but labeled with the current date (the snapshot name is like this $(hostname)-YYYYMMDDHHMMSS).
- Finally old snapshots are deleted (in the configuration file there is a MAX_SNAPSHOTS variable, if the snapshots are more than this number the old ones are removed).
- At the end of the script a message is shown to the user. Zenity command is used to tell the user that the backup has been successfully done or the script has terminated with errors.
Here a video is presented to show the backup execution. It is at accelerated speed, the real backup took around two minutes. First the disk is inserted and gnome requests the password for the encrypted partition. When the device is automatically mounted the graphical script is executed (first I show that only one snapshot is in the hosts directory). This script launches a new gnome-terminal, after the root password is also requested the backup (rsync) and snapshot are performed. Once the script finishes a successful message is shown. Finally I enter in the host directory and show the just created snapshot directory.
In summary this entry comments how to implement a backup utility over an encrypted external disk in Linux (Debian). I have written it just to remember what I did (I had never worked with this utilities, cryptsetup, dm-crypt, btrfs or rsync). As you have seen my idea is keeping it as simple as possible. Only the chosen File System (btrfs) is a bit strange, but thinking about current and announced features it seems to be the proper one (maybe in the near future btrfs alone can do all the stuff explained here, sync and encryption included, avoiding the use of any other program). Please reuse and adapt it if you think it is useful for you.
Remember to backup your ideas too!
Friday, June 3. 2011
Sound Issue in Linux Adobe Flash (Better Solution)
Yesterday I spent some time reading the fedora bug about the flash issue commented in the previous entry. There are very interesting comments in it, but more important, there are two attachments to replace by yourself the memcpy calls with memmove (one is a bash script and the other is a C++ program).
I tried the C++ source code program and it seems to work quite well:
# wget -O replace.c https://bugzilla.redhat.com/attachment.cgi?id=487982 # g++ -o replace replace.c # cd /usr/lib64/flashplugin-nonfree/ # cp libflashplayer.so libflashplayer.so.ORIG # ~/replace libflashplayer.so Found memmove at symbol table index 516 Found and fixed 1 reloc entries
Of course this solution is a much better approach, because it depends directly on you, you can understand what you are doing and it will work for future plugin releases (if they are still broken). But remember I was desperate at those times. Another thing I did not comment before is that this bug only applies to amd64 linux platforms (not i386, 32 bit installations). And paying more attention to glib package upgrade (I also upgraded my desktop debian box yesterday), I realized there is a warning screen about this memcpy issue you need to accept. I really do not know if I just accepted it without reading in the laptop upgrade or it is new now... I bet for the first option.
Cheerio!
Comments