Hi, I come late on the thread, but rewinding it I saw you were using SunRay server software. (from your /etc/hosts SRSS's added 192.168.128.1). I suppose it is SRSS 3.x stuff and that you are experiencing your troubles from a SunRay terminal ?
If no, then ignore that mail. Otherwise, perhaps what follows could help : You have to know some tuning have to be done to have SRSS 3.x working properly on TX (SRSS 4, planned for this summer will be the supported one on TX, SRSS 3.x is not supported yet...). Here we go... First, try to check with a directly connected screen/kbd/mouse if you still have the trouble; If you are in the "desperatly headless dilemna" we all "enjoy" one day (or more) then try setting up a second TX host and use remote TX dtlogin to check. Both of your hosts will have to know each other : - from their IP in /etc/hosts or name service if any. - from their IP in /etc/inet/ipnodes - as cipso in /etc/security/tsol/tnrhdb Does it work better ? (it should) If you can't do that (sorry dave), then forget the pod bay doors, and try the following way to avoid deep space loneliness anyway. (reminds me something...) Let's tune your SRSS configuration by replacing your pam.conf with the attached one. (BEWARE : The pam_tsol_account.so.1 of this pam.conf is setted with the allow_unlabeled option, that means any unlabeled host can connect ADMIN_HIGH by knowing root password. This is for debug purpose only and is *highly unsecure*. Once anything works, (or at your convenience) *remove this allow_unlabeled* keyword. Also, make a diff on it from your original so to see what is inside) Last, change your global zone definition in /etc/security/tsol/tnzonecfg with the following one : global:ADMIN_LOW:1:111/tcp;111/udp;515/tcp;631/tcp;2049/tcp;6000-6020/tcp:6000-6020/tcp;7007/tcp;7010/tcp;7012/tcp It will add MLP X11 sessions (not enough by default (3 increased to 20 in the example)), and declare other SRSS daemons on MLP. To make it short, then, reboot. Did that help ? HTH, Bruno. Glenn Faden wrote: > Kelley Shaw wrote: > >> I tried this, and everything went haywire :( I couldn't even get >> windows to come up in the global zone. >> > It should have worked. Make sure that the hostname specified in > /etc/hostname.vni0 exists in /etc/hosts or /etc/inet/ipnodes, and that > is specified as the loghost. > >> I understand what you are saying in terms of the DISPLAY variable >> being passed to the zones, but what I don't understand is how the >> virtual interface (vni0) can be tied to the hostname of the system. >> > > I do this all the time. Take a closer look at the laptop installation > instructions. > >> My understanding of a virtual interface is that it is only reachable >> locally. If vni0 is the configured interface for the IP associated >> with my hostname, how will I communicate with other systems on the >> network? >> > > You're right that the virtual interface can't be used externally. So the > system will just select a real interface when it needs to communicate > externally. > >> I'm guessing I configure a physical interface with a different name? >> My networking skill are a bit lacking, so please excuse my ignorance! >> >> > No problem. It's easy to get this messed up. Solaris doesn't have a > simple way to select vni0 as your primary interface. > >> You mentioned that the DISPLAY variable being passed into the zones >> has no route to my global zone. Is there a way to explicitly create >> routes so that things work using my configuration? >> >> > You shouldn't need to specify any routes to get the window system to > work if you are using vni0. However, you may need to specify routes for > the labeled zone interfaces since they are using different interfaces. > Once you get the trusted desktop working, run netstat -r in a labeled > zone to see if you are lacking a route. If so, you can set multiple > default routes, one per interface, in the global zone. > > --Glenn > _______________________________________________ > security-discuss mailing list > security-discuss at opensolaris.org -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: pam.conf URL: <http://mail.opensolaris.org/pipermail/security-discuss/attachments/20070412/6b03a533/attachment.ksh>
