-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I am curious -- given that authentication modules, etc, are configured at build time, what configuration would be considered for an Appliance? LDAP auth, JAAS auth, JDBC auth ....? Perhaps LDAP (due to common use) with an externalized LDAP configuration (perhaps a properties file in /etc/cas?)
Or ... would this appliance really be a Tomcat appliance, with a CAS source + maven installation, so that configuration and deployment is greatly simplified? Or ... would a new app (analogous to the Service Manager) be added for on-the-fly (re)configuration? - -Matt On 04/28/2011 11:19 AM, Aaron Fuleki wrote: > On Apr 27, 2011, at 2:33 PM, Marvin Addison wrote: >> Question remains: would anyone deploy a VM appliance to their >> production architecture? Please, please, speak up if you're >> willing and under what conditions. > > For the love of all that is good in the world, yes! > > There are a lot of smart folks on this list, who work in shops with > dedicated infrastructure teams, or who have ninja-level Java > application development/deployment skills. I think you guys are > awesome, and I've probably bought you many a beer at conferences > and meet-ups, while I ask seemingly inane questions :-) > > I'm from a small school, with a small shop. In my experience, a > small team in a heterogenous environment can't afford to have (or > maintain) the depth of knowledge it takes to config, deploy, and > maintain complex apps like CAS from the source and bare metal. When > even your programmers take support calls in the field, you can run > out of hours in a day pretty quickly. > > If there were some well documented, easy to setup CAS VMs that > covered common use cases, I'd use them in a heartbeat, for both > testing and production. I'd probably have _fewer_ security > concerns with a publicly-vetted config over my own. Heck, I > wouldn't mind replacing our uPortal server with a generic virtual > appliance. I'd love to just pick the flavor of VM(s) closest to my > scenario (standalone, LDAP, Services Manager, Distributed Ticket > Registry, etc.)., provide some details, point it at a database, and > maybe a theme to load, then deploy. I don't care about the OS, the > architecture, etc.; I'd never even look at it as server to support, > just a service. Other than security patching, it'll go months or > years without getting dedicated staff eyes on it again. > > I appreciate how little I probably understand the massive amount of > work it would take to develop production-quality generic CAS > appliances, for even the simplest configuration scenarios. Also, > I'm wary of putting too much stock in my own opinion, as I'm just > one voice. However, I'm equally wary of the responses on a list > where the most active participants are not the target audience. > Jasig projects, and community source movement in general would > probably benefit from lower costs of entry and maintenance. That's > not a dig, just a thought. > > -Aaron > > --------------------------------- Aaron Fuleki Senior Web > Architect Denison University 740.587.5752 > --------------------------------- > - -- Matthew J. Smith University of Connecticut UITS [email protected] -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk25iEoACgkQGER0Au6g8xAKkQCgzRrySHXYwWFfuQ7EM2Om5ocu JL8AoJAOMFqD6TEGk/eXtdKwLl47xH5b =GvFE -----END PGP SIGNATURE----- -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
