I have went and installed a piece of PHP Scripts for (mobile minecraft server software) and I went to execute the file 'start.sh' with the command;
'./start.sh'
When I pressed enter the SSH Client (Putty) it came and said 'Permittion Denied'
I have made the file permissions open with cmod. I am not sure what is wrong.
Thanks in advance!
The line you posted in your comment means that the owner can read and write, the owner's group can read, and everyone else can read.
Do
chmod +x start.sh
This will add the ability to execute as well as read and write.
Related
I have a post-commit hook in my subversion that will export a copy of my repo to a desired location for deployment. That part works fine, but it comes in with apache:apache. I need this to be changed to prod_user:prod_user. If I try to add a chown statement in my script, it will fail. If I try to use sudo, it will ask for a password that I cant give because this happening in a post-commit script. I'd like this to be as automated as possible.
My question is: How can I make this work? I need to export the contents of my repo to the production folder and convert the users/groups to match existing production users/groups.
Is there a way to pass my password as an argument to a sudo command?
Thank you for your help!
Is there a way to pass my password as an argument to a sudo command?
Don't do it, if at all possible. This will leak your password to anyone that can read the script.
But if you can't avoid it, use echo <password> | sudo -S <command> - -S makes sudo read from stdin so you can give it the password from there
Don't do any of sudo, chown, chgrp. It is not the responsibility of the uploader to fix permissions on the remote server.
Have the server administrator properly setup these, so that pushing production files from the repository works straight without messing with sudo permission at the server.
If you are the one same person, then take the time to fix the server side to avoid having a remote user elevate its privileges (even temporarily with sudo) for the sake of fixing uploaded files permissions.
Use crontab -e as root user, then you can change ownership without escalation of privileges.
Or run as prod_user and make it check out the code ...then it is already the owner of the files.
Keeping a file with the last deployment timestamp can be used to compare to HEAD timestamp.
When installing tripwire on debian, it prompts me if I want to create a site key, local key, and finally, need to click 'ok' when completed.
Is there a way I can install tripwire, not create any keys, and answer the 'ok' at the end?
I'm using Digital Ocean's 'user data' where I copy & paste a bunch of bash commands so I can deploy a new droplet quickly.
Edit:
Looks like I was able to mute them but I still get this:
Setting up tripwire (2.4.2.2-4) ...
chmod: cannot access ‘/etc/tripwire/site.key’: No such file or directory
chmod: cannot access ‘/etc/tripwire/debian-512mb-nyc2-01-local.key’: No such file or directory
How can I avoid the chmod: cannot access errors?
To just suppress the errors redirect the stderr to /dev/null in your userdata script. Or if you want a log of the errors redirect it to a file so you can review upon startup.
chmod /etc/tripwire/site.key 2>/dev/null
or
chmod /etc/tripwire/site.key &>/tmp/chmod.log
I have just got some domain hosting and I am wondering how to execute a CMD or a .sh file.
I am attempting to make a game server but the software requires me to execute the file. The file managers are rubbish and I have a Nexus 7 that can do FTP. I think I missed something just let me know if you need more information.
You must set executable permission to the .sh file in order to execute it in console.
First of all I am not sure if you could execute it with a cli ftp connection to the hosting.
You must connnect via ssh, then cd the directory where the .sh file is, then change the permission.
If you only want to execute the file, and you don't care the code, then give only execute permission to the file for your user with: chmod 100 file.sh then execute it with ./file.sh
If you want to read the code, then chmod 500, and if you want full perms for your user then chmod 700 make any combination to give or deny perms for users in your own group, or for others.
I have written a little test script to prevent running my script simultaneously with flock:
#!/bin/bash
scriptname=$(basename $0)
lock="/var/run/${scriptname}"
umask 0002
exec 200>$lock
flock -n 200 || exit 1
## The code:
sleep 60
echo "Hello world"
When I run the script with my user and try to run the script with another user I got following error message with the lock file.
/var/run/test.lock: Permission denied
Any idea?
Kind regards,
Andreas
In a comment, you mention that
other user is in the same group. file permissions are -rw-r--r--
In other words, only the first user has write permissions on the lock file.
However, your script does:
exec 200>$lock
which attempts to open the lockfile for writing. Hence the "permission denied" error.
Opening the file for writing has the advantage that it won't fail if the file doesn't exist, but it also means that you can't easily predict who the owner of the file will be if your script is being run simultaneously by more than one user. [1]
In most linux distributions, the umask will be set to 0022, which causes newly-created files to have permissions rw-r--r--, which means that only the user which creates the file will have write permissions. That's sane security policy but it complicates using a lockfile shared between two or more users. If the users are in the same group, you could adjust your umask so that new files are created with group write permissions, remembering to set it back afterwards. For example (untested):
OLD_UMASK=$(umask)
umask 002
exec 200>"$lock"
umask $OLD_UMASK
Alternatively, you could apply the lock with only read permissions [2], taking care to ensure that the file is created first:
touch "$lock" 2>/dev/null # Don't care if it fails.
exec 200<"$lock" # Note: < instead of >
Notes:
[1]: Another issue with exec 200>file is that it will truncate the file if it does exist, so it is only appropriate for empty files. In general, you should use >> unless you know for certain that the file contains no useful information.
[2]: flock doesn't care what mode the file is open in. See man 1 flock for more information.
I was trying to use flock on a file with shared group permissions with a system account. Access permissions changed in Ubuntu 19.10 due to an updated kernel. You must be logged in as the user who owns the file, and not a user whose group matches the file permissions. Even sudo -u will show 'permission denied' or 'This account is currently not available'. It affects fifo files like the ones used by the flock command.
The reason for the change is due to security vulnerabilities.
There is a workaround to get the older behaviour back in:
create /etc/sysctl.d/protect-links.conf with the contents:
fs.protected_regular = 0
Then restart procps:
sudo systemctl restart procps.service
Run the whole script by sudo /path/script.sh instead of only /path/script.sh
I am trying to write a script to automatically upload files to a sftp server. My problem is authentication.
I know it is not possible to store a password in a bash script for sftp.
I can't use keys because the admin of the server won't allow me.
I don't want to use any extras (sshpass/expect) because I can't
guarantee they will be on the machine I'm using (the script are wanted so that the processes are not tied down to a particular machine).
Manual entry of the password is not a problem I just need to get the script to wait for the user to put the password in. At the minute when I run the script it opens terminal, prompts for the password, but when this is entered nothing else happens. If I enter the lines of code manual after it uploads everything correctly.
#!bin/bash/
cd /remote_directory
lcd /local_directory
put some_file.txt
After months of looking for an answer I have finally found the solution. It was in a comment on an answer in some other thread I can't even remember. Hope this can help others out there.
Your bash script should look like this and will connect to the sftp server, prompt the user for the password, and then execute the remaining commands.
#!/bin/bash
sftp user#server <<!
cd /the/remote/directory
lcd /your/local/directory
put/get some.file
!