Re: [DNG] elogind testing for experimental and ascii-proposed
On 19.01.18 17:34, KatolaZ wrote: > On Fri, Jan 19, 2018 at 06:03:59PM +0100, Didier Kryn wrote: > > But wether that session is local or not is, in my opinion, and as I > > already said, futile; and it seems to be mostly used as a justification to > > develop a tangle of daemons and middleware to bypass the traditional unix > > security framework. > > This is where I get totally lost with sessions: why on Earth should I > be able to mount an external device on a remote host to which I login > via SSH? Or unable to do that, if I am a regular user of that machine? > What is the use case for this madness? Does it really solve a problem, > or is just the usual non-working and useless solution to a problem > that doesn't even exist? > > I am sure I must be missing something here... Yes, the Poettering Syndrome, but nothing else. If a device needs to be mounted on another host, then the *nix way is to log in there via ssh or similar. (Heck, 30 years ago we used rlogin, before security became an issue. I even remember having root trusted from my host to the others.) If we replicate all debian architecture, then we remain Poetteringed, and are doomed to suffer the distasteful consequences of poor design. On 19.01.18 14:29, Rick Moen wrote: > Quoting Arnt Karlsen (a...@iaksess.no): > > > ..so a good way forward is, treat this policykit/consolekit/logind > > etc thing like systemd, pulseaudio etc poetterware. ... > Why does PolicyKit want to have itself in charge of all user > permissions, including that of the root user? Because the > Freedesktop.org coders decided to override user/groups permissions and > put themselves in charge via PAM links. And then PolicyKit > (policykit-1) requires the rest of the marching band. > The only real solution is to do without the Freedesktop.org 'stack' and > give GNOME the heave-ho. Devuan appears unwiling to take that step so > far, therefore here you are, adopting Gentoo's systemd-logind forked > code (which is what elogind is). +1000 After 30 years in embedded systems design, I remain convinced that the path to a good design is to add simplicity. The converse does not serve the user at all well. When finished with taking out everything that can be removed without losing essential functions, the design is complete. The primary attribute of a good desktop is to come up fast. Gnome fails the test. And its tentacles are a problem, not an asset. On 19.01.18 23:36, KatolaZ wrote: > BTW, GNOME will most probably not work anyway without systemd, and I > haven't seen many GNOME fans around here anyway, so GNOME has > effectively been given the heave-ho so far... Oh-Oh, if gnome is dependent on systemd, then it is by definition excluded from Devuan, IIUC? That is without doubt another plus for Devuan. Now we just need to dump polycykit and elogind, for another step toward an elegant clean distro. The Devuan policykit could perhaps be a text file something like: "Linux at heart. No systemd, its dependencies, or ancilliary cruft." Erik ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Getting rid of gnome was elogind testing for experimental and ascii-proposed
On 2018-01-19 17:36, KatolaZ wrote: BTW, GNOME will most probably not work anyway without systemd, and I haven't seen many GNOME fans around here anyway, so GNOME has effectively been given the heave-ho so far... HND KatolaZ gnome as a desktop may be absent but gnome is very much entwined with De(bia/vua)n. In setting up ascii for really important things :D , I discovered that Aisleriot overrides my mouse icon choice of DMZ (white) and forces use of the Adwaita icon theme within the game. So I tried to uninstall adwaita and it wanted to take most of the desktop with it. So much for user choice in Gnomeland. For the moment I have gotten around this by renaming the theme adwaita.old and the DMZ theme was restored. Hopefully that won't break other things. So in effect gnome is equally as entwined with the desktop as systemd and would be equally as challenging to remove. I filed a bug report with Debian but don't expect anything to change. golinux ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] elogind testing for experimental and ascii-proposed
Quoting Adam Borowski (kilob...@angband.pl): > While I heartily agree with you about GNOME itself, there's too much > software that uses gnome libs to allow such a move without having to patch > hundreds if not thousands of packages. Last time I checked, the GNOME libs required by 90%+ of those hundreds if not thousands of packages didn't have dependency chain resolving to systemd-logind or replacements thereof. gnumeric didn't, Evince did't, Dia did't, Shotwell didn't, Brasero didn't, GNOME Terminal didn't -- not even Evolution did. What does? The gnome-core package, which isn't a requirement of those 90%+ of GNOME applications. gnome-disk-utility, ditto. gnome-settings-daemon, network-manager, modem-manager-gui, gnome-system-tools, gnome-music, gnome-shell, gnome-disk-utility, and the 'gnome' kitchen-sink metapackage. Stuff like that -- GNOME-specific glue code pieces required to run the GNOME core as opposed to GNOME apps. But those are not to be confused with 90%+ of those hundreds if not thousands of packages, of which you speak. > Thus, logind needs to be at least emulated. I have no objection to systemd-logind being emulated. I merely think it's a mistake if anyone deems those emulations essential. They're a brittle crutch to software that IMO ought to be deemed non-essential, > joeyh resigned right after his decision to switch to XFCE got overridden > this way. I didn't know that, but that makes sense. That was a colossal blunder. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] elogind testing for experimental and ascii-proposed
On Fri, Jan 19, 2018 at 02:29:58PM -0800, Rick Moen wrote: > The only real solution is to do without the Freedesktop.org 'stack' and > give GNOME the heave-ho. Devuan appears unwiling to take that step so > far, therefore here you are, adopting Gentoo's systemd-logind forked > code (which is what elogind is). While I heartily agree with you about GNOME itself, there's too much software that uses gnome libs to allow such a move without having to patch hundreds if not thousands of packages. Thus, logind needs to be at least emulated. It's currently the most visible bad piece of that stack, but far from being the only one. > Debian let itself have its decisions dictated by GNOME. Isn't this > making the same mistake, and _even_ in the exact same place in the > system architecture? Well, yes. You may want to take a look at this: https://wiki.debian.org/DebianDesktop/Requalification/Jessie I've watched this process in progress, it was disgusting. This table reeks of government procurement. For example, Mate got docked two points for "tasksel task quality" -- something that takes a single install run to verify. Or, "systemd integration" gives _positive_ points -- for me, a desktop that works well with all unrelated software is strictly better than one that requires a specific controversial init, thus it should be "init compatibility" with the sign reversed. There's also no entry for "usability", or "discoverability" (users universally get stumped on the lack of maximize/etc buttons; I still don't know what's the way to run a terminal without navigating a bunch of controls then typing a name); no points were assigned for "consistency" while GNOME works differently from what users were accustomed to. GNOME also fails to display systray icons (other than its own), etc. And, GNOME crashes on start on 9/11 primary and 13/13 secondary architectures[1]. Take _this_ for a default! This was papered over by making the default vary by architecture, but any other package would be slapped with a RC bug and kept out of release for something like this. Or, speed: even on a few years old amd64, GNOME draws slower than a 1995ish machine if you don't have a GPU that supports certain GL extensions that GNOME requires. The vast majority of x86 hardware has such GPUs, but it's not exposed by kvm. joeyh resigned right after his decision to switch to XFCE got overridden this way. He never described his reason, but I strongly suspect this was the cause. Meow! [1]. I'm not aware if this still is the case: for Jessie, I tested a bunch of machines and VMs I could and asked others for reports, no one could find a single non-amd64 non-i386 machine where GNOME worked. It is possible that in Buster GNOME works on _some_ such machines -- but not on any I own. -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢰⠒⠀⣿⡁ Imagine there are bandits in your house, your kid is bleeding out, ⢿⡄⠘⠷⠚⠋⠀ the house is on fire, and seven big-ass trumpets are playing in the ⠈⠳⣄ sky. Your cat demands food. The priority should be obvious... ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] elogind testing for experimental and ascii-proposed
Quoting KatolaZ (kato...@freaknet.org): > Devuan is not adopting anything atm. Those packages are in > experimental, that is a repo meant for experimentations and tests. Noted. Thank you for clarifying (and yes, that was also stressed in the Subject header). > The mistake made by Debian was to inconditionally adopt systemd and > its kitchen sink, leaving behind the users who did not want to get in > that messy wagon, i.e., us. For the record (at the risk of repeating myself), I do not agree, and think it worth explaining once again why. Debian's mistake IMO was to not respond to having been put in an untenable position by GNOME developers by unmooring themselves from GNOME as a core distro feature required by Debian Policy. In my view, the General Resolution concerned the wrong question. It should have been about adopting a different standard DE (or no DE), not about whether the Technical Commitee may require a specific init system as PID1 and whether interoperation with various init systems should be encouraged. Wrong question. If they had simply dis-established GNOME as the official DE, then the ConsoleKit bitrot issue would have been relegated to 'GNOME problem' rather than 'Debian problem'. I blame tunnel-vision. The DDs failed to assess the overall situation and realise that the real problem was GNOME (and its underlying dependencies on the ever-changing Freedesktop.org code hairball), and that they'd need to deal with it eventually or would keep finding their policies dictated by unplanned Freedesktop.org code churn via coercion applied through excessive and problematic dependencies. Devuan is at risk of falling into the same pitfall if it keeps framing the problem as merely systemd-avoidance, and at best seeks nothing better than compatible workalikes for Freedesktop.org components. That is all that elogind is, and IMO that's all eudev is, too. To quote an old movie, the only way to win is not to play. > Being a universal distro is not about satisfying the needs of a small > user base, rather about not leaving anybody behind. Debian has mostly > failed at that. That's why Devuan exists. I certainly respect Devuan for trying to respect that aspiration where Debian failed. However, I'm increasingly inclined to think that a universal operating system is an unwise goal. (As always, I'm not offended by distro software decisions I differ from. I'll change the necessary implementation details locally if necessary.) ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] elogind testing for experimental and ascii-proposed
On Fri, Jan 19, 2018 at 02:29:58PM -0800, Rick Moen wrote: [cut] > > The only real solution is to do without the Freedesktop.org 'stack' and > give GNOME the heave-ho. Devuan appears unwiling to take that step so > far, therefore here you are, adopting Gentoo's systemd-logind forked > code (which is what elogind is). > BTW, GNOME will most probably not work anyway without systemd, and I haven't seen many GNOME fans around here anyway, so GNOME has effectively been given the heave-ho so far... HND KatolaZ -- [ ~.,_ Enzo Nicosia aka KatolaZ - Devuan -- Freaknet Medialab ] [ "+. katolaz [at] freaknet.org --- katolaz [at] yahoo.it ] [ @) http://kalos.mine.nu --- Devuan GNU + Linux User ] [ @@) http://maths.qmul.ac.uk/~vnicosia -- GPG: 0B5F062F ] [ (@@@) Twitter: @KatolaZ - skype: katolaz -- github: KatolaZ ] signature.asc Description: Digital signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] elogind testing for experimental and ascii-proposed
On Fri, Jan 19, 2018 at 02:29:58PM -0800, Rick Moen wrote: [cut] > > The only real solution is to do without the Freedesktop.org 'stack' and > give GNOME the heave-ho. Devuan appears unwiling to take that step so > far, therefore here you are, adopting Gentoo's systemd-logind forked > code (which is what elogind is). > > Debian let itself have its decisions dictated by GNOME. Isn't this > making the same mistake, and _even_ in the exact same place in the > system architecture? > Dear Rick, Devuan is not adopting anything atm. Those packages are in experimental, that is a repo meant for experimentations and tests. The mistake made by Debian was to inconditionally adopt systemd and its kitchen sink, leaving behind the users who did not want to get in that messy wagon, i.e., us. With *workaraunds* like eudev and elogind we could possibly minimise the damage for Devuan users who want to use a DE with bells and whistles, but still don't want systemd. Despite I don't give a tiny toss to any of these automagic things, I don't see anyhting wrong with trying to allow other people to use them, if they want so. Being a universal distro is not about satisfying the needs of a small user base, rather about not leaving anybody behind. Debian has mostly failed at that. That's why Devuan exists. HND KatolaZ -- [ ~.,_ Enzo Nicosia aka KatolaZ - Devuan -- Freaknet Medialab ] [ "+. katolaz [at] freaknet.org --- katolaz [at] yahoo.it ] [ @) http://kalos.mine.nu --- Devuan GNU + Linux User ] [ @@) http://maths.qmul.ac.uk/~vnicosia -- GPG: 0B5F062F ] [ (@@@) Twitter: @KatolaZ - skype: katolaz -- github: KatolaZ ] signature.asc Description: Digital signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] elogind testing for experimental and ascii-proposed
Quoting Arnt Karlsen (a...@iaksess.no): > ..so a good way forward is, treat this policykit/consolekit/logind > etc thing like systemd, pulseaudio etc poetterware. I'm bemused by people in the Devuan Project wanting to find a compatible substitute for systemd-logind. The entire Debian fiasco was driven by the GNOME maintainers insisting that the 'seat' functionality of ConsoleKit was essential, even though it was an obscure, niche function used by almost nobody. ConsoleKit becoming deprecated meant the GNOME developers needed another 'seat' implementation, which effectively forced choice of systemd-logind with the rest of that marching band. But it should have been, and was, obvious that this trait of reimplementing standard functions badly, EOLing and rewriting codebases frequently, and having ridiculously excessive features and dependencies was far from being confined to systemd but rather affected the entire Freedesktop.org glue suite: udisks2, PolicyKit, ConsoleKit, packagekit, network-manager, etc. Why does PolicyKit want to have itself in charge of all user permissions, including that of the root user? Because the Freedesktop.org coders decided to override user/groups permissions and put themselves in charge via PAM links. And then PolicyKit (policykit-1) requires the rest of the marching band. The only real solution is to do without the Freedesktop.org 'stack' and give GNOME the heave-ho. Devuan appears unwiling to take that step so far, therefore here you are, adopting Gentoo's systemd-logind forked code (which is what elogind is). Debian let itself have its decisions dictated by GNOME. Isn't this making the same mistake, and _even_ in the exact same place in the system architecture? ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] elogind testing for experimental and ascii-proposed
On Fri, 19 Jan 2018 19:06:37 +0100, Didier wrote in message <4f0e082e-16d5-29d1-1f7a-edb06ce05...@in2p3.fr>: > The major use cases are: > 1) server with remote users and only root allowed to mount > removable devices. > 2) laptop/desktop with one user at a time with full authority to > mount removable devices. You can ssh to your desktop/laptop and still > have the same permissions, what's the harm? You should ask someone > else to insert the device, and this is the true issue and it's not > solved by the kits (-: > > If the only role of policykit/consolekit/logind is to give you > permissions only if you are local, then I'm just saying that they > provide a complex solution to a non-existing problem. > > Didier ..so a good way forward is, treat this policykit/consolekit/logind etc thing like systemd, pulseaudio etc poetterware. -- ..med vennlig hilsen = with Kind Regards from Arnt Karlsen ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] elogind testing for experimental and ascii-proposed
On Fri, Jan 19, 2018 at 09:52:03PM +0100, Irrwahn wrote: [cut] > > All in all, I think that looks somewhat promising. However, as KatolaZ > rightly > pointed out, it'd be important to know which other setups would possibly be > broken by that approach, and what issues in other DEs might still persist. > Given the clusterf^W glorious goodness that all these kits'n'kats constitute, > I doubt it would be possible for it to make it in an ascii release proper — > unless an armada of people step forward to volunteer for smoke testing this > in > each and every conceivably sane DE configuration. (I, for one, am however > tempted to actually use it on my actual desktop system, provided it ever hits > at least the experimental repository.) > That's really marvellous progress guys! Congrats!!! IMPORTANT NOTICE: whoever is reading this email and asking themselves "How can I help Devuan?", here is a concrete task: Please help testing the consolekit2 + elogind + policykit clusterf^H^H^H^H^H^H^H combination with any conceivable Desktop Environment available in Devuan Ascii, and report the results back. The number, quality, and completeness of Desktop Environments what will be available and fully functional in the forthcoming Devuan Ascii is in your hands ;) HND KatolaZ P.S.: Andreas, Hleb, Urban, could you please take charge of prepare a concise list of DEs combinations to be tested, of what should be tested exactly, and of *easy* steps to install the required experimental packages? -- [ ~.,_ Enzo Nicosia aka KatolaZ - Devuan -- Freaknet Medialab ] [ "+. katolaz [at] freaknet.org --- katolaz [at] yahoo.it ] [ @) http://kalos.mine.nu --- Devuan GNU + Linux User ] [ @@) http://maths.qmul.ac.uk/~vnicosia -- GPG: 0B5F062F ] [ (@@@) Twitter: @KatolaZ - skype: katolaz -- github: KatolaZ ] signature.asc Description: Digital signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] elogind testing for experimental and ascii-proposed
Hleb Valoshka wrote on 19.01.2018 20:44: > On 1/19/18, Irrwahn wrote: >> I think that has to be done anyway, because currently one cannot >> have policykit without having consolekit installed with it, due to >> the "Depends". The package should have something akin to: >> >> Depends: libpam-elogind | consolekit >> >> Anyone up for the task? > > As it has been already told this task is not about of mere package rebuilding. > > But if you are in mood for testing, you can download from [1] > policykit built with elogind support (consolekit support is dropped as > it supports only one) and repeat your test. It was built in ascii > chroot so it's installable both in ascii & ceres. > > Repository with its source is at [2]. The branch is based on > suites/ascii-proposed. > > 1. https://mega.nz/#!lEVXUY6R!5MJOEEAtSadvwkv27tAPZguuYh0kRI8TVh-OL0VEj5Q > 2. https://git.devuan.org/375gnu/policykit-1/tree/elogind-support Great, thanks a bunch Hleb! * Installed your packages over already present policykit, leaving elogind in place. * Was able to purge consolekit2 after that, without dragging policykit with it, as I expected. * Shutdown/Restart from XFCE GUI is now working correctly! * USB drive user mount in Thunar is now working! (Admittedly, in the meantime I had added udisks2 and related stuff, but that only made the drive show up automagically. Mounting it as user was still prohibited unless I installed your reconfigured policykit.) * "loginctl reboot" from VT now working! (Despite still spewing a slightly irritating message; console transcript follows:) urban@vbascii2:~$ loginctl reboot System is going down for reboot NOW! Failed to reboot system via elogind: Message recipient disconnected from message bus without replying urban@vbascii2:~$ Broadcast message from root@vbascii2 (console) (date yadda-yadda): The system is going down for reboot NOW! INIT: Switching to runleve: 6 INIT: Sending processes the TERM signal Removed session 2. etc. pp. (the usual runlevel change sermon) I guess that could be an artifact of the shutdown method used by elogind? All in all, I think that looks somewhat promising. However, as KatolaZ rightly pointed out, it'd be important to know which other setups would possibly be broken by that approach, and what issues in other DEs might still persist. Given the clusterf^W glorious goodness that all these kits'n'kats constitute, I doubt it would be possible for it to make it in an ascii release proper — unless an armada of people step forward to volunteer for smoke testing this in each and every conceivably sane DE configuration. (I, for one, am however tempted to actually use it on my actual desktop system, provided it ever hits at least the experimental repository.) Thanks again for going to such lengths, and best regards Urban -- Sapere aude! ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] elogind testing for experimental and ascii-proposed
On 1/19/18, Irrwahn wrote: > I think that has to be done anyway, because currently one cannot > have policykit without having consolekit installed with it, due to > the "Depends". The package should have something akin to: > > Depends: libpam-elogind | consolekit > > Anyone up for the task? As it has been already told this task is not about of mere package rebuilding. But if you are in mood for testing, you can download from [1] policykit built with elogind support (consolekit support is dropped as it supports only one) and repeat your test. It was built in ascii chroot so it's installable both in ascii & ceres. Repository with its source is at [2]. The branch is based on suites/ascii-proposed. 1. https://mega.nz/#!lEVXUY6R!5MJOEEAtSadvwkv27tAPZguuYh0kRI8TVh-OL0VEj5Q 2. https://git.devuan.org/375gnu/policykit-1/tree/elogind-support ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] elogind testing for experimental and ascii-proposed
KatolaZ wrote on 19.01.2018 19:05: > On Fri, Jan 19, 2018 at 06:48:42PM +0100, Irrwahn wrote: > > [cut] > >> >> In my mind, the whole mess looks more like a gigantic game of nuclear >> whack-a-mole, and the only winning move is not to play. (The optimist >> believes we are living in the best of all possible worlds. The pessimist >> is afraid the optimist is right. Guess, which faction I belong to. ;^) >> >> But honestly, KatolaZ, thanks for damping my enthusiasm. :) >> > > Dear Urban, it was not my intention to damp your enthisiasm, at all, > so please accept my apoligies if I did :\ Oh, no need to apologize! I guess my message read far more ironic, or even sarcastic, than I intended. I was trying to convey my sincere thanks for putting everything in perspective. Alas, English is not my native tongue, plus I'm German, and us being direct is a prejudice that oftentimes turns out to be true. ;o) > > We need a lot of enthusiasm. And we also need to test this stuff in as > many different setups as possible, before deciding what's next, > IMHO. The help of all the knowledgeable people who are working on that > is very much appreciated :) Oh, I wasn't discouraged by your input, no worries, please. :) > TBH, it would be great if at the end of those tests we could have a > summary that explains what are the issues, what are the possible > solutions, and what we can do to help implementing them without > breaking too much stuff around ;) And I'll continue to contribute whatever my time and capabilities allow to reach that goal. After all, Devuan was the last straw that kept me from ditching GNU/Linux altogether in the wake of the systemd meltdown. [rant] But, honestly, the *BSDs are not the best alternative when it comes to desktop systems; server installations are another cup of tea, but that's (no longer) my main concern right now. [/rant] Best regards Urban -- Sapere aude! ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] elogind available in experimental and ascii-proposed
On 1/19/18, Arnt Karlsen wrote: >> Have you rebooted your pc after upgrading CK to CK2? > > ..while ok for us mere mortal hobbyist end users, is this > reboot dance acceptable in business hours? Reboot is still required to enable a new kernel, and anyway operations like dist-upgrade should be run out of BH because they may require reboot. >> I believe this crash exist only when one is still running old ck >> daemon. Unfortunately it looks like there is no way to replace running >> ck daemon (we can kill running one and dbus will start a new instance, >> ck2, but it won't have information about seats, etc created by the >> previous instance) > > ..why can it not read that info in e.g. a "--set-up-hijack-mode"? We need to talk with the upstream author. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] elogind testing for experimental and ascii-proposed
Le 19/01/2018 à 18:34, KatolaZ a écrit : On Fri, Jan 19, 2018 at 06:03:59PM +0100, Didier Kryn wrote: [cut] I think the concept of session is still usefull in the framework of a Desktop Environment. When you log into that kind of environment, you have a few services associated to it which make your life easier, like monitoring removable devices, battery or wifi status. It is also easier for dummies to login through a display manager. Hi Didier, if I understand it correctly, it seems that elogind + consolekit2 + upower + udisks + other pieces of black magic already allow to mount removable devices, monitor battery, suspend the system, and so on, in several DE configurations. I personally don't get all the intricacies of this hairball of protocols and interdependencies, but I am *very* *happy* that it somehow works, nevertheless. For a layman like me this means that we can consider having stuff like KDE as a working install-time desktop option in Devuan. Maybe not immediately, but surely in the near future. Do I care about DEs? Not at all. Do I care about having as many working DEs options in Devuan as physically possible? Oh yes man, I damn do... But wether that session is local or not is, in my opinion, and as I already said, futile; and it seems to be mostly used as a justification to develop a tangle of daemons and middleware to bypass the traditional unix security framework. This is where I get totally lost with sessions: why on Earth should I be able to mount an external device on a remote host to which I login via SSH? Or unable to do that, if I am a regular user of that machine? What is the use case for this madness? Does it really solve a problem, or is just the usual non-working and useless solution to a problem that doesn't even exist? Hi Enzo. The major use cases are: 1) server with remote users and only root allowed to mount removable devices. 2) laptop/desktop with one user at a time with full authority to mount removable devices. You can ssh to your desktop/laptop and still have the same permissions, what's the harm? You should ask someone else to insert the device, and this is the true issue and it's not solved by the kits (-: If the only role of policykit/consolekit/logind is to give you permissions only if you are local, then I'm just saying that they provide a complex solution to a non-existing problem. Didier ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] elogind testing for experimental and ascii-proposed
On Fri, Jan 19, 2018 at 06:48:42PM +0100, Irrwahn wrote: [cut] > > In my mind, the whole mess looks more like a gigantic game of nuclear > whack-a-mole, and the only winning move is not to play. (The optimist > believes we are living in the best of all possible worlds. The pessimist > is afraid the optimist is right. Guess, which faction I belong to. ;^) > > But honestly, KatolaZ, thanks for damping my enthusiasm. :) > Dear Urban, it was not my intention to damp your enthisiasm, at all, so please accept my apoligies if I did :\ We need a lot of enthusiasm. And we also need to test this stuff in as many different setups as possible, before deciding what's next, IMHO. The help of all the knowledgeable people who are working on that is very much appreciated :) TBH, it would be great if at the end of those tests we could have a summary that explains what are the issues, what are the possible solutions, and what we can do to help implementing them without breaking too much stuff around ;) My2Cents KatolaZ -- [ ~.,_ Enzo Nicosia aka KatolaZ - Devuan -- Freaknet Medialab ] [ "+. katolaz [at] freaknet.org --- katolaz [at] yahoo.it ] [ @) http://kalos.mine.nu --- Devuan GNU + Linux User ] [ @@) http://maths.qmul.ac.uk/~vnicosia -- GPG: 0B5F062F ] [ (@@@) Twitter: @KatolaZ - skype: katolaz -- github: KatolaZ ] signature.asc Description: Digital signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] elogind testing for experimental and ascii-proposed
KatolaZ wrote on 19.01.2018 17:36: > On Fri, Jan 19, 2018 at 02:17:28PM +0100, Irrwahn wrote: >> [...], because currently one cannot >> have policykit without having consolekit installed with it, due to >> the "Depends". The package should have something akin to: >> >> Depends: libpam-elogind | consolekit >> >> Anyone up for the task? >> > > Urban, it's not just a matter of recompiling a single package. It is > more about knowing how such a change would impact the whole > distribution, and desktop-things in particular. > > So before we rush into "remove that dep...oh no add that other one > instead...oh no, let's replace this component with a brand-new one > which does not exist yet..." we must know exactly where we want to go, > how to get there, and if the trip is worth the effort at all. Yeah, I'm beginning to grasp how deeply intertwined this entire hairball is. Either things used to be much easier in the past, or I've become substantially dumber. (Probably both. :P) > Having elogind and consolekit2 in experimental is all about trying to > see if some of the few glitches on the Devuan desktop can be easily > solved. IMHO, this does not mean that we must solve *all* of those > glitches, especially because the same concept of "session" (which is > the root of all this evil) looks at best badly defined, if not totally > bogus. I agree, but as is, for elogind to be of any use, policykit must be installable independently of consolekit(2). Or maybe I completely misinterpreted the whole situation, which is absolutely possible — in which case I apologize for the noise. > We don't necessarily have to follow the white rabbit into its dark > hole, especially because there is a high probability that the rabbit > will turn into a snake. We have the option to stay outside and enjoy > the sun... In my mind, the whole mess looks more like a gigantic game of nuclear whack-a-mole, and the only winning move is not to play. (The optimist believes we are living in the best of all possible worlds. The pessimist is afraid the optimist is right. Guess, which faction I belong to. ;^) But honestly, KatolaZ, thanks for damping my enthusiasm. :) Best regards Urban -- Sapere aude! ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] elogind testing for experimental and ascii-proposed
On Fri, Jan 19, 2018 at 06:03:59PM +0100, Didier Kryn wrote: [cut] > > I think the concept of session is still usefull in the framework of a > Desktop Environment. When you log into that kind of environment, you have a > few services associated to it which make your life easier, like monitoring > removable devices, battery or wifi status. It is also easier for dummies to > login through a display manager. > Hi Didier, if I understand it correctly, it seems that elogind + consolekit2 + upower + udisks + other pieces of black magic already allow to mount removable devices, monitor battery, suspend the system, and so on, in several DE configurations. I personally don't get all the intricacies of this hairball of protocols and interdependencies, but I am *very* *happy* that it somehow works, nevertheless. For a layman like me this means that we can consider having stuff like KDE as a working install-time desktop option in Devuan. Maybe not immediately, but surely in the near future. Do I care about DEs? Not at all. Do I care about having as many working DEs options in Devuan as physically possible? Oh yes man, I damn do... > But wether that session is local or not is, in my opinion, and as I > already said, futile; and it seems to be mostly used as a justification to > develop a tangle of daemons and middleware to bypass the traditional unix > security framework. This is where I get totally lost with sessions: why on Earth should I be able to mount an external device on a remote host to which I login via SSH? Or unable to do that, if I am a regular user of that machine? What is the use case for this madness? Does it really solve a problem, or is just the usual non-working and useless solution to a problem that doesn't even exist? I am sure I must be missing something here... HND KatolaZ -- [ ~.,_ Enzo Nicosia aka KatolaZ - Devuan -- Freaknet Medialab ] [ "+. katolaz [at] freaknet.org --- katolaz [at] yahoo.it ] [ @) http://kalos.mine.nu --- Devuan GNU + Linux User ] [ @@) http://maths.qmul.ac.uk/~vnicosia -- GPG: 0B5F062F ] [ (@@@) Twitter: @KatolaZ - skype: katolaz -- github: KatolaZ ] signature.asc Description: Digital signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] elogind available in experimental and ascii-proposed
On Wed, 17 Jan 2018 13:22:13 +0300, Hleb wrote in message : > On 1/17/18, Andreas Messer wrote: > > > Btw, "ck-list-sessions" crashes for me: > ... > > Have you rebooted your pc after upgrading CK to CK2? ..while ok for us mere mortal hobbyist end users, is this reboot dance acceptable in business hours? > I believe this crash exist only when one is still running old ck > daemon. Unfortunately it looks like there is no way to replace running > ck daemon (we can kill running one and dbus will start a new instance, > ck2, but it won't have information about seats, etc created by the > previous instance) ..why can it not read that info in e.g. a "--set-up-hijack-mode"? > > Maybe something to forward to upstream. > > I need a bit more time to check that this crash is actually caused by > the old daemon. -- ..med vennlig hilsen = with Kind Regards from Arnt Karlsen ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] elogind testing for experimental and ascii-proposed
Le 19/01/2018 à 16:42, Irrwahn a écrit : Adam Borowski wrote on 19.01.2018 15:56: On Fri, Jan 19, 2018 at 02:17:28PM +0100, Irrwahn wrote: I think that has to be done anyway, because currently one cannot have policykit without having consolekit installed with it, due to the "Depends". The package should have something akin to: Depends: libpam-elogind | consolekit Anyone up for the task? You would have to change policykit to allow runtime detection of logind vs consolekit. Currently it can be compiled only one way or the other. Oh, crud! Nothings ever easy. Having two versions of policykit probably would be an even worse idea, wouldn't it? The dbus API is incompatible. Both can coexist, but it's a bad idea to have consolekit be unaware of sessions handled by logind -- thus, if you want to keep consolekit alive, it'd better to implement logind API, as that's what the desktop environments ecosystem moved to. I somehow doubt there's a lot of capable people willing to do it. Of course, I'd be happily proven wrong on that account. Devuan doesn't (currently?) support non-Linux kernels, but Debian/kfreebsd and Debian/hurd guys would thank you for this. Hm, that increases the chances again, I guess. On the other hand, I have doubts whether logind or consolekit are the best approaches. The more I look at them, the more I boggle about the pointlessness of the whole concept of "sessions": with systemd, you can't have more than one GUI session; when a GUI session is on, ssh-ing in lets you access all resources that are supposed to be restricted to that GUI session; switching to another VT stops music from playing (because security). Thus, if you drop things we don't want, it all boils down to "does this user have a locally logged in session?". Type "who" and here's your answer. It would be possible to have a thin stub that answers dbus requests with standard POSIX backends, or similar non-NIH tools like pm-suspend. [Rant] Honestly, I'm already close to the point to kick all that session bullshit to the curb, and go back to startx or the like to bring up a graphical environment, and sudo-mount my thumbdrives, or whatever. And before anyone cries "but, but, but security": there are much, much more serious security holes to plug, besides me running X as root on my @/)%$$ desktop!) [/Rant] Such a stub would lose that "fast user switching" feature, but come on -- we live in a many computers per person world, rather than many persons per computer as it was the case in the past. Thus, my idea would have the following assumptions: * someone with physical access can always shutdown/reboot the machine: if the software disagrees, there's a big button and a small one close to it, if even that fails, there's a power cord (or a laptop battery). Kiosks are about the only cases to the contrary, and they already restrict you from issuing a "shutdown" command anyway. * multiple remote users are an important use case, both for command-line and GUI (vnc/...) logins * conversely, multiple local users don't matter anymore: everyone has multiple screen-attached computers. Note the name: _personal_ computer. When I say this, someone always responds with "but sub-saharan classrooms". Nope: ages ago we had such a situation in our world, and I don't remember a single case when kids had separate accounts where they'd lock a session before passing the keyboard to their neighbour. Thus, I knowingly dismiss a valid use case as irrelevant, to buy us KISS. It's not so different from systemd: it disallows you to log in via vnc if you have a local session, which is an use case I did need in the past. I wholeheartedly agree. I never were able to find a single person that used, lest relied upon, that multi-seat/multi-session pseudo-feature. We've come a long way since 1984. I think the concept of session is still usefull in the framework of a Desktop Environment. When you log into that kind of environment, you have a few services associated to it which make your life easier, like monitoring removable devices, battery or wifi status. It is also easier for dummies to login through a display manager. But wether that session is local or not is, in my opinion, and as I already said, futile; and it seems to be mostly used as a justification to develop a tangle of daemons and middleware to bypass the traditional unix security framework. This said, getting rid of all that crap without breaking anything is certainly not trivial. Didier ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] elogind testing for experimental and ascii-proposed
On Fri, Jan 19, 2018 at 02:17:28PM +0100, Irrwahn wrote: [cut] > > Yes, that appears to be the most likely explanation. > > > Maybe we need to rebuild it with support for elogind. > > I think that has to be done anyway, because currently one cannot > have policykit without having consolekit installed with it, due to > the "Depends". The package should have something akin to: > > Depends: libpam-elogind | consolekit > > Anyone up for the task? > Urban, it's not just a matter of recompiling a single package. It is more about knowing how such a change would impact the whole distribution, and desktop-things in particular. So before we rush into "remove that dep...oh no add that other one instead...oh no, let's replace this component with a brand-new one which does not exist yet..." we must know exactly where we want to go, how to get there, and if the trip is worth the effort at all. Having elogind and consolekit2 in experimental is all about trying to see if some of the few glitches on the Devuan desktop can be easily solved. IMHO, this does not mean that we must solve *all* of those glitches, especially because the same concept of "session" (which is the root of all this evil) looks at best badly defined, if not totally bogus. We don't necessarily have to follow the white rabbit into its dark hole, especially because there is a high probability that the rabbit will turn into a snake. We have the option to stay outside and enjoy the sun... My2Cents KatolaZ -- [ ~.,_ Enzo Nicosia aka KatolaZ - Devuan -- Freaknet Medialab ] [ "+. katolaz [at] freaknet.org --- katolaz [at] yahoo.it ] [ @) http://kalos.mine.nu --- Devuan GNU + Linux User ] [ @@) http://maths.qmul.ac.uk/~vnicosia -- GPG: 0B5F062F ] [ (@@@) Twitter: @KatolaZ - skype: katolaz -- github: KatolaZ ] signature.asc Description: Digital signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] elogind testing for experimental and ascii-proposed
Adam Borowski wrote on 19.01.2018 15:56: > On Fri, Jan 19, 2018 at 02:17:28PM +0100, Irrwahn wrote: >> I think that has to be done anyway, because currently one cannot >> have policykit without having consolekit installed with it, due to >> the "Depends". The package should have something akin to: >> >> Depends: libpam-elogind | consolekit >> >> Anyone up for the task? > > You would have to change policykit to allow runtime detection of logind vs > consolekit. Currently it can be compiled only one way or the other. Oh, crud! Nothings ever easy. Having two versions of policykit probably would be an even worse idea, wouldn't it? > The dbus API is incompatible. Both can coexist, but it's a bad idea to have > consolekit be unaware of sessions handled by logind -- thus, if you want to > keep consolekit alive, it'd better to implement logind API, as that's what > the desktop environments ecosystem moved to. I somehow doubt there's a lot of capable people willing to do it. Of course, I'd be happily proven wrong on that account. > > Devuan doesn't (currently?) support non-Linux kernels, but Debian/kfreebsd > and Debian/hurd guys would thank you for this. Hm, that increases the chances again, I guess. > > On the other hand, I have doubts whether logind or consolekit are the best > approaches. The more I look at them, the more I boggle about the > pointlessness of the whole concept of "sessions": with systemd, you can't > have more than one GUI session; when a GUI session is on, ssh-ing in lets > you access all resources that are supposed to be restricted to that GUI > session; switching to another VT stops music from playing (because > security). Thus, if you drop things we don't want, it all boils down to > "does this user have a locally logged in session?". Type "who" and here's > your answer. It would be possible to have a thin stub that answers dbus > requests with standard POSIX backends, or similar non-NIH tools like > pm-suspend. [Rant] Honestly, I'm already close to the point to kick all that session bullshit to the curb, and go back to startx or the like to bring up a graphical environment, and sudo-mount my thumbdrives, or whatever. And before anyone cries "but, but, but security": there are much, much more serious security holes to plug, besides me running X as root on my @/)%$$ desktop!) [/Rant] > > Such a stub would lose that "fast user switching" feature, but come on -- we > live in a many computers per person world, rather than many persons per > computer as it was the case in the past. Thus, my idea would have the > following assumptions: > * someone with physical access can always shutdown/reboot the machine: if > the software disagrees, there's a big button and a small one close to it, > if even that fails, there's a power cord (or a laptop battery). Kiosks > are about the only cases to the contrary, and they already restrict you > from issuing a "shutdown" command anyway. > * multiple remote users are an important use case, both for command-line and > GUI (vnc/...) logins > * conversely, multiple local users don't matter anymore: everyone has > multiple screen-attached computers. Note the name: _personal_ computer. > When I say this, someone always responds with "but sub-saharan > classrooms". Nope: ages ago we had such a situation in our world, and > I don't remember a single case when kids had separate accounts where > they'd lock a session before passing the keyboard to their neighbour. > Thus, I knowingly dismiss a valid use case as irrelevant, to buy us KISS. > It's not so different from systemd: it disallows you to log in via vnc if > you have a local session, which is an use case I did need in the past. I wholeheartedly agree. I never were able to find a single person that used, lest relied upon, that multi-seat/multi-session pseudo-feature. We've come a long way since 1984. > > But, it's good to have elogind available, even if just for a transition. > For starters, such an unix-logind doesn't exist yet. Vapourware that I > don't volunteer to write is quite a weak argument... > (Compare the complete code of loginkit: > https://github.com/dimkr/LoginKit/blob/jessie/loginkitd/loginkitd.c) True dat. That's one, if not /the/, crucial point. I'd volunteer to support such an endeavor in whatever way I can, however writing stuff like that from scratch is currently beyond my capabilities, and would probably drive what's left of my sanity right over the edge (I've touched dbus before, will never touch that POC again!), so unfortunately I too have to pass on taking a lead role in that, sorry. > > Meow! Eek! Urban -- Sapere aude! ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] elogind testing for experimental and ascii-proposed
On Fri, Jan 19, 2018 at 02:17:28PM +0100, Irrwahn wrote: > > It seems to me that these issues are caused by policykit, in devuan it > > doesn't support logind (obviously) so it's unable to authenticate > > user's requests. > > Yes, that appears to be the most likely explanation. > > > Maybe we need to rebuild it with support for elogind. > > I think that has to be done anyway, because currently one cannot > have policykit without having consolekit installed with it, due to > the "Depends". The package should have something akin to: > > Depends: libpam-elogind | consolekit > > Anyone up for the task? You would have to change policykit to allow runtime detection of logind vs consolekit. Currently it can be compiled only one way or the other. The dbus API is incompatible. Both can coexist, but it's a bad idea to have consolekit be unaware of sessions handled by logind -- thus, if you want to keep consolekit alive, it'd better to implement logind API, as that's what the desktop environments ecosystem moved to. Devuan doesn't (currently?) support non-Linux kernels, but Debian/kfreebsd and Debian/hurd guys would thank you for this. On the other hand, I have doubts whether logind or consolekit are the best approaches. The more I look at them, the more I boggle about the pointlessness of the whole concept of "sessions": with systemd, you can't have more than one GUI session; when a GUI session is on, ssh-ing in lets you access all resources that are supposed to be restricted to that GUI session; switching to another VT stops music from playing (because security). Thus, if you drop things we don't want, it all boils down to "does this user have a locally logged in session?". Type "who" and here's your answer. It would be possible to have a thin stub that answers dbus requests with standard POSIX backends, or similar non-NIH tools like pm-suspend. Such a stub would lose that "fast user switching" feature, but come on -- we live in a many computers per person world, rather than many persons per computer as it was the case in the past. Thus, my idea would have the following assumptions: * someone with physical access can always shutdown/reboot the machine: if the software disagrees, there's a big button and a small one close to it, if even that fails, there's a power cord (or a laptop battery). Kiosks are about the only cases to the contrary, and they already restrict you from issuing a "shutdown" command anyway. * multiple remote users are an important use case, both for command-line and GUI (vnc/...) logins * conversely, multiple local users don't matter anymore: everyone has multiple screen-attached computers. Note the name: _personal_ computer. When I say this, someone always responds with "but sub-saharan classrooms". Nope: ages ago we had such a situation in our world, and I don't remember a single case when kids had separate accounts where they'd lock a session before passing the keyboard to their neighbour. Thus, I knowingly dismiss a valid use case as irrelevant, to buy us KISS. It's not so different from systemd: it disallows you to log in via vnc if you have a local session, which is an use case I did need in the past. But, it's good to have elogind available, even if just for a transition. For starters, such an unix-logind doesn't exist yet. Vapourware that I don't volunteer to write is quite a weak argument... (Compare the complete code of loginkit: https://github.com/dimkr/LoginKit/blob/jessie/loginkitd/loginkitd.c) Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢰⠒⠀⣿⡁ Imagine there are bandits in your house, your kid is bleeding out, ⢿⡄⠘⠷⠚⠋⠀ the house is on fire, and seven big-ass trumpets are playing in the ⠈⠳⣄ sky. Your cat demands food. The priority should be obvious... ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] elogind testing for experimental and ascii-proposed
Hleb Valoshka wrote on 19.01.2018 13:28: > On 1/19/18, Irrwahn wrote: >> Scenario 1: >> --- >> │ PAM profiles to enable: >> │ >> │[*] Unix authentication >> │[*] Authenticate using SSH keys and start ssh-agent >> │[*] elogind Session Management >> │[ ] ConsoleKit Session Management >> >> User loggind in via GUI: >> * session is listed by loginctl >> * Restart/Shutdown only logs out and leads back to lightdm greeter. >> >> User logged in via VT: >> * session is listed by loginctl >> * "loginctl reboot": "Failed to reboot system via elogind: >> Interactive authentication required." > > It seems to me that these issues are caused by policykit, in devuan it > doesn't support logind (obviously) so it's unable to authenticate > user's requests. Yes, that appears to be the most likely explanation. > Maybe we need to rebuild it with support for elogind. I think that has to be done anyway, because currently one cannot have policykit without having consolekit installed with it, due to the "Depends". The package should have something akin to: Depends: libpam-elogind | consolekit Anyone up for the task? Best regards Urban -- Sapere aude! ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] elogind testing for experimental and ascii-proposed
On 1/19/18, Irrwahn wrote: > Scenario 1: > --- > │ PAM profiles to enable: > │ > │[*] Unix authentication > │[*] Authenticate using SSH keys and start ssh-agent > │[*] elogind Session Management > │[ ] ConsoleKit Session Management > > User loggind in via GUI: > * session is listed by loginctl > * Restart/Shutdown only logs out and leads back to lightdm greeter. > > User logged in via VT: > * session is listed by loginctl > * "loginctl reboot": "Failed to reboot system via elogind: > Interactive authentication required." It seems to me that these issues are caused by policykit, in devuan it doesn't support logind (obviously) so it's unable to authenticate user's requests. Maybe we need to rebuild it with support for elogind. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] elogind testing for experimental and ascii-proposed
Andreas Messer wrote on 19.01.2018 07:16: > That seems strange. loginctl is a elogind command and when elogind does not > know about the session loginctl should reject or ask for auth. I'll dig into > this a little bit more. Probably time to setup a vm. So, I did a little more testing: * Fresh ascii VM with lightdm and XFCE4; not tampered with. * ConsoleKit is actually consolekit2 from experimental. * VM was rebooted after each PAM configuration change. * USB mass storage devices do not show up in Thunar at all, let alone being user mountable - despite udisks2 being installed. (So, I definitely did something special on the other, older VM!) Scenario 1: --- │ PAM profiles to enable: │ │[*] Unix authentication │[*] Authenticate using SSH keys and start ssh-agent │[*] elogind Session Management │[ ] ConsoleKit Session Management User loggind in via GUI: * session is listed by loginctl * Restart/Shutdown only logs out and leads back to lightdm greeter. User logged in via VT: * session is listed by loginctl * "loginctl reboot": "Failed to reboot system via elogind: Interactive authentication required." Scenario 2: --- │ PAM profiles to enable: │ │[*] Unix authentication │[*] Authenticate using SSH keys and start ssh-agent │[ ] elogind Session Management │[*] ConsoleKit Session Management User loggind in via GUI: * session not listed by loginctl * Restart/Shutdown work as intended. User logged in on VT: * session not listed by loginctl * "loginctl reboot": complains (dbus service unavailable), but works! Scenario 3: --- │ PAM profiles to enable: │ │[*] Unix authentication │[*] Authenticate using SSH keys and start ssh-agent │[*] elogind Session Management │[*] ConsoleKit Session Management User loggind in via GUI: * session is listed by loginctl * Restart/Shutdown only logs out and leads back to lightdm greeter. User logged in on VT: * session is listed by loginctl * "loginctl reboot": asks to authenticate as root. HTH, best regards Urban -- Sapere aude! ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
