Unable to Publish a Google Apps Spreadsheet Form

Google Apps is a great service that Google provides to organizations and businesses, large and small.

But some times Google Apps can be very frustrating, just like any software. Besides bugs and "occasional odd design choices", the fact that things often change under the hood, albeit (or especially?) in small ways, some times make it more difficult to find effective support in the large user community.

Here is one thing I am doing for my daughter's high school FIRST Robotics Competition team: put a form on the team's website for T-shirt orders. I have been coaching the small web team to build the website using Google Sites and other services. So naturally a Google Docs spreadsheet form is my first choice for this job.

I designed the form and inserted it into a page as a gadget. Then I got this message on the page telling me that I don't have permission to access this item, regardless if I am logged in or not. As a matter of fact, I do have permission to access the form and the spreadsheet.

Googling the problem led me to Richard Nichols' blog entry about the exact issue. But I have in effect, although not in words, the exact same setting as he wrote in the blog: Essentially users must be allowed to share documents outside the domain. I have even tried to share the spreadsheet associated with the form to the public, but even that did not change the situation.

The trick posted in a Google Docs help forum does not work either. I have tried both embedding the form from the spreadsheet and inserting it as gadget in Google Sites' page editing function. So far nothing has allowed me to see the form on the site.

I guess one thing I could try is to implement the form outside the domain, using a generic Google account. But it really should not be that frustrating!

Ubuntu 11.10 Unity Annoyances

I gave up on Unity on my netbook long ago, but I thought I'd give it a try on my desktop. The longer I use it, the more it annoys me, in many small ways, and below is a small list of them:

1. Application menu
   
   You have to move an application window all the way to the top of the screen so that its top edge touches the app panel to make sure you have the application menu. Otherwise, for example, if you are using GIMP, and there is another application window between the image window and the app panel in the background, moving the mouse across the app in the background up to the app panel will make it display the background application's menu instead of GIMP's menu.
   
   I realize that this may be the residual effect of me setting up Gnome desktop to focus on the window where my mouse pointer is. I could probably figure out how to turn that off -- but I don't want to. I like to have the ability to enter text using the keyboard while the application may be sitting in the background.


2. Missing application logos
   
   Many application are still missing logos in the applications panes. I was hoping the situation would turn better as 11.10 updated over time, but that has not happened yet.
   

I googled a bit to see what others thought. Some people seem to like it. But more do not. A snapshot of a vote in a TechRepublic article:

I think I am going back to Gnome for now.

Cisco IOS User Privilege

Nothing new in this entry. Just to jot down a couple of thoughts about the IOS command below:

aaa authorization exec default local group tacacs+

In Cisco IOS, a user may be assigned a privilege level from 1 to 15 for accessing a device. Each privilege level may be configured to do different things, but the most simple and common practice is likely that a user is given level 1 privilege, which by default only allows the user to do things like showing status, etc. When a user needs to change configuration on the device, he or she may use the enable command to gain the proper privilege, usually level 15.

There are a couple of ways for that privilege elevation to be authorized. One common way is to configure an enable secret on devices. The argument is that the device could be configured even when it loses connection to an authentication/authorization (AAA) server.

But on the other hand, if one by mistake messes up the enable secret configuration on a device, having an alternative authorization route allows that mistake to be fixed relatively easily without having to physically visit the device, provided that the only thing wrong on it is the enable secret and it is still talking to the AAA servers.

That leads to the IOS command line above: It says to try the local enable secret first when a user asks for the enable privilege level; If that fails, try the TACACS+ server(s) configured in the device.

References:

• How to Assign Privilege Levels with TACACS+ and RADIUS
• How to Configure tacacs Authentication and Authorization for Admin and non-Admin users in ACS 5.1