placeonthe.net

A site to share technological guides, news and scripts

add emojis to nginx HTTP headers

by

The other day while perusing Twitter, I came across a Tweet mentioning icanhazip.com, a site I regularly use to confirm either my IPv4 or IPv6 public IP address.

The site is run by Major Hayden who I also happen to follow on Twitter. The combination of the two yielded me coming across the following tweet by @elenalindq in my feed about a Duck emoji in the header of the site:

curl -IL https://icanhazip.com
HTTP/2 200
server: nginx
date: Tue, 15 Sep 2020 03:32:56 GMT
content-type: text/plain; charset=UTF-8
content-length: 13
access-control-allow-origin: *
access-control-allow-methods: GET
x-rtfm: Learn about this site at http://bit.ly/icanhazip-faq and do not abuse the service.
x-node: icanhazip-dfw-1
x-donation: This site is expensive to run. You can donate BTC to 3LSp89k9qnMJBpV7AUNF3M2Eo1vatpkYpm
x-duck: 🦆

That lead me to locate other Tweets and posts about using emoji’s in NGINX headers, or HTTP headers as a whole. Some further digging is showing that as long as the UTC-8 character set is enabled on the server, the use of emoji’s within the NGINX configuration file should work.

I went on to test various emoji setups out by setting various headers within placeonthe.net’s configuration file. While trying out different emoji’s, I did note that using the actual unicode for the emoji did not render correctly.

I eventually found an NGINX article covering the use of emoji’s within the NGINX configuration file at Introducing Full Emoji Support in NGINX and NGINX Plus Configuration. The article indicated just copying the emoji in to the configuration file will allow it to be used in even more ways than just returning a header.

I eventually found a good list of emoji’s to test within the configuration file and how they would look when being viewed via cURL in this case.. I eventually settled on the glorious donut: 🍩 

curl -IL https://placeonthe.net
HTTP/2 200
date: Tue, 15 Sep 2020 03:49:38 GMT
content-type: text/html; charset=UTF-8
set-cookie: __cfduid=d793486fe2bfb7cdbbfdb49f9b449b6541600141777; expires=Thu, 15-Oct-20 03:49:37 GMT; path=/; domain=.placeonthe.net; HttpOnly; SameSite=Lax
vary: Accept-Encoding
vary: Accept-Encoding
set-cookie: wp_visit_time_test=deleted; expires=Thu, 01-Jan-1970 00:00:01 GMT; Max-Age=0
link: <https://placeonthe.net/wp-json/>; rel="https://api.w.org/"
x-powered-by: WP Engine
x-cacheable: SHORT
vary: Accept-Encoding,Cookie
cache-control: max-age=600, must-revalidate
x-cache: MISS
x-cache-group: normal
x-xss-protection: 1; mode=block
x-content-type-options: nosniff
x-frame-options: SAMEORIGIN
x-donut: : 🍩
cf-cache-status: DYNAMIC
cf-request-id: 05317af42a0000bb1600ae9200000001
expect-ct: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"
server: cloudflare
cf-ray: 5d2f61004a11bb16-SEA

So far I have tested this on Ubuntu, OSX and OpenBSD using iTerm2 without issues and using Chrome’s Dev Tools to view headers too. I was able to open the NGINX configuration file using vim and the emoji was present. Parsing the configuration file also did not return any errors!

In order to set the actual header in the configuration file I merely applied the following header:

add_header X-Donut: "🍩";

I have found a few interesting examples online of using the headers more as comical representations than for anything beyond that, but it’s certainly a quirky feature. Definitely an interesting concept I will continue to explore.

happy 1999

by

So, happy 1999 everyone (date +%y%-m%-d)! I’ve been looking forward to posting an article on this day since last week and after some thinking, decided on a topic. I’ll cover some of the thought processes and resources that went in to my latest script: wpchg.

This script came about while studying for my RHCSA certificate. If you happened to leave your computer unlocked, you were likely to return to a changed desktop background. Time was limited when a) trying to find a wallpaper b) subsequently setting the wallpaper – therefore I wanted to see if I am able to automate the process with a shell script.

With RedHat Enterprise Linux 7, our desktop environment is managed by Gnome, therefore I set out to research a way to change the desktop background via the CLI. It didn’t take long before I found this article on Ask Ubuntu.

The link was very useful in getting the syntax for using the CLI with gsettings to achieve this. I started experimenting with using different file names, having image extensions (.jpg, .png, etc) with the image and seeing if I could change the path of the image from the home directory of the user to say /tmp.

From these initial tests I was able to figure out that the image didn’t need an extension, however it needed to be within the home directory of the user, else it wouldn’t set as a background.

My initial idea was to write a script, which would be a few lines, using wget and gsettings, I would download an image and set it. But this still meant I would have to download the script from a source, ensure that it was executable and run it. The script could then delete itself. Stack Overflow came to the rescue with an article that covered a self deleting script.

Now that the bare bones of the script were done, I began to think what else could I do to elevate the script and improve my scripting skills at the same time. I decided I would add a check to the script, that would ensure the image was still set as a background. While working on another script, I had plenty of experience using loops and if statements to check if files existed and utilizing crontabs.

I wanted to implement my knowledge of these into the script and set about using an infinite while loop, that would run in the background, constantly checking if certain conditions are met.

The conditions I wanted to check for were a) whether a crontab was present to set the background at a certain time b) whether the file that will run the gsettings command is present.

I began experimenting with the while loop until I got it working the way I had wanted it to. After some changes with using variables, file names, settings for sleep, I managed to run it in the background with it working away for five days without a hitch.

I decided on using here documents in order to create the additional scripts that will run in the background. After some more digging I figured out how I could execute the scripts the main script created from within the script. The here document took some experimentation in getting variables to copy over, but a quick search found the solution – the variables had to be escaped, otherwise they would be expanded when being copied.

The final bit I wanted it achieve was for the script to clean up after itself, removing the last few lines of the .bash_history file, so as to reduce the likelihood of detection. I achieved this by closing the terminal session to commit the temporary history to the file, and using the head command to pipe the filtered section to a temp file and overwrite the original.

The script would then remove any additional log files and delete itself. To achieve the ability for it to keep running even after the terminal session was closed, I utilized nohup.

Edit: after coming in this morning with the script running all night, I was expecting my desktop background to have been changed. However, this was not the case and I began troubleshooting. The first thing I checked was /var/mail/user which gave me my first clue:

Date: Tue, 10 Sep 2019 02:00:01 -0500 (CDT) /bin/sh: ./tmp/.uwpc.bak: No such file or directory

I noticed that I have made a typo in the script, adding a period before the file path. This meant the location could not be executed. I edited the crontab to remove that and altered the time to run every minute but again no change. I went back to /var/mail/user to see what was happening now. I was getting the following error message now:

(process:29203): dconf-WARNING **: 08:41:01.857: failed to commit changes to dconf: Cannot autolaunch D-Bus without X11 $DISPLAY

This told me immediately that there was an issue with X11, which is the X Window System. I copy and pasted that error message to Google and after some searching around I found the issue. When I was running the gsettings command from within a Terminal, the Terminal loads a variety of environment variables. which are not loaded in cron as it is a system process.

I began searching for a solution for this, which landed me on Stack Overflow again – that was extremely helpful in identifying the issue and providing a solution. After editing the shell script to be run, I went back to the crontab to test it out again. This time, it work! My desktop background changed. This is something that I will have to fix on GitHub for the script.

Summary of skills I’ve learnt while writing this script:

  • Troubleshooting – checking different functions of a script, checking log files, output and debugging issues
  • Researching – reading manpages and utilizing web resources to gather information and examples
  • Using here documents to create scripts from within a script
  • Using gsetting to alter Gnome from the CLI
  • Working with variables when using the here document and redirecting output of applications
  • Improved commenting within the shell script along with documenting through process along the way
  • Utilizing nohup to allow for a script to run in the background even after a terminal session is terminated
  • Version control via GitHub
  • Improved utilization and troubleshooting of crontab
  • File processing using head and piping / moving results to save edits

ssh with X window

by Leave a Comment

I recently found a very useful trick for when I need to run a GUI application, however the device that I would like to run it on, my connection is through SSH.

X11 has to be working on the device for this to work in the first place for it to run. I have tried this method with a number of GUI applications including configuring authentication procedures (LDAP) or Firefox.

I find this a much better and faster process than having to open up VirtualBox to use a GUI application.

To enable the X11 daemon through ssh, run the SSH client with the following flag:

$ ssh -X [email protected]

This will enable you to use and open GUI applications during your session. However a trick I found is putting the actual process in to the background. This means you get your cursor back and you’re able to run further commands while working on the GUI window:

<[email protected]> $ Firefox

The above command will open up Firefox while sending the job in to the background allowing you to carry on work on the machine without having to create new sessions.

You may want to carry on using the terminal session you have logged in while using the GUI application. By sending the process to the background, the cursor is available to utilize. The process can be sent to the background by adding a & to the end of it the line.

<[email protected]> $ Firefox &amp;

Below is an example of a Firefox window opened during a remote SSH session:

n.b. because the Firefox process has been sent to the background, even when the GUI Firefox window is closed, the process hangs in the background. This may cause issues when trying to close the shell session, having the shell hang until the process is stopped using ctrl+c.

change default shell to bash

by Leave a Comment

I recently acquired a shell account on a NetBSD box, where the default shell that came with the account happened to be the zsh. I personally prefer bash and set out to change to it accordingly. This short guide will give some information about changing the default shell:

The /etc/passwd file contains user credentials separated by colons (:). The following is an example of a line found within /etc/passwd:

jdoe:*:202:1:John Doe:/home/jdoe:/usr/bin/ksh

The above can be broken down as follows:

  • Username: jdoe
  • Encrypted password is signified by a *
  • User ID (UID): 202
  • Group ID (GID): 1
  • Full name of the user: John Doe
  • User home directory: /home/jdoe
  • Default shell: ksh

As you can tell in the above example, the default shell is set to /usr/bin/ksh. There are a number of ways that this can be changed. The first thing to do is find out what available shells are present on your system. This can be accomplished by checking the /etc/shells file.

bash is already installed on this system and is available to choose. Checking the /etc/shells file will also list the absolute path. Another way to check if bash is installed is by running the which command: $ which bash If the application we are checking is installed, it will return to absolute path for it.

Now that we’ve determined that bash is installed, we can go ahead and change our default shell to it. The first option to do this is utilizing the usermod utility. This edits the user’s details within the /etc/passwd file. Utilizing the -s or –shell option will edit the user’s default shell. The following example will edit the /etc/passwd file and replace the default shell to bash, defining the path we saw earlier, for the user jdoe. The absolute path has to be defined for the shell:

$ usermod -s /usr/pkg/bin/bash jdoe

The next option is using the chsh utility – which is short for change shell – which works much the same way as the usermod utility and uses -s and –shell options:

$ chsh -s /usr/pkg/bin/bash jdoe

The last option you have is to manually edit the /etc/passwd file. You will need to have superuser permissions.

To verify that these changes have taken affect, you can look for the user within the /etc/passwd file and check what default shell is assigned. You can use grep to search for the username:

$ grep jdoe /etc/passwod
jdoe:*:202:1:John Doe:/home/jdoe:/usr/pkg/bin/bash

As you can see, we have verified that the default shall has been changed for user jdoe.

rand_ip.sh

by

rand_ip.sh is a simple bash script to generate random IP addresses with a random CIDR subnet mask. The CIDR mask is in the range of 15-30. This can generate a large number of random IP addresses to use with subnet exercises. The following picture is a sample output:

$ rand_ip -h rand_ip [-h | --help] [-n | --number #]
$ rand_ip -n 10 51.146.20.194/29 114.175.20.57/23 179.212.3.34/16 252.232.99.109/27 51.109.37.57/29 219.84.104.244/30 231.188.155.203/16 114.19.233.251/21 237.135.144.45/26 132.83.57.211/15

Currently the IP addresses generated will be picked from all classes and both public and private ranges. I am looking to add additional features to the script including the ability to pick which class to use. In the mean time the following is the source code if anyone wishes to try it:

#!/bin/bash
# Random IP and CIDR subnet mask generator
# v1.1 07/28/19 am401

usage () {
echo "rand_ip [-h | --help] [-n | --number #]"
}

case $1 in
           -n | --number )
                for i in $(eval echo {1..$2}); do
                  subnetmask=$((RANDOM%16+15))
                  ip=$(printf "%d.%d.%d.%d" "$((RANDOM % 256))" \
                     "$((RANDOM % 256))" "$((RANDOM % 256))" \
                     "$((RANDOM % 256))")
                  echo $ip"/"$subnetmask
                done
                ;;
            -h | --help ) usage
                ;;
             * ) usage
                ;;
esac