Use Python to format JSON

Easier way to format JSON instead of JSONLINT

With Python 2.6+ you can just do:
echo '{"foo": "lorem", "bar": "ipsum"}' | python -mjson.tool

Citrix Receiver in Ubuntu

Download the receiver from the Citrix site:
http://www.citrix.com/downloads/citrix-receiver/linux/receiver-for-linux-130.html

So, you've upgraded Firefox on Ubuntu and Citrix no longer works, well do the following:

  • uninstall Firefox
  • install Firefox
  • $ sudo rm -rf /opt/Citrix/ICAClient/keystore/cacerts_old
  • reinstalled Citrix
  • redo the Citrix installation steps below
  • When you launch Citrix, make sure you ALLOW pop-ups, if asked!

Here are the steps to install Citrix for the first time:
For Ubuntu you will need to download the *.deb version and install through the software center

Now you need to get the certs to work properly in Firefox:
Refer: https://www.geekpete.com/blog/ssl-error-61-using-citrix-ica-client-on-linux/

You are going to copy the certs and create a symbolic link for all of the certs then:
$ sudo mv /opt/Citrix/ICAClient/keystore/cacerts /opt/Citrix/ICAClient/keystore/cacerts_old
$ sudo cp /opt/Citrix/ICAClient/keystore/cacerts_old/* /usr/share/ca-certificates/mozilla/
$ sudo ln -s /usr/share/ca-certificates/mozilla /opt/Citrix/ICAClient/keystore/cacerts

Using Expect Scripts to Automate Tasks (Macros)

Sample Script: sample.exp (You can run this in Ubuntu)

How to run scripts:
expect -f your-file-name.exp

Refer for possible extra goodies: http://www.thegeekstuff.com/2010/12/5-expect-script-command-line-argument-examples/

Ubuntu Installation:
$ sudo apt-get install expect
$ sudo apt-get install expect-dev

Refer: http://www.admin-magazine.com/Articles/Automating-with-Expect-Scripts

Expect is a natural and intuitive automation scripting language that operates in much the same way humans do when interacting with a system. You type in commands and expect a certain response to your command. When you receive the expected response, you enter another command and so on. Expect works in the same way, except you have to provide the script with commands and expected responses to those commands. Basically, you have to script out the entire two-way “conversation.”

You can think of an Expect script as a dialog script written for two actors: a sender and a receiver. One of the more popular activities to automate is an SSH session between two hosts, in which one host is the sender (local host) and the other is the receiver (remote host). Being able to emulate every keystroke and create a true interactive session between two systems via a script is an exciting proposition.

Expect Setup

Most Linux distributions include Expect as part of the available and installable software packages. In other words, you won’t have to download and install from source code. Use your system’s package manager to download and install Expect and any required dependencies or associated packages. For example:
$ sudo yum install expect
or
$ sudo apt-get install expect
Once you have Expect installed, you can begin writing scripts.

Creating an Interactive SSH Session

As stated previously, you must provide both sides of the conversation in your script because you’re setting up an interactive system. Look at a few essential items before diving right into a script.

To make an Expect script executable as a standalone program, you must do two things: Make the script executable, and supply the path to the script for expect . The path on my system is: /usr/bin/expect ; therefore, enter that path on the first line of your script with a preceding “shebang” (#! ):

!/usr/bin/expect -f

The -f switch tells Expect that it is reading commands from a file. The spawn command spawns or launches an external command for you. In this case, ssh to a remote host (aspen ):
spawn ssh aspen

Change the host aspen to your remote host. When you SSH to a remote system, you’re prompted for a password. This password prompt is what you “expect” from the remote system; therefore, you enter that expected response:
expect "password: "

From the local side, you have to enter your password at the password prompt. To send anything to the remote system, it must be included in double quotes and must include a hard return (\r ). Change PASSWORD to your password:

send "PASSWORD\r"
Again, you have to enter the expected response from the remote system, which in this case is a user prompt ($ ).

expect "$ "

Now that you’re logged in to the remote system, you can begin your interactive session on that remote host. The following send command issues the ps -ef |grep apache command:
send "ps -ef |grep apache\r"

Output will appear as STDOUT. After the command has executed, you’re returned to a prompt, so tell the Expect script that bit of information:
expect "$ "

Finally, send the exit command to the remote system to log out. Don’t forget that hard return (\r ):
send "exit\r"

The script in its entirety looks as follows:

!/usr/bin/expect -f

spawn ssh aspen
expect "password: "
send "PASSWORD\r"
expect "$ "
send "ps -ef |grep apache\r"
expect "$ "
send "exit\r"
Change permissions on the script so that it is executable; for example,
$ chmod 755 script.sh
and try it for yourself.

Expect Caveats

If your script hangs and doesn’t continue, try the command manually yourself and look for the response. If the remote system drops you to a prompt as its final act, then place that in your script (e.g., expect "$ " ). Be sure you have entered the hard return (\r ) inside the closing quotation mark in your send line. You might also find that your system needs two backslashes on the send line for a hard return (\r ).

Sometimes Expect scripts execute too fast, and you won’t see your expected response. If that happens, place a sleep command and a number of seconds for the command preceeding it to wait for a response, or your data might be ignored.

For example, if you connect to a remote system and there’s a delay in creating that connection, your script will continue to execute and fail because it sends commands before the remote system has time to respond.

You have to think about network delays, shell responses and system timing when scripting in Expect. Like any scripting language, Expect has its quirks, but you’ll find that it’s an easy way to automate those repetitious keystrokes and procedures. The time you spend debugging your scripts is well worth the effort.

Autoexpect

Of course, some lazy system administrators take lazy to a higher level and even cheat at writing Expect scripts by invoking a shell “watcher” or recorder script named Autoexpect. Once invoked, Autoexpect watches your every keystroke and records it to a file named, script.exp by default. You’ll almost certainly have to edit and prune this script to achieve your desired results; however, it can save hours of script debugging to have an almost complete script from which to work.

If you simply run a freshly created Autoexpect script, it will likely fail because, if you issued a command that answers your request by displaying information to the screen, the script picks up that answer, too, and copies it into the script file.

For example, if during your Autoexpect session, you type, ls , the result of that command appears in your script.exp file as well. After you’ve created a few Expect scripts by hand, you’ll appreciate the cleanup editing you have to do in an Autoexpect-created script.

To install Autoexpect, issue a command like:
$ sudo apt-get install expect-dev

You’ll likely require many more dependencies for this feature, so prepare yourself for a slight delay while everything installs.

Creating an Interactive SSH Session with Autoexpect

After installing Autoexpect and all of its required packages, you’re ready to create Expect scripts automatically by stepping through the procedures you want to automate. Using the above example, SSH to a remote system and run a
ps -ef |grep apache
command and then log out.

Invoking Autoexpect is easy:
$ autoexpect
$ autoexpect started, file is script.exp
Although it looks as if nothing has happened or is happening, every keystroke you type will be recorded into script.exp . Every STDOUT response you receive will also be copied into that same file. Your entire session is recorded – but not just recorded, it is also formatted in Expect script style. To stop recording keystrokes to your script, press Ctrl+D on your keyboard to stop Autoexpect and copy the buffer to your file.

Ubuntu MS Core Fonts Error for Wine Installation

Script: 20181209-fix-mscorefonts.txt

Fix for the below error:

$ sudo apt-get update && sudo apt-get install --reinstall ttf-mscorefonts-installer flashplugin-installer

This fix required a supplemental fix too
Refer: https://askubuntu.com/questions/766491/failure-to-download-extra-data-files-with-ttf-mscorefonts-installer-on-ubuntu

$ wget http://ftp.de.debian.org/debian/pool/contrib/m/msttcorefonts/ttf-mscorefonts-installer_3.7_all.deb
$ sudo apt-get purge ttf-mscorefonts-installer -y
$ sudo apt install ./ttf-mscorefonts-installer_3.7_all.deb

Data files for some packages could not be downloaded

The following packages requested additional data downloads after package installation, but the data could not be downloaded or could not be processed.

ttf-mscorefonts-installer

This is a permanent failure that leaves these packages unusable on your system.  You may need to fix your Internet connection, then remove and reinstall the packages to fix this problem.

Tether Ideas

Refer: http://pocketnow.com/2014/01/20/kitkat-broke-t-mobile-tethering

KitKat broke T-Mobile tethering

While using my Nexus 4 running various versions of Android, I never had a problem tethering my tablet to my phone, but after I got my Nexus 5 I noticed that whenever I’d try to tether, the tethered device would redirect to a “sign up for tethering page” hosted by T-Mobile. That’s not very cool, but since I’d recently upgraded my 5GB plan to T-Mobile’s “unlimited” plan, I figured it was no longer allowed. Out of curiosity, I bounced the problem off several of my friends across the country, some who still had the 5GB data plans (without any mention of tethering restrictions in their contracts). They, too, were unable to tether in a post-KitKat world — regardless of which device they were trying to tether to.

Since the old plans didn’t prohibit tethering, and are limited to a specific amount of traffic, it can be argued that it doesn’t matter where the data comes from (the device or something tethered to it). Therefore, re-enabling the tethering should be perfectly okay to do. Of course, I’m not a lawyer, nor am I dispensing with legal advice or telling you how to break any rules. I’ll let you decide for yourself if this hack is appropriate for your particular situation.

How to re-enable tethering

KitKat introduced a new “flag” which the OS sends along to the carrier to indicate whether the data is from a tethered device rather than from the device itself. So far it looks like T-Mobile is the only carrier that is using that flag.

To change things back to the way they were pre-KitKat, all one has to do is change that flag. Doing so isn’t difficult, but it does require that you have a rooted device. If you’re game, here are the steps you’ll need to take:

  1. Rooting and messing around with system files could render your device useless, so by continuing you’re assuming that risk
  2. Also, since this involves working around a carrier setting, you also need to make sure that your plan doesn’t prohibit you to tether (Note: your plan doesn’t have specifically allow you to tether, it just has to not prohibit doing so)
  3. Back up anything that you don’t want to lose
  4. OEM Unlock your device (if you have not done so already)
  5. Root your device (if you have not done so already)
  6. Using a root file explorer, navigate to /data/data/com.android.providers.settings/databases/ and make a copy of settings.db (this step is optional, but you’ll want a copy, just in case you need to restore it later)
  7. Install and open a SQL editor and grant it root access when prompted (I purchased SQLite Editor from the Play Store for a few bucks and it’s very easy to use)
  8. Tap the APPS tab and then “Settings Storage”
  9. Tap on settings.db then global
  10. Tap on the + symbol to add a new key/value pair
  11. In the name field type in tether_dun_required
  12. In the value field type in 0 (zero)
  13. Tap Save
  14. Open the Android system Settings
  15. Under WIRELESS & NETWORKS tap More…
  16. Tap Mobile networks then APNs
  17. Make sure your T-Mobile configuration is selected (mine is T-Mobile GPRS), then tap on it
  18. Make sure your APN protocol and APN roaming protocol are both set to IPv4 (it doesn’t look like tethering works with IPv6 yet)
  19. Make sure your APN is set to fast.t-mobile.com
  20. Reboot
  21. Enjoy your tethering!

The steps seem more difficult than they are, and I’m disappointed that Google and T-Mobile are forcing this restriction on people to whom it doesn’t apply. Nonetheless, with a little bit of know-how and rooted device, you can “fix” that oversight.