bogus argument - this so-called security risk is also there when the user is logged in - you cannot really make security contingent on a user being logged in, because logged in means zip - user can be logged in a system for weeks w/o doing anything..in reality LP redefines what it means to have a user account, and what it means to be logged in, arbitrarily limiting the user (and this *is* windows think), I mean next thing he figures out its a good idea for security to log user out at midnight, eventually figuring out he needs positive id checking user's ass is continuesly behind the terminal..)
No, it is a real security problem; lingering processes have been used countless time to regain access to systems from the outside. Pre-systemd there wasn't even a good and reliable way to kill a (logouted) user's processes across servers (pkill was never a standard and it is unreliable since both broken and malicious programs can escape it).
Hyperbolic assertions about what LP might do are lame arguments. Besides timed logouts have been the order of the day for decades; I have never worked on a sensitive system that allowed the user to stay connected for weeks on end; it just too dangerous to allow that. And don't forget that LP and the rest of the systemd developers really knows "user and session management" in Linux; they have practically invented and maintained all the core Linux software used for this like CK and logind.
Instead of abusing Unix signals like "nohup", lingering programs should just use PAM or similar to gain permission to run in their own scope; much better and much more granular security.
Lennart is too young to have read "The Cathedral and Bazaar" when it came out. He comes from an MS Windows background so never knew the Bazaar idea existed and has no patience with people who try to suggest it does.
Lennart Poettering have been working strictly on open source Linux software ever since he graduated. He has at least +15 years developer experience on Linux. I have no idea why you think he has a MS Windows background. Did you just made it up?
That's why things like persistent user processes in the background (about chapter three in most scripting books) is just not something he sees as being something that should exist.
He says that: 1: it should be an easy admin task to enable-disable users ability to run such tasks since they are a security risk (eg. a lingering ssh connection out through the firewall can be reversed so it can be used to connect back into the system). 2. As default, only programs that explicitly have permissions (from PAM etc) to linger after logout should be allowed to do so.
So he has no problems with lingering processes, he just thinks they should be secure and easy to admin. No sane modern OS would ever implement the current Linux scheme with unrestricted ability for users to run arbitrary programs after logout (and even after the account have been locked).
Telnet and ssh are different programs, you incomprehensibly stupid piece of shit. I know you're a troll, because only a troll could be so stupid.
Yeah, I actually know the difference between those two programs, and old enough to have used both telnet and see ssh replace it as the default way for connecting to other machines.
People unable to cope with technological changes like the transition from telnet (rsh/rlogin/etc) to ssh, SysVinit to systemd, or the future, Xorg to Wayland, just eject themselves out of tech.
No I don't. I just accept technically superior solutions as the way forward, even if they means another way of working.
I have no sentimental feelings for old, close source, Unix systems made by money grabbing, Linux-hating companies. So I have no problems discarding ancient Unix ways of doing things if I find new ways that are better.
Finally, I actually study the new tech I embrace by reading the technical documentation. That is apparently a lost art among many modern Linux users.
that will create a new scope and anything executed from that scope will remain in it
Something handed over to a thing like torque/openpbs or other scheduling systems will obviously not remain in the scope - as would many other things. Closed source workstation software frequently has many parts and it is impractical to write little wrapper scripts around each portion that is called in a non-trivial way.
It goes without saying, that if the close source vendors want to sell their stuff as supported on RHEL and E-Suse, and this is something they certainly will, they will make sure their stuff works with systemd.
Not familiar with "torque", but this doesn't seem like anything a single user will start from a terminal. It seems more like a fundamental system service, and therefore won't have any problems with "KillUserProcesses=yes". Nor would any jobs it handed over to other machines be affected, unless it happens to "physically" login with username and password and run the instance under that user account. Highly unlikely IMHO.
The pathetic little troll appears to have no idea that running applications remotely via X instead of MS Windows RDP is a thing.
X's network transparency have basically been broken for many years for anything complex. For simple uses of old legacy software it may still work for some. But really, I and many others are cheering for the day we can clean our systems for that insecure monster called X and start to use Wayland. Yeah, that will break peoples workflow too. But that is how progress works.
Peter H.S. - why are you wasting all the time of all these people with your nonsense and deliberate antagonism?
If you don't want me to answer your often rather unsavory personal attacks, then just stop talking to me. I don't remember starting to address you in the first place.
Hey, dickhead: many of us run many many machines, and not all of them have systemd.
Then use different procedures for different machines. Not a problem in the real world where people often work with several incompatible OS's. Anyway, that problem will solve itself as the non-systemd Linux machines slowly are phased out.
Even with the new settings, no user process will be killed on exit/logout if the user have told the systemd not to.
FTFY, jackass. systemd ain't my momma and never will be.
Maybe you need a real mother that can love you unconditionally for what you are. You certainly seem like a bitter bileful person in desperate need for love.
Or even better. Start screen automatically at boot by running it as a.service
You see guys - they just don't get multi-user and cannot even dream that a second user may want to use something like screen as well.
That stupid single user MSDOS mentality was obsolete before MSDOS even started and should be kept out of modern systems.
Please be aware that we are talking about user.services, not system.services. A users services are totally independent from other users services, and the system services. Each user can control their own services with standard systemd tools like "systemctl start screen.service" and you can employ the whole suite of systemd features like socket activation, AmbientCapabilities, Cgroup resource management, etc. on such services.
I think the systemd developer group is the single most knowledgeably Linux developer group when it comes to multi-user Linux. The very existence of "systemd-logind" is a proof on how much better multi-user Linux work on systemd compared to any non-systemd distro. I mean, running Xorg rootless is only safe on systemd distros.
So please name me just one example of breakage or non-contrived stuff that are no longer possible to do with the new systemd settings?
Closed source workstation software. The user can't modify the process launch and put "systemd-run" in front of things and when they close the GUI launcher they still expect their stuff to run for hours or days instead of being killed off by a pointless major policy change.
Just lock the session instead of logging out. That would be the typical thing to do with a workstation since it runs a DE of some sort.
I must say I have a hard time imagine CLI software being launched from a GUI and then detach from the terminal. But I don't think there is any problem with using "systemd-run" on the GUI; that will create a new scope and anything executed from that scope will remain in it. So even if the GUI is closed, the scope will remain with all the processes launched from it. At worst they can just add the user to the "KillExcludeUsers=" in logind.conf to have the old behavior.
So systemd is changing the behavior of every other program? I still have telnet, and still use it. But not for the same things I used to. But it still works the same way. Installing openssh did NOT change the behavior of telnet. ssh did not kick telnet off my system. I can kick it off if I want to - I sure as hell don't want the ssh (or the openssh installer or whatever) kick off telnet for me.
Oh yes, telnet was kicked off the default installation list along a lot of other inherently insecure Unix stuff like rsh and rlogin etc. Instead you got ssh. People whined about that too; suddenly they had to manually install a telnet client (lets just suppress the memories that some Linux distros came with a telnet-server as default).
ssh dramatically changed the whole workflow on both Linux and Unix, and a lot of people didn't like that. Same with packages and package management (how I don't miss hand patching and compiling). These days it is systemd that changes how Linux work, and I must say I much prefer how it does things as opposed to the old days of SysVinit.
The bottom line is that tech changes all the time, or else it becomes obsolete. That is just the price of progress. Cling to the old ways, and you and your skills become obsolete in the same way.
Yes it does, because using systemd-run enables you to use resource management on the user run service. See https://www.freedesktop.org/so... for some options.
Also, it really is best practice to totally clean the user session at logout, only allowing explicitly permitted processes to continue to run.
It does create (which seems to be the whole idea of systemd) incompatibilities with other systems. Suddenly, I now have to care if my script is running on Systemd/Linux or if it is running on any other Unix system (and yes, I have scripts that currently work perfectly without modification on IRIX, Solaris, and Linux).
Cross platform scripts have always been problematic. Sometimes they work, sometimes they get broken when things change. Solaris changed a lot with SMF etc, and Linux with systemd. That is just progress.
Most of the old close source Unix's have chosen not to evolve and are now firmly niche OS's working in a very narrow confinement (and loosing ground there too every year). Linux runs everywhere, from tiny embedded to clusters and supercomputers, and therefore have other needs than classic Unix. It is just logical that Linux evolve with new features while many Unix's are standing still, and that therefore it will become harder and harder to run platform-independent scripts on them. While it may be inconvenient to some, it is what is saving Linux from ending up in the same, small dying niche as the close source Unix's.
In 10 years there will be even less Irix, AIX, Solaris etc., but Linux has a fighting chance still to be relevant in the future, exactly because it changes.
You're an idiot. The name of the command is part of its functionality. If systemd were to insert itself in front of the bash interpreter and swap around 'rm -rf' and 'ls -lh', while preserving the 'functionlity' of one under the name of the other, who would need to be jerking you off under the table for you to claim that nothing has changed, and 'it's not a big deal, IMHO'?
Do you really think your made up, incoherent hyperbolic stories counts as technical arguments?
It is scary to think that you probably are old enough to shave yet behave like a retarded 10 year old. You mother must really have hated you since you ended up in such a sad state. I am sorry for you, I really am.
*For a concrete example, all of your scripts that automatically ssh into a server, start a process with screen, and log out, now break. To name just one thing that I have done on numerous occasions.
Just edit your scripts. You had to edit them too when ssh replaced rsh back in day. Or just set "KillUserProcesses" to "no" and live with the same old problems. Hardly a big deal.
In Unix and its derivatives, frequently used commands are terse If there's something new for me to learn, it ought to be a half-dozen keystrokes.
No, I am not going to learn to use a new command that has over 40 extra keys to type
I think it is rather a question of who first "stole" the nice short commands, leading to permanent hogging of the namespace. Who is really using ar these days.
Anyway, those "terse" commands and their "terse" switches are really hard to remember, especially when they only have the vaguest mnemonic resembles to what they perform. And "-t" can mean anything depending on what program it is used with.
The solution was to use proper mnemonic commands and have tab completion of everything, including switches, and always have "long option" switches so a simple "--*tab*" would reveal the options. This combined with using the command stack is highly efficient, not only when it comes to typing, but also when it comes to remember what stuff do. Programs like git and systemd is designed around this concept. I like it.
to support a misfeature that has no benefits to me.
I think we can safely assume here that do don't really have any experience with systemd-run, nor have actually read its man-page. So you must have psychic powers in order to know that it offers no benefits to you.
Seriously? "Jump through extra hoops and it'll work like it always did?" If you have to jump through such stupid extra hoops then it fucking doesn't work like it always did!
The way you run the programs may have changed, but not the functionality. Screen works just like expected when started by systemd-run once it is running. So no functionality is lost.
Being able to run stuff in the background has been around for decades
This isn't about running stuff in the background (though systemd-run can do that too), but about keeping processes alive after logout.
With systemd-run the programs get their own scope that you can manipulate with standard systemd tools and use many of the standard systemd resource management features like limiting IO etc. In short, you can trivially constrain your long running processes so they don't DoS the system, even if some process went rogue. Another major benefit is the ability to safely purge the user session in a clean way, so that only explicitly allowed processes survive the logout.
Anyway, it is trivially easy for those who want it to revert to the old (rather hackish) way of doing things. man logind.conf will show you how.
SSH came with a provable security benefit and didn't silently fail,
Yes, that is exactly what we told the whining users back in the day when they fiercely resisted to stop using telnet, rlogin and similar old Unix crap.
But some people just have severe trouble adapting to new tech and new work flows and start to cling to old outdated procedures and programs.
this change is merely an opinion of best practice and forces a poorly documented change on an unsuspecting public
But the new defaults really _is_ best practice. Denying that is like denying that ssh is better than telnet.
No it does not work as before. Before you just typed "screen", and it worked on any system.
Life is too short to spend time committing all that extra crap to memory or else having to configure every system you touch with custom shortcuts.
If you think that having to remember to type "systemd-run --user --scope-screen" in front of a frequently used utility (and having the system silently clobber your work if you forget) is reasonable, you're deluded.
Just recall the command line from the stack. No need to type when eg. "Ctrl-r" works so well.
Really such changes occur all the time in tech; we no longer use telnet, rlogin, uucp and similar old and insecure stuff anymore either. It must be hard to work in tech when unable to learn new commands and new ways of doing things.
Yes. The issue isn't that it can't be done. The issue is that longstanding default behavior has changed. Since it appears that there's no good, solid reason for the change, people are objecting to it. Change for change's sake is bad.
Why do you think there no solid reasons for this new default. It is something somebody told you, or are you just presenting what you imagine as facts?
What about when I have a long running process I need to run and I don't want it to be stopped if I get disconnected from wifi? Or maybe I know it'll still be running when I have to go home?
The way it is now, if I just disconnect from ssh, they get killed. If i go out of my way to ensure they won't (e.g. start them in a screen session) then they aren't. How is the old way a problem?
That isn't a problem of course, even with the new systemd defaults. Just use systemd-run --user --scope screen and the process and all other processes started from screen will survive logout.
Correct. Rewrite everything in the past to accomodate our New Leader. All scripts, all startup commands. Shake it all up because the new Briteboys said so.
Oh, Hyperbolic twaddle instead of technical arguments. Hardly surprising.
But please. WHY. THE. FUCK. break decades of well-established Unix conventions? Why the actual fuck? I hate the arrogance of the systemd folks who think they are doing everything better. Even Darwin respects Unix conventions more than systemd. And yes, they scrapped sysvinit too. And yes, I still prefer sysvinit.
Well established Unix conventions, like using unencrypted connections (Telnet, UUCP, rlogin etc) that sends password in clear text? Unix was chock full of insecure way of doing things and an unfortunately a lot of this have carried over to Linux with the end result that multi-user Linux security seems to rely on users being nice guys as a basic security measure.
With this change, people can at least ensure that their user run service doesn't DoS the server unintentionally.
Slashdot Mirror
bogus argument - this so-called security risk is also there when the user is logged in - you cannot really make security contingent on a user being logged in, because logged in means zip - user can be logged in a system for weeks w/o doing anything ..in reality LP redefines what it means to have a user account, and what it means to be logged in, arbitrarily limiting the user (and this *is* windows think), I mean next thing he figures out its a good idea for security to log user out at midnight, eventually figuring out he needs positive id checking user's ass is continuesly behind the terminal..)
No, it is a real security problem; lingering processes have been used countless time to regain access to systems from the outside. Pre-systemd there wasn't even a good and reliable way to kill a (logouted) user's processes across servers (pkill was never a standard and it is unreliable since both broken and malicious programs can escape it).
Hyperbolic assertions about what LP might do are lame arguments. Besides timed logouts have been the order of the day for decades; I have never worked on a sensitive system that allowed the user to stay connected for weeks on end; it just too dangerous to allow that.
And don't forget that LP and the rest of the systemd developers really knows "user and session management" in Linux; they have practically invented and maintained all the core Linux software used for this like CK and logind.
Instead of abusing Unix signals like "nohup", lingering programs should just use PAM or similar to gain permission to run in their own scope; much better and much more granular security.
Lennart is too young to have read "The Cathedral and Bazaar" when it came out. He comes from an MS Windows background so never knew the Bazaar idea existed and has no patience with people who try to suggest it does.
Lennart Poettering have been working strictly on open source Linux software ever since he graduated. He has at least +15 years developer experience on Linux. I have no idea why you think he has a MS Windows background. Did you just made it up?
That's why things like persistent user processes in the background (about chapter three in most scripting books) is just not something he sees as being something that should exist.
He says that:
1: it should be an easy admin task to enable-disable users ability to run such tasks since they are a security risk (eg. a lingering ssh connection out through the firewall can be reversed so it can be used to connect back into the system).
2. As default, only programs that explicitly have permissions (from PAM etc) to linger after logout should be allowed to do so.
So he has no problems with lingering processes, he just thinks they should be secure and easy to admin. No sane modern OS would ever implement the current Linux scheme with unrestricted ability for users to run arbitrary programs after logout (and even after the account have been locked).
Telnet and ssh are different programs, you incomprehensibly stupid piece of shit. I know you're a troll, because only a troll could be so stupid.
Yeah, I actually know the difference between those two programs, and old enough to have used both telnet and see ssh replace it as the default way for connecting to other machines.
People unable to cope with technological changes like the transition from telnet (rsh/rlogin/etc) to ssh, SysVinit to systemd, or the future, Xorg to Wayland, just eject themselves out of tech.
Well, you assume every change is for the better.
No I don't. I just accept technically superior solutions as the way forward, even if they means another way of working.
I have no sentimental feelings for old, close source, Unix systems made by money grabbing, Linux-hating companies. So I have no problems discarding ancient Unix ways of doing things if I find new ways that are better.
Finally, I actually study the new tech I embrace by reading the technical documentation. That is apparently a lost art among many modern Linux users.
Something handed over to a thing like torque/openpbs or other scheduling systems will obviously not remain in the scope - as would many other things.
Closed source workstation software frequently has many parts and it is impractical to write little wrapper scripts around each portion that is called in a non-trivial way.
It goes without saying, that if the close source vendors want to sell their stuff as supported on RHEL and E-Suse, and this is something they certainly will, they will make sure their stuff works with systemd.
Not familiar with "torque", but this doesn't seem like anything a single user will start from a terminal. It seems more like a fundamental system service, and therefore won't have any problems with "KillUserProcesses=yes".
Nor would any jobs it handed over to other machines be affected, unless it happens to "physically" login with username and password and run the instance under that user account. Highly unlikely IMHO.
The pathetic little troll appears to have no idea that running applications remotely via X instead of MS Windows RDP is a thing.
X's network transparency have basically been broken for many years for anything complex. For simple uses of old legacy software it may still work for some. But really, I and many others are cheering for the day we can clean our systems for that insecure monster called X and start to use Wayland. Yeah, that will break peoples workflow too. But that is how progress works.
Peter H.S. - why are you wasting all the time of all these people with your nonsense and deliberate antagonism?
If you don't want me to answer your often rather unsavory personal attacks, then just stop talking to me. I don't remember starting to address you in the first place.
Hey, dickhead: many of us run many many machines, and not all of them have systemd.
Then use different procedures for different machines. Not a problem in the real world where people often work with several incompatible OS's. Anyway, that problem will solve itself as the non-systemd Linux machines slowly are phased out.
Even with the new settings, no user process will be killed on exit/logout if the user have told the systemd not to.
FTFY, jackass. systemd ain't my momma and never will be.
Maybe you need a real mother that can love you unconditionally for what you are. You certainly seem like a bitter bileful person in desperate need for love.
> Anyway, those "terse" commands and their "terse" switches are really hard to remember
No, only for clueless morons like yourself.
A rather typical response from you. Please learn to argue if you want to be taken seriously.
You see guys - they just don't get multi-user and cannot even dream that a second user may want to use something like screen as well.
That stupid single user MSDOS mentality was obsolete before MSDOS even started and should be kept out of modern systems.
Please be aware that we are talking about user .services, not system .services.
A users services are totally independent from other users services, and the system services.
Each user can control their own services with standard systemd tools like "systemctl start screen.service" and you can employ the whole suite of systemd features like socket activation, AmbientCapabilities, Cgroup resource management, etc. on such services.
I think the systemd developer group is the single most knowledgeably Linux developer group when it comes to multi-user Linux. The very existence of "systemd-logind" is a proof on how much better multi-user Linux work on systemd compared to any non-systemd distro. I mean, running Xorg rootless is only safe on systemd distros.
Closed source workstation software. The user can't modify the process launch and put "systemd-run" in front of things and when they close the GUI launcher they still expect their stuff to run for hours or days instead of being killed off by a pointless major policy change.
Just lock the session instead of logging out. That would be the typical thing to do with a workstation since it runs a DE of some sort.
I must say I have a hard time imagine CLI software being launched from a GUI and then detach from the terminal. But I don't think there is any problem with using "systemd-run" on the GUI; that will create a new scope and anything executed from that scope will remain in it. So even if the GUI is closed, the scope will remain with all the processes launched from it.
At worst they can just add the user to the "KillExcludeUsers=" in logind.conf to have the old behavior.
So systemd is changing the behavior of every other program? I still have telnet, and still use it. But not for the same things I used to. But it still works the same way. Installing openssh did NOT change the behavior of telnet. ssh did not kick telnet off my system. I can kick it off if I want to - I sure as hell don't want the ssh (or the openssh installer or whatever) kick off telnet for me.
Oh yes, telnet was kicked off the default installation list along a lot of other inherently insecure Unix stuff like rsh and rlogin etc. Instead you got ssh. People whined about that too; suddenly they had to manually install a telnet client (lets just suppress the memories that some Linux distros came with a telnet-server as default).
ssh dramatically changed the whole workflow on both Linux and Unix, and a lot of people didn't like that. Same with packages and package management (how I don't miss hand patching and compiling). These days it is systemd that changes how Linux work, and I must say I much prefer how it does things as opposed to the old days of SysVinit.
The bottom line is that tech changes all the time, or else it becomes obsolete. That is just the price of progress. Cling to the old ways, and you and your skills become obsolete in the same way.
But the new defaults really _is_ best practice. Denying that is like denying that ssh is better than telnet.
Asserting that over and over doesn't make it true. Your argument seems to be that "With this change, people can at least ensure that their user run service doesn't DoS the server unintentionally." Which this change doesn't even do.
Yes it does, because using systemd-run enables you to use resource management on the user run service. See https://www.freedesktop.org/so... for some options.
Also, it really is best practice to totally clean the user session at logout, only allowing explicitly permitted processes to continue to run.
It does create (which seems to be the whole idea of systemd) incompatibilities with other systems. Suddenly, I now have to care if my script is running on Systemd/Linux or if it is running on any other Unix system (and yes, I have scripts that currently work perfectly without modification on IRIX, Solaris, and Linux).
Cross platform scripts have always been problematic. Sometimes they work, sometimes they get broken when things change. Solaris changed a lot with SMF etc, and Linux with systemd. That is just progress.
Most of the old close source Unix's have chosen not to evolve and are now firmly niche OS's working in a very narrow confinement (and loosing ground there too every year).
Linux runs everywhere, from tiny embedded to clusters and supercomputers, and therefore have other needs than classic Unix. It is just logical that Linux evolve with new features while many Unix's are standing still, and that therefore it will become harder and harder to run platform-independent scripts on them. While it may be inconvenient to some, it is what is saving Linux from ending up in the same, small dying niche as the close source Unix's.
In 10 years there will be even less Irix, AIX, Solaris etc., but Linux has a fighting chance still to be relevant in the future, exactly because it changes.
Just edit your scripts.
Are you serious? How about you edit my scripts? You broke it, you fix it.
Yes I am seriously suggesting to edit scripts so they work with new tech.
But I don't care whether you edit your scripts or not. If you prefer prefer broken scripts to editing them, that is your problem, not mine.
You're an idiot. The name of the command is part of its functionality. If systemd were to insert itself in front of the bash interpreter and swap around 'rm -rf' and 'ls -lh', while preserving the 'functionlity' of one under the name of the other, who would need to be jerking you off under the table for you to claim that nothing has changed, and 'it's not a big deal, IMHO'?
Do you really think your made up, incoherent hyperbolic stories counts as technical arguments?
It is scary to think that you probably are old enough to shave yet behave like a retarded 10 year old. You mother must really have hated you since you ended up in such a sad state. I am sorry for you, I really am.
*For a concrete example, all of your scripts that automatically ssh into a server, start a process with screen, and log out, now break. To name just one thing that I have done on numerous occasions.
Just edit your scripts. You had to edit them too when ssh replaced rsh back in day. Or just set "KillUserProcesses" to "no" and live with the same old problems. Hardly a big deal.
In Unix and its derivatives, frequently used commands are terse If there's something new for me to learn, it ought to be a half-dozen keystrokes.
No, I am not going to learn to use a new command that has over 40 extra keys to type
I think it is rather a question of who first "stole" the nice short commands, leading to permanent hogging of the namespace. Who is really using ar these days.
Anyway, those "terse" commands and their "terse" switches are really hard to remember, especially when they only have the vaguest mnemonic resembles to what they perform. And "-t" can mean anything depending on what program it is used with.
The solution was to use proper mnemonic commands and have tab completion of everything, including switches, and always have "long option" switches so a simple "--*tab*" would reveal the options. This combined with using the command stack is highly efficient, not only when it comes to typing, but also when it comes to remember what stuff do.
Programs like git and systemd is designed around this concept. I like it.
to support a misfeature that has no benefits to me.
I think we can safely assume here that do don't really have any experience with systemd-run, nor have actually read its man-page. So you must have psychic powers in order to know that it offers no benefits to you.
Seriously? "Jump through extra hoops and it'll work like it always did?" If you have to jump through such stupid extra hoops then it fucking doesn't work like it always did!
The way you run the programs may have changed, but not the functionality. Screen works just like expected when started by systemd-run once it is running. So no functionality is lost.
Being able to run stuff in the background has been around for decades
This isn't about running stuff in the background (though systemd-run can do that too), but about keeping processes alive after logout.
With systemd-run the programs get their own scope that you can manipulate with standard systemd tools and use many of the standard systemd resource management features like limiting IO etc. In short, you can trivially constrain your long running processes so they don't DoS the system, even if some process went rogue.
Another major benefit is the ability to safely purge the user session in a clean way, so that only explicitly allowed processes survive the logout.
Anyway, it is trivially easy for those who want it to revert to the old (rather hackish) way of doing things. man logind.conf will show you how.
SSH came with a provable security benefit and didn't silently fail,
Yes, that is exactly what we told the whining users back in the day when they fiercely resisted to stop using telnet, rlogin and similar old Unix crap.
But some people just have severe trouble adapting to new tech and new work flows and start to cling to old outdated procedures and programs.
this change is merely an opinion of best practice and forces a poorly documented change on an unsuspecting public
But the new defaults really _is_ best practice. Denying that is like denying that ssh is better than telnet.
No it does not work as before. Before you just typed "screen", and it worked on any system.
Life is too short to spend time committing all that extra crap to memory or else having to configure every system you touch with custom shortcuts.
If you think that having to remember to type "systemd-run --user --scope-screen" in front of a frequently used utility (and having the system silently clobber your work if you forget) is reasonable, you're deluded.
Just recall the command line from the stack. No need to type when eg. "Ctrl-r" works so well.
Really such changes occur all the time in tech; we no longer use telnet, rlogin, uucp and similar old and insecure stuff anymore either. It must be hard to work in tech when unable to learn new commands and new ways of doing things.
Yes. The issue isn't that it can't be done. The issue is that longstanding default behavior has changed. Since it appears that there's no good, solid reason for the change, people are objecting to it. Change for change's sake is bad.
Why do you think there no solid reasons for this new default. It is something somebody told you, or are you just presenting what you imagine as facts?
What about when I have a long running process I need to run and I don't want it to be stopped if I get disconnected from wifi? Or maybe I know it'll still be running when I have to go home?
The way it is now, if I just disconnect from ssh, they get killed. If i go out of my way to ensure they won't (e.g. start them in a screen session) then they aren't. How is the old way a problem?
That isn't a problem of course, even with the new systemd defaults. Just use systemd-run --user --scope screen and the process and all other processes started from screen will survive logout.
Correct. Rewrite everything in the past to accomodate our New Leader. All scripts, all startup commands. Shake it all up because the new Briteboys said so.
Oh, Hyperbolic twaddle instead of technical arguments. Hardly surprising.
But please.
WHY. THE. FUCK. break decades of well-established Unix conventions? Why the actual fuck?
I hate the arrogance of the systemd folks who think they are doing everything better. Even Darwin respects Unix conventions more than systemd. And yes, they scrapped sysvinit too. And yes, I still prefer sysvinit.
Well established Unix conventions, like using unencrypted connections (Telnet, UUCP, rlogin etc) that sends password in clear text? Unix was chock full of insecure way of doing things and an unfortunately a lot of this have carried over to Linux with the end result that multi-user Linux security seems to rely on users being nice guys as a basic security measure.
With this change, people can at least ensure that their user run service doesn't DoS the server unintentionally.