I've been trying to figure out how to work the command lines for a GPA task that I want to automate. Currently, I just use GPA for Windows, select the key, select the file, check off "Armor", and click GO. There must be some command line interface for this. I'd like to work that into an automation program to eliminate the manual work.
Any ideas?
Use both the --encrypt and --sign operations at the same time, eg.
gpg --armor --recipient a4ff2279 --sign --encrypt <input
Adjust the input pipe as needed, and on Windows systems you might need to use gpg.exe instead (and make sure GnuPG is in your path variable).
Related
I need to write a Linux shell script that looks something like this -- it will be executed by a job-scheduling tool where ordinary end users can configure $1 and $2:
SERVER=$1
OPTIONS=$2
ssh -t remote_user_name#$SERVER 'ksh -lc "remote_command_name $OPTIONS"'
Looking here, I can see that I need to be careful how I write this to avoid "injection" issues.
(Not to mention, being inside single quotes, I don't actually have $OPTIONS interpolating at this point.)
In my case, acceptable options for remote_command_name are things like:
--help
config_file_path_to_run_against
--verbose config_file_path_to_run_against
I'm not really a Linux person -- how would I get $OPTIONS interpolating and, to the extent possible, minimize "injection" vulnerabilities? (Note that the scheduling tool's configuration panel is already behind a login-wall that, if breached, probably means someone is already running amok. But to the extent possible, I'd like to avoid being the person who wrote something new for the scheduling tool that turns a phished user account into a lever to elevated wild privileges on the machines it schedules or that provides a handy privilege elevation lever for a malicious end user.)
FWIW, it looks like the shell of choice on both machines defaults to ksh.
Okay, so far, I've gotten this far -- interpolation is now working.
Is it ... safe-ish?
SERVER=$1
OPTIONS=$2
REMOTE_COMMAND_DBL_QUOT="\"remote_command_name $OPTIONS\""
LOCAL_COMMAND="ksh -lc $REMOTE_COMMAND_DBL_QUOT"
ssh -t remote_user_name#$SERVER $LOCAL_COMMAND
I have a Bourne-Again shell script text executable named engine.bin that I want to install.
If I install the executable manually ./engine.bin I get a screen with the EULA I have to accept (by pushing space), then accept it by writing yes and then enter the installation path by typing /usr/local/engine.
Now I want to do the installation automatically through provisioning scripts without manual interaction. Is there a way to do this? I do not know if the installer accepts any parameters, unfortunately the thing is undocumented.
Based on the suggestion of bill-agee and jgr208 I wrote the following which is working for me:
#!/usr/bin/expect -f
set timeout -1
spawn /tmp/engine.bin
expect {
-gl "*Press SPACE or PAGE DOWN key to continue, U or PAGE UP key to scroll back*" { send -- " "; exp_continue }
-gl "*yes/no*"
}
send -- "yes\r"
expect -gl "*press ENTER to accept the default*"
send -- "/tmp/tce\r"
expect eof
If the executable allows you to spam input at it without waiting for each separate prompt to appear, you might be able to accomplish this with bash.
For example, this script will run program_that_takes_several_lines_of_input.py and send it four lines of input - three with text and one blank line:
#!/bin/bash -eux
./program_that_takes_several_lines_of_input.py <<EOD
first line
one enter keypress later
yet another line of input after the empty line above
EOD
If you need to stop and wait for each prompt to appear, the cram Python package may be a good fit for this scenario - I find it useful for tasks like this where you only need to send a few lines of input, but each line of input is different.
See:
https://bitheap.org/cram/
https://pypi.python.org/pypi/cram
Expect would also work, but I find that I reach working solutions a bit faster when using cram than with Expect.
pexpect is a great choice as well! See:
https://pexpect.readthedocs.org/en/stable/
EDIT: I'm re-writing this because the first time was a bit unclear.
Let's say I have a program (an executable) such that when I run it, it prompts me to enter an input.
For example, I execute ./myProgram
and the program prompts: Please enter your username:
Here, I would type in my username.
Now, how would I write a bash script so that after I start the above program, I can enter inputs to it?
Something along the lines of this:
#!/bin/bash
path/to/myProgram
# And here I would enter the commands, such as providing my username
Thanks
reading values interactively is rather uncommon in *nix scripts, and is frowned upon by those who want to do exactly what you're trying to do. The standard way of doing this would be changing myProgram to accept arguments. At that point it's trivial to do this.
If you really need to use this pattern you need to use some tool like expect, as pointed out by #EricRenouf.
If myProgram reads from standard input, you can use a here-document:
path/to/myProgram <<\END
username
more input if needed
END
On CentOS 6 we currently encrypt the grub password using the password --md5 option and we are able to script this into our standard server build.
We are busy migrating to CentOS 7 and it appears that the password --md5 option has been removed in grub2 and replaced with grub2-mkpasswd-pbkdf2.
Although I welcome the improved security, I can't find a way to pass a password to the grub2-mkpasswd-pbkdf2 command via standard input, and it appears that grub2 has removed support for md5, the combination of which breaks our script building automation.
Can anyone possibly help with:
A way to pass a password to grub2-mkpasswd-pbkdf2 via standard input?; or
An alternative pbkdf2 generation utility to grub2-mkpasswd-pbkdf2 that accepts standard input?; or
A mechanism for using --md5 with grub2?
grub-mkpassswd-pbkdf2 takes the password (twice) from stdin.
If your password is in $passwd:
passwd="my test password"
You can get the hash with: (Using bash as your shell)
echo -e "$passwd\n$passwd" | LC_ALL=C /usr/bin/grub-mkpasswd-pbkdf2 | awk '/hash of / {print $NF}'
The AWK prints the last field of the line matching the given pattern, which is the hash. The locale is forced to the default one (C), in case the message is translated in other locales.
I recently wrote a tool to do just this -- namely, to be able to more easily generate GRUB2 hashes non-interactively, and to be able to do so on RHEL6. It's on GitHub.
burg2-mkpasswd-pbkdf2: Non-interactively generate GRUB2-compatible PBKDF2 hashes from the cmdline with python
In the readme you'll also see explanation of how to use the standard grub2-mkpasswd-pbkdf2 to generate hashes non-interactively by piping the password twice with newline.
I use some minor scripts at work under cygwin, and I would like to make them available to workmates with a familiar Windows icon. For instance, suppose I have the following:
cat *tsv | sort > combined_n_sorted.txt
Is there a simple way to make a corresponding icon, assuming cygwin is installed in my workmates' systems? These scripts may involve (cygwin's) python.
Thanks!
It seems that your question has two parts:
How to make scripts accessible on users' desktops.
How to give the each script a particular icon.
For (1), you could create a shortcut on the users' desktops that runs the following command:
C:\cygwin\bin\bash.exe -c 'cat *tsv | sort > combined_n_sorted.txt'
or if the commands are stored in a script,
C:\cygwin\bin\bash.exe -c /path/to/script
If you want to hide the console window from appearing while the script runs, you could use the run command (in the run package), e.g.:
C:\cygwin\bin\run.exe /bin/bash -c 'cat *tsv | sort > combined_n_sorted.txt'
# or
C:\cygwin\bin\run.exe /path/to/script
But it might be better for users to see the console window, so they know the script is running.
For (2), you can change each shortcut's icon individually by right-clicking on it and choosing Properties, but AFAIK that's a one-host-at-a-time change. I don't know of any batch way to do it, although no doubt there's a registry key you can set. Or, if you change the icon of the shortcut on your host and then distribute that shortcut, it might keep the same icon on other users' desktops, if the icon is a standard one that exists on their hosts.