Jacek Konieczny's questions

I have a system with / on tmpfs. Most / subdirectories have aufs mounted overlaying the read-write root filesystem with read-only base filesystem (the system boots from a read-only medium). Earlier, I used to use unionfs instead of aufs. It has been working properly until recently the tmpfs started to fill up. I am not sure what triggered the change. It could be the unionfs to aufs change, a kernel upgrade or some changes in the system and how it accesses the file systems.

Anyway, it seems it is the tmpfs which behaves somehow wrong.

Although the system should not write a lot to tmpfs, quite a bit of it is used up:

# df -m /
Filesystem     1M-blocks  Used Available Use% Mounted on
tmpfs                200    50       151  25% /

while:

# du -smx /
2       /

This is my test system, doing basically nothing. Things are wore on production system when usage quickly reach over 90% and the system crashes.

I would suspect these are deleted files still open, but:

# lsof | grep deleted

shows nothing.

The other idea was, that some files on / are masked by a file system mounted over it, so I tried this:

# mount --bind / /mnt
# du -sm /mnt
2       /mnt

Still, no trace of the 48MB lost.

How can I find out what is using up my tmpfs file system?

System information:

# uname -rm
3.4.6 i686

Update: I have tried kernels 3.4.17 and 3.6.6 – no change.

We have many different systems that are managed by several people. We have chosen to use SSH public key authentication to access those systems. This works great, as there is no need to manage or share administrative account passwords, no need to remember passwords to the various systems (only the pass-phrase to your private key), no need to interaction (entering password) with every remote command.

The problem is, the public keys installed on the systems need to be managed somehow. People come and go, keys may get compromised, responsibilities change (a person authorised to enter one system today may be authorised to access a different one tomorrow). Currently we manage it by manually editing ~/.ssh/authorized_keys files on every account that needs that, but that is a lot of work and prone for mistakes.

Is there any ready tool to manage public keys in such scenario? Do you have your own solutions? Or is that whole idea of managing systems this way flawed?