8

I'm trying to find a way to report on the most recent login for all users on my Solaris 10 server. I'm starting with the output of the last command. Using that command, I get output like this:

bd9439    pts/1        vpn-xxx-xx-xxx-x Fri Oct 25 10:46   still logged in
vf7854    pts/1        vpn-xxx-xx-xxx-x Fri Oct 25 10:23 - 10:38  (00:15)

According to the man page, the date and time formats are controlled by locale. I've very rarely used locale settings. Is there something I can use that will change the display to include the "year" portion of the date? I'm hoping to get an output line similar to this:

bd9439    pts/1        vpn-xxx-xx-xxx-x Fri Oct 25 2013 10:46   still logged in
vf7854    pts/1        vpn-xxx-xx-xxx-x Fri Oct 25 2013 10:23 - 10:38  (00:15)

It's not clear to me if the man page was referring to the output of the last command itself or how the data is actually stored in /var/adm/wtmpx.

If there is another way to get this "last login" attribute, I'd be happy to learn it.

3 Answers 3

8

In which I half-provide context, half rant

You're running into an example of the main reason I don't like managing Solaris systems: Nothing is ever just easy.

I don't know if the locale's really going to do anything except change the order of certain portions of the timestamp around. I'm interested if anyone knows of a way to coax Solaris's last into giving the year, but I'm not going to hold my breath. Sun's software development mantra seems to have been "It Technically Works."

Sun seems to have pretty much developed something right up to the point absolutely required of them, and then pretty much stopped there. So you end up with generally accepted solutions being like these and you just keep a listed collection of workarounds for common problems.

The only way I've ever found of doing this is to use /usr/lib/acct/fwtmp to dump the entire contents of /var/adm/wtmpx to a pipe to some other program that I use for manipulating the text output (grep, tac, sed, etc).

Bonus: Since seeking the end of the file and just moving back by the fixed wtmpx record length would be asking too much, fwtmp can only print out the contents of wtmpx as they appear in the file. So you have to use some other means (probably tac) of reversing the lines, unless you're actually interested in the oldest information (which is the least likely use case, but I digress).

Depending how long your system has been in operation wtmpx might be kind of large, so you may want to go get a cup of coffee, maybe go check to see if your tires are underinflated, and maybe go read a book or two while you're at it.

The Actual Answer to your question:

This is a command that emulates last in way that is usable to most people interested in looking at login records:

# cat /var/adm/wtmpx | /usr/lib/acct/fwtmp | tac | head 

You'll notice I have to pipe wtmpx in since they don't give you a means of just giving the file to fwtmp. That's because feeding it in via stdin Technically Works™ in the majority of use cases and they wouldn't have had to write a few extra lines of code. So they'd rather just make Admins do that.

This is example output of the above on on of the systems I look after:

[root@atum root]# cat /var/adm/wtmpx | /usr/lib/acct/fwtmp | tac | head
jadavis6                         ts/1 pts/1                                19410  7 0000 0000 1382723864 157168 0 19 ditirlns01.xxx.edu Fri Oct 25 13:57:44 2013
jadavis6                              sshd                                 19404  7 0000 0000 1382723864 133973 0 19 ditirlns01.xxx.edu Fri Oct 25 13:57:44 2013
oracle                                sshd                                  6640  8 0000 0000 1382713401 157107 0 0  Fri Oct 25 11:03:21 2013
oracle                           ts/1 pts/1                                 6647  8 0000 0000 1382713401 150489 0 0  Fri Oct 25 11:03:21 2013
oracle                           ts/1 pts/1                                 6647  7 0000 0000 1382712445 24488 0 23 a0003040148735.xxx.edu Fri Oct 25 10:47:25 2013
oracle                                sshd                                  6640  7 0000 0000 1382712442 304729 0 23 a0003040148735.xxx.edu Fri Oct 25 10:47:22 2013
jadavis6                              sshd                                 23537  8 0000 0000 1382560970 410725 0 0  Wed Oct 23 16:42:50 2013
jadavis6                         ts/1 pts/1                                23544  8 0000 0000 1382560970 404795 0 0  Wed Oct 23 16:42:50 2013
jadavis6                         ts/1 pts/1                                23544  7 0000 0000 1382552999 619524 0 19 ditirlns01.xxx.edu Wed Oct 23 14:29:59 2013
jadavis6                              sshd                                 23537  7 0000 0000 1382552999 602215 0 19 ditirlns01.xxx.edu Wed Oct 23 14:29:59 2013
[root@atum root]#

EDIT:

I know I'm whining about something small up there, but after a while I just get tired of every little thing (such as simply asking "what's the year?") turning into an hour long googlefest or something that's more or less just tribal knowledge (such as the existence of fwtmp).

5
  • I'm going to go ahead an accept this answer because it does address my question. Unfortunately, I just learned that the accounting file is "rolled" every day, so the last command is useless to me. I came up with a different solution to my original problem: I added touch /var/lastlogin/$USERNAME to my /etc/profile, which will create or update a file whenever someone logs in. Other than having to create that directory with 777 permissions, this meets my needs. Going to figure out that next. Commented Oct 25, 2013 at 19:33
  • Also not super reliable to have the login accounting writable by regular users. I'm not able to actually find it online but several places are saying that pam_exec.so builds successfully on Solaris. If it's a big deal that would be more secure than chmod 777. Commented Oct 25, 2013 at 20:19
  • I plan to write a script to run that "touch" command using my application account and setuid it to remove the 777 problem. Never done it before myself, but I think it should be easy so that's what I'm working toward. Commented Oct 25, 2013 at 21:23
  • This has been bugging me since I first read it, but you may try either some setuid binary (and/or sudo) or if the file is on ZFS you can set the ACL such that users can only append to it. I'm going to keep looking/brainstorming and if I come onto something better I'll let you know. Also, do you have BSM auditing enabled? That might be preferable since you can audit login/logout events then search the audit logs, regular users can't access it. Commented Oct 26, 2013 at 4:23
  • The more I think about it, the more I think using BSM to audit lo events is actually the way to go here. It's a standard feature of the OS, versus what you're doing which is specific to your shop. If you get hit by a bus and they have to replace you (or even just supplement you) that person should know all about BSM versus having to manually learn whatever system you put together. Commented Oct 26, 2013 at 4:24
4

GNU/Linux's last offers the -F switch. I'd be surprised if Solaris does, though.

Internally, the wtmp file should have epoch timestamps and thus if you would care to write something in C or Perl you can create your own last command. You will need to look at the appropriate C-header file for the structure. The wtmp is a "binary" file and isn't amenable to evaluation with standard parsing tools.

Consider periodically archiving and truncating your wtmp file so that you know what year to which it applies.

1
  • This worked perfectly for me on CentOS 6.7. Thank you. Commented Jan 19, 2017 at 18:01
1

I had a similar case, but needed the login date in my custom format. This works for me:

date -d "`last -F | head -n1 | sed -r 's/.*\.[0-9]+\s+//' | sed -r 's/\s(still|-).*//'`" +"%F_%R"
1
  • Not sure why this was voted down, I found this very useful! Commented Dec 12, 2018 at 17:28

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.