Changing terminal font in Visual Studio Code on Linux to get symbols working

 I've been using VS Code lately, since Atom is being killed off. I also switch to using ZSH with OhMyZsh a while back. I had noticed that while using the integrated terminal in VS Code, all of my nice status icons were showing as empty boxes, indicating that the font didn't have symbol support compiled in.

  I found this post for fixing the problem on OSX, and was able to adapt it to my needs. 

• Press Ctrl + Shift + P and choose Preferences: Open User Settings (JSON)
• Add these lines (in my case) to your config:

"terminal.integrated.defaultProfile.linux": "zsh",

"terminal.integrated.fontFamily": "SauceCodePro Nerd Font"

SauceCodePro is my preferred font currently, being the Nerd Fonts version of Adobe's Source Code Pro font.

Once you save the settings.json file, the terminal (if visible) should immediately update and your symbols should be visible. This of course assumes that you have a working font with symbols already installed and that you specify it correctly on the second line.

Dotfiles Part 2: I Knew It Couldn't Be That Easy

    As I discussed in the first post, I wanted a place to store my dotfiles where I could easily pull them down onto a new system. Github has become a popular place for this. It makes sense. Github is a cloud based git repo that you can easily reach from anywhere you have an internet connection. Git is a VCS which makes it easy to track changes to text files, which dotfiles are by definition. A simple git clone on a new system, and you have all your files ready and waiting for you.

    There are, of course, some issues with simply creating a git repo out of your entire home directory. So, many systems have been created which usually use symlinks to point into the repo controlled directory instead. There is even a nice listing available on the unofficial guide at github at http://dotfiles.github.io. It lists out some bootstrap systems to handle the symlinking and setup. It moves on to some app specific options, for things like shells and editors which may have extensive config and plugins that may be better managed with a dedicated system. Lastly, it covers general purpose dotfiles utilities, which may do more than just symlinking and syncing them for you.

    I've started to figure out how I wanted to manage my dotfiles many times over the years, and never gotten much further than looking at this massive page of options, opening up many of them in tabs, and then getting overwhelmed or distracted. This time, however, I was determined to make a choice and start trying to implement it. Even if it didn't end up being the solution I use in the end, I needed to get started at some point and figure out what would and wouldn't work for me. So, I made an initial pick.

Dotfiles: More Than Meets the Eye

    Dotfiles are pretty important. Anyone who has used a *NIX OS for a while will recognize the truth of this simple statement. For the uninitiated, Linux, Unix, and BSD (and OSX, which is a variant of BSD) operating systems have many things in common. One of these things is that files whose name begins with a period, like .config for example, are treated specially and hidden from the vanilla file list command, ls. Now, they aren't super secret or anything. A simple -a added to the ls command (making it ls -a) will show them again, they are just hidden by default. Due to the naming and pronunciation (.config would be spoken dotconfig by most people) they have become known collectively as dotfiles.

    The assumption is that they will be system files, usually configuration settings and the like, that you won't work with every day and won't want cluttering up your file listings all the time. Which is a pretty good assumption considering that the things multiply like crazy. These days it isn't just dotfiles, you have entire subdirectories that hold all sorts of things for whatever program uses them. Example, I have a .weechat that holds all the config settings, plugins, and chat logs from my irc client. Many programs use these the way Windows programs use their directory under Program Files. It is a good system, as it keeps the config easily findable in the user's home directory and also keeps the config user specific.

    Since they control the configuration of so many different pieces of your system, the dotfiles become important. They are how your system has been configured the way you like it. How it knows the behavior you want. They become very valuable, and over time, very difficult to replace. Some people spend years making small modifications to files like .bashrc and .vimrc until the resulting config is perfect. However, recreating it from scratch might be impossible as you won't remember what the setting you found on that obscure blog 3 years ago that solved this one issue was. You basically have to start over and tweak slowly until you arrive at another working, but inevitably different, config.

SSL, Tomcat, Android, and keeping my sanity

Recently, at work, I was tasked with getting some SSL certs installed and working on a tomcat installation. This was a bit outside my normal duties, as work is rather segregated, and tomcat falls under an application admin's responsibilities, not a server admin's. However, there isn't an app admin available who knows tomcat, so I was given the job by virtue of competence, and having built the server. For reference, the OS was RHEL 5.7, running Tomcat 6.0.33, and trying to use JSSE for SSL.

Our normal setup for web servers is apache, sometimes using the Cool Web Stack or something like it, so tomcat isn't something that my team has any familiarity with. Additionally, I built this server, but that was just the OS (RHEL). A third party installed the tomcat application server with grails on top of it, for the purpose of hosting some mobile apps (Android and iPhone) created using their toolkit. They set this up without SSL, and in looking through their available documentation, the only reference I could find to SSL was a single footnote on a document about the security of the system which essentially said, since you asked, of course this should all be done over SSL. Just ignore the fact that none of our documentation or reference implementations bother to do so.

So, I set about trying to get the SSL cert working, armed with a set of instructions (team standard procedures) for doing so with apache, and a single page from our wiki on setting up SSL in Tomcat. This page was proof that someone had done so in the past, but it consisted of a couple command lines to run, some java source code to be compiled and then invoked, and no reference to the implementation details of telling tomcat to use the SSL cert itself. The command line invocations converted the standard x509 cert we received from our CA and the key we generated when making the CSR into another format, DER.The java source code formed a program which would read in the der formatted certificate and key, and convert them into a Java keystore (JKS) formatted file. The instructions were for Solaris, our main OS, and not RHEL which these servers were running. The java program wouldn't compile, because the JDK that the third party installed for use with tomcat seemed to have a broken compiler! I installed a new jdk from the RHEL repos, and found that the source code didn't have any include statements, which also caused problems. A bunch of wildcard based includes later, I had a compiled program and a freshly created keystore. I installed it into tomcat, using some helpful online instructions, made a mental note that I wanted to come back at some point and find a way to convert the SSL cert without using a custom compiled program, because that seems like overkill for a problem where standard tools should exist, and continued on my way, after verifying that the site was accessible over SSL now.

I did end up finding a way to convert from the openSSL cert to a java keystore without using a custom compiled java program. After much, much searching, I found a tough to navigate site that was stuffed with useful information! This page shows how to use the openssl tool to combine a key and a cert into one PKCS12 file. Then, this page shows how to use the java (or JDK maybe) command keytool to import the PKCS12 file into a Java KeyStore file. Thus, we are now able to use two commands where before we used 2 different commands & a custom compiled java program. (In theory, we don't have to perform the conversion to a Java KeyStore format, as Tomcat can be told to use the PKCS12 file directly as a keystore. However, this involves more poorly documented tomcat configuration, and I didn't want to keep pressing my luck once I got everything working. If someone else wants to try for efficiency later on, then they are more than welcome to it.)

Those in charge of this project then decided I should turn off all non-SSL traffic to the servers. After doing this, they discovered that they could not download the new APK files to their Android phones from the server over SSL. Android was throwing an untrusted certificate error (the kind you expect with a self-signed cert, not a CA issued one) and will silently fail to download files from a server over SSL in this scenario.

I suspected that the intermediate certs were not being handed out correctly, and was eventually able to prove this with the help of these two sites. Our internal instructions said to import the intermediate cert from our CA into the JKS file with an alias of intermediateca. The official instructions said to import it with an alias of root. Somewhere else online said to use an alias of intermediate. I tried all of these, as well as combining them all, with no luck. I looked through the documentation, and could find no mention of a specific alias name to use for tomcat to magically pick it up and serve it out.

I went searching again, and finally stumbled upon this question on stack overflow. This was the same problem I was having, so I tried the solution, but ran into problems. They placed the intermediate cert into /etc/ssl/certs, then ran the command to create the PKCS12 file with an additional flag -chain. RHEL doesn't have an /etc/ssl/certs, so I searched, and found the equivalent at /etc/pki/tls/certs. I tried placing the intermediate cert there, and running the command with -chain added, and got errors because the cert wasn't found. I then went looking to see what options could be passed to the openssl command, and found the -CAfile and -caname flags. Using these, I was able to use the -chain flag and eventually get a Java KeyStore that caused tomcat to serve out the intermediate cert correctly.


After some experimenting, I finally isolated what creates a working keystore. The -chain flag with the openssl command is the critical key. Combine this with -CAfile to create the PKCS12 file with the intermediate cert included. The -caname flag ends up to not be needed at all. Importing the intermediate certs into the JKS (Java KeyStore) file with an alias, doesn't matter at all. (It doesn't break anything to have them there, but it also isn't needed for it to work.) Counterintuitively, the working JKS file will only show to contain one cert when viewed with keytool -list.

[root@fido sslcerts]# keytool -list -keystore fido.jks 
Enter keystore password:  

Keystore type: JKS
Keystore provider: SUN

Your keystore contains 1 entry

tomcat, Mar 22, 2012, PrivateKeyEntry, 
Certificate fingerprint (MD5): 83:F5:A4:7D:2A:39:35:FB:8B:41:B7:34:B5:97:45:92

I was able to verify with both of the SSL checking sites above that this file will serve out the intermediate certs correctly. On Android, it no longer throws the untrusted cert error, and now silently validates. So, now, we have a new working procedure that only requires the same files we were downloading from the CA before, and uses two commands to turn them into a working Java KeyStore that will serve out intermediate certs correctly

openssl pkcs12 -export -inkey fido-2012-03-15.key -in fido-2012-03-15-cert.cer \
-out fido_key_cert_chain.p12 -chain -name tomcat -CAfile fido-2012-03-15-interm.cer 

keytool -importkeystore -srckeystore fido_key_cert_chain.p12 -srcstoretype pkcs12 \
-srcstorepass changeme -destkeystore fido.jks -deststoretype jks -deststorepass changeme

Citrix Receiver on 64-bit Arch Linux

I recently made the switch from Ubuntu to Arch Linux (with E17) on my workstation at work, and I am now in the process of getting all my apps setup and working again. Pretty high up on that list was the Citrix receiver. Work is a largely Windows based setup, with Exchange for e-mail. I actually prefer a few things about the newer versions of Outlook, when compared with most of the Linux clients I have tried in the past.
This means my choices boil down to:

1. Get Outlook running under Wine (yeah, that'll work out real well) 
2. Run Outlook in a Windows VM (I have this setup, but prefer not to run the VM at all times, it is a real memory hog)
3. Run a separate computer with Windows on it, just for Outlook (not going to happen)
4. Get the Citrix receiver working, and use the Citrix version of Outlook that we make available

I chose #4. The problem here is not the linux part, install packages exist for the receiver on linux. The problem is the 64-bit part. Out Citrix server only hands out a 32-bit installer. I went looking, and while Citrix has started offering 64-bit installers now, they only come in .deb or .rpm. There isn't a .tar.gz package like there is for 32-bit. Arch linux, of course, does not use .deb or .rpm packages.

I had the receiver installed on Ubuntu, and it worked mostly. It worked fine, but I could not run the manager app to change the settings, which meant that I could never map my local hard drive to show up as a drive in the software run on Citrix. For e-mail, this meant I could not save or send attachments, unless I used a USB stick for them, because the default settings would auto-mount USB devices.

I found these instructions on the Arch wiki, and followed the manual install instructions. Probably because I had already downloaded the package from Citrix, and sunk some time into getting the installer to run, so I didn't want to take the easy route out and use a pre-built package now.

Just to get the installer to run, I had to do some research, and finally figure out that the "no such file or directory" errors being thrown by echo_cmd were because I only had the 64-bit glibc libraries, and I needed to install the lib32-glibc from the multilib repo as well.

I followed the instructions on the wiki, making modifications as I went because my install of the receiver was in a different directory, and got a working install, except that I had problems getting firefox to see the Citrix plugin for some reason. I also was not able to get the manager app (wfcmgr) to run, despite the wiki article explicitly saying it should. I was getting this error:

/opt/Citrix/ICAClient/wfcmgr: error while loading shared libraries: libXm.so.4: cannot open shared object file: No such file or directory

I did some more digging, and found the 32-bit library package from the AUR containing libXm.so.4, aur-lib32-openmotif, installed into /opt/lib32/usr/lib directory, instead of into the /usr/lib32 directory where the wfcmgr program was trying to find it.

One way to fix this is with a simple

sudo ln -s /opt/lib32/usr/lib/libXm.so.4 /usr/lib32/libXm.so.4

however, I chose to modify the PKGBUILD to put the libraries in /usr/lib32 with all the others, in case a program went looking for one of the other openmotif libraries in the future.

I also figured out that my problem getting firefox to see the plugin was that I checked whether the plugin was setup with

sudo nspluginwrapper -l

using sudo here, because the wiki article showed the install command, nspluginwrapper -i, being run as root. This showed the plugin to be in place already:


/root/.mozilla/plugins/npwrapper.npica.so
  Original plugin: /opt/Citrix/ICAClient/npica.so
  Plugin viewer: /usr/lib/nspluginwrapper/i386/linux/npviewer
  Wrapper version string: 1.4.4-1

It took me too long to realize that this plugin was not system-wide, but was root-specific, and that I needed to do this as my user instead. I checked and it was not setup for my user, so I used the -i command to install it, and restarted firefox. It is now detected, which means I don't have to skip past the install prompt from the server when the silent-detection routine fails to find the plugin on my system.

In the end, I have a newer version of Citrix Receiver installed and I was able to setup my home directory to be mapped as a drive to be seen inside the Citrixed apps. I do not have the USB device support, because the installer can't figure out Arch's system for managing services, but I don't think I'll miss that.

My Webpage Addiction

So, yesterday, I had a recurring issue happen to me, which causes me much frustration. I lost about 100 webpages in Firefox. Yes that's right, I lost webpages. Ok, let me explain what I mean.

First, I have a problem. I collect webpages. I think that's about the only way to describe it. I will find a new webpage through any of a variety of means. I might open 15 pages from search results when I'm trying to troubleshoot a problem, or I might follow some links from various webcomics, or be sent something by a friend. Then, for whatever reason, I don't just read the page and move on. Instead, I save it. Either because I don't have the time to read it entirely right now, or I want to try it out later, or I think it's great reference material to keep around, or I want to send it to someone else. So for whatever reason, I want to keep it around.

Because of this, I've got hundreds of untamed bookmarks, synced between browsers, in theory, whenever Google Browser Sync works properly. (It synced at the beginning, but I'm not sure about lately.) I've also got a del.icio.us list that is 234 pages long at 10 items per page. And lately, I've become known (read as:ridiculed) for having as many as 150 tabs open in several windows in Firefox at any given time. Yes, starting Firefox is a 15 minute ordeal.

The strategy of just leaving the tabs open, works best for things I just haven't had time to read, or want to try in the next day or two. In theory. So, pre-Firefox 2.0, I use an extension to save my tabs, and restore them in case Firefox crashed on me. It also had the nice extra of saving the last 2 sessions, so if for some reason it didn't load my tabs properly, I could go back to the previous saved version. (Just don't close Firefox after not having your tabs load, or you will lose the good saved session information.) Firefox 2.0 came along, and with it, integrated session saving. This has been nice, and is more robust that the extension I relied on before (which is no longer compatible with current versions). However, it does not have the ability to re-load the session, or to load an older session.

Why does this matter? Well, I usually have the most tabs open on my laptop. And, for whatever reason I haven't tracked down yet, this is also my least stable installation of Firefox. I deal with a few crashes each day, on average. My laptop also has a quirk dealing with its Wifi, often requiring me to powercycle the radio before it will connect. Thankfully, it's just a key press on my laptop. However, if I fail to realize I'm not connected before I launch Firefox, or if (as happened this last time) Firefox gets auto launched because it was open when my previous X11 session ended, then all my tabs come up unable to connect. Once this happens, I have to go connect to the net, then reload each tab by hand. If I don't, then they will be saved as blank tabs, and Firefox will forget what site was previously loaded in them. Once this happens, they are usually gone, because I obviously do not remember what I had loaded in 150 different tabs. In addition, many of the tabs have been open for weeks, or longer, so they will no longer be listed in my browser history.

So, today, when my laptop decided it wasn't going to resume from suspend anymore, but would instead hang on booting, I managed, through a serious of events, to have this happen. This is probably the tenth time or so I have lost my tabs. It really, really ticks me off. So I decided to see what I could do about it. Unfortunately, the answer is, if I had known what to do, and had been quick enough, I might have been able to save them. Maybe. Depends on how far gone they were once I got the rest of the system functioning again. (How does Gnome just forget you had a notification area on your taskbar?)

There is an API available, with something vaguely like what I would want, mentioned as a potential use case. However, my coding skills are infantile, and creating a program to utilize this would be way beyond me. I did, however, come up with a stop gap measure. I added an entry t o have logrotate copy the session saving information for me (which is updated routinely as Firefox runs). This means, in theory, that I will have snapshots from several days available, and hopefully anything added after the snapshot was taken will be recent enough to still be found in my history.

Yes, I do realize that the real solution is to change my habits, and stop leaving so many tabs open. However, this is my stopgap solution. Time will tell if it works or not. May I never need to use it.

My configuration entry for logrotate:

/home/madasi/.mozilla/firefox/8ryaickb.default/sessionstore.bak
/home/madasi/.mozilla/firefox/8ryaickb.default/sessionstore.js {
        rotate 7
        daily
        copy
        dateext
        compress
        missingok        

}

Bug Affliction

A few weeks ago, I lost my swap space again, exactly like last time. Once again, a resume from hibernate failed after a routine fsck check ran. And once again, I missed the fact that my swap was gone until later when I noticed the computer failing to hibernate due to lack of swap space.

Since this was the second time it happened, I was sure that it wasn't due to an accidental run of mkswap. Not that I was doubting it after the first time, but you wonder if maybe some obscure option you hit in the GUI might have triggered it behind-the-scenes or something. This time, I was certain.

I was also thankful I blogged the instructions for fixing it the first time, as it save me a lot of research this go-round. Not that I didn't research it, I just did so after fixing it.

Thankfully, I didn't come up empty handed. I found Bug #90526: Routine fsck deactivates swap, changing UUID. Yep, that's it exactly officer. The clue this time was that I saw the fsck happen as my laptop booted, and realized that the last time seemed to be in close temporal proximity to a fsck as well. It's a confirmed bug, with no indication of a time frame for a fix. However, it's always nice to know that you aren't crazy, and that your issues have already been documented.