I am looking to have the Transmission bittorrent client execute a script that changes the owner and permissions of all torrents in the completed folder when a torrent completes downloading.
I am using the following relevant settings in /etc/transmission-daemon/settings.json:
"download-dir": "/data/transmission/completed",
"script-torrent-done-enabled": true,
"script-torrent-done-filename": "/home/user/script.sh",
The script does not seem to be executing after a torrent completes, I know there are other issues that could be going on aside the from the content of the script itself. The owner of the script file is debian-transmission and I have the permissions set to 777, so there shouldn't be an issues with Transmission accessing the script unless I have missed something here.
The /home/user/script.sh file is as follows:
#!/bin/bash
echo sudopassword | /usr/bin/sudo -S /bin/chmod -f -R 777 /data/transmission/completed
echo sudopassword | /usr/bin/sudo -S /bin/chown -f -R user /data/transmission/completed
I know it is poor form to use a sudo command in this fashion, but I can execute the script on it's own and it will work correctly. I am not sure why Transmission is not executing the script. Transmission supports some environment variables such as TR_TORRENT_NAME that I would like to use once the script is being triggered. Is there anything I am not setting up in the file that would prevent the script from working correctly and how would I use environment variables?
I'll probably answer a different question here, but if you're trying this simply to gain write permissions on your Transmission Daemon's downloads to your user, try a different approach.
I'm running my Transmission Daemon under my username, as set in it's systemd service file. (/etc/systemd/system/multi-user.target.wants/transmission-daemon.service in my case)
[Unit]
Description=Transmission BitTorrent Daemon
After=network.target
[Service]
User=myuser # set user here
Group=mygroup # set group here :)
UMask=0022 # 0022 gives 644 permissions on files (u+w), 0002 gives 644 (g+w), 0000 gives 666 (a+w)
Type=notify
ExecStart=/usr/bin/transmission-daemon -f --log-error
ExecStop=/bin/kill -s STOP $MAINPID
ExecReload=/bin/kill -s HUP $MAINPID
[Install]
WantedBy=multi-user.target
Notice User, Group and UMask (with capital M) directives.
See Execution environment configuration for Systemd manpage.
Then run:
sudo chown -fR user /data/transmission/completed
sudo systemctl daemon-reload
sudo service transmission-daemon restart
and you should set :)
Add the user who will execute the script to a group with default sudo access.
Fedora - add user to the wheel group
sudo usermod -aG wheel $(whoami)
Ubuntu - user group: sudo or admin (deprecated)
Related
I am trying to reference a user directory on boot for my raspberry pi 4 32 bit bullseye desktop with a service setup on systemctl. This service maps my ip address to an .env file. The process is as follows:
setup.service attempts to create a .env file using setup.sh with my current ip address
setup.timer fires off the service 1 minute after boot
This works flawlessly when my setup.sh looks like this:
...
destdir=/home/me/my_directory/.env
echo "REACT_APP_MACHINE_HOST_IP=$REACT_APP_MACHINE_HOST_IP" > "$destdir"
But when I try to replace the value of "me" with the machine user in order to make this more transferrable I get this error on boot:
...
destdir=/home/"$USER"/my_directory/.env
echo "REACT_APP_MACHINE_HOST_IP=$REACT_APP_MACHINE_HOST_IP" > "$destdir"
/home//my_directory/.env does not exist...
Not sure where I'm off because I made a quick test.sh script and the following echoed the directory correctly:
#!/bin/bash
mydir=/home/"$USER"/my_directory/
echo $mydir
It seems like no user is recognized. I am assuming this has something to do with system running on root? Or is my syntax off?
EDIT:
My setup.service below:
[Unit]
Description=setup mcw
After=multi-user.target
[Service]
Type=oneshot
ExecStart=/usr/local/bin/setup.sh
[Install]
WantedBy=multi-user.target
And what I run to automate aka automate.sh:
# copy ip file to task and authorize
sudo cp /home/${USER}/my_directory/setup.sh /usr/local/bin/setup.sh
sudo chmod 744 /usr/local/bin/setup.sh
# create setup files
sudo cp /home/${USER}/my_directory/setup.service /etc/systemd/system/setup.service
sudo cp /home/${USER}/my_directory/setup.timer /etc/systemd/system/setup.timer
# add permissions for the service
sudo chmod 644 /etc/systemd/system/setup.service
# setup and reload systemctl
sudo systemctl daemon-reload
sudo systemctl enable setup.timer
sudo systemctl start setup.timer
I have several servers running Ubuntu 18.04.3 LTS. Although it's considered bad practice to auto login, I understand the risks.
I've done the following to auto-login the user:
sudo mkdir /etc/systemd/system/getty#tty1.service.d
sudo nano /etc/systemd/system/getty#tty1.service.d/override.conf
Then I add the following to the file:
[Service]
ExecStart=
ExecStart=-/sbin/agetty --noissue --autologin my_user %I $TERM
Type=idle
Then, I edit the following file for the user to be able to automatically start a program:
sudo nano /home/my_user/.bash_profile
# Add this to the file:
cd /home/my_user/my_program
sudo ./program
This works great on the console when the server starts, however, when I SSH into the server, the same program is started and I don't want that.
The simplest solution is to SSH with a different user but is there a way to prevent the program from running when I SSH in using the same user?
The easy approach is to check the environment for variables ssh sets; there are several.
# only run my_program on login if not connecting via ssh
if [ -z "$SSH_CLIENT" ]; then
cd /home/my_user/my_program && sudo ./program
fi
When executing a shell script, how does sudo come into play in the following?
# script.sh
ls /root
sudo ls /root
Now, if I run $ sudo ./script.sh or $ ./script.sh what will be the difference? For example:
Do all commands that are run with sudo ./script.sh automatically prepend a "sudo" to that command?
Is the sudo ls /root line vlid? Or should the line instead of ls /root and require root invocation?
Basically, I'm trying to figure out the difference in a line-item being run as sudo, or the script itself being run as sudo.
If you have a script that requires elevated privileges for certain commands, one way to handle those commands is with sudo. Before using sudo, there are several considerations for configuring its use. For instance, if you have certain users you want to be able to run commands with sudo and further to run sudo without being prompted for a password, you need a bit of configuration first. sudo is configured through the visudo utility. For most uses of sudo you will simply need to uncomment options at the end of the file. However to allow users to run sudo without a password, you will also need to add those users to the wheel group (some distros now use a sudo group -- check). After adding users to the wheel group, to allow them to use sudo without a password, you would run visudo and uncomment the following line:
## Same thing without a password
%wheel ALL=(ALL) NOPASSWD: ALL
With sudo configured, then within a script, if elevated (root) privileges are needed you simply need to check whether the user UID (and/or EUID) are equal to zero indicating the user is root, if not, then you use sudo to run the command. You can structure the test in the negative or in the positive to fit your taste, e.g.
if [ "$UID" -eq 0 -o "$EUID" -eq 0 ]; then
command
else
sudo command
fi
or
if [ "$UID" -ne 0 -a "$EUID" -ne 0 ]; then
sudo command
else
command
fi
If your command is not a simple command, but instead contains redirections or pipelines, then you must run the entire command with sudo not just the first command in the list. To do so, just use sudo bash -c "your long command" to ensure elevated privileges are available to each part of a compound command that needs it. For example if you attempt:
sudo cat /etc/sudoers > sudoersbackup
The command will fail. While cat has the elevated privileges to read the file the > redirection is run as the regular user and will fail due to lack of permission. To handle that circumstance, you can do:
sudo bash -c "cat /etc/sudoers > sudoersbackup"
That ensures elevated privileges are available to the entire command.
SUDO stands for "super user do". Basically it is a keyword that when prefixed before any other command, will force that command to run with elevated privileges. Certain commands require elevated privileges. There should be a file located at /etc/sudoers which provides a list of users or user groups who have permission to execute privileged commands.
So if your shell script requires no special privileges to run (which I expect it does not), then sudo ./script.sh should be equivalent to bash script.sh or ./script.sh.
Whenever i access sudo nano /etc/network/interfaces the file is essentially empty which is hindering me because i need to disable the power saving feature that automatically disables the wifi after a minute or so
This is what shows in my file
# interfaces(5) file used by ifup(8) and ifdown(8)
# Please note that this file is written to be used with dhcpcd
# For static IP, consult /etc/dhcpcd.conf and 'man dhcpcd.conf'
# Include files from /etc/network/interfaces.d:
source-directory /etc/network/interfaces.d
Because of this there is no where i can add the wireless-power off text and have it work.I have already tried to add this just at the bottom but it does not work.
Firstly you should repost this over at https://raspberrypi.stackexchange.com/
Secondly I am just facing the same issue, and solved it by entering this line into the crontab:
#reboot /sbin/iw dev wlan0 set power_save off&
I used the below to PERSISTENTLY kill WiFi Power Management across reboots. It's done as a systemd service so independent of how the network interfaces are configured and "just works".
Should work on any modern Pi which has systemd. Just copy & paste below bash script into a file, set it to executable and sudo ./fileName.sh:
if [ -d /root/scripts ]; then
mkdir /root/scripts
fi
apt-get -y install iw
apt-get -y install wireless-tools
cat <<EOF> /root/scripts/pwr-mgmnt-wifi-disable.sh
#!/bin/bash
iw dev wlan0 set power_save off
EOF
chmod 700 /root/scripts/pwr-mgmnt-wifi-disable.sh
cat <<EOF> /etc/systemd/system//pwr-mgmnt-wifi-disable.service
[Unit]
Description=Disable WiFi Power Management
Requires=network-online.target
After=hostapd.service
[Service]
User=root
Group=root
Type=oneshot
ExecStart=/root/scripts/pwr-mgmnt-wifi-disable.sh
[Install]
WantedBy=multi-user.target
EOF
chmod 644 /etc/systemd/system/pwr-mgmnt-wifi-disable.service
systemctl enable pwr-mgmnt-wifi-disable.service
systemctl start pwr-mgmnt-wifi-disable.service
I have a jenkins job, which has its own set of build servers. The process which i follow is building applications on the jenkins build server and then I use "send files or execute commands over ssh" to copy my build and deploy the same using a shell script.
As a part of the deployment commands, I have quite a few steps to be done, like mkdir, tar -xzvf etc.I want to execute these deployment steps with a specific user "K". But when i type the sudo su - k command, the jenkins job fails because i am unable to feed the password to it.
#!/bin/bash
sudo su - K << \EOF
cd /DIR1/DIR2;
cp ~/MY_APP.war .
mkdir DIR 3
tar -xzvf MY_APP.war
EOF
To handle that, I used a PASSWORD parameter and made the build as parameterized, so that i can use the same PASSWORD in the shell script.
I have tried to use Expect, but looks like commands like cd, tar -xzvf are not working inside it and even if they work they will not be executed with the K as a user since the terminal may expire(please correct if wrong).
export $PASSWORD
/usr/bin/expect << EOD
spawn sudo su - k
expect "password for K"
send -- "$PASSWORD"
cd /DIR1/DIR2;
cp ~/MY_APP.war .
mkdir DIR 3
tar -xzvf MY_APP.war
EOD
Note: I do not have the root access to the servers and hence cannot tweak the host key files. Is there a work around for this problem?
Even if you get it working, having passwords in scripts or on the command line probably is not ideal from a security standpoint. Two things I would suggest :
1) Use a public SSH key owned by the user on your initiating system as an authorized key on the remote system to allow logging as the intended user on the remote system without a password. You should have all you need to do that (no root access required, only to the users you already use on each system).
2) Set-up the "sudoers" file on the remote system so that the user you log in as is allowed to perform the commands you need as the required user. You would need the system administrator help for that.
Like so:
SUDO_PASSWORD=TheSudoPassword
...
ssh kilroy#somehost "echo $SUDO_PASSWORD | sudo -S some_root_command"
Later
How can i use this in the 1st snippet?
Write a file:
deploy.sh
#!/bin/sh
cd /DIR1/DIR2
cp ~/MY_APP.war .
mkdir DIR 3
tar -xzvf MY_APP.war
Then:
chmod +x deploy.sh
scp deploy.sh kilroy#somehost:~
ssh kilroy#somehost "echo $SUDO_PASSWORD | sudo -S ./deploy.sh"