I execute the script below as root within MAC OS X terminal. The piped command runs successfully, but the script fails at the chown command with the following error:
chown: Domain Users: illegal group name
Why?
See script below:
#!/bin/bash
echo Enter username
read Name
echo Enter number
read NUM
sudo -s "(cd /Users/$NAME && tar c .) | (cd /Users/$NUM && tar xf -)"
sudo chown -R $NUM:"Domain Users" /Users/$NUM
sudo chmod g+rwx /Users/$NUM
"Domain Users" is an Active Directory group, hence one must be connected to the domain in order to CHOWN against a specified user within this group and take ownership of the resources specified. I was working remotely this day and was not connected via our VPN, hence not connected to our domain and thus unable to CHOWN against this Active Directory group "Domain Users".
Your reading the variables wrong:
should look like this:
...
read NAME
....
read NUM
Related
I am trying to set up a cron on several AWS EC2 machines and would like to run a command on all of them at once, with the following shell script:
#!/bin/sh
cd /etc/cron.daily
touch ecs.sh
echo '#!/bin/sh' > /etc/cron.daily/ecs.sh
echo 'sudo yum update -y ecs-init' >> /etc/cron.daily/ecs.sh
echo 'sudo yum update -y' >> /etc/cron.daily/ecs.sh
sudo chmod 755 /etc/cron.daily/ecs.sh
cd ~
(crontab -u root -l; echo '0 0 * * * /etc/cron.daily/ecs.sh') | crontab -u root -
sudo yum update -y
The part that does not work is: chmod 755 /etc/cron.daily/ecs.sh
I am not sure, what am I missing.
If you can (have sufficient rights to) create a file, you do not need to sudo to change its permissions to 0755. Which would also likely prompt you to input your password and run non-interactively could be the reason why the action did not take place.
On the other hand, if the user running this did not have the necessary (write) permission, preceding lines creating the file would not happen either.
You also do not need to touch a file, because that > redirection will create it (always a new one).
You also should not cd somewhere and and continue performing actions without checking directory was changed as expected. But since on all action but the unnecessary touch you use absolute path names, you can just as well leave out both cd lines.
If you clean-up the script and it still does not perform expected action, it might be useful (assuming non-interactive execution) to save its output (redirect both standard > (or 1>) and error (2>) output to a file) and examine it for errors.
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"
I have a user named cam. Cam stores a bunch of files. Now I want to move those files so I tried the following...
sudo mv /home/cam/DCS-*.jpg /home/cam/cam/
But when I run this command I get...
mv: cannot stat ‘/home/cam/DCS-*.jpg’: No such file or directory
But if I runt the command like...
sudo mv /home/cam/DCS-934L2015110711425501.jpg /home/cam/cam/
It works fine. WTF am I missing
if I do a sudo ls /home/cam I see everything but without sudo I don't have permissions to see anything.
When this command is executed:
sudo mv /home/cam/DCS-*.jpg /home/cam/cam/
The * is expanded by the shell according to the permissions of the current user. As the current user cannot see those files (ls /home/cam has no permission), the shell cannot expand the parameter list.
shouldn't sudo have permissions regardless?
No. With sudo, the mv command will be executed as root, but the parameter list expansion happens before execution is passed to sudo mv.
To have the * expansion happen with root permission (so that the content of the directory will be visible), you can wrap the command in its own shell like this:
sudo sh -c 'mv /home/cam/DCS-*.jpg /home/cam/cam/'
I have some files to upload. Usually to edit anything while logged in the server I must precede the command with sudo. That is known.
How do I send a file then as "admin" instead of "root" when I have disabled root login.
scp path\to\file admin#myaddress.com:/var/www/sitename/public/path/
PERMISSION DENIED
In my opinion, either you should give permissions to the admin user or scp your file to /tmp/ and then sudo mv /tmp/yourfile /var/www/sitename/public/path/.
There is no sudo option when we are using scp command from local to server.
Each user will have upload permission to its own folder in home directory ex. home/xxxxuser so use as below:
scp file_source_here xxxuser#yourserver:/home/xxxuser/
Now you can move file from this folder to your destination.
I suggest these two commands as it works in a bash script.
Move the file to tmp as suggested.
scp path\to\file admin#myaddress.com:/tmp
Assuming admin user can do sudo. The ssh option -t allow you to do sudo command.
ssh -t admin#myaddress.com 'sudo chown root:root /tmp/file && sudo mv /tmp/file /var/www/sitename/public/path/'
I'm struggling with a Mac OS X 10.5.8 that I've started using recently for development. I successfully installed tomcat and create launchd.conf for my environment variables.
I believe it works fine. Coz I can build a project with Netbeans using maven and cargo plugins successfully so i found online a script for start and stop the tomcat
#!/bin/bash
case $1 in
start)
sh /Library/apache-tomcat-6.0.20/bin/startup.sh
;;
stop)
sh /Library/apache-tomcat-6.0.20/bin/shutdown.sh
;;
restart)
sh /Library/apache-tomcat-6.0.20/bin/shutdown.sh
sh /Library/apache-tomcat-6.0.20/bin/startup.sh
;;
*)
echo "Usage :start|stop|restart"
;;
esac
exit 0
That script was created in nano in sudo sh
but when i want to run it. is spit out this
sh: /usr/bin/tomcat: Permission denied
I've added chmod 755 *.sh and *.bat inside /Library/apache-tomcat-6.0.20/bin
Still access denied so what do I go around that? I have the admin privileges on the machine.
Thanks for reading
Go to Tomcat bin directory and run the below command:
chmod +x *.sh
This worked for me.
Where did you install the tomcat script to? I'd recommend you install it to /usr/bin. Once installed, make sure the permissions are correct (i.e. chmod 755 /usr/bin/tomcat). You can then confirm with ls -l /usr/bin/tomcat.
If you still get errors once the permissions on /usr/bin/tomcat are correct, then you can add the following two lines following the #!/bin/bash line.
set -x
set -v
With the above lines, bash will output additional information that will allow you to tell what's being executed and where the error is happening.
1) Go to the tomcat directory, which preferably should be "/usr/local/folder-name"
2) Check for the permissions for the folder: ls -l
3) Change the permissions using: sudo chmod -R 755 folder-name
4) Change the owner to the current owner: sudo chown -R owner-name:group-name folder-name
e.g sudo chown -R userName:admin folder-name
Try executing the script again and it should work.