Skip to main content ↑ ↓
Topic: Semi random thinking out loud (Read 8120 times) previous topic - next topic
0 Members and 4 Guests are viewing this topic.

Semi random thinking out loud

Ok I've had Artix installed a few days now and during that time I also decided it was about time I removed years and years of cruft from my install. I did consider doing a clean install but in the end migrated.

While de-crufting I went through the tree and renamed any folder 'systemd' to systemd.bak. Nothing seemed to break so I deleted them. But I noticed there was one under /run. Which seemed odd at first as its on tmpfs so was being recreated at boot. I came to the conclusion that elogind was creating this.

In these few days of using Artix I've also done a lot more reading about systemd and it's encroachment into the Linux ecosystem and I'm slightly embarrassed that although I knew it was a 'thing' I had no idea how bad it was/is
Which also make me wonder about the aims, methods & approach of a project such as this. I have looked though the forum and tried to digest as much as possible but I am still a bit confused. Shouldn't elogind be one of the first things to try and replace ? eudev I get. That came before and was assimilated into systemd.

And with my tinfoil hat on I wonder why it seems so many packages abandoned support for what came before systemd when over the years I've noticed packages continuing to support all sorts of legacy alternatives to what is in vogue. Like all the media players that still support OSS sound. Does anyone use that anymore ?

I've been using linux for quite a long time. I just went on LFS partly to see what came before Consolekit. Happily back in the day I registered with their user counter so I could see that I first built a LFS system in around 2002. From a quick scan it appears that nothing really compared to Consolekit back then ? I could be wrong.
And it seems that a lot of the reason for the dependence on elogind is this concepts of ''seats' and 'sessions' ? I can't quite fathom why it's not possible to have a ./configure option of --disable-multiseat on programs which depend on (e)logind. What % of linux users have multiple keyboards and mice etc. attached to their boxes ? There must be more to it but I don't know what it is ?

What would happen if elogind was omitted and not replaced with something with similar functionality. Just something simple that said "One seat's all you are having, username and password please. Thanks you're logged in". How many current programs would break ? Mainly DM's and WM's I guess but I truly don't know.

And from what I can gather one of the aims of this project is to build all packages in core, extra, community, multilib on a systemd-free install and on a post I read you'd done about a 1000 out of 9000 (not sure how old the post was ?)
Surely there must be some way of automating a large part of this ? Greping code and linked libs to separate packages that can be rebuilt fully automated from those which will require a closer look and changes or patches ?

Anyway I could go on (and probably will at some point) but it's bed time soon.

None of this is meant to be critical of what you've already achieved, far from it. I'm just trying to get my head around it all.

And I'd like to help if I can. I can't program (I can hack a patch together a little) but I do have experience messing around with PKGBUILD's. I used to maintain a load of them for my ODROID XU and then XU3 as I was not satisfied that Arch Linux ARM disabled NEON extensions across the board so redid all the packages that could make use of NEON. A few people on the odroid forum used to use them (eg https://github.com/gripped/odroid-xu3-pkgbuilds).  Abandoned as I no longer use the boards.( I wish I'd known back then I could have just put my repo at the top of pacman.conf, would have saved all the renaming and conflicts=  )
So if I can help in this way let me know but I'm not often very time rich unfortunately.

TLDR
I don't blame you :)

Re: Semi random thinking out loud

Reply #1 –
Quote from: gripped – on

And from what I can gather one of the aims of this project is to build all packages in core, extra, community, multilib on a systemd-free install and on a post I read you'd done about a 1000 out of 9000 (not sure how old the post was ?)
Surely there must be some way of automating a large part of this ? Greping code and linked libs to separate packages that can be rebuilt fully automated from those which will require a closer look and changes or patches ?


We are at about 1800 PKGBUILDs now, which amounts to roughly 2000+ binary packages.
We already build packages fully automated with jenkins.
What caps the amount of packages is hardware resources and manpower to maintain them, some packages such as browsers won't build on our server due to lack of more server resources.
We also do not aim to fully reproduce the entire arch package set, because not all arch packages have a systemd depends and thus work with artix as well. Typical case is for example desktops, kde, its free of systemd and just works.

Regarding elogind, why would you want to drop it? Its a drop in replacement for systemd's logind. Consolekit2 is dead and lacks features compared to elogind.

Re: Semi random thinking out loud

Reply #2 –
Thanks for the reply. As I said, but will say again, I'm just trying to get my head around it all.
The last thing I want to do is appear critical. As a starting point lets say that I fully accept that I am probably wrong every-time.

I just came across
https://gitea.artixlinux.org/artix/documentation/src/branch/master/Notes%20for%20packagers.markdown
which has helped me to understand some of the methods you are using.

I'm still unclear how you decide which packages to target for inclusion in your repos ? I've seen another post that mentioned it's difficult as systemd is often not included in a PKGBUILD's 'requires= ' as it's expected to be present on every Arch install anyway.
So I'm interested in how you are identifying which packages do need repackaging and including in your repo and which do not ?

I believe I came across a post where a dev did state that the intention was to repackage everything in Arch repo's but may be mistaken.

As to (e)logind it is systemd created. A small part of it but a part of it nonetheless. I not saying "This must be removed" but curious as to why you are not concerned it remains ? Surely in the long run it would be better if there were alternatives to it so that other projects would not just expect, and rely on it , being there ?

Got to go to work now for a bit.

Any more "semi random thinkings out loud" I have I'll add to the thread and please ignore or reply as you see fit

Re: Semi random thinking out loud

Reply #3 –
Unless you're one of the suckless-types (hey, dmenu is pretty nice at least!), there's not really a reason to drop elogind. It's actually pretty easy to patch projects to build with elogind instead of systemd/logind. You really don't have to have it installed (same with something like dbus), but it just makes things easier if you do use it. Artix doesn't have the manpower to offer alternate builds of certain software with consolekit or something.

Re: Semi random thinking out loud

Reply #4 –
Quote from: gripped – on

As to (e)logind it is systemd created. A small part of it but a part of it nonetheless. I not saying "This must be removed" but curious as to why you are not concerned it remains ? Surely in the long run it would be better if there were alternatives to it so that other projects would not just expect, and rely on it , being there ?



If, and thats the if and answer. There are no alternatives, as said, ck2 is dead and lacks behind, producing tons of headaches with packages that require a session tracker.

Re: Semi random thinking out loud

Reply #5 –
Quote from: Dudemanguy – on
Unless you're one of the suckless-types (hey, dmenu is pretty nice at least!), there's not really a reason to drop elogind. It's actually pretty easy to patch projects to build with elogind instead of systemd/logind. You really don't have to have it installed (same with something like dbus), but it just makes things easier if you do use it. Artix doesn't have the manpower to offer alternate builds of certain software with consolekit or something.


it is an uneeded security nightmare and it should be eliminated.  longind was stupid and elongind is an extension of the stupidity

Everything runs through PAM anyway

Re: Semi random thinking out loud

Reply #6 –
Quote from: mrbrklyn – on

it is an uneeded security nightmare and it should be eliminated.  longind was stupid and elongind is an extension of the stupidity

Everything runs through PAM anyway

How does logind/elogind make security worse?

Re: Semi random thinking out loud

Reply #7 –
Quote from: Dudemanguy – on
Artix doesn't have the manpower to offer alternate builds of certain software with consolekit or something.

Right, its also technically not really desirable, because you would need specifically patched ck desktop packages, whereas these just work out of box with elogind.
Consolekit2 in the repos would drastically complicate everything, and frankly, that's not worth the headache, given ck is the precursor of logind, and we have elogind, which has by now also upstream support for often used packages, eg polkit, NM, dbus.
elogind is the better choice in the structure we have and use.

Re: Semi random thinking out loud

Reply #8 –
Just as a followup

I'm yet again embarrassed by how little I know about how some of these things actually work , what they provide, what they do.

Quote from: mrbrklyn – on
Everything runs through PAM anyway

Reading that made me wonder what happens if I just remove elogind. Answer in my case is not a lot.
tty logins work. Lightdm complains
Code: [Select]
WARNING: Failed to get list of logind seats: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.login1 was not provided by any .service files
But then creates a seat and works. Other DM's may not be so accommodating ?
KDE/Plasma still works
Creating a 2nd Xserver with unified monitors for games still works.

So in my case I don't appear to need elogind.
I created and installed an empty package that does nothing other than provides('elogind') to stop it reappearing on upgrades.

This is just for me. I'm not saying no-one needs elogind. Or the distro doesn't need it.
But so far it appears that I don't need it, so I see no reason to keep it. There's probably no real reason to remove it either. But I'm just playing around :)

Re: Semi random thinking out loud

Reply #9 –
Quote from: gripped – on
So in my case I don't appear to need elogind.


Have you checked if polkit works, eg priv granting via polkit?

To fix the lightdm to work properly, you need to adjust your /etc/pam.d/lightdm* and replace pam_systemd.so with pam_elogind.so in your lightdm pam files. Lightdm comes from arch repos, and its pam is configured for systemd.
Btw, you will definetely need elogind when the switch to wayland default comes.

Re: Semi random thinking out loud

Reply #10 –
In the rare case of a single user system how do you start a desktop or the xserver without a DM?
From the little that I have tried it was only possible through ck2, but I have no idea how valid and global this is.  I use openbox.
On the other  hand ck2 without a DM took slightly more ram to start than elogind and sddm.
Thanks to the good people at freedesktop they have nothing to do with ck2 development now :)
It seems that the last commit for ck2 was Dec 2017.  :(

Re: Semi random thinking out loud

Reply #11 –
This elogind package tracker might be of interest.
Note, this is cross distro.

If you remove elogind, and you use a desktop and display manager, don't blame artix if any of the listed packages do not work properly or cause  packages that depend on the listed ones stop working properly.

Re: Semi random thinking out loud

Reply #12 –
Quote from: Dudemanguy – on
How does logind/elogind make security worse?

Are you familiar with security?  Do you know what a vector surface is and what happens when you can a user space programing to your log in authentiation chain?  By definition you have decreased your security.

How does login and polkit suck... let me count the ways!

  • It increases the attack vector
  • It exposed the attack vector to user space
  • It allows for moron package managers to ship systems that allow for sudo to work with any random password (this was in manjaro openrc btw)
  • It allows for systems to be shutdown without root permissions
  • It bypasses Unix architectural security models
  • It carves a HUGE hole is security by  non-privileged processes to communicate with privileged ones which is what one does when they want to create a worm.
  • It execute commands with elevated privileges including unmoutning and mounting attached and remote file systems
  • It can alter your networking without root permisions

Re: Semi random thinking out loud

Reply #13 –
Quote from: mrbrklyn – on

How does login and polkit suck... let me count the ways!


I find logind for the aims it wantsto achieve ok, problem is, its tied to systemd in its source. Xorg is mature, but has shortcomings, wayland is the thing they want to replace it with, and this needs a session tracker etc, for which logind is sufficient and eventually made for.
I dislike polkit, and since you mentioned it, you can prevent normal users to shutdown with logind by setting polkit rules.

Re: Semi random thinking out loud

Reply #14 –
Quote from: artoo – on
This elogind package tracker might be of interest.
Note, this is cross distro.

If you remove elogind, and you use a desktop and display manager, don't blame artix if any of the listed packages do not work properly or cause  packages that depend on the listed ones stop working properly.


If we used the BSD or  Gentoo packages for X and etc, all these can be replaced.  Everytone of these packages are heartburn.
Network Manager is the firs thing that should go.
pambase can just be borrowed since PAM hasn't fundementally changed in a decade.
gvfs and dbus spins out of control when it can't find its happy mimetype app... it is screwed.
pulseaudio is a huge pia and a security hole big enough for a M1 Tank
and nothing inherent in X needs polkit.  That is the hardest one and you would likely need to use a supported BSD x configutation
especially with that garbage wayland coming...

Quote
  procps (upstream)
dbus
networkmanager (upstream)
gvfs (upstream)
accountsservice (upstream)
pambase
udisks2 (upstream)
sddm (upstream)
packagekit
pulseaudio (--enable-systemd-login=yes, needs decoupling from global HAVE_SYSTEMD)
modemmanager (--with-systemd-suspend-resume)
xorg-server (likely not required due to --keep-tty, systemd_logind=true)
polkit (partial, still broke upstream)