Month: July 2013

Let me preface this post by saying that satellite radio is a great service.  You get access to a whole lot of content that you might not otherwise be able to access.  When I got my new 2012 Ford F150 XLT SuperCrew, I got a trial subscription for the first six (6) months to a subset of the SiriusXM stations.  I thoroughly enjoyed listening to the selections on the Electronic and Dance stations, the BBC content, stations from Canada, and a wide variety of news outlets, not too mention the comedy channels.

On September 3rd, my trial subscription expired.  I knew that it was going to expire.  In fact, I put a reminder in my personal calendar to warn me that the trial expiration date was arriving.  I liked the service enough that I was going to subscribe so that I could continue enjoying the service.

However when the renewal date approached, I determined that it was not financially smart to sign myself up for yet one more monthly payment at this time.  No big deal, I would just use Pandora, Spotify, Google Music and standard terrestrial radio until I was where I could pay for the subscription.

That’s where it all gets painful.  When the SiriusXM customer service representative called me to make sure that I knew my trial expiration was coming up I explained that I was not currently interested in signing up to pay for it.  When he helpfully (at least in his mind it was helpful) informed me that the monthly payment was only $16 a month, I ensured him that I had actually read the mailing they sent out and knew what the prices were and I just didn’t want to continue.

Now despite the belligerent tone of voice he continued to use to try and bully me into a subscription, I finally managed to get off the call without losing my temper (which was a major feat, let me tell you).  In a logical universe, they would mark my account as having declined service and to try again in a few months (but hopefully never since I did mention that I didn’t want them to call me again) and that would end the matter.

This is where SiriusXM has failed to gain a customer.  Almost every day so far this month I have received at least one call from the SiriusXM folks (866-903-7474) trying to suck me back into the fold.  This constant bombardment is a real pain in the rear.  I can understand one or two attempts, but at some point you have to realize that continued calls are not going to get the customer.

So here’s the email I sent to the SiriusXM Customer Service folks today after yet one more call:

I realize that my trial subscription has expired. In fact I even talked to your customer representatives at least once concerning this prior to the expiration.

I happily informed the customer service representative that I knew my subscription was going to expire and that I was not interested in converting my trial at that time due to the cost, and yes that I knew it wasn’t a lot each month if I subscribed for a year. After he kept trying to get me to convert, rather insistently to the point of belligerence, I finally was able to get him to hang up.

Recently I have been receiving calls from your company (866-903-7474) at least once a day (sometimes twice).

I realize that you would like to retain customers and to gain new ones, however when a current/former customer informs you that they no longer wish to continue the subscription, it doesn’t engender good customer relations to bombard them on a daily basis with calls.

For this reason it is unlikely that I or anyone in my household will ever subscribe to your services at any point in the future. I appreciate that you have made it even easier for me to embrace the free and/or ad-supported streaming services like Pandora Radio, Spotify, Live365, Google Music, and Amazon Music.

Thanks,
Andy Fore

So instead of caring about subscribing to SiriusXM, I will just use my mobile data plan to get the most out of Internet-based streaming services that I can.  I would rather give my money to my mobile provider for data usage than to SiriusXM, since Verizon doesn’t deem it necessary to spam me with phone calls about their services.

Today while working on the AASU Blackboard VISTA custom login page, I ran into an issue loading Java applets.

Apparently, Google Chrome checks your browser plug-ins to determine if they are out of date when you attempt to load content requiring them.  Here’s a snippet from the Google Support Site about the bug feature:

To make sure you’re protected, whenever Google Chrome detects that a common plug-in on a page is out of date with a security vulnerability, a message will appear beneath the address bar notifying you that the plug-in has been blocked.

While this is a great feature, since it is an attempt to protect your computer from nefarious code, there are times that it just doesn’t work properly.

The situation I ran into is described on a chromium issue report.  Basically, the Linux version of Oracle Java 7 is being seen as out-of-date, even though it is the most recent version available.  When going into the Google Chrome plug-in preferences you may see the Java plug-in marked as disabled and showing the version number in red as well as a link to java.com to download a security update.

While Chrome does give you ability to run the plug-in each time it is used, this can rapidly become a pain in the rear.  The checkbox labeled Always Allow also doesn’t seem to work.

So what to do?  Well, you can either painstakingly click the Run this time button or you can run Google Chrome with a command line switch that turns off the plugin checking mechanism.

Being an intrepid sort that likes to live on the edge and dance where angels fear to tread, I chose to run with the checking mechanism turned off.  To update the Ubuntu application launcher to make this easier, I edited the following file:

/usr/share/applications/google-chrome.desktop

sudo vi /usr/share/applications/google-chrome.desktop

Look for the first instance of a line starting with Exec and alter it to read as follows:

Exec=/opt/google/chrome/google-chrome --allow-outdated-plugins %U

After saving the file and restarting Google Chrome you will no longer be bothered by the annoying Java plug-in error warning.  To verify this is working, you can enter the following on the command line:

ps ux | grep -v grep | grep allow-outdated-plugins

You should get back at least one result.

As a bonus, you can ensure that you are running the most recent version of Java (1.7.0_05 as of this writing) by doing the following on a command line:

java -version
javac -version

You should see something like the following:

foreandy@foreandy-iMac:~$ java -version
java version "1.7.0_05"
Java(TM) SE Runtime Environment (build 1.7.0_05-b05)
Java HotSpot(TM) 64-Bit Server VM (build 23.1-b03, mixed mode)
foreandy@foreandy-iMac:~$ javac -version
javac 1.7.0_05

At work we run the WebCT Vista course management system by Blackboard.

Recently I was requested to figure out how to import the security certificate from the command line so that we could add this to the login script used for our campus computers. The main reason behind this was to eliminate the need for the user to have to manually agree to the security certificate when browsing to the CMS.

Normally when you want to create a Java keystore, you would use the keytool program located in

. If you run this program to import a certificate without specifying a location for the keystore it tries to create one named

in the user profile home directory.

However, when the JRE actually imports a certificate it doesn’t put it in this file. After some investigation, it turns out that the JRE imports certificates into a file named

which is located in the following directory

C:\Documents and Settings\USERNAME\Application Data\Sun\Java\Deployment\security\

In order to import a certificate into a keystore you need to vital pieces of information:

1. the keystore name
2. the keystore password

The problem here is that this keystore is being automatically created by the JRE. It turns out that this keystore has a password that is an empty string. What this means is that when you import a certificate you have to specify the password by using the storepass parameter with a value “”.

For example if the certificate that you want to import has a name and path of

the command to import the certificate for the user jdoe would be

keytool.exe -import -noprompt -keystore C:\Documents and Settings\jdoe\Application Data\Sun\Java\Deployment\security\trusted.certs -storepass “” -file c:\Blackboard.cer

Update 2008-04-09:

I have also found how to do this on Mac OS X. According to the developer documents, the JVM on Mac OS X uses the user’s default keychain to store this type of certificate instead of using a file-based keystore like the other OS.

In order to store the certificate in the user’s login keychain you can import it via the command line tool

that is installed on the OS.

The command to import this certificate from the command line is

certtool i path/to/cert/file k=~/Library/Keychains/login.keychain

If you want to have this happen at login for each user who might login, then you could implement this via a login hook. For more on this, take a gander at the article 301446 in the Apple knowledgebase.

Let me preface this post by saying that satellite radio is a great service.  You get access to a whole lot of content that you might not otherwise be able to access.  When I got my new 2012 Ford F150 XLT SuperCrew, I got a trial subscription for the first six (6) months to a subset of the SiriusXM stations.  I thoroughly enjoyed listening to the selections on the Electronic and Dance stations, the BBC content, stations from Canada, and a wide variety of news outlets, not too mention the comedy channels.

On September 3rd, my trial subscription expired.  I knew that it was going to expire.  In fact, I put a reminder in my personal calendar to warn me that the trial expiration date was arriving.  I liked the service enough that I was going to subscribe so that I could continue enjoying the service.

However when the renewal date approached, I determined that it was not financially smart to sign myself up for yet one more monthly payment at this time.  No big deal, I would just use Pandora, Spotify, Google Music and standard terrestrial radio until I was where I could pay for the subscription.

That’s where it all gets painful.  When the SiriusXM customer service representative called me to make sure that I knew my trial expiration was coming up I explained that I was not currently interested in signing up to pay for it.  When he helpfully (at least in his mind it was helpful) informed me that the monthly payment was only $16 a month, I ensured him that I had actually read the mailing they sent out and knew what the prices were and I just didn’t want to continue.

Now despite the belligerent tone of voice he continued to use to try and bully me into a subscription, I finally managed to get off the call without losing my temper (which was a major feat, let me tell you).  In a logical universe, they would mark my account as having declined service and to try again in a few months (but hopefully never since I did mention that I didn’t want them to call me again) and that would end the matter.

This is where SiriusXM has failed to gain a customer.  Almost every day so far this month I have received at least one call from the SiriusXM folks (866-903-7474) trying to suck me back into the fold.  This constant bombardment is a real pain in the rear.  I can understand one or two attempts, but at some point you have to realize that continued calls are not going to get the customer.

So here’s the email I sent to the SiriusXM Customer Service folks today after yet one more call:

I realize that my trial subscription has expired. In fact I even talked to your customer representatives at least once concerning this prior to the expiration.

I happily informed the customer service representative that I knew my subscription was going to expire and that I was not interested in converting my trial at that time due to the cost, and yes that I knew it wasn’t a lot each month if I subscribed for a year. After he kept trying to get me to convert, rather insistently to the point of belligerence, I finally was able to get him to hang up.

Recently I have been receiving calls from your company (866-903-7474) at least once a day (sometimes twice).

I realize that you would like to retain customers and to gain new ones, however when a current/former customer informs you that they no longer wish to continue the subscription, it doesn’t engender good customer relations to bombard them on a daily basis with calls.

For this reason it is unlikely that I or anyone in my household will ever subscribe to your services at any point in the future. I appreciate that you have made it even easier for me to embrace the free and/or ad-supported streaming services like Pandora Radio, Spotify, Live365, Google Music, and Amazon Music.

Thanks,
Andy Fore

So instead of caring about subscribing to SiriusXM, I will just use my mobile data plan to get the most out of Internet-based streaming services that I can.  I would rather give my money to my mobile provider for data usage than to SiriusXM, since Verizon doesn’t deem it necessary to spam me with phone calls about their services.

Today while working on the AASU Blackboard VISTA custom login page, I ran into an issue loading Java applets.

Apparently, Google Chrome checks your browser plug-ins to determine if they are out of date when you attempt to load content requiring them.  Here’s a snippet from the Google Support Site about the bug feature:

To make sure you’re protected, whenever Google Chrome detects that a common plug-in on a page is out of date with a security vulnerability, a message will appear beneath the address bar notifying you that the plug-in has been blocked.

While this is a great feature, since it is an attempt to protect your computer from nefarious code, there are times that it just doesn’t work properly.

The situation I ran into is described on a chromium issue report.  Basically, the Linux version of Oracle Java 7 is being seen as out-of-date, even though it is the most recent version available.  When going into the Google Chrome plug-in preferences you may see the Java plug-in marked as disabled and showing the version number in red as well as a link to java.com to download a security update.

While Chrome does give you ability to run the plug-in each time it is used, this can rapidly become a pain in the rear.  The checkbox labeled Always Allow also doesn’t seem to work.

So what to do?  Well, you can either painstakingly click the Run this time button or you can run Google Chrome with a command line switch that turns off the plugin checking mechanism.

Being an intrepid sort that likes to live on the edge and dance where angels fear to tread, I chose to run with the checking mechanism turned off.  To update the Ubuntu application launcher to make this easier, I edited the following file:

/usr/share/applications/google-chrome.desktop

sudo vi /usr/share/applications/google-chrome.desktop

Look for the first instance of a line starting with Exec and alter it to read as follows:

Exec=/opt/google/chrome/google-chrome --allow-outdated-plugins %U

After saving the file and restarting Google Chrome you will no longer be bothered by the annoying Java plug-in error warning.  To verify this is working, you can enter the following on the command line:

ps ux | grep -v grep | grep allow-outdated-plugins

You should get back at least one result.

As a bonus, you can ensure that you are running the most recent version of Java (1.7.0_05 as of this writing) by doing the following on a command line:

java -version
javac -version

You should see something like the following:

foreandy@foreandy-iMac:~$ java -version
java version "1.7.0_05"
Java(TM) SE Runtime Environment (build 1.7.0_05-b05)
Java HotSpot(TM) 64-Bit Server VM (build 23.1-b03, mixed mode)
foreandy@foreandy-iMac:~$ javac -version
javac 1.7.0_05

When doing system administration it is often more convenient to connect to a server through some sort of remote connection setup rather than having to sit at a console in a datacenter.  The comfort of one’s office (or living-room) is often far superior in terms of noise and temperature than the environs of the datacenter itself.

When setting up the RHEL5 server this week here at VSU, I was forced to use the Sun iLOM connection to do the initial install of the server.  While I generally use command-line only tools, the ease of use one gains from the GUI tools can often make some tasks much simpler.  Towards this end I decided to setup the server and my client to allow XDMCP sessions so that I could have full access to the GUI when necessary.

On the server there are a couple of things that you need to configure in order to make this workFirew:

1. Firewall ports
2. GDM configuration options

On the client you will need to configure the OS X firewall, as well as use the correct Xephyr connection syntax.

Step 1: The server firewall

The firewall ports necessary for the use of XDMCP are:

• 177/TCP,UDP – X Display Manager Control Protocol
• 6000/TCP – X11 client/server communication
• 6001/TCP – X11 client/server communication

The two common methods for allowing these ports are to either use the iptables command-line interface or the GUI system administration tool.

To change the firewall ports from inside the GUI you will need to be at the console or using an X11 session forwarded via SSH.

If you are logged into the console:

1. Select the System menu from the menu bar
2. Select Administration from the System menu
3. Select Security Level and Firewall from the Administration sub-menu
4. Authenticate as the root user if necessary (you didn’t login as root did you?)
5. In the Security Level and Firewall dialog that comes up
   1. Make sure you are on the Firewall Options tab
   2. Expand the section at the bottom labeled Other ports
   3. Click Add
   4. In the dialog that pops up
      1. Put the port number(s) in the Port(s) field
      2. Select tcp or udp from the Protocol dropdown
      3. Click OK
   5. Click OK

To add the port from the command-line use the following command as a guideline and replace PROTOCOL with either tcp or udp and PORT_NUMBER with the number of the port exception that you are creating:

iptables -A INPUT -p PROTOCOL -m PROTOCOL --dport PORT_NUMBER -j ACCEPT

For example, to open port 80 on the firewall you would issue the following command:

iptables -A INPUT -p tcp -m tcp --dport 80 -j ACCEPT

Step 2: The GDM configuration

After you have opened the appropriate ports you still need to configure the login manager to allow XDMCP connections and to allow

1. On the server open a terminal window (unless you editing this via SSH)
2. Open the GDM configuration command as the root user using the editor of your choice (I like vim)

   sudo vim /etc/gdm/custom.conf

3. Add the following in the [XDMCP] section

   Enable=true

At this point you should restart the login manager by issuing the following command

[webadm@elmo ~]$ sudo gdm-restart

After the login manager process has been restarted, you are finished with the server side of things.

Step 3: The client firewall

On the Mac OS X side of the security equation, you will need to change the way your security setup is configured for this to work.  By default, the Mac OS X firewall in Leopard is set to allow all incoming communications.  While this is all great and wonderful, it is really insecure, and you should change it.

1. Open System Preferences
2. Click on Security
3. Click on the lock to authenticate (if necessary)
4. Click on Firewall
5. Select the radio button next to Set access for specific services and applications

Now that you have set some better security options, you have to specifically allow X11 and Xephyr to accept incoming connections

1. Click the plus sign at the bottom left of the white box on the Firewall tab
2. Press CMD + Shift + G on the keyboard to bring up the Go to the folder box
3. Type the following into the text field and click OK

   /usr/X11/bin

4. Select Xephyr from the list and click Add
5. Click the plus sign again
6. Navigate to Applications
7. Select Utilities then select X11
8. Close System Preferences

Step 4: Connecting with Xephyr

Open X11 from the Utilities folder inside Applications.  When you open X11 an xterm window should open up automatically.  In the xterm window type the following command where SERVER_NAME is replaced by the FQDN of the server you are connecting to:

Xephyr -ac -query SERVER_NAME -screen 1280x1024 -br -reset -terminate :1

This should open an X11 window showing the login screen of the server.  If you wish to automate this process a little, you could use the customize option in the Applications menu of X11 to add an entry that saves you from having to enter the command each time.

References:

One of the touted features of the unibody design MacBook Pro line was the introduction of two different graphics processing units [1].  Initially they shared two Nvidia GeForce chipsets. Beginning with the Core i5 and Core i7 models, this was changed to use an Intel HD Graphics chipset and either an Nvidia chipset or an AMD chipset (depending on the model and year of introduction).

This was put forth as a great power savings feature, but as many users have seen it has had unintended consequences. [2, 3, 4]

I have had no real issues involving this until I fired up Photoshop CS5 last night and found that the canvas window was missing! Now to be fair this doesn’t appear to be a problem on Snow Leopard, but nonetheless it was passing strange.  After some diligent searching, I discovered that the solution appears to be turning off the automatic graphics switching and rebooting the laptop. (Hint: it’s in the Energy Saver system preference pane)

After doing this all was once again well with Photoshop.  So if you encounter some odd graphics issues with your unibody MacBook Pro and Lion, try it and see if it helps.

References