On Wed, 28 Aug 2002, Dan Harkless wrote: > > "Michael D. Schleif" <[EMAIL PROTECTED]> writes: > > Vic Berdin wrote: > > > > > > I need to manage /var/log/wtmp data log on a regular basis (preferably > > > using a cron triggered binary/script). > > > As other mail archive trails suggests, A C program that will truncate it > > > must be created. It can be done but, > > > what do you guys have to say about it? How do LEAF users manage > > > /var/log/wtmp? > > > > What is your real problem? > > > > Generally, on a LEAF firewall, if wtmp grows by mB per day, then you > > have a problem; and, the real problem is not wtmp. > > BTW, note that on Bering 1.0-rc3 /var/log/wtmp doesn't exist at bootup, and > unlike /var/log files under the control of syslog, wtmp won't be written to > unless it exists. Thus 'last' will just error if you run it.
wtmp is not under the control of syslog. It is under the control of login (and sshd). [1] login is implemented in Bering with tinylogin, and depending on the compile option, tinylogin may or may not maintain lastlog/utmp/wtmp. Given the problems with "last" that have been pointed out, I would guess this compile option is not selected. Some compiles of sshd have inadvertently left support for lastlog in, but there isn't much point if login isn't supporting it also. > The solution is to put 'touch /var/log/wtmp' in one of the startup scripts. > On my systems I put that in the 'start' section of /etc/init.d/sysklogd, > since that's the point at which the other /var/log files get created. In > his response to my bug report, Jacques stated that in the next version of > Bering, /etc/init.d/rcS will contain the command somewhere. I recall that lastlog has been a pain in the past, because it is arranged as an "array" indexed by UID, yielding large blanks in utmp between unassigned UIDs. These blanks appeared not to be "holes", so actual ramdisk space was squandered in them. It would seem that using nonstandard UIDs would solve this problem, but the typical solution has been to omit lastlog processing entirely. If lastlog is not used, then wtmp is pointless. If wtmp is not present, then last is pointless. So what really needs to be fixed? One might argue that it would be nice to see who had logged in recently, but that will almost certainly be "root". Knowing when root logged in would be nice, but "fixing" lastlog/wtmp is a standard intrusion action and would most likely be the first thing an unauthorized root user would do. So we would be deluding ourselves if we thought wtmp was a security measure in LEAF. In the interest of not providing false hope, and in minimizing filesystem and disk usage, I lean toward the "remove last" rather than the "support wtmp" option. [1] http://www.tac.eu.org/cgi-bin/man-cgi?utmp+5 --------------------------------------------------------------------------- Jeff Newmiller The ..... ..... Go Live... DCN:<[EMAIL PROTECTED]> Basics: ##.#. ##.#. Live Go... Live: OO#.. Dead: OO#.. Playing Research Engineer (Solar/Batteries O.O#. #.O#. with /Software/Embedded Controllers) .OO#. .OO#. rocks...2k --------------------------------------------------------------------------- ------------------------------------------------------- This sf.net email is sponsored by: Jabber - The world's fastest growing real-time communications platform! Don't just IM. Build it in! http://www.jabber.com/osdn/xim ------------------------------------------------------------------------ leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
