|
|
| (One intermediate revision by the same user not shown) |
| Line 1: |
Line 1: |
| = Migrate to lastlog2 =
| | Typo in heading. Moved to https://fedoraproject.org/wiki/Changes/Migrate_to_lastlog2 |
| | |
| {{Change_Proposal_Banner}}
| |
| | |
| == Summary ==
| |
| Migrate lastlog and all functionality associated with it (e.g. pam_lastlog, the PAM stack) to lastlog2.
| |
| | |
| == Owner ==
| |
| * Name: [[User:ipedrosa| Iker Pedrosa]]
| |
| * Email: <ipedrosa@redhat.com>
| |
| | |
| == Current status ==
| |
| [[Category:ChangePageIncomplete]]
| |
| <!-- When your change proposal page is completed and ready for review and announcement -->
| |
| <!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler -->
| |
| <!-- The Wrangler announces the Change to the devel-announce list and changes the category to Category:ChangeAnnounced (no action required) -->
| |
| <!-- After review, the Wrangler will move your page to Category:ChangeReadyForFesco... if it still needs more work it will move back to Category:ChangePageIncomplete-->
| |
| | |
| [[Category:SystemWideChange]]
| |
| | |
| * Targeted release: [https://docs.fedoraproject.org/en-US/releases/f43/ Fedora Linux 43]
| |
| * Last updated: <!-- this is an automatic macro — you don't need to change this line --> {{REVISIONYEAR}}-{{REVISIONMONTH}}-{{REVISIONDAY2}}
| |
| <!-- After the change proposal is accepted by FESCo, tracking bug is created in Bugzilla and linked to this page
| |
| Bugzilla state meanings:
| |
| ASSIGNED -> accepted by FESCo with ongoing development
| |
| MODIFIED -> change is substantially done and testable
| |
| ON_QA -> change is fully code complete
| |
| -->
| |
| * [<link to devel-announce post will be added by Wrangler> Announced]
| |
| * [<will be assigned by the Wrangler> Discussion thread]
| |
| * FESCo issue: <will be assigned by the Wrangler>
| |
| * Tracker bug: <will be assigned by the Wrangler>
| |
| * Release notes tracker: <will be assigned by the Wrangler>
| |
| | |
| == Detailed Description ==
| |
| The Year 2038 problem (Y2038) poses a significant threat to systems relying on 32-bit time representations. It's crucial to address this before it impacts Fedora. This proposal suggests replacing the current lastlog utility with lastlog2, a robust and widely adopted solution already integrated into distributions like Debian and openSUSE.
| |
| | |
| lastlog reports the last login of a given user or of all users who did ever login on a system. The standard `/var/log/lastlog` implementation using `lastlog.h` from glibc uses a 32bit `time_t` in struct lastlog on bi-arch systems like x86-64 (so which can execute 64bit and 32bit binaries). So even if you have a pure 64bit system, on many architectures using glibc this leads to the
| |
| [https://www.thkukuk.de/blog/Y2038_glibc_utmp_64bit/ Y2038 problem]. lastlog2 is a Y2038 safe implementation of lastlog and it is considered as the natural replacement.
| |
| | |
| lastlog2 offers a comprehensive solution, including not just the lastlog2 binary for interacting with user login information, but also a dedicated library and a PAM module for seamless integration and accurate user tracking. Critically, lastlog2 provides a migration path for existing lastlog data.
| |
| | |
| == Feedback ==
| |
| This Fedora System-Wide Change is open to feedback and other proposals from the community.
| |
| | |
| == Benefit to Fedora ==
| |
| * Y2038 safe: it addresses the core issue by using a time representation that avoids the Y2038 overflow.
| |
| * SQLite3 backend: it leverages a modern and efficient database for storing login information.
| |
| * PAM module integration: data collection is handled exclusively through a PAM module, allowing any tool to utilize the information without requiring modifications to existing packages. This ensures broad compatibility and avoids cascading changes.
| |
| * Backward compatibility: output is designed to be as compatible as possible with the traditional lastlog format, minimizing disruption to existing workflows.
| |
| * Data migration: it provides a mechanism to import existing data from the legacy `/var/log/lastlog` file, preserving valuable login history.
| |
| * Scalability: the database size scales with the number of users, not the largest UID, offering improved performance and resource utilization, especially in environments with sparse UID allocation.
| |
| | |
| This change offers a proactive and well-supported solution to the Y2038 problem within Fedora, ensuring the continued reliability and security of the system. In short, lastlog2 is part of the util-linux project, which Fedora has been using for years, and which has been accepted by different communities such as Debian or OpenSuse as the ideal replacement for lastlog.
| |
| | |
| == Scope ==
| |
| * Proposal owners: shadow-utils, PAM and util-linux projects need to change their configuration to stop providing lastlog functionality and start providing lastlog2. authselect project needs to replace pam_lastlog by pam_lastlog2 in the PAM stack and update fedora content accordingly. Finally, util-linux will have to migrate the existing database from lastlog to lastlog2 format during the upgrade process.
| |
| | |
| * Other developers: N/A
| |
| | |
| * Release engineering: [https://pagure.io/releng/issues #Releng issue number] <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
| |
| <!-- Does this feature require coordination with release engineering (e.g. changes to installer image generation or update package delivery)? Is a mass rebuild required? include a link to the releng issue.
| |
| The issue is required to be filed prior to feature submission, to ensure that someone is on board to do any process development work and testing and that all changes make it into the pipeline; a bullet point in a change is not sufficient communication --> N/A
| |
| | |
| * Policies and guidelines: N/A
| |
| | |
| * Trademark approval: N/A
| |
| | |
| * Alignment with the Fedora Strategy: N/A
| |
| | |
| == Upgrade/compatibility impact ==
| |
| Nothing will be affected, since the old database format from lastlog will be automatically migrated to the new lastlog2 format.
| |
| | |
| == How To Test ==
| |
| Two different scenarios come to my mind:
| |
| # New system: once the system is correctly installed authenticate as a user and run `lastlog2` for this user. The timestamp of the last login should match the one that recently happened.
| |
| # Old system: once the system is correctly updated authenticate as a user and run `lastlog2` for another user. The timestamp of the last login should have happened before the update happened.
| |
| | |
| == User Experience ==
| |
| `lastlog` and `pam_lastlog` don't exist anymore and are replaced by `lastlog2` and `pam_lastlog2`. They should behave in a similar manner to the aforementioned artifacts, thus no other change will be experienced by the user.
| |
| | |
| == Dependencies ==
| |
| There are no other dependencies.
| |
| | |
| == Contingency Plan ==
| |
| * Contingency mechanism: If any change was committed revert it.
| |
| * Contingency deadline: Just before beta freeze.
| |
| * Blocks release? No
| |
| | |
| == Documentation ==
| |
| * https://en.wikipedia.org/wiki/Year_2038_problem
| |
| * https://www.thkukuk.de/blog/Y2038_glibc_utmp_64bit/
| |
| * https://ikerexxe.github.io/idm/2023/06/14/Y2038-problem-in-shadow/
| |
| | |
| == Release Notes ==
| |
| Users should be informed that `lastlog` and `pam_lastlog` are replaced by `lastlog2` and `pam_lastlog2` in Fedora 43. In addition, the reasons for this change should be clearly explained. This FSWC proposal should be enough to understand the context, but if you have any doubts while writing the RN don't hesitate to contact the owner.
| |
