Andrew Wippler's Sketchpad - Terminal

Easy unix epoch timestamps from CLI

2016-12-23T14:00:27+00:00

While working on various projects and ultimately the need for a Unix timestamp for expiring swift objects in OpenStack, I needed a quick way to convert past, present, and future timestamps to the Unix epoch. Traditionally, I went to google, searched for a Unix timestamp converter, and retrieved my seconds that way. Unfortunately in exams, you are not allowed to visit external websites.</p>

If you know how to read documentation, you will already know that the date</code> command has this feature already built in. An excerpt from the docs is as follows:</p>

 ...
</span>       Show the local time for 9AM next Friday on the west coast of the US
</span>
</span>              $ date --date='TZ="America/Los_Angeles" 09:00 next Fri'
</span>
</span>DATE STRING
</span>       The  --date=STRING  is  a mostly free format human readable date string
</span>       such as "Sun, 29 Feb 2004 16:21:42 -0800" or "2004-02-29  16:21:42"  or
</span>       even  "next Thursday".  A date string may contain items indicating cal‐
</span>       endar date, time of day, time zone, day of week, relative  time,  rela‐
</span>       tive date, and numbers.  An empty string indicates the beginning of the
</span>       day.  The date string format is more complex than is easily  documented
</span>       here but is fully described in the info documentation.
</span>...
</span></code></pre>
Further reading of the docs will point you in specifically formatting a return string by doing a date +%s</code>. So when the time comes to expire an object from swift at 17:00 next Friday, you can do something like:</p>
swift post container file -H 'X-Delete-On: </code>date +%s --date="17:00 next Friday"'</code></p>



Expect with expect
2015-08-30T22:41:50+00:00
Wouldn't it be nice to program a script that expects a certain line of text then sends a predetermined string? How about copy your ssh id to 40 different RPi units without typing the command for every one? Expect is that sort of program we all have been dreaming about. Just look at this script:</p>
#!/usr/bin/expect -f
</span>
</span>set timeout 3
</span>set serv [lindex $argv 0];
</span>
</span>spawn ssh-copy-id pi@$serv
</span>sleep 4
</span>expect "Are you sure you want to continue connecting (yes/no)?"
</span>send "yes\r"
</span>expect "pi@{$serv}'s password: "
</span>send "p@ssw0rd\r"
</span>interact
</span></code></pre>
When this block of code is saved as copy_pi.sh</code> and invoked as ./copy_pi.sh 192.168.1.42</code>, it will attemp to connect as the pi user, copy the current public key, say yes to the prompt, send the password (provided it is escaped properly), and drop you into the process you spawned.</p>
Now, let's look at the script in more detail as to what expect has to offer.</p>
#!/usr/bin/expect -f
</span></code></pre>
This line has to be the absolute path of expect with the -f</code> switch. This is to tell the program that it is being passed a file with a list of commands. On Debian/Fedora, this path is where expect</code> is located. On other systems, you will need to run which expect</code> to find the absolute location.</p>
set timeout 3
</span>set serv [lindex $argv 0];
</span></code></pre>
The first line tells expect</code> to wait up to 3 seconds for a new line before it times out. The second line is grabbing the variable being passed into this script. Normally, one would think arg 0 would be the name of the program (i.e. copy_pi.sh</code>); however, expect</code> captures the variables into $argv</code> ($argc</code> is the length of the variables).You can also specify a range of variables into one: set range [lrange $argv 0 2];</code></p>
spawn ssh-copy-id pi@$serv
</span>sleep 4
</span></code></pre>
This is we are initializing the process of copying our ssh key to $serv</code>.
This is the part we would normally be typing ourselves. sleep 4</code> tells expect to wait 4 seconds before continuing.</p>
expect "Are you sure you want to continue connecting (yes/no)?"
</span>send "yes\r"
</span>expect "pi@{$serv}'s password: "
</span>send "p@ssw0rd\r"
</span>interact
</span></code></pre>
The expect</code> line could either be regex or what will be exactly shown. Since I know exactly what will appear in the process, I have chosen to go that route. The send</code> command is transmitting the text into the spawned program. Special characters such as & need to be escaped with a backslash. The \r</code> simulates a carriage return (enter key). Since the ssh-copy-id</code> is completed by the time interact</code> is called, you will not be in the remote pi's shell. I have sometimes found it necessary to include interact</code> so that the password is actually sent.</p>
expect</code> is a great tool that uses TCL syntax. expect</code> has prooved useful to me many times over - especially when I had to re-key my puppet deployment after Heartbleed.</p>


Send Aliases over SSH connections
2015-07-18T22:12:35+00:00
Bash reads aliases from a file only; however, this file does not have to reside on the server you are connecting to. With OpenSSH, we have to ability to send environment variables that the server allows.</p>
On Debian/Ubuntu systems, the default accept environment variables are:
</span># Allow client to pass locale environment variables
</span>AcceptEnv LANG LC_*
</span>
</span>On CentOS/Fedora systems, the default accept environment variables are:
</span># Accept locale-related environment variables
</span>AcceptEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES
</span>AcceptEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT
</span>AcceptEnv LC_IDENTIFICATION LC_ALL LANGUAGE
</span>AcceptEnv XMODIFIERS
</span>
</span></code></pre>
If you remote into a mixed environment of servers - whether they be Debian, Ubuntu, or CentOS, you will need to find a common AcceptEnv</code> variable. Since Debian and Ubuntu allow LC_* (everything with the prefix LC_), we are limited to forwarding our aliases over one of CentOS's variables. For me, it was easy to decide on a variable to overwrite - LC_PAPER</code>. I hardly print anything and I especially do not print on remote servers.</p>
In order to send your aliases into a remote server, you have to set up your environment first.</p>
In ~/.ssh/config</code>, you need a line that sends the environment variable of your choice. These two lines denote that for every host, we will send the environment variable.</p>
Host *
</span>     SendEnv LC_PAPER
</span>
</span></code></pre>
Next, we will have to set an alias file we want to transfer. For my test, I create ~/.bash_aliases_xfer</code> and had the contents of:</p>
# .bash_aliases_xfer
</span># Source global definitions
</span>if [ -f /etc/bashrc ]; then
</span>    . /etc/bashrc
</span>fi
</span>alias lollypop="echo lollypop"
</span>alias lolp="lollypop"
</span>#My servers display useful information in the motd.
</span>[ ! -z "$TERM" -a -r /etc/motd ] && cat /etc/motd
</span>
</span></code></pre>
Next, we have to craft our ssh command:</p>
LC_PAPER=$(cat ~/.bash_aliases_xfer; exec 3<&-) \
</span>ssh -t user@remote \
</span>    'exec bash --rcfile /dev/fd/3 3< <(printf %s "$LC_PAPER")'
</span>
</span></code></pre>
The first line defines the environment variable - an output of our local file and places that information in file descriptor 3. The second line is where we actually connect to the server. The third line is the command executed on the remote server: cleanly print the contents of our environment variable, put that information in file descriptor 3, and reload bash with that file as the only configuration file.</p>
To make the process easier, I have place the following function in my .bashrc. Since the function has $@ variable, I can use it as a replacement to ssh and I can pass any needed ssh switches to my new function.</p>
function ssha() {
</span>LC_BASHRC=$(cat ~/.bash_aliases_xfer; exec 3<&-) ssh -t "$@" 'exec bash --rcfile /dev/fd/3 3< <(printf %s "$LC_BASHRC")';
</span>}
</span>
</span></code></pre>
After I reload my bashrc ( source ~/.bashrc</code> ), I can then pass my aliases into my new ssh session: ssha user@remote -i ~/.ssh/remote_id -X</code>.</p>