Andrew Fore

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

When you setup a website to be managed by Contribute, the name that shows up in the client for the connection description is generated from the text of the title tag of the index page of the website.

For setups where you are only managing a single site, this may not matter, but if you have a system where you use a development server and a production server, you may want the connection string to depict which server the user is editing and publishing to.

In order to change the text of the description you have to alter some text in a few files on the CPS management server.

In the installation directory of CPS, there is a database directory. This is the location of the files that are specific to the individual websites that are being managed.

The files in each site being managed are in a directory that is “numbered”, the number relates to the numerical order in which they were set up. If you remove a particular site, the numbers are not reused.

In each of the site directories there is a file named: connection_key.stc

This file, in XML format, contains a localinfo tag. The attribute sitename is the text that shows up in the Contribute client on the start page.

Once this is updated and a user logs into the Contribute server, the client connections are updated.

While this may be enough on it’s own to effect the change desired, the original name is still referenced in the cthub file for each individual site. I changed the name in both locations for completeness.

At VSU, we are implementing the Adobe (formerly Macromedia) Contribute Publishing Server and CMS.

This is a two-piece system that involves a client-side component (Contribute) and a server-side component (CPS).

We are running this on a Linux server, so we needed an easy way to start the service up should a system reboot occur.

Now Macromedia included a very simple shell script that made a call the included OEM Jrun binary to start the server. The only problem is that it had no facility to plugin to the chkconfig tool that can be used to manage services in the various runlevels.

So I wrote a very simple one:

#!/bin/bash # # CPS Startup script for the Macromedia Contribute Publishing Server # # chkconfig: 2345 80 20 # description: The CPS is the backend to manage the Macromedia Contribute CMS. # processname: jrun -nohup -start contribute-wps # pidfile: none noticed # Source function library. . /etc/rc.d/init.d/functions jrun=${JRUN-/usr/Macromedia_CPS/jrun4/bin/jrun} prog=CPS lockfile=${LOCKFILE-/var/lock/subsys/macromedia_cps} RETVAL=0 start() { echo -n $"Starting $prog: " $jrun -nohup -start contribute-wps RETVAL=$? echo [ $RETVAL = 0 ] && touch ${lockfile} return $RETVAL } stop() { echo -n $"Stopping $prog: " $jrun -stop contribute-wps RETVAL=$? echo [ $RETVAL = 0 ] && rm -f ${lockfile} } # See how we were called. case "$1" in start) start ;; stop) stop ;; status) $jrun status ;; restart) stop start ;; *) echo $"Usage: $prog {start|stop|restart|status|}" exit 1 esac exit $RETVAL

Note that the lockfile referenced was an invention on my part, since the standard startup of jrun included with CPS doesn’t appear to create either a standard lockfile or pidfile.

After creating the file in /etc/init.d directory, you will need to run the following command: chkconfig --add CPS

This will add your new script to the service list maintained for use with chkconfig. At this point all the standard chkconfig commands can be used to manage this.

For more on chkconfig check out the chkconfig online man page at LinuxCommand .

Recently I was tasked to install the Nagios add-on NRPE on two OS X 10.5 servers.

I read a little on the ‘net about it, but no one actually had much in the way of a walkthrough, so I thought I would fill the void.

The basic steps involve compiling the NRPE source, but doing so involves altering some of the code.

Prerequisites

Requirements

1. NRPE source code
2. Nagios Plugin source code

Setup the environment

1. Install OS X Developer Tools
2. Create the nagios user using Workgroup Manager
3. Create the nagios group using Workgroup Manager
4. Change the primary group for the nagios user to be nagios

Compile and Install the Nagios Plugins

1. Open Terminal (/Applications/Utilities/Terminal.app)
2. cd ~/Downloads/ – see note 1
3. Extract the Nagios plugins source code tarball
   • tar xvf nagios-plugins-1.4.13.tar.gz
   • cd nagios-plugins-1.4.13
4. Compile and install the plugins
   • ./configure
   • make
   • sudo make install
5. Update the permissions on the directories
   • sudo chown nagios:nagios /usr/local/nagios
   • sudo chown -R nagios:nagios /usr/local/nagios/libexec

Compile and Install the NRPE daemon

1. cd ~/Downloads/ – see note 1
2. Extract the NRPE source code tarball
   • tar xvf nrpe-2.12.tar.gz
   • cd nrpe-2.12
3. Update the configure file for Mac OS X compatibility
   • vim ./configure
   • on line 6673 change the text to read
     • if test -f “$dir/libssl.dylib”; then
4. Compile the NRPE daemon
5. Install the NRPE plugin, dameon and example config file
   • sudo make install-plugin
   • sudo make install-daemon
   • sudo make install-daemon-config

At this point you will have the NRPE daemon itself correctly installed.  To run it just execute the following in a terminal:

/usr/local/nagios/bin/nrpe -c path/to/config -d

This will start the daemon using your config file in daemon mode, instead of xinetd mode.

In order to get the daemon to startup at system boot you will need to create a launchd plist.  I will be writing this up for post later today.

Recently we acquired a new firewall to place in between our datacenter and the rest of our network.  This is a fairly standard security procedure used to isolate the servers from the rest of a network that can be loaded with all kinds of nasty spyware, malware and viruses, not to mention really nifty people that want to violate the security of the data.

Security is a two-edged sword for many systems folk. Firewalls are really great security tools, yet they can also get in the way of nice tools that provide access into the servers for remote administration.

Prior to the placement of the new firewall, I often used XDMCP sessions to access my unix servers from the comfort of my office, rather than traipsing to the data center to use the console.  While these servers do have iLOM ports, there are some interface issues that make their use less elegant that I would wish.

After the new firewall entered the equation, I found that my normal XDMCP setup using Xephyr on my iMac no longer worked for some reason.  It appeared that some of the rulesets were blocking either the particular TCP or UDP traffic necessary for the communication to work.  Rather than worry our firewall administrator with troubleshooting the issue, I decided to find another way in via ssh.

It turns out that I could easily tunnel an X11 login session through an ssh session.  Given that I have sshd configured to allow for TCP forwarding I was able to use an Xnest session that was initiated after logging in via ssh.  Here’s the process I used:

First you need to initiate the ssh session while enabling X11 TCP forwarding.  Depending on your particulars this can be done by one of the following commands:

bash-3.2$ ssh -X server.example.com

bash-3.2$ ssh -Y server.example.com

The next command is executed on the server, but the X11 session is actually running under the X11 installation on the local workstation:

Xnest :1 -geometry 1280x1024 -query localhost -terminate

Here’s a breakdown of the command parameters:

:1

determines the X11 screen to be used on the local workstation, screen 0 is the default screen used for X11

-geometry

set the screen resolution to use for the X11 window on the local workstation

-query localhost

determines which host to actually make the connection with

-terminate

closes the XDMCP session once the user logs out

All of this can actually be accomplished with a single step, by chaining the ssh login command with the Xnest command:

ssh -X REMOTESERVERNAME Xnest :1 -geometry 1280x1024 -query localhost -terminate

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.
Continue reading

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.
Continue reading

One of the standard methods of configuring Mac OS X in the enterprise has become known as the magic triangle or golden triangle. This is generally described as a setup involving Active Directory (AD) for authentication of the clients and services and Open Directory (OD) for managing the client preferences.  The triangle comes from the fact that you have the Mac clients talking to AD, the clients also talking to OD, and the Mac server talking to AD. (Apple officially calls this the magic triangle setup in the Snow Leopard Server Open Directory Administration documentation.)

One of the issues I ran into was granting a non-admin in AD the ability to perform administrative functions on the clients bound to AD.  The way this is handled with the Windows clients is for the particular AD user to be a member of a group that grants local administrator privileges.

Unfortunately there is no simple equivalent on the OD side of the equation to allow this for the technicians working on the Mac OS X clients.  If you add an AD user to the system level group Open Directory Administrators using Workgroup Manager (WGM) this has no effect on whether a user is granted local administrator privileges to a connected client machine.

The solution to this involves:

1. creating a group in OD to hold the members of AD that should have local administrative privileges,
2. adding this OD group to the requisite local workstation groups to mimic the standard administrative privileges, and
3. adding the OD group to the sudoers file

Continue reading

At work we currently use version 3.3.3 of the Luminis III platform by SunGard Higher Education.  This product handles our mail and portal needs for the time being.  While it is definitely not the best web-based mail client in the world I have seen worse.

Recently I had received a notice from a friend that he couldn’t read my signed e-mail in the web-client.  After having him forward the message to me as an attachment, I determined that the problem had to do with my digital signature.

I use Apple’s Mail client for OS X 10.5.  Currently I also have GPGMail by Stéphane Corthésy installed so that I can seamlessly use my GPG keys to sign and encrypt my e-mail.  After sending an unsigned message and finding out that it went through with no problems, I started investigating the options provided by GPGMail.

It turns out that I had checked the option to use OpenPGP/MIME by default.  Apparently this creates an message body that the Luminis III web-mail client can’t read.  So if you are running into this problem with a web-based client, check to see if your messages are going out as OpenPGP/MIME.

At work I am in charge of running our Macromedia Adobe Contribute Publishing Server.

Since I like to duplicate my work environment on my laptop for local development, I needed to install JBoss 4.0.5.GA.  I won’t go into why we are running such an old version, that’s all Adobe’s fault.

Installing JBoss

1. Download the JEMS installer for 4.0.5.GA from the JEMS Installer Downloads page at jboss.org.
2. Execute the installer:
   java -jar jems-installer-1.2.0.GA.jar
3. If you get asked to allow java to talk through the firewall, choose Allow.
4. The default installation location is: /Applications/jboss-4.0.5.GA

   It will create the directory if it doesn’t exist already.

5. During the install process choose the Advanced install method.  This allows you to pick your database environment, as well as making the process of securing the JMX Console and JBoss Web Console much easier.

Starting JBoss

1. Open a terminal
2. Goto the install location binary directory (I used the default)
   /Applications/jboss-4.0.5.GA/bin/
3. execute run.sh
   ./run.sh -b 127.0.0.1 &
4. You will see the output of the startup process show up in the terminal window.

Stopping JBoss

1. Open a terminal
2. Goto the install location binary directory
   cd /Applications/jboss-4.0.5.GA/bin
3. Run the shutdown script (don’t forget to authenticate!)
   ./shutdown.sh –server=localhost:1099 –shutdown -u admin -p password

Notes

• The default port for the HTTP connector is 8080
• The SSL connector is disabled by default

In the application selection process for 10.5, the X11 maintainers elected not to include Xnest.

While most users will probably not need this, since you can export X11 application through a SSH connection, sometimes it is quite handy to have the entire gui session available from a remote server.

I use this when managing some of my Solaris servers. With X11 on 10.4 this was readily available, but after installing 10.5 I found that it had not been included. Initially I just copied the binary from my 10.4 install into the expected location and tried to use it. However, as I expected, the results were not particularly satisfactory, given that the binary was built against a different X11 source tree.

After posting some of my compile issues to the X11-Users mailing list (archives are here), the code maintainer released a patch to the xorg code that fixed the symbol issues that had reared their ugly heads.
For those who are interested in making it work here’s what you need to do:

1. Follow the first seven lines under the section Source installation on the XDarwin wiki page
2. Change the configure instruction line to be as follows:
   ./configure --prefix=/usr/X11 --enable-xnest=yes --with-mesa-source=`pwd`/../Mesa-6.5.2
3. Continue with the rest of the source instructions as posted in the wiki page
4. After copying the new Xquartz binary over, copy the Xnest binary as well:
   sudo cp hw/xnest/Xnest /usr/X11/bin/
5. Don’t forget the manpage:
   sudo cp hw/xnest/Xnest.1 /usr/share/man/man1/

Now you have a nicely patched install of the latest fixes for Xquartz as well as the Xnest binary.

If only compiling Xpehyr was working now…sigh.

Resources:

• Applications supplied with the default X11 install on 10.5

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.
Continue reading