Can I ask a series of pointed questions about your use case? They're not intended to imply that you're trying to do the wrong thing, but might help you decide where effort is best spent and how you want to operate your platform overall, regardless of building display servers.
1. Who is logging on to the console in the data centre with direct physical proximity? a. How are you going to manage credentials and authentication for these users to the nodes? b. Under what circumstances would they need to do this instead of a network login? I'll assume there's a limited number of such use cases, around initial install or recovery after hardware failure. I'm interested in other cases you have in mind if that assumption is incorrect. 2. What GUI tools are needed for these use cases? a. Can they be run over the network (including ssh X forwarding), if the first step of a recovery/install workflow is "get networking (back) up"? 3. What other off-host facilites would an operator need access to while performing these tasks on-site? (Examples: reference wiki pages with procedure steps and config snippets, ticket and tracking systems to record activities and fault information, chat and collaboration tools with remote colleagues, ... ). 4. Is there likely to be a need to perform the same operations on multiple hosts together, or compare config between hosts? 5. Would it be useful for operators to be able to copy/paste or even screen-share between the host(s) being worked on and these external apps and colleagues? 6. How are you going to manage the authentication-to-external-services and integration of these tools onto the potential SmartOS GUI console, while not exposing your admin accounts and GZs to additional possible threats (and not adding all the "fluff" of library dependencies you want to avoid)? In consideration of these questions, you'll get a better focus on your operational design (rather than a particular technical dependency). You might, for example, reach a conclusion that your time is better spent developing an operator desktop SoE, based on a laptop or RPi or whatever. You might also find that this device is then also useful for other purposes, like providing DHCP and netboot images, etc. Again, if you decide you really want a GUI head on each node, I'll be curious about your reasons - even for a small PoC with few nodes. On 28 Oct. 2017 00:18, "Lonnie Cumberland" <[email protected]> wrote: Hi Jonathan, Thanks for getting back to me. I actually had mentioned this to someone that replied to me so as to give a little purpose for the exploration and as to why I was interested in SmartOS specifically over OpenIndiana which was suggested as well. For this POC project there are 2 area that I am considering, but the key to wanting to use SmartOS is that it has a very small cloud level footprint and is geared toward just being a hypervisor which is exactly what I need. I do not really want all of the extra fluff that is included in other Illumos-based distributions that are geared towards being more of a "general" OS. This is really more towards an extreme minimalist hypervisor approach without the external clustering at this step which may come up in a future discussion. The 2 areas that I am seeking to explore with SmartOS are these: 1.) Possibly adding a GUI over the CLI for local administration. (i.e. very simple and small XServer although there are a number of possible options (MicroXWin, Y Window System, Wayland Display Server, DirectFB, Xynth Window System, Fresco, Metisse, and KDrive "or TinyX" which may/may not work with Ilumos-based systems) 2.) Ultimately, I would also really like to have a local XServer with just a single VNC/Spice client either in the global zone or another zone so that I can remote into the other local zones. These are the current interests for this basic exploration. Of course, Triton SDC and Danube have it covered for clustering in the much larger data center approach and this was mainly just to play around with local hypervisors on a single system. The idea is a simple, but very tight, and extremely small footprint hypervisor and SmartOS seemed to be the best candidate thus far. Cheers, and just playing with some ideas, Lonnie On Fri, Oct 27, 2017 at 8:30 AM, Jonathan Perkin <[email protected]> wrote: > * On 2017-10-24 at 23:19 BST, Lonnie Cumberland wrote: > > > Long story short, I think that I would like to take a copy of SmartOS and > > see about adding a very small XServer and just one X-application to the > > global zone. > > > > With this in mind, I was wondering if anyone has done something similar, > or > > might be able to offer some guidance as I am really coming from the > > Windows/Linux world and my Solaris background is very limited. > > It's possible but will require you to build your own version of > SmartOS. Off the top of my head you'll need to include at least the > xsvc driver, as well as pre-populating the required users. It's not > particularly difficult, but will require quite a bit of trial and > error until you have everything necessary baked into your image. > > For what it's worth I use Tribblix as my test distribution for the > illumos pkgsrc packages, it's a nice small distribution that generally > gets out of the way and lets me focus on testing our packages to > ensure they work across illumos distributions. My test usually > involves installing a full set of Xorg and some desktop environment > which works fine so that is certainly one alternative option. > > Cheers, > > -- > Jonathan Perkin - Joyent, Inc. - www.joyent.com > *smartos-discuss* | Archives <https://www.listbox.com/member/archive/184463/=now> <https://www.listbox.com/member/archive/rss/184463/27748248-82bb0956> | Modify <https://www.listbox.com/member/?&;> Your Subscription <http://www.listbox.com> ------------------------------------------- smartos-discuss Archives: https://www.listbox.com/member/archive/184463/=now RSS Feed: https://www.listbox.com/member/archive/rss/184463/25769125-55cfbc00 Modify Your Subscription: https://www.listbox.com/member/?member_id=25769125&id_secret=25769125-7688e9fb Powered by Listbox: http://www.listbox.com
