Tag Archive | ecryptfs

Opensuse Leap 42.1 Milestone 2

Milestone 2 for Leap 42.1 was announced on Friday.  So, naturally, I downloaded the install DVD iso, and attempted an install.

Both the download and the install went quite well.  As usual, I wrote the iso to a USB flash drive, and used that for installing.  I installed Leap on its own (unencrypted) partition, but with swap and home coming from an existing encrypted LVM.  I mounted the home volume from the LVM as “/xhome”, so that “/home” is actually part of the root partition.  The idea was that users could symlink back to files in “/xhome” to make their usual files/directories available.  But desktop configuration would be kept separate to avoid conflicts between different desktop versions.

Booting woes

Trouble began with the first boot.  I was prompted for the encryption key, but the system was not reading the keyboard and this prevented entering the key.

Read More…

Systemd user manager, ecryptfs and opensuse 13.1

I have briefly mentioned this in an earlier post.

When I look around, while running 13.1, I notice that there are some systemd user manager processes:

% ps -ef | grep '[/]systemd'
root       377     1  0 10:29 ?        00:00:00 /usr/lib/systemd/systemd-journald
root       418     1  0 10:29 ?        00:00:00 /usr/lib/systemd/systemd-udevd
root       749     1  0 10:29 ?        00:00:00 /usr/lib/systemd/systemd-logind
lightdm   3258     1  0 10:29 ?        00:00:00 /usr/lib/systemd/systemd --user
root      3421     1  0 10:30 ?        00:00:00 /usr/lib/systemd/systemd --user
rickert   3443     1  0 10:30 ?        00:00:00 /usr/lib/systemd/systemd --user

The last three of those are user manager processes, as shown by the “–user” flag to the process.  There is also an additional process that seems to be PAM related:

% ps -ef | grep '[p]am'
lightdm   3259  3258  0 10:29 ?        00:00:00 (sd-pam)           
croot     3423  3421  0 10:30 ?        00:00:00 (sd-pam)           
rickert   3447  3443  0 10:30 ?        00:00:00 (sd-pam)

Read More…

Opensuse 13.1 after one week

It is now a little more than a week since 13.1 was released.  There are things that one only notices with sustained use.  So, here, I’ll mention some of what I have been noticing since switching my main desktop over to 13.1.


This one is really good news.  Konqueror has been running continuously for over three days, with nary a problem.  Previously, it was likely to crash after 12 hours or less, and sometimes it would crash when minimized.  It looks as if a long standing bug has finally been fixed.

Normally, I close and reopen the browser once per day, as a way of deleting session cookies (and thus reducing tracking).  But I’ve kept it open to see how long it lasts.  I will close it shortly after posting this.

Read More…

Opensuse 13.1 glitches

In my previous post, I indicated that I would report on any glitches.

This will be a short post.  I have installed on four different machines.  The install went as smoothly as any.

I did run into one glitch, with ecryptfs.  And that showed up on all of the installs.  When installing from the DVD (which I did, except I “burned” to a USB), you cannot directly include “ecryptfs”.  That software is in the repos, but not on the DVD.  So, technically, this was a post-install glitch.

I used Yast software manager to add ecryptfs.  After adding it, I noticed that the pam configuration had not been updated.  The result is that login does not automatically decrypt the Private directory.

The problem is easily corrected by running (as root)

# pam-config -a --ecryptfs

With that change, everything has been just about perfect.  Well, Apper is still a bit flaky, so I’ll probably turn it off.

An encrypted home directory with ecryptfs

In a recent post, I reviewed how to setup ecryptfs for providing a private directory.  In that scenario, the directory “$HOME/Private” is the private directory.  The files in that directory are stored on disk as encrypted files, but you see them as if unencrypted.  The actual encrypted files are stored in “$HOME/.Private”, and what you see is a virtual unencrypted version of those files, mounted on “$HOME/Private”.  The virtual unencrypted file system is only mounted while you are logged in.  If properly setup, it is automatically mounted on login and automatically umounted on logout.

In this post, I want to describe how to have your actual home directory encrypted in this way.  That amounts to having the virtual unencrypted file system mounted as “$HOME” instead of as “$HOME/Private”. Read More…