On 2024-05-31 01:05:51 +0800, Jun MO wrote:
> And if I understood correctly, wtmpdb require program use PAM to update
> wtmpdb, thus program not use PAM will still write /var/log/wtmp. For
> example, tmux write /var/log/wtmp via libutempter0 and I do not see tmux
> depends on pam.
GNU Screen and
On Fri, 31 May 2024 at 06:07, Jakub Wilk wrote:
>
> * Jun MO , 2024-05-31 01:05:
> >And something "off topic". I find there is a char __glibc_reserved[20]
> >variable in the struct utmp, which is commented as "Reserved for future
> >use". Just a brainstorm, if this variable is not currently used,
On 2024-05-30 18:41:51 +0200, Chris Hofstaedtler wrote:
> wtmpdb takes over the "last" name. Unfortunately without support for
> reading the old files. Nobody wrote tooling to import them or so.
In the new versions of the package, "last" could have been installed
under another name (e.g.
* Jun MO , 2024-05-31 01:05:
And something "off topic". I find there is a char __glibc_reserved[20]
variable in the struct utmp, which is commented as "Reserved for future
use". Just a brainstorm, if this variable is not currently used, maybe
it can be used to solve the Y2038 problem for wtmp?
* Jun MO [240530 19:09]:
> On Thu, 30 May 2024 13:18:17 +0200, Vincent Lefevre wrote:
> > I agree, this may be useful. Unfortunately, the current status is
> > that one cannot have both: installing wtmpdb forces the upgrade of
> > util-linux to 2.40.1-3 (at least), where "last" is no longer
On Thu, 30 May 2024 13:18:17 +0200, Vincent Lefevre wrote:
> I agree, this may be useful. Unfortunately, the current status is
> that one cannot have both: installing wtmpdb forces the upgrade of
> util-linux to 2.40.1-3 (at least), where "last" is no longer installed.
Thanks for the change
* Vincent Lefevre [240530 13:21]:
> On 2024-05-08 16:53:53 +0800, Jun MO wrote:
> > For last(1) my concern is that it will be helped to keep the original
> > last(1) for back-compatibility to read old wtmp files.
>
> I agree, this may be useful. Unfortunately, the current status is
> that one
On 2024-05-08 16:53:53 +0800, Jun MO wrote:
> For last(1) my concern is that it will be helped to keep the original
> last(1) for back-compatibility to read old wtmp files.
I agree, this may be useful. Unfortunately, the current status is
that one cannot have both: installing wtmpdb forces the
On Wed, 8 May 2024 at 09:21:35 +1000, Craig Small wrote:
> I can only speak for w. It currently prefers what it gets from
systemd or
> elogind, effectively
> iterating over the sessions coming from sd_get_sessions() if sd_booted()
> returns true.
>
> If sd_booted() returns false, then it
On Wed, 8 May 2024 at 09:03, Jun MO wrote:
> 1) I hope there will still be the original
> w(1)/last(1)/lastb(1)/lastlog(1)/faillog(1)
> tools which can still read *old* format utmp/wtmp/lastlog in Debian at
> least for
> a while after switch to Y2038-safe replacements. Those tools can read
>
I
Dear Developers,
A bit from a Debian user. Please note that I am not come to here to
blame/complain
against the Upstream/Maintainer of the pam package and the Maintainer of
the shadow
package, or come to here to request something. I just come to here to
present
some of my hope.
I often use
On Fri, Apr 26, 2024 at 08:06:15PM +0100, RL wrote:
> the chkrootkit package provides several utilities for examining some of
> these files: chkutmp chkwtmp and check_wtmpx and chklastlog [a] -- it does
> not use pam but reads the files in /var/log
>
> How would I test these against the new files
The following message is a courtesy copy of an article
that has been posted to
gmane.linux.debian.devel.general,gmane.linux.debian.devel.release as well.
Chris Hofstaedtler writes:
> you are probably aware of the time_t-64bit migration :-)
> However, this does not magically transition all data
On Fri, 26 Apr 2024 at 12:30, Chris Hofstaedtler wrote:
>
> Fellow Developers,
>
> you are probably aware of the time_t-64bit migration :-)
> However, this does not magically transition all data formats to 64bit
> times. One such instance is the set of utmp/wtmp and lastlog files.
>
> Thorsten
> "Chris" == Chris Hofstaedtler writes:
Chris> Fellow Developers,
Chris> you are probably aware of the time_t-64bit migration :-)
Chris> However, this does not magically transition all data formats to 64bit
Chris> times. One such instance is the set of utmp/wtmp and lastlog
Fellow Developers,
you are probably aware of the time_t-64bit migration :-)
However, this does not magically transition all data formats to 64bit
times. One such instance is the set of utmp/wtmp and lastlog files.
Thorsten Kukuk and others have been working on replacements for the
existing file
16 matches
Mail list logo
