Showing posts with label installation. Show all posts
Showing posts with label installation. Show all posts

Sunday, June 20, 2010

64-bit Linux Flash Player discontinued

It seems that at least temporarily the 64bit version of Flash Player will not be available for Linux. I found out when upgrading my system, where at some point I got the following error message:
[myPC:/home/leo] update-flashplugin-nonfree --install
ERROR: 64 bit player temporarily not supported
More information might be available at:
  http://wiki.debian.org/FlashPlayer

The solution is to install the 32bit version of it, as explained here at this forum (another option is to install gnash, but I haven't tried). The details are described on this post, specifically.

Sunday, June 13, 2010

Recovering an encrypted hard disk and creating encrypted partitions

I recently wrote about how to make a secure connection to a remote machine. Now I'll make a few comments on how to create and use an encrypted partition, including DVDs. I apologize for skipping comments and technical details, these are just personal notes in case I must repeat the procedure in the future. I started to think about this when my not-so-old laptop broke, and I had to recover my file system, which was automagically set up by the Debian installation using the LVM+LUKS encryption. That is, what I was using as partitions were in fact "logical volumes" whose physical volume was an encrypted partition of the hard disk.

Creating an encrypted partition

First, a simpler version of the problem, which is to create an encrypted partition from a removable disk using cryptsetup with LUKS extensions. There is nothing special about being a removable disk, the procedure is exactly the same for a local disk. If we assume that the disk /dev/sdc has a partition /dev/sdc1, we can encrypt it by:
[thisPC:~] cryptsetup luksFormat /dev/sdc1
WARNING!
========
This will overwrite data on /dev/sdc1 irrevocably.

Are you sure? (Type uppercase yes): YES
Enter LUKS passphrase:
Verify passphrase:
You can change the cipher algorithm with e.g. the parameters "-c aes -s 256 -h sha256". I haven't mentioned but the partition should be initialized with garbage data using the command dd. If the system complains, try loading some modules:
[thisPC:~] apt-get install loop-aes-utils cryptsetup
[thisPC:~]
modprobe loop
[thisPC:~]
modprobe aes
[thisPC:~]
modprobe cryptoloop
[thisPC:~]
modprobe dm-crypt
(those with "loop" in the name are actually for creating a loopback partition, see below). This partition is still unusable, we must map it to a accessible device by decrypting it:
[thisPC:~] cryptsetup luksOpen /dev/sdc1 backup
Enter passphrase for /dev/sdc1:
Key slot 0 unlocked.
[thisPC:~]
dmsetup ls
backup  (254, 5)
thisPC-swap_1  (254, 2)
thisPC-usr     (254, 3)
sda2_crypt     (254, 0)
thisPC-home    (254, 4)
thisPC-root    (254, 1)
The first command "opens" a device called "backup", accessible through /dev/mapper/backup. The name "backup" is arbitrary, and could be any name distinct from the existing mapped devices. The second command shows us the list of these devices - we can see that besides the newly-created "backup" I have other "logical" partitions set up by LVM. The device "backup" can now be formatted as an ext3 partition:
[thisPC:~] mkfs.ext3 /dev/mapper/backup -L CryptBackupDisk
mke2fs 1.41.12 (17-May-2010)
Filesystem label=CryptBackupDisk
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=0 blocks, Stripe width=0 blocks
19537920 inodes, 78141903 blocks
3907095 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=4294967296
2385 block groups
32768 blocks per group, 32768 fragments per group
8192 inodes per group
Superblock backups stored on blocks:
        32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632,
        2654208, 4096000, 7962624, 11239424, 20480000, 23887872, 71663616

Writing inode tables: done                           
Creating journal (32768 blocks): done
Writing superblocks and filesystem accounting information: done

This filesystem will be automatically checked every 37 mounts or
180 days, whichever comes first.  Use tune2fs -c or -i to override.
The partition is now ready to be used:
[thisPC:~] mount /dev/mapper/backup /mnt
...
[thisPC:~]
umount /mnt
[thisPC:~]
cryptsetup luksClose /dev/mapper/backup
Since the action "luksClose" will remove the device "backup", you must call the cryptsetup command "luksOpen" (and type the passphrase) again if you want to mount the partition once more. You must repeat the procedure every time you reconnect the removable disk or reboot the machine. One advantage of the LUKS extensions (as compared with the traditional "cryptsetup -c aes -y create backup /dev/sdc1") is that most environments can recognize that /dev/hdc1 is a LUKS encrypted partition and prompt the user for the passphrase when automatically mounting the removable devices.

Super-user privileges

So far I assumed root privileges, and for completeness I'll write below the configurations that should allow me to mount the partition as a regular user:
[thisPC:~] md /media/CryptBackupDisk
[thisPC:~]
sudo chmod g+s /media/CryptBackupDisk
[thisPC:~]
chown leo:leo /media/CryptBackupDisk
[thisPC:~]
cat /etc/crypttab
 sda2_crypt /dev/sda2 none luks
 backup     /dev/sdc1 none luks
[thisPC:~]
cat /etc/fstab
# /etc/fstab: static file system information
#              
proc                    /proc   proc  defaults          0    0
/dev/mapper/thisPC-root /       ext3  errors=remount-ro 0    1
# ... (other entries)
/dev/mapper/backup /media/CryptBackupDisk/ ext3 user,noauto 0 0

By creating a directory with the same name as the partition label ("CryptBackupDisk"), I should control the mounting process, but it is simply not working - it creates another directory called /media/CryptBackupDisk_ (notice the underscore), and with root permissions only. For now I removed the directory (since it will be dynamically created) and created a directory inside the encrypted partition (after being properly mounted) to which I have access as a regular user. There is another option using cryptomount but I haven't tried it with LUKS. It seems an easy alternative to the whole process described above, since you can create the encrypted partition from scratch using it. For setting up an already created encrypted partition it was not so easy (but again, I haven't tried with a LUKS partition).

Files and DVDs

The procedure above works not only with partitions, but with files as well. The trick is to transform the file (like an ISO image) into a filesystem, using the loopback device (more information here). So a 1Gb partition can be created through the file /home/leo/fake.img:

[thisPC:/home/leo] dd if=/dev/zero of=/home/leo/fake.img \
      bs=1M count=1024
A safer but slower alternative to /dev/zero is /dev/random. This file can thus be mounted as a partition, like /dev/sdc1 of the previous example:

[thisPC:/home/leo] losetup /dev/loop0 /home/leo/fake.img
...
[thisPC:/home/leo]
losetup -d /dev/loop0
That is, you can encrypt the device with "cryptsetup luksFormat /dev/loop0", etc. Don't forget that "losetup" should be the first and last recipes ("-d" for deleting the device), before "luksOpen" and after "luksClose", respectively. As a last digression, here is how to create an encrypted data DVD (with my precious "articles" directory as an example):

[thisPC:/home/leo] sudo apt-get install aespipe mkisofs \
      loop-aes-utils
; sudo modprobe aes; sudo modprobe cryptoloop
[thisPC:/home/leo] mkisofs -U -R -J -r /home/leo/articles | \
      aespipe -e aes256 > backup.iso
#encrypted backup.iso image

[thisPC:/home/leo] sudo mount -t iso9660 backup.iso /mnt/iso \
      -o loop=/dev/loop0,encryption=aes256
#confirm that image is OK
After burning the backup.iso image to a DVD, you can mount and access it with

[thisPC:/home/leo] sudo mount -t iso9660 /dev/cdrom /mnt/iso \
      -o loop=/dev/loop0,encryption=aes256
Recover an encrypted root partition

Now, my original problem. Assuming that I have a hard disk where even the root directory was part of an LVM which was encrypted inside partition /dev/sdc2, we decrypt it as before (obviously, you should know the passphrase!):

[thisPC:/home/leo] cryptsetup luksOpen /dev/sdc2 BrokenPCPartition
[thisPC:/home/leo] dmsetup ls
thisPC-swap_1     (254, 2)
thisPC-usr        (254, 3)
sda2_crypt        (254, 0)
thisPC-home       (254, 4)
BrokenPCPartition (254, 5)
thisPC-root       (254, 1)

But now BrokenPCPartition is not a regular device, it is the part of an LVM. We can scan all possible volume groups (LVM lingo...) with the command:

[thisPC:/home/leo] vgscan
  Reading all physical volumes.  This may take a while...
  Found volume group "brokenPC" using metadata type lvm2
  Found volume group "thisPC" using metadata type lvm2

The group "thisPC" is from my working machine, and the newly-recognized "brokenPC" is the one found through /dev/mapper/BrokenPCPartition (of course the real name was not "brokenPC" :). Now we make this volume group available, and scan all possible logical volumes. IOW, we will activate the logical volumes from this group and list them:

[thisPC:/home/leo] vgchange -a y brokenPC
   3 logical volume(s) in volume group "brokenPC" now active
[thisPC:/home/leo] lvscan
  ACTIVE            '/dev/brokenPC/swap_1' [2.50 GiB] inherit
  ACTIVE            '/dev/brokenPC/root' [59.60 GiB] inherit
  ACTIVE            '/dev/brokenPC/home' [235.74 GiB] inherit
  ACTIVE            '/dev/thisPC/root' [6.52 GiB] inherit
  ACTIVE            '/dev/thisPC/swap_1' [7.92 GiB] inherit
  ACTIVE            '/dev/thisPC/usr' [111.76 GiB] inherit
  ACTIVE            '/dev/thisPC/home' [469.73 GiB] inherit

Now we have, besides the volumes from thisPC, the "recovered" volumes from brokenPC that can be regularly mounted and played with:

[thisPC:/home/leo] mount /dev/brokenPC/home /mnt/
[thisPC:/home/leo] ls /mnt/
leo/  lost+found/
[thisPC:/home/leo] umount /mnt/
[thisPC:/home/leo] vgchange -a n brokenPC
  0 logical volume(s) in volume group "brokenPC" now active
[thisPC:/home/leo]
cryptsetup luksClose /dev/mapper/BrokenPCPartition
 Notice that the volumes names (like /dev/brokenPC/home) are just links to the device mapper (like /dev/mapper/brokenPC-home).



Tuesday, June 8, 2010

More secure Secure Shell


Hakone-Zaiku, a japanese wooden "safe" (this one is closed)

When we connect to a remote machine using Secure Shell (SSH), we routinely must type the password that we use on this remote machine. But SSH allows for public key authentication, where the remote machine has a public key, and it grants access to whoever has the corresponding private key (broadly speaking; if you want a proper explanation please refer to e.g. this book's section or the "Authentication" section of the ssh(1) man page). A possible analogy is a lock-and-key pair, where the lock may be accessible to everybody as long as you keep the key with yourself. It is also similar to PGP cryptography.

But with SSH it is also possible to encrypt the private key with a passphrase, such that the file with the private key is not enough for authentication. In the lock-and-key analogy, this would be equivalent to these modern cars where the owner's fingerprint is necessary to unlock the doors, besides the key.  So far I have always used empty passphrases (that is, the private key was unencrypted), but now that we're migrating to a more secure server I'm better trying a distinct passphrase for each remote machine I connect regularly.

To create the public/private key pair is relatively simple, this is how I did it:
23:30[myPC:~] ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/home/leo/.ssh/id_rsa): /home/leo/.ssh/id_rsa-theirPC
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/leo/.ssh/id_rsa-theirPC.
Your public key has been saved in /home/leo/.ssh/id_rsa-theirPC.pub.
The key fingerprint is:
a2:c3:1f:1c:fc:ae:df:2f:af:77:aa:1d:81:00:6a:ed leo@myPC
The key's randomart image is:
+--[ RSA 2048]----+
|=+oo             |
|+=*+o            |
|+=o++.           |
| .=.E.           |
| o o. o S        |
|  o  o .         |
+-----------------+

Here I have chosen the standard RSA algorithm, but gave a custom name to my private (id_rsa-theirPC) and public (id_rsa-theirPC.pub) files. This is because I want to use this pair for connecting only to theirPC machine (any name would do, BTW). You cannot see, but I chose a fancy passphrase for that too. The next step is to send the public file id_rsa-theirPC.pub to the remote machine and there, to include it into the list of public keys:
23:35[theirPC:~] cat id_rsa-theirPC.pub >> /home/leo/.ssh/authorized_keys
To test if this configuration is working, we can do the following:
23:37[myPC:~] ssh -i ~/.ssh/id_rsa-theirPC theirPC.bigcorp.com
(notice how we must explicitly tell SSH about the location of the private key, otherwise it would fall back to your password at the remote host). If everything went fine, we can automatize the process by creating a configuration file for the SSH client with our customizations:
23:39[myPC:~] cat ~/.ssh/config
Host theirPC
HostName theirPC.bigcorp.com
IdentityFile ~/.ssh/id_rsa-theirPC
This way we can easily include more and more remote machines, and in the example above I could connect with the command "ssh theirPC". But the problem is that with more machines we connect to, the more times we need to type long passphrases into. To solve this you can use ssh-agent to keep the authentication keys (the unencrypted private keys) in memory for all commands spawned from it. That is, ssh-agent acts over a command (which can be a terminal, or startx), and all commands called from it will inherit the authorization keys. But sometimes this is not enough, you might want authentication keys shared between sessions (even after logout). For me the solution was keychain (not the Mac OSX application!), which is a wrapper around ssh-agent (and its low-level friend ssh-add).

Both keychain and ssh-add can read from the terminal prompt, but normally they will use a program that provides the passphrase dialog window. This program is generally called ssh-askpass, but each window manager offers its own implementation as well. In my case I'm using ksshaskpass, that can be integrated with the  KDE Wallet system (which is installed under the name kwalletmanager). The kwallet is an application that manages passwords and passphrases, storing them in encrypted "wallets". That is, you only need to type one master password per wallet.

I will skip the details of kwallet configuration - it suffices to say that you should create at least one wallet and it will prompt you when creating or retrieving passwords - and comment on the keychain program. The installation instructions always tell us to call keychain from .bash_profile (like here), but this didn't work for me since I must make sure it is called only after KDE is up. When following the instructions, I had kwallet asking for my wallet's password (or ssh-askpass asking for the passphrase for id_rsa-theirPC, when I deactivated kwallet) before startkde being called, and thus the keyboard was unresponsive. Maybe because I have an exotic keyboard configuration. Anyway, the solution to that was to create an executable to be called after startkde, and the place to put these custom "daemons" is in ~/.kde/Autostart:
23:39[myPC:~] cat ~/.kde/Autostart/keychain.sh
#!/bin/bash

# initialize SSH key management ("keychain" wrapper for ssh-agent)
# depends on a ssh_askpass (which for KDE is ksshaskpass)
keychain ~/.ssh/id_rsa-theirPC ~/.ssh/id_rsa-anotherPC
source ~/.keychain/${HOSTNAME}-sh
Keychain can also handle GnuPG signatures and several SSH private keys, like in the id_rsa-anotherPC example. Now, when I start a KDE session I am asked about my wallet password, which then offers my SSH passphrases  whenever requested. To be germane, it is actually more nuanced: the program requesting the passphrase will trigger the "upper-level" program to or offer the passphrase or ask another program for it (like in the hierarchy ssh -> ssh-agent -> keychain -> ssh-askpass -> kwallet).

Some general comments:
  • your private keys should not be accessible or readable by anybody but you ("chmod 600 /home/leo/ssh/id_rsa-theirPC");
  • the passphrase can have spaces, punctuation marks etc. So you can mix passwords, but avoid literature quotes! The larger the better;
  • avoid leaving private keys on your remote hosts, that you are unlikely to use to access other machines;
  • do not share private keys among machines, these should be present only in the machines you physically access (in my case these are my desktop and my laptop, which have different configurations);
  • you can change the passphrase later with "ssh-keygen -p id_rsa" (I haven't tried this, but I believe in the man page ;)
  • within kwallet, you can see the passwords and passphrases of open wallets in plain text. I usually panic, but these wallets are themselves encrypted...
  • I haven't tried, but it should be also possible to a) work with ssh-agent and ssh-add without keychain (launching them before the KDM or GDM display managers, or even in Autostart); b) do not use kwallet/ksshaskpass, by using the original x11-ssh-askpass or on the terminal; c) some other killer-app that I don't know about yet.




A Hakone-Zaiku opened. I never cracked the encryption key of these :(


Friday, April 9, 2010

Debiansaurus


With all the buzz about these fancy new cell phones, I started missing my PDA. Actually I still have it here with me, a Sharp Zaurus that I bought in Japan around 2004 to use as a dictionary - this company was famous for having a good kanji recognition software. It also happens to run linux, I even got R to run on it (iPhone lovers don't need to envy me anymore). Since the software is a little bit outdated, I thought about upgrading the system, maybe to Debian - despite I would loose the nice "stroke recognition" app that is able to decipher the kanji you want to write in just a few touches.

But after seeing the lack of development for it (even the official ROM was last updated in 2005), I guess I'll just leave it as it is. I still can play with the tablet and listen to mp3 (although it doesn't seem to recognize newer SD cards...). Other places that may have relevant info on the Zaurus upgrade are here, here and here.

Saturday, March 20, 2010

javaws not working with KDE

I used to have problems with KDE 3.x audio system conflicting with other services, and the solution was always to turn off all KDE sound. With KDE 4 series I didn't have this problem, and I could use the facilities of the window manager. Until now, when I decided to watch the recorded phyloseminars (from home, since my Mac at the lab runs smooth). These video-conferences are based on the EVO software (launched via Java Web Start). It was clear that java was having a hard time accessing my audio devices: the seminars had no sound and EVO's FAQ mentioned competing applications. The solution I found (or a version of it) consists in installing the PulseAudio sound server and removing conflicting programs:
  1. Install PulseAudio and the GUI control panel: aptitude install pulseaudio pavucontrol
  2. Include this line in ~/.xsession (or ~/.xinitrc): pulseaudio --daemonize
  3. Restart X system and check if pulseaudio is accessing the sound device: lsof | grep /dev/snd
In my case I realized that there was another program, called knotify4, competing with pulseaudio for the device. This is the notification system of KDE (with fancy bells and whistles), and to turn it off I went to System Settings -> Notifications -> System Notifications -> Player Settings and selected "No audio output" (the configuration file is ~/.kde/share/config/knotifyrc).

In hindsight, I think that simply disabling the KDE sound notifications would have been enough - and I was explicitly advised to shut down pulseaudio - but I'll keep this information as a logbook... The drawback so far is that there is still conflict when some programs try to access the output sound, like flash (youtube...).

Now at least I think I'm ready for the next lecture.

Friday, March 12, 2010

Leo, why does my google Buzz have so much garbage from you?

My original idea for this post was to present articles that I share using the bundle feature of google reader. But since now and then I feel like explaining the basics, I thought it was time to introduce the tools I employ to read and share articles from magazines and academic publications, as well as blog posts like this one. And since I started using blogs/RSS/etc only recently (in 2007) the first steps are still fresh on my mind. So please forgive me if I skim over technical details, neglect other services or over-simplify the descriptions (but don't hesitate to comment if my explanation is wrong or confusing). Not that I could explain much better than this...

Google Buzz and FriendFeed

It became easier to share articles and blog posts with google Buzz, that aggregates shared content like FriendFeed, but integrated with google mail and google reader. The contents to be gathered might be your posts to the twitter microblogging service (see my stream as an example), pictures you upload to Picasa web albums, posts from blogs you contribute or items you share through google reader, among others. You can also post directly to FriendFeed or Buzz. The idea is that you keep track of what your friends and colleagues are writing or reading, with the possibility of commenting.

Once you set up the sites that you want to connect with Buzz or FriendFeed, you don't need to do anything else, since whenever you write a blog post or share an item on google reader, they will be updated automatically and be available to people on your network (friends and colleagues that follow you on Buzz or FriendFeed).  To start tweeting, you just need to create an account on twitter but you might want to use an application like echofon or tweetdeck to read and write posts. To write a blog post you must create a blog (blogspot and wordpress are the most famous ones) or join a collaborative one. I use the ScribeFire firefox extension to write my posts, but any text editor can help if you don't want to type from within your blog. But even without producing content (=writing) you can already enjoy these tools by sharing what you read or reading what other people share.

Google Reader


Nowadays web pages are dynamic (now you have a lower bound for my age), and this is specially true for newspapers and academic publications. There is always new information available - new issues from a magazine, new blog posts or new articles from a newspaper - and from several sources, that we should read regularly. While it is impossible to keep up-to-date by reading on the websites, receiving e-mails (with e.g., TOCs) is also very time-consuming and far from ideal to me. Fortunately all decent sites provide an RSS feed with the headlines of the "posts" - where by  "post" I mean the more static part, like the article itself, that can be referenced through a link. Then if you have an RSS reader (a.k.a. feed reader or aggregator) you can let it know about the location of the RSS feed provided by the site, and it will be updated whenever the site releases a new post.

My favorite RSS reader is certainly google reader, despite I also use akregator to have a backup of important feed entries. With akregator the feed entries are downloaded to your computer, while with google reader everything is in their servers. A feed entry can have the whole post, just the abstract or no explanation at all besides the post title and eventually the author, but all entries have a link to the original post on the site to which the feed belongs to. Usually you have the options of browsing the entries in a compact view (like in the picture) or expanded, marking them as "read" such that the reader doesn't  present you the same entry again. The feeds you subscribe to can be classified by folders - for example one folder for academic journals, another for blogs etc - and, at least in google reader, the entries can be tagged. I find the tags very useful for fine-tuning how I share the entries: besides the straightforward sharing (responsible for showing the items in google Buzz, google profile and the public page depending on the privacy settings), I publicize entries which I tag as a science-related post or an academic article [1].

Have in mind that RSS readers cannot recognize homepages in general, only those in a specific XML (not HTML) format. Therefore despite you can do a search for the journal or blog you want to follow from google reader (since it knows how to find the related RSS), in some cases you may need to search for the RSS feed manually. It is common for newspapers and journals to offer several RSS feeds, one per subject, and you might want to choose only a few of them. You can find the link to the RSS feed if you can spot this icon, on the homepage or on your browser:


[1] The "bundle" feature of google reader is for sharing feeds, but I actually tweak it to include the corresponding tag. It is also possible (and much simpler) to just make the tag public in the google reader settings, like here and here. But the bundle is prettier.

Sunday, April 19, 2009

My struggle with the japanese keyboard

Untill now I had two "independent" language settings in my Debian system: a default of  pt-BR (using the iso-8859-1 encoding) and when launching a kterm terminal all locales were set to ja-JP (for using iso-2022-jp and euc-JP encodings). For typing in portuguese (or spanish, french, etc.) I had a 'compose key' AKA 'Multi_key' such that "ç", for instance, could be entered as <,> + . This is in opposition to the (more common?)  'dead key' approach where some keys (like <'> and <~>) wait for the next key before they get printed. To write in japanese I used the kinput2 program, that was activated when I pressed the 'Kanji' key (to write in japanese/chinese/korean in general you need a program that interprets what you type and maps the keystrokes to compatible symbols). I mapped these 'Kanji' and 'Multi_key' to unused keys on my keyboard (like the Windows menus...) using xmodmap.

This inconvenience is because most e-mail in Japan follows iso-2022-jp and documents are in euc-JP. I avoid creating text files (including code and latex) that don't fit into a one bite encoding, but I may have myself other messy files. Recently I was borged migrated to google mail, bought a new machine, upgraded KDE, and started using Mac OS X (which is UTF-8). And I thought that this was a good opportunity to change my Debian to UTF-8 as well - one friend told me that he had no problem with japanese/french on Ubuntu. So I'll describe here the many ways that I failed.

My first problem was when using KDE to set the keyboard layout (System Settings -> Regional & Language -> Keyboard Layout): my jp-106 keyboard was configured just fine by the command setxkbmap, but I wasn't able to customize other keys with xmodmap. The problem was that xmodmap was being called before startkde on .xsession, and setxkbmap (called from startkde) overwrited the xmodmap settings. There should be many ways of solving it, but what I did was to use the setxkbmap settings to create a customized xmodmap configuration (xmodmap -pke >> ~/.xmodmap to dump the keycodes). This '.xmodmap' file can then be modified (I simply mapped the exoteric 'Henkan_Mode' key to 'Multi_key') and the KDE keyboard layout unchecked to prevent loading the setxkbmap. With this I have a working "european" keyboard. 

Now, the japanese input. I migrated from kinput2 to scim (skim in KDE, to be more precise) since it allows you to internationalize your keyboard "on the fly". I have two japanese dictionaries for scim, scim-anthy and scim-canna (with kinput2 I used the canna dictionary), and my '.xsession' file is as follows:


#!/bin/bash --login

xmodmap /home/leo/.xmodmaprc

export XMODIFIERS="@im=SCIM"
export GTK_IM_MODULE="scim"
export QT_IM_MODULE="scim"
export XIM_PROGRAM="scim"
export XIM="SCIM"
export XIM_ARGS="-d"

startkde

In the skim settings I defined one key ('Zenkaku_Hankaku') to toggle scim input on/off. Some applications like iceweasel and gnome-terminal (GTK apps) worked without problem for japanese and "european" input: I use 'Multi_key' to type european accents and scim to switch to japanese mode. But other applications like konsole and openoffice (Qt-based apps) were unable to recognize the 'Multi_key' signal. The problem here is that I should check other -> English/European  in the skim setup, even though I don't need to activate scim to type european accents.

I ran into other troubles like trying to set up hotkeys for the different dictionaries (activate scim and jump to a specific dictionary in one stroke): for some mystical reason I could not revert the changes, and the situation became worst when I mistakenly associated 'Multi_key' to the european dictionary. The solution to this was to remove the lines corresponding to the hotkeys definitions from the file  '~/.kde/share/config/skimrc'.

I ommited the details of installation (like running im-switch and scim-setup) but I believe my testimony takes account of some common mistakes. I may update this post later if I remember anything else - or I find out that my problems were just beginning...

Update 2009.08.06
:

When installing Debian GNU/Linux in a new machine I had the same problem with QT-based applications (like konsole, skype and openoffice), where special characters (like "ç" or "日本") would appear as messed up ASCII characters. Even with the skim setup fix mentioned above, I had no luck. I've got it working after doing the following steps:

  • updated the xinput method alternatives through the command im-switch -z all_ALL -c (and by choosing skim within the update-alternatives command). I believe that the command im-switch -z all_ALL -s skim would have the same effect;
  • told skim to explicitly support the locales ja_JP.UTF-8 and pt_BR.UTF-8 (besides my global en_US.UTF-8), going to the skim configuration option General SCIM->Other->Advanced->Support Unicode Locales (Edit). This is equivalent to including the line /SupportedUnicodeLocales = en_US.UTF-8, ja_JP.UTF-8, pt_BR.UTF-8 to the file ~/.scim/global



Update 2011.01.16:


It seems that skim/scim development is discontinued. The new "standard" input method is ibus. Fairly similar to scim:
  • in the .xsession file replace "scim" for "ibus";
  • be sure to install "ibus-gtk" and "ibus-qt4";
  • run the daemon when the X session starts as "/usr/bin/ibus-daemon -d -x" (you can put it in ~/.kde/Autostart/ibusdaemon.sh or within ~/.session)



LinkWithin

Related Posts with Thumbnails