In recent tests with openSUSE Leap 15.0 and with Tumbleweed, I have been testing out pam_kwallet. It seems to work pretty well. So I have since converted another Tumbleweed system to using pam_kwallet. However, I am not using pam_kwallet with Leap 42.3, on the grand principle that if it ain’t broke, don’t fix it.
Leap 15.0 should be released some time in May. So pam_kwallet is something you might want to think about when you install it.
What is pam_kwallet?
First things first, so I should first explain “kwallet”, sometimes called “kdewallet”. It is a protected place for storing passwords that are used by KDE applications. Typically, it is used for the WiFi passphrase, for web password and email passwords. This, of course, depends on what applications you are using for web browing and for email.
A quick reminder that Leap 15.0 is still at the alpha pre-release stage.
Today, I decided to experiment with upgrading. I have openSUSE Leap 42.3 installed in a virtual machine under KVM. So I cloned that virtual machine, using the “virt-clone” command (as root). I then proceeded to upgrade it to Leap 15.0.
This is intended to be a throw-away. I’ll delete that upgraded virtual machine after a few days of testing. I may repeat the entire procedure when 15.0 is closer to final release.
I first booted the clone VM, to make sure that it could boot into Leap 42.3.
Next, I shutdown that VM. Then on the “hardware details” screen of the viewer, I configured the virtual DVD device to use the DVD installer iso for Leap 15.0. I also checked the box to enable the boot menu (under “boot options”).
As anticipated Mint 17 “Qiana” was released not too long after the Ubuntu 14.04 on which it is based. I waited a little longer, because I wanted to try the KDE version. When I last tried Mint, it was the Mate version. But that was a while ago. I primarily use KDE, so that seemed to be the appropriate version for me to test.
The download was of a live DVD image, which contained the installer. Downloading was simple enough. I then checked with the MD5 and SHA256 hashes. I could not find a gpg signature to check.
As preparation for booting, I copied the image to a USB. In my case, I used the command
dd_rescue linuxmint-17-kde-dvd-64bit.iso /dev/sdd
from my opensuse system.
I have been using ecryptfs with the early milestone releases, the beta releases, the release candidates and the final release of 12.3. It has worked very well. The only problem I have seen, is that some of the ecryptfs utilities do not properly load the ecryptfs module. I have rarely encountered this problem, though it can occasionally arise.
All it takes to make ecryptfs available on your system, is to install “ecryptfs-utils”. I did that with Yast software management, though it could also be done with zypper (at a root command line) or with Apper.
[Update: it appears that the ecryptfs kernel module may need to be loaded before you can setup a private directory. See the comments below, particularly my reply with time stamp of “2012/09/10 at 22:16”.]
It has been a while since I first posted on ecryptfs, and there have been some changes (improvements) with opensuse 12.2. My earlier post was about my experimenting. Some time in the near future, I will do a more complete post about ecryptfs. For now, this will be specific to using it with opensuse 12.2, and about what has changed since that earlier post.
What has mainly changed, is that opensuse support for ecryptfs has improved. It still does not quite work “out of the box,” but it is closer. Read More…
Since I last blogged about encryption, I have made a few changes in how I do things. I’ll give an overall summary and recommendations at some time in the future.
The weakest point in my encryption strategy was with my desktop computer at work. I set that up only for encrypted swap. The reason is that I leave that running at all times, and expect to be able to access it remotely from home and elsewhere. If there’s a power interruption when I am not present, it needs to be able to boot unattended. And if I encrypt the “/home” file system, then that won’t work very well. The boot would hang at the point where it was asking for the encryption key. So my choice was to go without an encrypted “/home”, but be cautious about storing anything sensitive on that computer, unless in an encrypted file. Read More…