Jim, How do I set the uttsc-direct wrapper in SRSS 4.1 with SRWC 2.0? Also, if I wanted to direct a specific DTU to a terminal server, what would be the syntax in the options description of the DTU?
Thanks. Costa -----Original Message----- From: Jim Klimov [mailto:kli...@2ka.mipt.ru] Sent: Monday, December 15, 2008 4:55 AM To: SunRay-Users mailing list Cc: Constantine Morris Subject: Re[2]: [SunRay-Users] LDoms with SRSS 4.1 and SRWC 2.0 Hello Constantine, Monday, December 15, 2008, 2:25:16 AM, you wrote: CM> We are looking to have different companies share the same physical Sun CM> Ray environment but connect to separate TS farms. What are some of the CM> ways we could accomplish this? If the "physical Sun Ray environment" includes the desktop units then (especially then) you'd want to have a single SRSS server or a FOG of servers and direct the end-users to different Windows TS farms according to registered user attributes which are stored by you on the server. I think that AMGH with multiple separate SRSS instances (in LDOMs if possible or separate servers) would be an overkill. At least, if your need to separate the servers does come from splitting network domains for security (i.e. classified and public data processed in different segments), your sunray DTUs for different WinTS farms (and different client companies) should probably be in separate subnets as well. This could also be avoided using some specialized solutions from Sun's partners, or by TSol zones, etc. but that doesn't seem like the way you're tryeing to take. So the presumptions I take while rambling on the rest of my letter ;) is that you are allowed in terms of security to put all DTUs and the SRSS server(s) in one pile, SRSS server(s) can access all windows TS farms, and you allow different users different access by making decisions in software (as SRSS Kiosk sessions) according to some stored information about each user. There's a number of ways you can store end-user info - in DTU or token (smartcard) comments (which are further processed as options by your kiosk scripts), text files, databases, LDAP parameters and so on. The token or DTU comments are stored on your SRSS server when you register the token or DTU into the server's database. If your several servers comprise a FOG, this registration data is replicated to all servers of the FOG. Note: I don't think such replication works across AMGH as well. Personally I'd use my own framework project "FLButselector" (links below), particularly the uttsc-direct wrapper. You'd set the Windows server (TS farm name/ip) and probably user/domain-names in per-user smartcard and/or DTU comments, and this would cause each user to connect to his certain WinTS farm. Each user's kiosk session wrapper would just be uttsc-direct or preferably a simple script like this (to save on session teardowns and restarts due to timeouts of no-login to Windows): -- #!/bin/sh while true; do /opt/flb/bin/uttsc-direct done -- All options to actually run Sun's "uttsc" would be taken from user's parameters (smartcard token if available, DTU otherwise if available, your defaults from config files otherwise). Note that in terms of networking this allows the single SRSS server to see each Windows farm, and may potentially be misused, misconfigured by admins or abused by users to access an invalid (not their) Windows server. For example, if you allow to run some applications from the kiosk-desktop context menu. Of course, users would need to further log-in to the wrong Windows server to do actual harm. However this also allows you to set up specific sessions (i.e. for admins or power-users) which can have completely different sessions (using different wrapperscripts). For example, it can be a predefined list of all or some Windows servers (uttsc-select) or the famous three-button selector (utsplash) to run any program like the shell or browser, etc. These FLButselector scripts can be easily configured per-user, while the script logic remains the same for all users, and data is taken from the custom configs. You do this by creating symlinks (i.e. bin/uttsc-select-constantine pointing to bin/uttsc-select) and custom config files (etc/uttsc-select-constantine.conf) which in this example would define your own list of windows TS servers. For my script framework and its READMEs see sources or packages: https://svn.sun-rays.org/viewvc/FLButselector/ https://svn.sun-rays.org/viewvc/FLButselector/trunk/release/FLButselecto r-pkg-solaris-1.1.0.zip?revision=52&pathrev=52 http://www.cos.ru/sunray/FLButselector-pkg-solaris-1.1.0.zip //Jim CM> -----Original Message----- CM> From: sunray-users-boun...@filibeto.org CM> [mailto:sunray-users-boun...@filibeto.org] On Behalf Of Ceri Davies CM> Sent: Sunday, December 14, 2008 4:33 PM CM> To: SunRay-Users mailing list CM> Subject: Re: [SunRay-Users] LDoms with SRSS 4.1 and SRWC 2.0 CM> On Fri, Dec 12, 2008 at 10:50:45AM -0500, Constantine Morris wrote: >> Does anyone have any insight on performance and usability of Solaris >> LDoms on T1/T2 processors and the SRSS/SRWC? We are trying to CM> configure >> an environment with multiple SRWC's connecting to completely different >> Terminal Server farms without having to purchase separate physical >> servers for each instance. Is this approach a recommended/supported >> approach for Sun Ray deployments? CM> What limitation are you trying to work around? Is this is a security CM> domain thing? You could very well use a single OS instance and have CM> different clients which are connecting to different backend TS farms; CM> I'm not sure where you see the need for ldoms, so could you please CM> expand? CM> Ceri -- Best regards, Jim Klimov mailto:kli...@2ka.mipt.ru _______________________________________________ SunRay-Users mailing list SunRay-Users@filibeto.org http://www.filibeto.org/mailman/listinfo/sunray-users
