d_inevitable's questions

Sometimes my Windows are incorrectly associated to an application group. For example when I use the application switcher (Alt-Tab) I end up wondering where my chrome browser windows are, only to end up finding them being hidden under the wrong application (i.e. under WebStorm).

This also happens on the window switcher, where wrong icons are being shown and application switcher (chrome windows are assigned under WebStorm), and chrome is not even showing up as Application, even though it is clearly running.

Also on the sidebar it thinks chrome is not even running at all.

This issue is intermittent. I have not found any ways to reproduce it reliably. In most cases logging out and then in again fixes.

How do I go about troubleshooting this issue?

All of the sudden gksu stopped working for me:

~$ gksu gparted

(gpartedbin:24252): Gtk-WARNING **: cannot open display: :0

The same happens with gparted-pkexec:

~$ gparted-pkexec 
No protocol specified

(gpartedbin:25454): Gtk-WARNING **: cannot open display: :0

What could possibly be causing this?

I am not running this through SSH or VNC. This is localhost in a normal terminal window.

I've been happily using blueproximity in 13.10, but since upgrade to 14.04 it only locks when my phone goes out of range (using gnome-screensaver-command -l), but it does not unlock with gnome-screensaver-command -d.

Now the reason that gnome-screensaver-command -d doesn't work is because of a bug.

However on that bug report it is mentioned that the gnome-screensaver is no longer used in trusty and therefore the gnome-screensaver-command is expected to be phased out, which could also be related to why the command doesn't work.

So my question is, if the gnome-screensaver is replaced, then what would be the new command to unlock the screen without relying on gnome-screensaver-command?

I have a krb5-ldap user in an "administrators" which is added to sudoers list as follows:

%administrators ALL=(ALL) ALL

Now that works fine for all sudo operations.

But when that user wants to install something in the Ubuntu Software Center, he gets prompted for the password of a local "admin" user.

I have no idea why it would behave that way. How can I fix this?

Update

Also tried to add these users to the sudo groups with pam-groups in /etc/security/group.conf:

*;*;%administrators;Al0000-2400;sudo

The sudo group now shows up correctly in groups, however the software center still asks for the password for another, local user.

I am attempting to setup a centralized home-directory server through sshfs and pam-mount.

Currently I am stuck at this point:

When attempting to mount the remote home directory sshfs just gets stuck:

d_inevitable@laptop:~$ sshfs -o nonempty,debug server: .
FUSE library version: 2.9.0
nullpath_ok: 0
nopath: 0
utime_omit_ok: 0

It freezes at this point.

This seems to be because the home directory includes ~/.ssh. So when I try sshfs -o nonempty server:.ssh .ssh the same thing happens.

I suppose fuse somehow initializes the mount, but then ssh needs something from it's config directory so it tries to read from it. Fuse will just block that read resulting in a deadlock.

What kind of stuff does sshfs need from ~/.ssh?

I have tried to remove all read/write permissions from ~/.ssh and then mounting on some other directory. That worked fine. The debug output only complained about writing to .ssh/known_hosts.

My SIM card is stuck inside the slot of my laptop and I can't get it out without causing further damage to my laptop.

Every time I log in gnome-shell prompts me for the PIN. Whether I am about to use it or not.

On my phone I know I can disable the PIN altogether so that it doesn't get requested again (even if place the SIM card on another device). How can I do the same in Ubuntu?

I need to prevent users from authenticating through Kerberos when the encrypted /home/users has not yet been mounted. (This is to avoid corrupting the ecryptfs mountpoint)

Currently I have these lines in /etc/pam.d/common-auth:

auth    required                        pam_group.so use_first_pass
auth    [success=2 default=ignore]      pam_krb5.so minimum_uid=1000 try_first_pass
auth    [success=1 default=ignore]      pam_unix.so nullok_secure try_first_pass

I am planning to use pam_exec.so to execute a script that will exit 1 if the ecyptfs mounts are not ready yet.

Doing this:

auth    required        pam_exec.so     /etc/security/check_ecryptfs

will lock me out for good if ecryptfs for some reason fails. In such case I would like to at least be able to login with a local (non-kerberos) user to fix the issue.

Is there some sort of AND-Operator in which I can say that login through kerberos+ldap is only sufficient if both kerberos authentication and the ecryptfs mount has succeeded?

I just came to realize that my system is not limiting the amount of processes per user properly thus not preventing a user from doing a fork-bomb and crashing the entire system:

user@thebe:~$ cat /etc/security/limits.conf | grep user
user        hard    nproc   512
user@thebe:~$ ulimit -u
1024
user@thebe:~$ :(){ :|:& };:
[1] 2559
user@thebe:~$ ht-bash: fork: Cannot allocate memory
-bash: fork: Cannot allocate memory
-bash: fork: Cannot allocate memory
-bash: fork: Cannot allocate memory
-bash: fork: Cannot allocate memory
-bash: fork: Cannot allocate memory
-bash: fork: Cannot allocate memory
-bash: fork: Cannot allocate memory
...
Connection to thebe closed by remote host.

Is this a bug or why is it ignoring the limit in limits.conf and why is not applying the limit that ulimit -n claims it to be?

PS: I really don't think the memory limit is hit before the process limit. This machine has 8GB ram and it was using only 4% of it at the time when I dropped the fork bomb.

EDIT:

I managed to reproduce this on a live CD. So I guess this must be a bug. It basically ends up killing all processes, including system critical things like X11, SSHD etc.

Any user can crash the system.

When rebooting the sequence freezes at the very last stage in which it attempts to the the system to reset through ACPI.

Setting acpi=off in grub.cfg fixed this problem, but I was unable to suspend, which was the greater evil.

Shutdown and Suspend work fine with ACPI enabled.

How can I get this fixed without disabling ACPI (or without being unable to suspend)?

How do I make sure that all users have their home directory encrypted when the login for the first time?

I have setup pam to use Kerberos authentication and LDAP authorization (which I think should not really have any effect on ecryptfs).

I have also setup pam-mkhomedir to create the home directories from /etc/skel in which I have placed some standard configurations.

Looking at the .ecryptfs directory in one user account that already has ecryptfs enabled, there are some user-specific configurations, such as the mountpoint (set to /home/d_inevitable) for example, which would be no good in /etc/skel.

Also the configurations in /etc/skel would need to be copied after the home directory has been mounted with ecryptfs.