I have written several shell scripts with tcl/tk and I run it on the machine with the user group, when I give it to another user with different machine or from another IP it gives error.
Spawn/bin/bash
But if I run it from my machine where I wrote it, it runs correctly.
The header is so defined.
#! / Usr/bin/expect -f
#
Can you tell me that I have not added or am missing so that it can run from any pc and any user?
From the question you have posted, it looks like to me one or more of following issues. Apart from that the real problem looks to me is in /bin/bash. Check manually once in the machine where the problem lies.
First check manually from other machine where the issue is present. Checking is easy.
which expect
expect
spawn /bin/bash
Have you got the error? Also check if there is -
Difference in expect version
Permission issue
Have you considered the scenario where you are prompted for storing RSA key? Relevant in case you are connecting to other machines from the host you are running the program.
Thank,
Mr. Bordoloi
Related
I am trying to connect to mysql in my CI workflow and to make sure setting up the DB worked I am passing in the echo command.
I get this error.
I can't believe this is'nt written as an Answer in every single question about this topic, and it is an absolutely retarded fix but here it goes.
Add to the script section.
script:
sleep 300
[do other scripts here]
The container is started but the db has'nt had time to be installed yet. Thats why it did not work.
I'm seeking for solution to pass the password securely to MySQL client on *nix platforms while using automated script solution (i.e Bash script).
So far, I had to realize that MySQL ignores password input from stdin at all (still asks for password on terminal, crashes on automation).
The worst, solution using ~/.mylogin.cnf also doesn't work for me, it seems MySQL somehow ignores it at all.
I prefer to not to use the command line -p argument for password to prevent described "all-around" security issues.
--defaults-file and --defaults-extra-file handn't give the solution as well, seems like the password is prompted by client at "all-cost".
Therefore, I'm just running out of solutions for that primitive (at first sight) task!
Any help will be highly appreciated!
I'll try to be short in my findings:
First, the solution using mysql --defaults-extra-file="path/to/file" is actually worked for me among with --default-file option until it is passed as the first argument (as well noticed by Bill Karwin here).
Second, usage of ~/mylogin.cnf also workes fine until the file access restricted for all users except the current account the MySQL client is running under + file is restricted from execution even by current user (chmod u-x) as well, possibly treated by MySQL as a threat due to Linux GUI x permission umbrella on many systems (execute permission is enabled for user, group and others by setting one V in GUI for the file). Still this reason is just a suggestion.
I am using couchbase server 6.0.2 image from RedHat
https://access.redhat.com/containers/?tab=overview&get-method=registry-tokens#/registry.connect.redhat.com/couchbase/server
in openshift.
The Pod is running but does not react to http://localhost:8091. The Logs show the error shown below.
I have 3 questions:
Why is whoami failing in the entrypoint?
Why isn't the server responding on port 8091?
Does the couchbase server image require root permissions?
It seems the couchbase/server image is expecting to be run as root, then creates its own user couchbase and group couchbase.
At the end it's running an entrypoint script and in there checking if the user running the whole thing, is actually the user couchbase by executing the whois command.
This is not the case if you just run it in openshift, as the container will be run as some "random" unprivileged user.
This leads to a set of consecutive failures:
Here You will find the evaluation that is done in the entrypoint.sh.
Now the whois command is failing since there is not actual user just said random UID. that failing, leaves the first part of the evaluation blank, which will result in a failure.
This is a bug in the couchbase/server image and as such you should, if time allows contribute to fixing by opening an issue against that repo.
I am having problems authenticating to my sql server with roundhouse and Teamcity. Teamcity is running as the local system account, so the cmd shell will open under the local sytem. When I pass in rh.exe -d=DB -s=SQLSERVER -csa=uid=DOMAIN\USER;pwd=PASSWORD ...
I get an error that logging in under the local machine name is not a valid login.
I then tried the format listed here RoundhousE - Change login used by scripts scripts , and I get an error about a failed login for the specific user. I know that the password is correct, so I'm confused as to why it would not be working now.
RH.exe version 0.8.5.0
Teamcity version 8
I tried out a workaround on the TeamCity side. By switching my buildAgent to the account that I normally use for deployment, I can successfully authenticate.
The format that I use is
rh.exe -d=param -s=param -f=param -vf=param
If you have any other solutions that involve the exact syntax for Roundhouse, I would still greatly appreciate them.
Dumb question but is that your bare command args?
It might be better to enclose those in double quotes -csa="COMPLETE Connection String, end with ;"
I have a web application that runs queries on the database. The application is trying to run a query, and send the results to the an output file. I have confirmed that the issue is actually a permission denied (error 13) problem, not an issue with any other part of the query. A simplified form of the query follows:
SELECT 'anything'
INTO OUTFILE '/var/www/html/sl/filestore/dbadpt_database.tmp'
FROM INFORMATION_SCHEMA.TABLES;
This query runs fine when I remove the INTO OUTFILE line. I have tried every permissions setting for this dir that I can think of. I have even changed the permission to 777, and gotten the same results. (Yes, I know 777 is not secure. Just did it for testing) I have tried every ownership combination of 'root', 'apache', and 'mysql' that I could think to try for this dir. I have pasted the above query into the MySQL command-line tool, and it has produced the same results.
We are running CentOS 5.5. The web server running the application is Apache 2. I cannot create the file ahead of time, nor can I change the directory that the program is trying to write to.
I would hazard a guess that problem is with SELinux.
The first thing I would try would be setenforce 0 and see if that fixed it. It will only fix the symptoms (you still need to reconfigure SELinux to allow what you need), but it will at least confirm whether that's the problem or not.