Quote:
Originally Posted by SecondMet
The problem with the faillog does not seem to be related to the pam-configuration.
What I observed is that the /var/log/faillog file has a size of 128 GB.
I then deleted the file using rm /var/log/faillog and rebooted the system.
I then created a new faillog using "touch /var/log/faillog".
Then I tried to configure the maximum number of failed logins using:
faillog -m 5
After that the file is immediately back to the size of 128 GB.
What could that be?
|
Try this
Verify that it's the large sparse files which are causing the problem. A sparse file is one that has allocated (reserved) some amount of space, but has only used a small portion of it.
The typical culprit files in this situation are
/var/log/lastlog
and
/var/log/faillog
use "ls -lh" to find how much space these files have allocated, and "du -h" to see how much they have actually used.
root@host:/var/log # ls -lh lastlog faillog
-rw------- 1 root root 132M Jul 17 12:26 faillog
-rw-r--r-- 1 root tty 1.2G Jul 17 12:26 lastlog
.......................^^^^
.......................space allocated
root@host:/var/log # du -h lastlog faillog
12K lastlog
12K faillog
^^^
space used
In this example, the 2 files combined have over 1.2GB of space allocated, but are using only 24K !
2) Either remove or compress the sparse files.
/var/log/lastlog keeps track of the last successfull login of each user on the system, and
/var/log/faillog maintains a count of login failures and the limits for each account.
If the customer does not want to keep this information you can simply zero out the files. Issue the following commands to do so
root@host:/var/log # > /var/log/lastlog
root@host:/var/log # > /var/log/faillog
root@host:/var/log # ls -l lastlog faillog
-rw-r--r-- 1 root tty 0 Jul 17 12:30 lastlog
-rw------- 1 root root 0 Jun 17 12:30 faillog
If the customer wants to save the files, you will need to compress them instead.
root@host:/var/log # gzip lastlog
root@host:/var/log # gzip faillog
Note: This may take a long time depending on the "ls -l" size of these files.
3) Perform the vm&f upgrade.
4) If you gzip'd the files in step #2, you should now uncompress them on BOTH BEs.
If you zero'd the files in step #2, you can skip this step.
Unfortunately, since gzip does not know how to deal with sparse files, we will need to use some trickery to get around that.
First on the current running BE ...
root@host:/var/log # zcat lastlog.gz | cp --sparse=always /dev/stdin /var/log/lastlog
root@host:/var/log # zcat faillog.gz | cp --sparse=always /dev/stdin /var/log/faillog
Note: This may take a long time depending on the "ls -l" size of these files.
root@host:/var/log # ls -lh lastlog faillog
-rw------- 1 root root 132M Jul 17 12:36 faillog
-rw------- 1 root root 1.2G Jul 17 12:35 lastlog
root@host:/var/log # du -h lastlog faillog
12K lastlog
12K faillog
We see that the files are restored, and are still sparse.
Now use vmf_sh to switch to the new ABE and do the same.
root@host:/var/log # vmf_curr <<< show currently running boot environment
BE1
root@host:/var/log # vmf_sh BE2 <<< open a shell on the ABE
vmf_sh: WARNING: You will not be able to run any other VM&F
processes on the ACTIVE Boot Environment while this SHELL is active.
In order to perform other VM&F operations on the ACTIVE Boot Environment
you will have to exit this SHELL.
Also, all commands run from this shell are running under chroot on
the INACTIVE Boot Environment that was specified
BE2: cd /var/log
BE2: zcat lastlog.gz | cp --sparse=always /dev/stdin /var/log/lastlog
BE2: zcat faillog.gz | cp --sparse=always /dev/stdin /var/log/faillog
BE2: ls -lh lastlog faillog
-rw------- 1 root root 132M Jul 17 12:55 faillog
-rw-r--r-- 1 root tty 1.2G Jul 17 12:54 lastlog
BE2: du -h lastlog faillog
12K lastlog
12K faillog
BE2: exit
exit
