I am using sbt-docker and trying to setup ssh on docker by following this link: https://docs.docker.com/examples/running_ssh_service/.
sbt-docker seems not to understand below:
run("echo", "'root:root' | chpasswd")
Instead of changing the root user password, this run command simply prints string "'root:root' | chpasswd".
Similarly,
run("echo", "root:root", "&>", "rootpasswd.txt")
This command print "root:root &> rootpasswd.txt" instead of writing "root:root" into rootpasswd.txt file.
Any idea how to make sbt-docker correctly execute these echo commands? Thanks!
Docker can run commands in 2 ways, shell form and exec form. The shell form will run your command in a shell.
sbt-docker supports both formats with the methods: run (exec) and runShell (shell).
Since you are using a pipe you need to run your command using a shell. This is what the runShell method is for:
runShell("echo", "root:root", "|", "chpasswd")
runShell("echo", "root:root", "&>", "rootpasswd.txt")
You can also use the runRaw method, which allowes you to freely use any form:
runRaw("echo root:root | chpasswd")
runRaw("echo root:root &> rootpasswd.txt")
Related
Is there any way to have a "hook" execute a shell command? Either through a:
-
- tick marks (``)
- through "a macro"
I checked the neomutt documentation and it says that the hook command can execute something with backticks:
shutdown-hook 'echo `mbsync -a`'
But whenever I do that, I get:
echo: unknown command
I tried doing a:
shutdown-hook 'echo `ls`'
and I still get the same error. Am I missing something?
Did you place these commands in your .muttrc file?
This does work for me, inserting in .muttrc file
startup-hook 'echo `echo did it > /tmp/mutt-did-it`'
then running mutt, the file /tmp/mutt-did-it then contains did it. It does also work with folder and send hooks.
I'm writing a daemon that will log in to other machines to confirm that a service is running and also start, stop, or kill it. Because of this, the unix commands get a little long and obfuscated.
The basic shape of the commands that are forming are like:
bash -c 'ssh -p 22 user#host.domain.com pgrep -fl "APP.*APP_id=12345"'
Where APP is the name of the remote executable and APP_id is a parameter passed to the application when started.
The executable running on the remote side will be started with something like:
/path/to/APP configs/config.xml -v APP_id=12345 APP_port=2345 APP_priority=7
The exit status of this command is used to determine if the remote service is running or was successfully started or killed.
The problem I'm having is that when testing on my local machine, ssh connects to the local machine to make things easier, but pgrep called this way will also identify the ssh command that the server is running to do the check.
For example, pgrep may return:
26308 ./APP configs/config.xml APP_id=128bb8da-9a0b-474b-a0de-528c9edfc0a5 APP_nodeType=all APP_exportPort=6500 APP_clientPriority=11
27915 ssh -p 22 user#localhost pgrep -fl APP.*APP_id=128bb8da-9a0b-474b-a0de-528c9edfc0a5
So the logical next step was to change the pgrep pattern to exclude 'ssh', but this seems impossible because pgrep does not seem to be compiled with a PCRE version that allows lookaheads, for example:
bash -c -'ssh -p 22 user#localhost preg -fl "\(?!ssh\).*APP.*APP_id=12345"
This will throw a regex error, so as a workaround I was using grep:
bash -c 'ssh -p 22 user#host.domain.com pgrep -fl "APP.*APP_id=12345" \\| grep -v ssh'
This works well for querying with pgrep even though it's a workaround. However, the next step using pkill doesn't work because there's no opportunity for grep to be effective:
bash -c 'ssh -p 22 user#host.domain.com pkill -f "APP.*APP_id=12345"'
Doesn't work well because pkill also kills the ssh connection which causes the exit status to be bad. So, I'm back to modifying my pgrep/pkill pattern and not having much luck.
This environment can be simulated with something simple on a local machine that can ssh to itself without a password (in this case, APP would be 'watch'):
watch echo APP_id=12345
Here is the question simply put: How do I match 'APP' but not 'ssh user#host APP' in pgrep?
It's kind of a workaround, but does the job:
bash -c 'ssh -p 22 user#host.domain.com pgrep -fl "^[^\s]*APP.*APP_id=12345"'
...which only matches commands that have no space before the application name. This isn't entirely complete, because it's possible that the path to the executable may contain a directory with spaces, but without lookaround syntax I haven't thought of another way to make this work.
really old q but!
export VAR="agent.py"; pkill -f .*my$VAR;
I need to replace a string in a file on a remote server with this:
ssh username#${TARGETSERVER} -i /path/to/ssh-key perl -p -i -e "s#\$user = \'${SDBUSER}\'\;#\$user = \'${TDBUSER}\'\;#g" ${TARGETDIR}/configuration.php
That would replace the db user on a remote server in a joomla installation, btw.
If I execute that interactively on the remote server with all the variables filled, it IS working.
If I put the above line in a bash script, I get this message and no replacement takes place:
"Substitution pattern not terminated at -e line 1."
Any clue how I can make this work? I've already tried several escapes like \\' and so forth, but I didn't succeed.
Thanks in advance.
BINGO - Got it working:
ssh -T username#${TARGETSERVER} -i /path/to/ssh-key <<EOI
perl -p -i -e "s#\$user = \'${SDBUSER}\'\;#\$user = \'${TDBUSER}\'\;#g" ${TARGETDIR}/configuration.php
exit
EOI
From there, I could add several perl commands so I wouldn't have to have the payload of sshing in each time.
This question already has answers here:
Piping (or command chaining) with QProcess
(5 answers)
Closed 8 years ago.
I want to restart the computer by running a command in linux using QProcess. I have hard-coded my root password in my application.
When i run the following in a terminal it works perfect:
echo myPass | sudo -S shutdown -r now
When i put the command in a shell script and call it via QProcess it is also successful :
QProcess process;
process.startDetached("/bin/sh", QStringList()<< "myScript.sh");
But i can not run it by directly passing to QProcess:
process.startDetached("echo myPass | sudo -S shutdown -r now ");
It will just print myPass | sudo -S shutdown -r now
How is it possible to run such relatively complex commands directly using QProcess. (Not putting in a shell script).
The key methods that exist for this purpose established in QProcess:
void QProcess::setProcessChannelMode(ProcessChannelMode mode)
and
void QProcess::setStandardOutputProcess(QProcess * destination)
Therefore, the following code snippet would be the equivalence of command1 | command2 without limiting yourself to one interpreter or another:
QProcess process1
QProcess process2;
process1.setStandardOutputProcess(&process2);
process1.start("echo myPass");
process2.start("sudo -S shutdown -r now");
process2.setProcessChannelMode(QProcess::ForwardedChannels);
// Wait for it to start
if(!process1.waitForStarted())
return 0;
bool retval = false;
QByteArray buffer;
// To be fair: you only need to wait here for a bit with shutdown,
// but I will still leave the rest here for a generic solution
while ((retval = process2.waitForFinished()));
buffer.append(process2.readAll());
if (!retval) {
qDebug() << "Process 2 error:" << process2.errorString();
return 1;
}
You could drop the sudo -S part because you could run this small program as root, as well as setting up the rights. You could even set setuid or setcap for the shutdown program.
What we usually do when building commercial Linux systems is to have a minimal application that can get setuid or setcap for the activity it is trying to do, and then we call that explicitly with system(3) or QProcess on Linux. Basically,
I would write that small application to avoid giving full root access to the whole application, so to restrict the access right against malicious use as follows:
sudo chmod u+s /path/to/my/application
First, you could configure sudo to avoid asking you the password. For instance by being member of the sudo group and having the line
%sudo ALL=NOPASSWD: ALL
in your /etc/sudoers file. Of course not asking the password lowers the security of your system.
To answer your question about Qt, remember that bash(1), like all Posix shells, hence /bin/sh, accept the -c argument with a string (actually system(3) is forking a /bin/sh -c). So just execute
process.startDetached("/bin/sh", QStringList()<< "-c"
<< "echo myPass | sudo -S shutdown -r now");
As AntiClimacus answered, puting your root password inside an executable is a bad idea.
You must put your command in a shell script and execute sh or bash with QProcess with your shell script as argument, because your command contains |, which must be interpreted by sh or bash.
However, it's just my opinion, but: I don't think it is a good solution to do what you are doing, i.e. include your root password in an executable.
I have a extremely complicated shell script, within which it calls a C++ program I want to debug via GDB. It is extremely hard to separate this c++ program from the shell since it has a lot of branches and a lot of environmental variables setting.
Is there a way to invoke GDB on this shell script? Looks like gdb requires me to call on a C++ program directly.
In addition to options mentioned by #diverscuba23, you could do the following:
gdb --args bash <script>
(assuming it's a bash script. Else adapt accordingly)
There are two options that you can do:
Invoke GDB directly within the shell script. This would imply that you don't have standard in and standard out redirected.
Run the shell script and then attach the debugger to the already running C++ process like so: gdb progname 1234 where 1234 is the process ID of the running C++ process.
If you need to do things before the program starts running then option 1 would be the better choice, otherwise option 2 is the cleaner way.
Modify the c++ application to print its pid and sleep 30 seconds (perhaps based on environment or an argument). Attach to the running instance with gdb.
I would probably modify the script to always call gdb (and revert this later) or add an option to call gdb. This will almost always be the easiest solution.
The next easiest would be to temporarily move your executable and replace it with a shell script that runs gdb on the moved program. For example, in the directory containing your program:
$ mv program _program
$ (echo "#!/bin/sh"; echo "exec gdb $PWD/_program") > program
$ chmod +x program
Could you just temporarily add gdb to your script?
Although the answers given are valid, sometimes you don't have permissions to change the script to execute gdb or to modify the program to add additional output to attach through pid.
Luckily, there is yet another way through the power of bash
Use ps, grep and awk to pick-out the pid for you after its been executed. You can do this by either wrapping the other script with your own or by just executing a command yourself.
That command might look something like this:
process.sh
#!/usr/bin/env bash
#setup for this example
#this will execute vim (with cmdline options) as a child to bash
#we will attempt to attach to this process
vim ~/.vimrc
To get gdb to attach, we'd just need to execute the following:
gdb --pid $(ps -ef | grep -ve grep | grep vim | awk '{print $2}')
I use ps -ef here to list the processes and their arguments. Sometimes, you'll have multiple instances of a program running and need to further grep down to the one you want
the grep -ve grep is there because the f option to ps will include the next grep in its list. If you don't need the command arguments for additional filtering, don't include the -f option for ps and ignore this piece
grep vim is where we're finding our desired process. If you needed more filtering, you could just do something like grep -E "vim.*vimrc" and filter down to exactly the process that you're trying to attach to
awk '{print $2}' simply outputs just the process' pid to stdout. Use $1 if you're using ps -e instead of ps -ef
My normal setup is to run such script that starts my process in 1 tmux pane and having typed something similar to the above in a bottom pane. That way if I need to adjust the filtering (for whatever reason), I can do it pretty quickly.
Usually though, it will be the same for a specific instance and I want to just attach automatically after its been started. I'll do the following instead:
runGdb.py
#!/usr/bin/env bash
./process.sh &
PID=$(ps -ef | grep -ve grep | grep -E "vim.*vimrc" | awk '{print $2}')
#or
#PID=$(ps -e | grep vim | awk '{print $1}')
gdb --pid $PID
This assumes that the original process can be safely run in the background.