Date: Fri, 03 Jun 2011 13:57:59 -0700 From: Doug Barton <dougb@FreeBSD.org> To: Garrett Cooper <yanegomi@gmail.com> Cc: Ed Schouten <ed@80386.nl>, current@freebsd.org Subject: Re: llimport(8): Import lastlog into utmpx Message-ID: <4DE94AD7.6060007@FreeBSD.org> In-Reply-To: <BANLkTinYVAEZARfVTTCCF3taitYsbQJFFw@mail.gmail.com> References: <20110603204358.GC50646@hoeg.nl> <BANLkTinYVAEZARfVTTCCF3taitYsbQJFFw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 06/03/2011 13:47, Garrett Cooper wrote: > On Fri, Jun 3, 2011 at 1:43 PM, Ed Schouten<ed@80386.nl> wrote: >> Hi all, >> >> I think not long after I replaced utmp with utmpx, I got requests to add >> utilities to convert the old utmp databases to the new formats. I added >> wtmpcvt(1) for /var/log/wtmp*, but I didn't add any tools for the other >> databases. Even though it's a bit overdue (more than one year later?), I >> think it wouldn't be a bad idea to add a utility to import lastlog for >> people who are going to upgrade from 7.x/8.x to 9.0. >> >> I've written a utility called llimport(8), which imports entries from >> lastlog into utx.lastlogin for users which do not already have an entry >> in the latter. I've also added an rc-script, which executes llimport >> when /var/log/lastlog is present and renames the old database to >> /var/log/lastlog.old. >> >> Any objections if I commit the following patch to HEAD one of these >> days? I will remove it from HEAD not long after we release 9.0, since an >> upgrade from 8.x to 10.x should go through 9.x anyway. >> >> http://80386.nl/pub/llimport.txt >> >> It would be nice if someone could look at the rc script. I think it >> should be okay, but it's not a part of the tree I'm familiar with. > > Is this a one time change? If so, wouldn't it make more sense to > put this into mergemaster(8) instead of rc(5)? FWIW I'm not enthusiastic about either option. I definitely don't think an rc.d script is desirable, since it would be run at every boot for what (if I understand it correctly) is a one-time thing. More or less the same argument applies to adding this to mergemaster. In my mind the best way to handle this would be to add it to tools/ and let users who need it access it that way. But perhaps I'm missing something? Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4DE94AD7.6060007>