Quick question. I'm using rundeck 3.1.2-20190927 installed via the yum repo on Centos7/RHEL7.
I'm trying to generate the MD5 password using the command line but it looks like its only through the interactive prompts using the WAR file.
ie:
java -jar rundeck-3.1.2-20190927.war --encryptpwd Jetty
Is there a way I can feed it the username/password so I can grep out the MD5 hash instead of having to do this interactively? The documentation is a bit of a mess and I'm seeing references to jetty-all JAR being able to do this but that file isn't in the bootstrap directory, just the WAR.
You can use expect as inline script or "external" script to do that without any interaction
#!/usr/bin/expect
spawn java -jar rundeckpro-cluster-3.1.2-20190927.war --encryptpwd Jetty
expect -exact "Username (Optional, but necessary for Crypt encoding):"
send -- "user\r"
expect -exact "*Value To Encrypt (The text you want to encrypt):"
send -- "user\r"
expect eof
Related
I have a web page running on Apache which uses a matured set of Perl files for monitoring our workplace servers and applications. One of those tests goes through Cygwin´s SFTP, list files there and assess them.
The problem I have is with SFTP itself - when I run part of test either manually from cmd as D:\cygwin\bin\bash.exe -c "/usr/bin/sftp -oIdentityFile=[privateKeyPath] -oStrictHostKeyChecking=no -b /cygdrive/d/WD/temp/list_SFTP.sh [user]#[hostname]" or invoke the very same set of Perl files as web it works OK (returns list of files as it should). When exactly same code is run through web page it fails quick and does not tell anything. Only thing I have is error code 255 and "Connection closed". No error stream, no verbose output, nothing, no matter what way to capture any error I have used.
To cut long story short, the culprit was HOME path.
When run manually either directly from cmd or through Perl, the D:\cygwin\bin\bash.exe -c "env" would report HOME as HOME=/cygdrive/c/Users/[username]/ BUT this same command when run through web page reports HOME=/ i.e. root, apparently loosing the home somewhere along the path.
With this knowledge the solution is simple: prepend SFTP command with proper home path (e.g. D:\cygwin\bin\bash.exe -c "export HOME=/cygdrive/c/Users/%USERNAME%/ ; /usr/bin/sftp -oIdentityFile=[privateKeyPath] -oStrictHostKeyChecking=no -b /cygdrive/d/WD/temp/list_SFTP.sh [user]#[hostname]") and you are good to go.
I have some scripts that I run using jboss-cli -c --controller=... --file=myscript.cli.
The -c and --controller options are great, because my script does not know which server it should be run against and can be reused for multiple servers.
I now want to use the offline-cli feature to avoid port conflicts and prevent servers from beeing reachable through the network while they are beeing set up.
My issue is now that in order to start an embedded server I have to use the CLI-command embed-server, but I don't want to add that command to my scripts, because the scripts are not supposed to know the name of the server config xml file.
Unfortunately I can't use both --command="embed-server --server-config=my-standalone.xml" and --file=myscript.cli at the same time, because the CLI complains with:
Only one of '--file', '--commands' or '--command' can appear as the argument at a time.
Another thing I tried was: --commands="embed-server --server-config=my-standalone.xml,run-batch --file=\"myscript.cli\" but this does not work either, because my scripts contain some if-else logic, for instance:
if (outcome == success) of /subsystem=iiop-openjdk:read-resource()
/subsystem=iiop-openjdk:remove()
end-if
And unfortunately conditional logic is not supported in batch mode (see https://bugzilla.redhat.com/show_bug.cgi?id=1083176).
the simple way is to start your embedded server in your script :
embed-server --std-out=echo --server-config=standalone-full.xml
/subsystem=messaging-activemq/server=default/jms-queue=inQueue:add(durable=true, entries=["/queue/inQueue","java:jboss/exported/queue/inQueue"])
/subsystem=messaging-activemq/server=default/jms-queue=outQueue:add(durable=true, entries=["/queue/outQueue","java:jboss/exported/queue/outQueue"])
quit
Don't forget to quit at the end of your cli script :)
If you are using a Unix system you may try something like this:
(echo embed-server --std-out=echo --server-config=my-standalone.xml; cat myscript.cli) | jboss-cli.sh
I have the following excerpt from a perl script to automate an FTP session, I'm hoping someone can explain how it works.
system("rsh some_server ftp -in ftp.something.com << !
user anonymous someone\#somewhere.org
some ftp commands
bye");
The background. This perl script runs on a Linux machine, it remotes into a Solaris machine. The FTP session must be executed from the Solaris machine because the FTP site performs IP address checking.
Formerly this script ran on the Solaris machine directly (i.e. it didn't use rsh) I hacked it around and came up with this which seems to work. However I have little idea how, in particular I don't understand the << ! bit at the end of the first line. It looks a little like a here-document but I'm not really sure.
Any explanations welcome.
You are right, << is a heredoc, which is made clear by the following warning (which I get when I take out the rsh command):
sh: line 2: warning: here-document at line 0 delimited by end-of-file (wanted `!')
The construct
<< HEREDOC
reads as standard input everything from HEREDOC up to a line containing only HEREDOC or up to an end-of-file character. When you put this after a command, it is equivalent to
command < file
where file contains the text in the heredoc. In your case, instead of HEREDOC the delimiter is !, so the ! is not passed to ftp but everything after ! is. This is equivalent to
$ cat file
user anonymous someone\#somewhere.org
some ftp commands
bye
$ ftp -in ftp.something.com < file
rsh takes that entire command and runs it on your remote host.
As illustrated by user1146334's answer, this command does not act on the principal of least surprise. At the very least, make it less confusing by changing it to
system("rsh some_server ftp -in ftp.something.com << HEREDOC
user anonymous someone\#somewhere.org
some ftp commands
bye
HEREDOC");
Or even better, as mpapec mentioned in the comments, use Net::FTP and Net::SSH2.
Did you look at the man page?
-i Turns off interactive prompting during multiple file transfers.
-n Restrains ftp from attempting “auto-login” upon initial connection. If auto-login is enabled, ftp will check the .netrc (see netrc(5)) file in the user's
home directory for an entry describing an account on the remote machine. If no entry exists, ftp will prompt for the remote machine login name (default is
the user identity on the local machine), and, if necessary, prompt for a password and an account with which to login.
The client host and an optional port number with which ftp is to communicate may be specified on the command line. If this is done, ftp will immediately attempt
to establish a connection to an FTP server on that host; otherwise, ftp will enter its command interpreter and await instructions from the user. When ftp is
awaiting commands from the user the prompt ‘ftp>’ is provided to the user. The following commands are recognized by ftp:
! [command [args]]
Invoke an interactive shell on the local machine. If there are arguments, the first is taken to be a command to execute directly, with the rest of
the arguments as its arguments.
So essentially you're ftp'ing in and providing a new command per line in-line instead of from a file.
I am using a Windows System Command Prompt to call on a Perl Script. At one point and time, the Perl Script calls on svn+ssh to update a repo. The repository that is called asks the for user input - specifically a password.
I am trying to automate the execution of the Perl Script, but it continually gets hung up on the call to svn. I have tried many forms of input redirection (specifically < with an external file, | with cat, and the windows power shell use of the # symbol to specify a multi-lined string). Is there a way to input a password for this Perl script?
For purposes of this problem, I do not have access to the Perl Script and I will need to implement a work around.
You don't mention the svn+ssh implementation the script uses, but my guess is that the problem is this:
SSH clients tend to ask for passwords directly from the terminal. Password prompts often don't read from stdin, so you can't redirect input. For example, the OpenSSH client does it that way. It is designed that way to prevent users from doing insecure things - like storing passwords in files, environment variables or shell variables.
The common recommandation in this situation is to use public key authentication.
Without knowing your script, it will not be possible to come up with a workaround I think.
Is it possible to have a Perl script run shell aliases? I am running into a situation where we've got a Perl module I don't have access to modify and one of the things it does is logs into multiple servers via SSH to run some commands remotely. Sadly some of the systems (which I also don't have access to modify) have a buggy SSH server that will disconnect as soon as my system tries to send an SSH public key. I have the SSH agent running because I need it to connect to some other servers.
My initial solution was to set up an alias to set ssh to ssh -o PubkeyAuthentication=no, but Perl runs the ssh binary it finds in the PATH instead of trying to use the alias.
It looks like the only solutions are disable the SSH agent while I am connecting to the problem servers or override the Perl module that does the actual connection.
Perhaps you could put a command called ssh in PATH ahead of the ssh which runs ssh as you want it to be run.
Alter the PATH before you run the perl script, or use this in your .ssh/config
Host *
PubkeyAuthentication no
Why don't you skip the alias and just create a shell script called ssh in a directory somewhere, then change the path to put that directory before the one containing the real ssh?
I had to do this recently with iostat because the new version output a different format that a third-party product couldn't handle (it scanned the output to generate a report).
I just created an iostat shell script which called the real iostat (with hardcoded path, but you could be more sophisticated), passing the output through an awk script to massage it into the original format. Then, I changed the path for the third-party program and it started working fine.
You could declare a function in .bashrc (or .profile or whatever) with that name. It could look like this (might break):
function ssh {
/usr/bin/ssh -o PubkeyAuthentication=no "$#"
}
But using a config file might be the best solution in your case.