All | Personal | Sun

« Previous month (Jan 2007) | Main | Next month (Mar 2007) »
 20070309 Friday March 09, 2007

Another AMGH update regarding usernames which can't be overridden

Due to popular demand, I just added this section to the "AMGH HOW-TO Guide":

An unsupported way to make the "username" non-overridable


Today, the username returned by the API can be overridden by the Display Manager (e.g. dtlogin's "Start Over" button).  Some customers would like this setting to be a sort of "security" feature that cannot be overridden by the user, rather than a "convenience" feature as it exists today.  In future, we may add such a feature to the product.  There is an unsupported way to deal with this today, however for non-NSCM logins.  You can edit /etc/pam.conf and remove the clearuser option from the pam_sunray_amgh.so module.  This is not officially supported because it has not been tested by our Quality Assurance team but it has been known to work for some customers. There is no similar recourse for NSCM logins today - the "Start Over" button will clear the preset login name returned by AMGH.

Posted by bobd [Sun] ( March 09, 2007 01:59 PM ) Permalink Comments [5]

Sun IT's AMGH script available

I've gotten permission from our (very supportive) VP Bill Vass to post the source to the AMGH script used by Sun IT internally. I've posted that script to my "blog references" links. Hopefully with the model/object description in the "AMGH HOW-TO Guide" it should be comprehensible. Thanks, Bill!

Posted by bobd [Sun] ( March 09, 2007 01:41 PM ) Permalink |

Update to the "AMGH HOW-TO" guide

I have added a section to the guide which describes why you probably don't want to create an AMGH script using the SRDS registration database, and some tips if you should decide to do this anyway :). It appears to be a common request.
In the spirit of a proper blog (which this really isn't), here's the new text in case somebody would like to comment:


Why not write an AMGH script utilizing information in the SRDS token registration database?


Initially this may seem attractive but keep in mind that AMGH is intended to work across FOGs, so you really ought to use a single, consistent database which can be shared across FOGs and is not subject to FOG-local typos or errors. Such errors can create inconsistent and hard to diagnose behavior.

If you do go this route, do not be tempted to use the "-c" option to utuser. Although it will restrict the output only to relevant tokens it will have an undesirable performance impact since it involves the Authentication Manager (utauthd) at what can be a critical time (e.g. as a server is first coming up many Sun Rays may be connecting to utauthd simultaneously and creating sessions, all going into the greeter at once so invoking AMGH). "utuser -l" generates more output but does not involve utauthd so will actually scale better in such scenarios.

Posted by bobd [Sun] ( March 09, 2007 01:02 PM ) Permalink