Re: [DNG] elogind testing for experimental and ascii-proposed

[Yevgeny Kosarzhevsky]

Hi all,

I am trying consolekit2 and getting screen locked with KDE on ascii.
To unlock it needs loginctl unlock-sessions ut I cannot find it in my
system.
Does anyone know how to fix that?

On 20 January 2018 at 19:28, KatolaZ  wrote:

> On Sat, Jan 20, 2018 at 11:46:33AM +0100, Andreas Messer wrote:
>
> [cut]
>
> >
> > So my oppinion is, that, at least for transition or migration purposes
> > we need to provide two paths in devuan, the user needs to choose one of
> them
> >
> > - consolekit(2) + policykit
> > - elogind + policykit-logind
> >
>
> Dear Andreas,
>
> I respectfully disagree on that point. Devuan should always allow a
> third option, that is:
>
>  - none of the above
>
> and a fourth option, that is:
>
>  - mix and match, at your own risk
>
> This is an attitude that we can't relinquish, whatever the cost. It's
> at the very heart of Devuan. Not all Devuan users want to have a fully
> "featured" desktop, and they must retain the possibility of *not*
> having any of that cruft in their systems (yes, I normally consider
> that stuff *cruft* in my systems, and I am definitely one of those
> choosing "none of the above"). Many Devuan users are natural
> tinkerers, to whom experimenting is at the heart of their GNU/Linux
> experience. Many more are server users, and don't give a toss to the
> elogind + policycit + consolekit clusterfuck anyway.
>
> Being a universal operating system is about allowing users to choose
> what to use and what to discard, avoiding unnecessary
> entanglement. That's why we are here.
>
>
> > Generally i would like to see get rid of all systemd originating software
> > monoliths. So what i could imagine:
> >
> > - Create a logind replacement which redirects all dbus queries to
> consolekit
> >   and let consolekit doe the session management. dbus queries for which
> no
> >   consolekit stuff exists (e.g. shutdown/reboot...) could be simply fan
> out
> >   into an external command, e.g. shell script. Its up to the
> >   administrator/maintainer whats happens then. Using this we can have
> consolekit
> >   and logind api at the same time while not struggling with two session
> >   management systems.
> >
> > - Create a minimal logind replacement which uses unix commands as
> thought of
> >   by Adam. This can be used by people who want install DEs requiring
> logind
> >   but dont want ck or logind to be installed
> >
> > If this is possible, every one can choose what he like and what fits
> > her/his needs. That is the spirit of linux.
> >
>
> To create something we need creators. Personally, I am not interested
> in desktop-things (it should be very clear by now :P), so I don't see
> myself actively working to develop replacements for those components.
>
> I am otherwise interested in experimenting with different possible
> alternatives for device management (mdev/smdev?), init systems
> (sinit?), and process management (perp?), and in possibly making them
> available in Devuan for those who like minimalism. That's my personal
> goal for after ascii will be out.
>
> Developing a universal operating system is about me and you working at
> the same distribution, with goals as different as a microminimal
> shell-only system and a full-featured gorgeous desktop environment,
> and still not noticing any inconsistency.
>
> 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  ]
>
> ___
> Dng mailing list
> Dng@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>
>


-- 
Regards,
Yevgeny
___
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]

On Sat, Jan 20, 2018 at 11:46:33AM +0100, Andreas Messer wrote:

[cut]

> 
> So my oppinion is, that, at least for transition or migration purposes 
> we need to provide two paths in devuan, the user needs to choose one of them
> 
> - consolekit(2) + policykit
> - elogind + policykit-logind
>

Dear Andreas,

I respectfully disagree on that point. Devuan should always allow a
third option, that is:

 - none of the above

and a fourth option, that is:

 - mix and match, at your own risk

This is an attitude that we can't relinquish, whatever the cost. It's
at the very heart of Devuan. Not all Devuan users want to have a fully
"featured" desktop, and they must retain the possibility of *not*
having any of that cruft in their systems (yes, I normally consider
that stuff *cruft* in my systems, and I am definitely one of those
choosing "none of the above"). Many Devuan users are natural
tinkerers, to whom experimenting is at the heart of their GNU/Linux
experience. Many more are server users, and don't give a toss to the
elogind + policycit + consolekit clusterfuck anyway.

Being a universal operating system is about allowing users to choose
what to use and what to discard, avoiding unnecessary
entanglement. That's why we are here.


> Generally i would like to see get rid of all systemd originating software
> monoliths. So what i could imagine:
> 
> - Create a logind replacement which redirects all dbus queries to consolekit
>   and let consolekit doe the session management. dbus queries for which no
>   consolekit stuff exists (e.g. shutdown/reboot...) could be simply fan out
>   into an external command, e.g. shell script. Its up to the
>   administrator/maintainer whats happens then. Using this we can have 
> consolekit
>   and logind api at the same time while not struggling with two session
>   management systems.
> 
> - Create a minimal logind replacement which uses unix commands as thought of
>   by Adam. This can be used by people who want install DEs requiring logind
>   but dont want ck or logind to be installed
> 
> If this is possible, every one can choose what he like and what fits
> her/his needs. That is the spirit of linux.
> 

To create something we need creators. Personally, I am not interested
in desktop-things (it should be very clear by now :P), so I don't see
myself actively working to develop replacements for those components.

I am otherwise interested in experimenting with different possible
alternatives for device management (mdev/smdev?), init systems
(sinit?), and process management (perp?), and in possibly making them
available in Devuan for those who like minimalism. That's my personal
goal for after ascii will be out.

Developing a universal operating system is about me and you working at
the same distribution, with goals as different as a microminimal
shell-only system and a full-featured gorgeous desktop environment,
and still not noticing any inconsistency.

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

[Andreas Messer]

Hello all,

sorry for beeing mute for so long, but i was busy with other things, and
still have not much time at the moment

On Fri, Jan 19, 2018 at 11:48:43AM +0100, Irrwahn wrote:
> 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:
> [...]

Thank you very much for the elaborate testing! Taken all the test results
into account so far, I conclude we should mark elogind "Conflicts:
consolekit". When both are available, one seems not be working properly.
Furthermore elogind should get some default configuration which make it to
not cause unexpected side effects:

- disable killing of porcesses when session ends
- ...

On Fri, Jan 19, 2018 at 03:56:22PM +0100, Adam Borowski wrote:
> [...] 
> 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 fully agree with that. 

> 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
> [...]

Well, I use :-). 

On Fri, Jan 19, 2018 at 05:34:23PM +, 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?

For me, the mainreason to have this is. Just imagine the
case of a machine having a desktop, but also regulary used by other remote
users. We had this scenario at university - all desktops where used to run
simulation jobs remotely by all users  while the secretary was typing in 
letters. In that case a remote use should not be able to mount USB stick 
plugged in by the secretary. 

There also scenarios, where such desktops are not assigned to a particular 
user but used by different users. (Students Computer pool) The you really
want allow mounting only to the guy logged in and sitting in front of the
screen.

I you dont want to use it on your system, just dont install it.

[...]

So for me, there is a need for such a function on a desktop system. I could
agree with the problem that logind is doing much more than it should. I
really dislike that it:

- kills process  depending on its decision
- manipulates control groups - we have already daemons for this
- reboots/shutdowns/supsends the system if it like to do so

I'm not fully sure, but as far as I understand consolekit does not do such
things, so from my viewpoint consolekit is the one to prefer. It is more
unix spirit. But we need a solution to allow for different DEs to be used 
in devuan and for now, many DEs require logind. 

So my oppinion is, that, at least for transition or migration purposes 
we need to provide two paths in devuan, the user needs to choose one of them

- consolekit(2) + policykit
- elogind + policykit-logind

Generally i would like to see get rid of all systemd originating software
monoliths. So what i could imagine:

- Create a logind replacement which redirects all dbus queries to consolekit
  and let consolekit doe the session management. dbus queries for which no
  consolekit stuff exists (e.g. shutdown/reboot...) could be simply fan out
  into an external command, e.g. shell script. Its up to the

Re: [DNG] elogind testing for experimental and ascii-proposed

[Didier Kryn]

Le 20/01/2018 à 01:01, Adam Borowski a écrit :

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.

    It is true that a lot of things depend on Gnome libraries, Gnome 
themes and Gnome icons. But the Gnome libraries may be installed without 
the whole Gnome monty.


    It remains that DEs, in particular Xfce4, depend also on the 
permission kits to perform some operations. Therefore I also think that 
the best road would be to emulate these kits without the need for a 
session database and/or PAM integration. However this may be a longer 
term goal; and, to avoid breaking things in the mean time, use elogind.


        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

[Erik Christiansen]

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] elogind testing for experimental and ascii-proposed

[Rick Moen]

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

[Adam Borowski]

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

[Rick Moen]

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

[KatolaZ]

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

[KatolaZ]

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

[Rick Moen]

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

[KatolaZ]

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

[Irrwahn]

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

[Hleb Valoshka]

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

[Irrwahn]

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 testing for experimental and ascii-proposed

[Didier Kryn]

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

[KatolaZ]

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

[Irrwahn]

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

[KatolaZ]

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 testing for experimental and ascii-proposed

[Didier Kryn]

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

[KatolaZ]

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

[Irrwahn]

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

[Adam Borowski]

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

[Irrwahn]

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

[Hleb Valoshka]

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

[Irrwahn]

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

Re: [DNG] elogind testing for experimental and ascii-proposed

[Irrwahn]

Andreas Messer wrote on 19.01.2018 07:16:
> On Wed, Jan 17, 2018 at 09:26:59PM +0100, Irrwahn wrote:
>> Outcome is the same when logged in via a VT console, while elogind 
>> is fully enabled (and ck2 and pk installed). With elogind disabled 
>> (ck+pk only), no extra authentication is needed. 
> 
> That seems strange. loginctl is a elogind command and when elogind does not
> know about the session loginctl should reject or ask for auth.

And that would make a lot more sense. Maybe it has some kind of 
fallback implemented? After all, it's elogind, not sd-logind.

I sincerely hope we're actually debugging elogind, and not a 
setup I broke. In the course of the day I will probably find 
more time to invest in this.

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

[Andreas Messer]

On Wed, Jan 17, 2018 at 09:26:59PM +0100, Irrwahn wrote:
> Hleb Valoshka wrote on 17.01.2018 20:54:
> > [...] 
> > Can you repeat the same but with a local login?
> 
> Outcome is the same when logged in via a VT console, while elogind 
> is fully enabled (and ck2 and pk installed). With elogind disabled 
> (ck+pk only), no extra authentication is needed. 

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.

Cheers,
Andreas



signature.asc
Description: PGP 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

[Irrwahn]

Hleb Valoshka wrote on 17.01.2018 20:54:
> On 1/17/18, Irrwahn  wrote:
> 
>> * screen sessions killed on logout
>>   (regression, works with elogind disabled!)
> 
> This is because elogind is designed to be logind replacement (and
> actually shares its code) and so it's bug-for-bug compatible. Systemd
> uses cgroups to track processes and on logout kills all user's
> processes started during the session.

According to A. Messer this behavior can be changed in a configuration 
file.

> 
>> *  urban@vboxascii:~$ loginctl reboot
>>AUTHENTICATING FOR org.freedesktop.login1.reboot
> 
> This is incorrect behaviour. Required privileges should be granted
> automatically due to pam module, could you show your
> /etc/pam.d/session-common?
> 
> Oh, wait...
> 
>>Connection to 192.168.2.167 closed by remote host.
> 
> Remote connection, so this explains the previous message.
> 
> Can you repeat the same but with a local login?

Outcome is the same when logged in via a VT console, while elogind 
is fully enabled (and ck2 and pk installed). With elogind disabled 
(ck+pk only), no extra authentication is needed. 

However, I just finished debootstrapping a fresh ascii VM, and 
interestingly USB mounting with ck2 is broken again. Presumably I 
previously messed around with the older VM I made the tests with, 
possibly hacked open some polkit actions, or the like. Thus, the 
results I got must be taken with considerably more than just a grain 
of salt! OTOH, the reboot/shutdown sequences look the same as before,
i.e. requiring extra authentication.

HTH, 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

[Hleb Valoshka]

On 1/17/18, Irrwahn  wrote:

> * screen sessions killed on logout
>   (regression, works with elogind disabled!)

This is because elogind is designed to be logind replacement (and
actually shares its code) and so it's bug-for-bug compatible. Systemd
uses cgroups to track processes and on logout kills all user's
processes started during the session.

> *  urban@vboxascii:~$ loginctl reboot
>AUTHENTICATING FOR org.freedesktop.login1.reboot

This is incorrect behaviour. Required privileges should be granted
automatically due to pam module, could you show your
/etc/pam.d/session-common?

Oh, wait...

>Connection to 192.168.2.167 closed by remote host.

Remote connection, so this explains the previous message.

Can you repeat the same but with a local login?

> 3. No consolekit/policykit, only elogind installed and activated
>(not sure if that even makes any sense, but what the heck):
...

Works as expected.
___
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

[Irrwahn]

Andreas Messer wrote on 16.01.2018 22:24:
> since we have to test elogind now with various setups, KatolaZ asked me to
> write a short guide what needs to be tested. So here we go:
[snipped procedure]

I gave it a quick spin on my ascii VM with lightdm and XFCE:

1. Simply installing elogind caused no regressions, as expected.

2. With consolekit/policykit and elogind fully enabled:

  - lightdm+XFCE graphical login: 

* login, logout, poweroff, reboot, USB drive mount: 
   working (same as without elogind, or disabled elogind)

  - ssh console login:

* screen sessions killed on logout 
  (regression, works with elogind disabled!)

* ssh-agent killed on logout 
  (regression, not killed with elogind disabled!)

*  urban@vboxascii:~$ loginctl reboot
   AUTHENTICATING FOR org.freedesktop.login1.reboot
   Authentication is required for rebooting the system.
   Authenticating as: ,,, (urban)
   Password: 
   AUTHENTICATION COMPLETE
   Failed to reboot system via elogind: Message recipient disconnected
 from message bus without replying
   urban@vboxascii:~$ 
   Broadcast message from root@vboxascii (console) (Tue Jan 16 23:25:17 
2018):
   The system is going down for reboot NOW!
   Connection to 192.168.2.167 closed by remote host.

*  root@vboxascii:~# loginctl reboot
   Failed to reboot system via elogind: Message recipient disconnected 
 from message bus without replying
   root@vboxascii:~# 
   Broadcast message from root@vboxascii (console) (Tue Jan 16 23:52:22 
2018):
   The system is going down for reboot NOW!
   Connection to 192.168.2.167 closed by remote host.

3. No consolekit/policykit, only elogind installed and activated
   (not sure if that even makes any sense, but what the heck):

  -lightdm+XFCE graphical login: 

* login, logout: working

* GUI poweroff, reboot, USB mount: NOT working!

  - ssh console login:

* screen sessions and ssh-agent killed on logout

*  urban@vboxascii:~$ loginctl reboot
   Failed to reboot system via elogind: The name org.freedesktop.PolicyKit1 
 was not provided by any .service files
   

TL;DR: 
The only immediately noticeable regression caused by enabling elogind 
in this setup was detached background processes (screen, ssh-agent) 
being killed upon session termination; user mount, poweroff, and reboot 
worked as expected.

HTH, best regards
Urban

-- 
Sapere aude!
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng