4 ms·

> which people are trying to expose to the internet directly [citation needed].

qwertyuiop924 10y ago
Bows Gladly, good sir. https://cfp.systemd.io/en/systemdconf_2016/public/events/21 https://cfp.systemd.io/en/systemdconf_2016/public/events/21 Sit back, and witness the insanity.
- justinsaccount 10y ago
  That's funny, because that's the same link referenced in the blog post, where david says: > That presentation is from the Cockpit project, which isn’t part of systemd and doesn’t even share its main developers. It’s as much “remote access to systemd” as using SSH and then invoking systemctl. and then further states in the 2nd blog post: > I certainly don’t buy his original argument (which he hasn’t repeated in his second post) that tools like Cockpit should change the view of systemd. Just like SSH or Remote Desktop in Windows, Cockpit is the tool providing the remote, privileged access; systemd is just on the server listening locally. Blaming systemd for a Cockpit-based compromise is like blaming the “dnf” utility for removing the web server packages after someone gets root over SSH. (Cockpit is neither developed by the systemd team nor installed by default in any distributions.) So.. > Sit back, and witness the insanity. Who is acting insane here? A systemd developer, or people spreading FUD?
  - qwertyuiop924 10y ago
    First off, this doesn't defeat my point: people are trying to connect systemd to the browser. Secondly, no, I wasn't aware it was a separate project, because it didn't initially appear to be. Ordinarily, I'd assume it was, but frankly, at this point, I can totally see Lennart doing this. So yes, systemd isn't at fault, and I did miss it, and, to some degree, spread FUD, for which I am sorry. However, it's still a very silly idea.
    - agwa 10y ago
      No need for you to apologize - you never said systemd was at fault. (Neither did I - the point is that systemd has to be careful with its inputs, since they won't necessarily be coming from someone with root shell access.)

Bows Gladly, good sir. https://cfp.systemd.io/en/systemdconf_2016/public/events/21 https://cfp.systemd.io/en/systemdconf_2016/public/events/21 Sit back, and witness the insanity.

justinsaccount 10y ago
That's funny, because that's the same link referenced in the blog post, where david says: > That presentation is from the Cockpit project, which isn’t part of systemd and doesn’t even share its main developers. It’s as much “remote access to systemd” as using SSH and then invoking systemctl. and then further states in the 2nd blog post: > I certainly don’t buy his original argument (which he hasn’t repeated in his second post) that tools like Cockpit should change the view of systemd. Just like SSH or Remote Desktop in Windows, Cockpit is the tool providing the remote, privileged access; systemd is just on the server listening locally. Blaming systemd for a Cockpit-based compromise is like blaming the “dnf” utility for removing the web server packages after someone gets root over SSH. (Cockpit is neither developed by the systemd team nor installed by default in any distributions.) So.. > Sit back, and witness the insanity. Who is acting insane here? A systemd developer, or people spreading FUD?
- qwertyuiop924 10y ago
  First off, this doesn't defeat my point: people are trying to connect systemd to the browser. Secondly, no, I wasn't aware it was a separate project, because it didn't initially appear to be. Ordinarily, I'd assume it was, but frankly, at this point, I can totally see Lennart doing this. So yes, systemd isn't at fault, and I did miss it, and, to some degree, spread FUD, for which I am sorry. However, it's still a very silly idea.
  - agwa 10y ago
    No need for you to apologize - you never said systemd was at fault. (Neither did I - the point is that systemd has to be careful with its inputs, since they won't necessarily be coming from someone with root shell access.)