openrc 'service' binary removal: news post [SOLVED]

[dufeu]

I've read the news post.

As a user, how can I tell if I'm using the "service" binary?

My current install dates back to 2007. Since I'm not a programmer, I often don't know about behind the scene items like this.

I'd prefer not to find out I'm using the binary "service" in openrc through updating then rebooting and then having something break.


_________________
People whom think M$ is mediocre, don't know the half of it.

[John R. Graham]

If you're not a systemd user, and you don't know you're using it, then in all likelihood you're not using it. It was never the standard or documented way of controlling init scripts in Gentoo. Booting does not depend on it. If you were a systemd user, I don't think you would see this news item in the first place.

- John
_________________
I can confirm that I have received between 0 and 499 National Security Letters.

[Hu]

Technically, a systemd user can get this message. The news item is gated by whether the system has <=sys-apps/openrc-0.33 installed. As I understand it, it's perfectly valid to install both openrc and systemd, then use only one and completely ignore the other. In such a case, someone who used systemd as their active init system might get this message because Portage reacted to the presence of openrc, rather than its usage.

[Tony0945]

I really don't understand this. They removed "service" and substituted "rc-service". Why not just symlink them and not make a big deal of it?
This reminds me of the openrc-run/runscript fiasco. https://forums.gentoo.org/viewtopic-t-1045350-start-0.html

And was "service" just a way of invoking "/etc/init.d<some service name> <action>"? Wouldn't an alias work as well? Why all these binaries?

To be perfectly clear I'm running OpenRC-0.17 and had to undo the PATH variable change.

[steveL]

[Naib]

[Zucca]

It was/is a binary? O.o
Like posted above: a simple symlink to replace the service binary would propably "do the thing".
_________________
..: Zucca :..
Gentoo IRC channels reside on Libera.Chat.
--

[Genone]

[Naib]

I didn't advocate a symlink, I was posting that this is solved.
I agree renaming is done to stop collisions
_________________

[steveL]

[Tony0945]

[Tony0945]

[steveL]

[Tony0945]

[Hu]

You could use a Match Address block in sshd_config to apply different rules when the connection comes from your IP. Beware getting locked out if your IP changes, though.

For logging in behind a NAT device, you need a port forwarding from the public IP to the administered machine's ssh port.

[Tony0945]

[jonathan183]

[Tony0945]

Interesting. I would be making a call anyway to tell her to turn the computer on.

I would do my home updates first, so I would know if there were any portage issues or blockers. I probably would update the kernel very infrequently because the hardware is old (2013, model came out in 2012) so there is probably not any driver updates. Besides it's a one lung AMD E2-1800 and big builds would be very slow. I might even block Xorg and Mate updates, at least until the current builds pass out of the tree. I would like to keep up with updates on ssh, ssl, FF, and T-bird.

[krinn]

why not make it easy and allow any IP to use ssh, but disallow password login and only with key, you have to setup host once and everyone coming without the right key will be kick out.
you should have tones of "passwordless ssh" wiki and documents, but it's as easy as: add your key in the client /user/.ssh/autorized_keys file and fix its /etc/ssh/sshd_config to disallow password login

[Hu]

Flipping the IP address seems like unnecessary complication and disruption. I concur with krinn that authentication should require a key, never a password. If you really want extra security, keep a Netfilter rule blocking ssh active except during maintenance and let the local operator enable/disable that rule, rather than flipping the IP address. If you go that route, the "open" condition can be by IP whitelist as discussed above, rather than open to all (although in most cases, aside from log spam, open-to-all is probably safe if you require key authentication).

[Tony0945]

[krinn]

[jonathan183]

Just to clarify ... the method I suggested means:-
A. The destination does not have to fight off attempts to connect in any way at any time other than when you are doing updates (using screen and disconnecting could reduce the exposure time further).
B. Any other devices connected to the router don't get exposed in error.
C. I had suggested key based authentication (see 3b in the post).
D. Access to allow updates etc is actually controlled by the owner of the system. Because the user is involved you get feedback on if the system has not been working/acting in an unusual way rather than just thinking you may have been doing an update.

Running a script to set things up for the update at the remote end should be easy to do irrespective of how many steps are taken.
Having DHCP and static networks and allowing the user to select normal_use or allow ssh_and_system_update means you don't even need to do the network switch with a script.
I had previously configured the router with a normal (all incoming ports closed) and ssh allowed and got the user to switch them but dropped that in favor of having 2 network configurations on the remote machine.

The approach does not scale well ... but this is a family and few friends only type approach. Exposing systems to potential attack for the minimum time, and at random times seemed like a reasonable thing to do ... ymmv

[Hu]

Rather than playing games with writing flag values to a socket[1], why not just give the user permission to sudo exactly two commands: allow-maintenance and disallow-maintenance? These would then do the work of the root program in your example, without the need for a running program and probably without the need for any custom programs at all. Further, since it would be routed through sudo, it would automatically be logged by the usual logging mechanism, giving you an audit trail of when access was turned on/off.

Key authentication is vastly superior to password-based authentication. Both require the connecting system to know secret information, but since the keys are persisted to the client's storage instead of held in someone's memory, they can be far larger than a human could remember (or tolerate typing). For added security, you can password-protect the at-rest private key on the client. This is better than not protecting it, but beware that an attacker who steals an encrypted private key can bruteforce it offline, whereas an attacker who wants to bruteforce a password must do so online. On the other hand, if the attacker is stealing data off the administrator's hard drive, you have other problems, regardless of whether that data is encrypted.

[1] If you want to use a socket, use a local (AF_UNIX) socket for this, so that it's completely impossible for remote peers to connect, even if they know everything about how the scheme works.

jonathan183: so you did. Sorry, I missed that in the larger scheme, and remarked on it primarily because the post immediately above mine mentioned it and I wanted to emphasize that I thought it was a good idea. I should have credited both of you.

[Tony0945]