- This topic has 78 replies, 14 voices, and was last updated Jan 1-8:23 am by Anonymous.
-
Posts
-
Anonymous
FWIW, 2 months ago I received a report stating someone testing my revised version of SLiM was unable to use F1 (to toggle sessions from the SLiM login screen). In reply, I explained that I’m not reproduce the error. The reporter never followed up to provide additional details nor to report he’d found a solution.
@dave
Toward achieving multiseat, have you ever looked at ‘qingy’ (Qingy Is Not GettY)
It’s available from debian repositories (v0.9.7.2 is in jessie and sid repos)qingy is a replacement for getty. Written in C, it uses DirectFB to provide a fast, nice GUI without the overhead of the X Windows System. It allows the user to log in and start the session of his choice (text console, gnome, kde, wmaker, …)
Documentation (and in-the-wild discussions of it) is sparse.
I’ll collect my bookmarked links and post a followup here.I investigated the prospect of adding a picklist (selectbox) to the SLiM login screen.
Ugh.
To avoid package dependency on the unmaintained ‘xaw’ (athena widget toolkit for X), I expected could just copy (only!) the relevant xaw classfiles into the SLiM codebase. 7,000+ LOC later (larger than the existing SLiM codebase), I discovered that the debian-packaged version of libxext lacks a particular header file xaw would have needed… and I threw in the towel.Call a spade a spade ~~ the SLiM “F1 to toggle sessions” detail is awkward, is ASININE. At least I now understand why that feature-as-a-bug, across two decades, has remained unaddressed.
I’m not “onboard” with the prospect of using LightDM, due to its package dependencies. If future antiX versions ship LightDM, I would strip it (and its deps) then remaster for use on the systems I personally maintain.
This decade, all the niche login manager projects seem to be utilizing homemade OpenGL GUI toolkits. I’m guessing the prospect of using a component which requires OpenGL support is contrary to “supporting old hardware”.
Personally, I don’t even want a login/display manager which provides a “gui” login screen (and brings a burden of maintaining ‘themes’)… but, after many (!) hours of ongoing research, I believe I’ve exhausted all the prospective text-based alternatives ~~ none provides both PAM + consolekit support. For me, the fact that my revised version of SLiM supported both was its sole merit, its sole “saving grace”.
Dave
@dave
Toward achieving multiseat, have you ever looked at ‘qingy’ (Qingy Is Not GettY)
It’s available from debian repositories (v0.9.7.2 is in jessie and sid repos)Yes I have though that was a few years ago. I cannot recall the results and I am not using it now. As this is the case I assume that the results were not as good as I had hoped.
Computers are like air conditioners. They work fine until you start opening Windows. ~Author Unknown
bookmarked qingy links:
http://qingy.sourceforge.net/manual.php
http://qingy.sourceforge.net/faq.php
https://forums.gentoo.org/viewtopic-p-7310820.html
https://flameeyes.blog/2010/11/15/qingy-and-consolekit/
https://flameeyes.blog/2010/11/12/it-s-getting-boring-i-know-more-consolekit-braindumps/
https://help.ubuntu.com/community/qingy
https://wiki.gentoo.org/wiki/X_without_Display_Manager
https://wiki.gentoo.org/wiki/Qingy
fungalnet
what is it that (e)logind is meant to replace?
it replaces ConsoleKit.Additionally, it internally handles power management
(provides poweroff, reboot, sleep, hibernate, and hybrid-sleep commands.
For shutdown, reboot, and kexec, elogind shells out to “halt”, “reboot”, and “kexec” binaries)
thereby eliminating the need for a separate “pm-utils”ref:
elogind is meant to be a login manager, it should have no business handling power-on and power-off functions which should exclusively be handled by the init system. The init system needs to do at least this, be able to boot the system and make some basic functionality available and when time comes and it gets a signal to be able to safely bring the system down (without corrupting data by just pulling the chord).
Now in the case of systemd an init system is much more than this and the login management is blended in it. While using sysvinit or runit you are dragging the functionality of an init system (in this case systemd) and pushing the actual init system aside and allowing the “virus” to control this process.
Unless you are wrong, and elogind has nothing to do with power functionality. Are you?
PS I think what you meant to say it is with the helo of elogind a user can have the privileges elevated to poweroff a system or suspend it to disk or have it restart. Imagine having more than one users in the system and allowing each the privilege to bring it down. It is utter stupidity to allow the virus to define such things in a personal system where you better know your root password of be sudo empowered, it is even more mind boggling to have any user other than the sys-admin to control the system in such way. A unix system, although not very secure, should be able to run as a single user/sysadmin without any authorization regulator. One root does it all, not even having a password. We are introducing a bullshit necessity so we can have MS-win like functionality and all this madness stems from one source … freedesktop.IBM.Inc.
- This reply was modified 3 years, 2 months ago by fungalnet.
- This reply was modified 3 years, 2 months ago by fungalnet.
anti-X - Adélie - obarun - systemd Free Space
Unless you are wrong, and elogind has nothing to do with power functionality. Are you?
Instead of defending am I wrong, I’ll just invite you discover the answer firsthand, by consulting the elogind manpage.
man elogind
press forward slash to initiate search, type power, press enter
during search, pressing p and n keys will navigate previous/nextupstream source code for elogind available here:
https://github.com/elogind/elogind
by searching for references to “power” within the source code, one can quickly glean the nitty-gritty details
https://github.com/elogind/elogind/search?q=power&unscoped_q=powerhttp://tldp.org/HOWTO/User-Authentication-HOWTO/x115.html
3. PAM (Pluggable Authentication Modules)
Pluggable authentication modules are at the core of user authentication in any modern linux distribution.
3.1. Why
Back in the good old days of linux, if a program, such as su, passwd, login, or xlock, needed to authenticate a user, it would simply read the necessary information from /etc/passwd. If it needed to change the users’ password, it would simply edit /etc/passwd. This simple but clumsy method presented numerous problems for system administrators and application developers. As MD5 and shadow passwords became increasingly popular, each program requiring user authentication had to know how to get the proper information when dealing with a number of different schemes. If you wanted to change your user authentication scheme, all these programs had to be recompiled. PAM eliminates this mess by enabling programs to transparently authenticate users, regardless of how user information is stored.
3.2. What
Quoting from the Linux-PAM System Administrator’s Guide: “
- It is the purpose of the Linux-PAM project to separate the development of privilege granting software from the development of secure and appropriate authentication schemes.
This is accomplished by providing a library of functions that an application may use to request that a user be authenticated.” With PAM, it doesn’t matter whether your password is stored in /etc/passwd or on a server in Hong Kong. When a program needs to authenticate a user, PAM provides a library containing the functions for the proper authentication scheme. Because this library is loaded dynamically, changing authentication schemes can be done by simply editing a configuration file.
Flexibility is one of PAM’s greatest strengths. PAM can be configured to deny certain programs the right to authenticate users, to only allow certain users to be authenticated, to warn when certain programs attempt to authenticate, or even to deprive all users of login privileges. PAM’s modular design gives you complete control over how users are authenticated.
re: “power-on and power-off functions
whichshould exclusively be handled by the init system.”I’ll suggest reading the entire TDLP.org page, but consider the the underlined portions of this quoted excerpt.
re: “Now in the case of systemd an init system is much more than this…”
login manager {—} elogind {—} dbus {—} polkit {—} lib_pam.so {—} kernel
^— This reflects the current antiX implementation, and obviously the mechanism has remained init-system agnostic.the the underlined portions of this quoted excerpt.
Hmm, those UL portions can be seen in the webform textarea when someone clicks the “quote” button.
Idunno why they aren’t properly displayed as underlined in the posted message.fungalnet
🙂 I didn’t think for a second you are wrong, I am simply asking whether power functionality should be defined by the login daemon. If so then it dictates more things that the init should do or shouldn’t do, which is one layer of the system overtaking the role of another layer. In other words elogind in a way wants to dictate what compatible init you should have, and if it is not you better make it compatible with it.
Consolekit was never that invasive to other layers of the system.
Fortunately, by small, and insignificant to me, sacrifices, I can live without either one of them, for the time being.anti-X - Adélie - obarun - systemd Free Space
anticapitalista
@fungalnet – which version of antix are you using and what desktop-environment/window manager?
Do you use a login manager, if so, which one?Philosophers have interpreted the world in many ways; the point is to change it.
antiX with runit - leaner and meaner.
fungalnet
I have one main sid installation and two vm installations (one sid one buster/19 both running s6/66 – the second one is pretty much as it was in the live runit image but added openbox as well).
I always use openbox, no dm, I just login through console. Although I use obmenu-generator pretty much I start everything through the terminal. So I am not concerned for myself much when it comes to logind but I think allowing more and more software to depend on this piece of systemd that is constantly changing within systemd .. is for me a practice that I suspect it would run a distribution eventually into troubled territory. It is like a fish running after a fast moving bait.anti-X - Adélie - obarun - systemd Free Space
anticapitalista
Wondering how you got synaptic installed?
Do you have dbus-x11?I think you are wrongly targeting elogind. The real culprit is policykit-1.
Debian removed consolekit (after stretch) and has never supported consolekit2.
We have the stretch version of consolekit in all our repos, but use policykit-1 from Debian, which depends on libpam-systemd or libpam-elogind-compat.
If any app needs policykit, libpam-ck-connector gets removed and replaced by elogind.
Does anyone know if policykit will work with consolekit/libpam-ck-connector?
If it does, I could see about repackaging policykit and so it needs as a dependency libpam-systemd or libpam-elogind-compat or libpam-ck-connector.Philosophers have interpreted the world in many ways; the point is to change it.
antiX with runit - leaner and meaner.
anticapitalista
I just repackaged policykit (buster, testing and sid versions) to (hopefully) avoid bringing in elogind (for those that don’t want it), but uses libpam-ck-connector instead with consolekit.
Hopefully it doesn’t break anything.
Philosophers have interpreted the world in many ways; the point is to change it.
antiX with runit - leaner and meaner.
fungalnet
Sorry for not responding, I always think the box of email notifications is checked but I never get notified, except for one thread (screenshots 🙂
https://www.antixforum.com/forums/topic/synaptic-is-it-installable-in-sid/page/3/#post-33414
dbus/unstable,now 1.12.16-2 amd64 [installed,automatic]
simple interprocess messaging system (daemon and utilities)Installed but not always running unless absolutely necessary.
anti-X - Adélie - obarun - systemd Free Space
“This article explains what multi-seat is, how it works, and…”
Multi-seat on Linux, demystifiedfurther references cited in the above article:
http://en.wikipedia.org/wiki/Multiseat_configuration
http://netpatia.blogspot.com/2006/09/multiseat-vi-final-notes.html
http://www.x.org/wiki/Development/Documentation/Multiseat/
http://wiki.gentoo.org/wiki/Multiseat
https://wiki.archlinux.org/index.php/xorg_multiseat
Arch forum topic: » “Multiseat” gaming with multi-pointer X
ArchWiki: Multi-pointer X
- You must be logged in to reply to this topic.
