All the below command needs to be run as root:
poweroff
halt
shutdown
telinit
reboot
but still a user who is not a sudoer can shutdown by clicking on the shutdown button in GUI. What happens when we click shutdown button in GUI? How to replicate in cmd?
Sudo is just a one way for a regular user to execute commands as root. The other ways include:
processes with SETUID/SETGID bit set, which are executed under other privileges than the original caller - https://en.wikipedia.org/wiki/Setuid ('sudo' executable has also this bit set)
processes that already run under root privileges and accept external commands (via API, for example), and then call the command on behalf of the original caller (also, same thing that sudo basically does)
Related
I'm currently running a python script as a systemd service. Is there any way to "switch" into the service and take control of the script? The script has a menu but runs calculations in the background in another thread. Most likely not, so is there a way to run a python script 24/7, start on boot, restart on crash etc (just like systemd service) but be able to take control of it after I connect to the server via SSH, so I can manipulate the app?
One solution you could try would be to edit the systemd configuration to launch the process in screen or tmux, then attach that when logging in via SSH.
For instance, in the systemd unit, you might have:
[Service]
Type=single
ExecStart=tmux new "command"
Using Type=single will treat the tmux command as the main process, which would be killed if you stop it with systemctl stop systemprocess
The ExecStart=tmux new "command" creates a new tmux session with the command inside of it.
You can then attach to it using tmux attach as the same user the systemd unit is running as (I believe this is root by default).
So, I can get the directory of dump.rdb's location to change by using the dir option in redis.conf when I start it normally (just calling redis-server). If I want redis-server to run all of the time (I do) without needing a terminal window always open, I think I need to daemonize it. However, it doesn't seem this ever persists to the disk automatically and whenever the redis-server process ends (I've been ending it in testing by just running redis-cli shutdown or sometimes just killing the process with kill PID) and starts back up, all database changes are lost, which seems pretty bad if a crash or unexpected shutdown were to happen in the future. In the code that runs the processing of data (either python with redis-py or java with jedis), I can explicitly run bgsave(), but that saves dump.rdb in the directory that the code was run in and not where the dir option specifies in redis.conf
So, is there either another way to run redis-server without requiring a whole terminal window to stay open that allows what I want to do or is there a way to get the data to persist on disk in the proper directory when it's run as redis-server --daemonize yes or similar?
You could put it on linux "background" using nohup. It does not need a terminal window to stay up and running. I don't know the daemonize option to give you an advice about that, but, see if it works for you:
nohup redis-server &> redis.log&
or
Set daemonize yes in the conf file and run:
redis-server path/to/redis.conf
I have a service that I want to start with system startup. I have built a ap#.service definition for it as a template, because there could be many instances.
Defined in the root systemd, this works well, and starts and stops the service with the system. The service instance is installed with systemctl enable ap#inst1 as would be expected. Root is also able to start and stop the service without problems. The service runs in its own account (myuser), not root, controlled by User=myuser in the ap#.service template.
But I want user 'myuser' to be able to start and stop their own service, without compromising system security.
I switched to using a user systemd, and enabled lingering with loginctl enable-linger myuser. I then enable the service defined in the ~myuser/.config/systemd/user directory. The service now starts and stops cleanly with the system, as designed. If I log in to a terminal as 'myuser', systemctl --user start ap#inst1, and systemctl --user stop ap#inst1 both work perfectly.
However, if I log in as a different user (user2) and perform sudo su - myuser in a terminal, then systemctl --user commands now fail with error message "Failed to get D-Bus connection: no such file or directory".
How do I enable systemctl --user to work after a sudo su - myuser command to switch the user?
I found the answer on another site with further searches using different terms.
The solutions needed was to provide the shell with information to reach the correct DBUS for the user.
By adding the following environment variables to the shell before running systemctl --user, the DBUS problem is eliminated, and systemctl operates correctly.
export XDG_RUNTIME_DIR="/run/user/$UID"
export DBUS_SESSION_BUS_ADDRESS="unix:path=${XDG_RUNTIME_DIR}/bus"
To ensure that the DBUS_SESSION_BUS_ADDRESS is available in the sudo shell, I added the environment variables to ~/.bash_profile of the target userid. This requires that a login shell ( sudo su - myuser or sudo -l myuser) is created in order to create the correct environment.
Alternatively, add the creation of the environment variables to ~/.bashrc (or equivalent for other shells). The environment will then be established anew for all shell creations.
systemd 248 (released March 2021) introduced support for the syntax -M myuser# for specifying another user.
$ sudo systemctl --user -M myuser# start ap#inst1
A side-note:
If you want to get an interactive login shell for the user myuser
$ sudo machinectl shell myuser#
On my raspberry pi, I want my own written server to be started at startup, and to be restarted when it segfaults, so I added it to /etc/inittab. The problem is that the server won't start
The line I added:
1:2345:respawn:/home/gear/lionfish/main /home/gear/lionfish/app
When I run this command from the command line it works just fine, but the server doesn't run. I've checked this with ps aux, and it didn't show up
Have I made some sort of mistake?
EDIT: Small side question. The server needs root privileges, does inittab do this automatically or do I need to add something to it?
Typical problems:
As already mentioned, environment is set up differently. Make sure $PATH iscorrect.
Does your program try to execute in a directory which becomes unmounted? If so, cd to / first.
Access restrictions to files and directories.
Process doesn't detach from stdin/stdout/stderr.
The process runs in foreground instead of background.
Parent process receives a terminating signal such as SIGTERM which kills your process as well. Try ignoring this (and some others) signals by using nohup or sigset/sigignore.
Debugging hint: Let the server start by appending current time to the end of an already existing file in a directory which is guaranteed to be writable. Make sure you flush (and close) the file pointer immediately. Then at least you can see whether it was started at all or not.
I am writing a Daemon and I want to use start-stop-daemon command to do it but, when I use it in the command line I get :
The command could not be located because '/sbin' is not included in the PATH environment variable.
This is most likely caused by the lack of administrative privileges associated with your user account.
start-stop-daemon: command not found
but when i use it with sudo it run perfect but i need it to run in daemon and i think it is not good to use sudo in bash script in daemon something like :
sudo start-stop-daemon --start --background ...
Isn't it? When I deleted sudo from it it gave me command not found. How can i fix it? if it is wrong to use sudo in daemon.
start-stop-daemon can also set the user ID for the daemon process.
That said, you'd generally use start-stop-daemon from a script in /etc/rc.d, which is run with root privileges either from the init system that is being used this week (sysvinit, upstart, systemd, ...) and/or from the service(8) command.
So, if a user should be able to start/stop the service (which is a rather uncommon scenario), you'd use the sudoers file to grant them access to the service command, with the name of your service as a mandatory first argument.
In general though, write your service so it can be simply started at boot or during installation, and used by users as long as it's running. If the user needs to be able to start and stop instances of the service, then your daemon is in the business of managing instances, and the instance manager should be continually running, and users then contact this service via a socket (so users don't need sudo at all, which would make the lives of many administrators who don't install sudo quite a bit easier).
That depends on your settings in '/etc/sudoers'.
If the environment is reset (default),
the following path definition 'secure_path' contains /sbin (excerpt from Ubuntu '/etc/sudoers'):
Defaults env_reset
Defaults secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
Otherwise you need to provide the full program path
/sbin/start-stop-daemon