Bob Doolittle wrote:
Paul Greidanus wrote:
Bob Doolittle wrote:
No, not if you avoid the "-c" option to utrestart. Restarting
utauthd is safe and will result only in a temporary disconnection
of the DTUs - they'll immediately bind to the other server.
But, the other server tells me that they won't have the login sessions
still connected.. possibly they could reconnect to the backup, but
that's not solving the problem..
I'm sorry, I don't follow you. What do you mean
"the other server tells me ..."?
Do you *want* people to lose their sessions on the backup
server? If so, use utrestart -c. If not, use utrestart. I don't
know your policy and whether you use smartcards or not,
but it's like I said before:
- If you are using smartcards, as soon as people insert their
smartcard, the dedicated server will do session location,
and if the smartcard has a session on the backup server, it
will connect to it.
- If not using smartcards, and using NSCM, as soon as the
user enters their name, if they have a session on the backup
server they will connect to it.
- If not using smartcards, and not using NSCM, or
- If using smartcards, and people left their cards in and don't
remove/reinsert them, and
- people don't power-cycle the Sun Ray
Then if people had a session on the backup server they will
not connect to it. They must remove/reinsert their card or
power cycle the DTU (and not login to the dedicated server)
to connect to their session on the backup server.
Not sure what I was thinking there either.
In my case, I don't want people to loose sessions, and I'm running 3
servers as a cluster, paired, and equal.. I don't care which server the
sessions is on. I'm using both NSCM and smartcards for the privileged
(me, I need to buy a box or two, I just have one).. This is the topic
that started the thread, but I think we diverged it pretty far..
If you use NSCM, this isn't a problem, because session
location and load balancing happens after you enter
your user name, at which time both servers will be
up.
The only problem is people who leave their cards in
over night. In that case, if they don't remove and
then reinsert their cards (or power-cycle the Sun Ray)
in the morning, they'll log in and get a new session on
the dedicated server, which is not what you want.
Shouldn't there be policy against this sort of thing? It's a huge
security risk IMHO
Explain the security issue here please.
It's a physical security issue, like getting users to lock their
session, not a network security thing.. This is sort of especially
needed in my area because the card removal doesn't lock the session..
but, this is really dependant on the security needs of your environment.
As soon as a user's session is disconnected it is
automatically locked (see man -M /opt/SUNWut/man
utxlock). So card removal *should* lock the
session. If not, you may be seeing one of the
many xscreensaver bugs :-( If you have the latest
patch for xscreensaver it should work properly (do
you have pam_sunray.so as 'sufficient' on top of
the xscreensaver stack in /etc/pam.conf? You need
this, and depending on the order you installed
SRSS and xscreensaver patches and other upgrades
you might not have it).
Well, it starts with windowmaker, and I've not really tried to fix it..
I'm not too concerned about the token being the only line of defence, be
it smart card, or NSCM session.. the DT and JDS logins do lock as expected..
but you could do something like lockstep the 2 machines together, and
run them like that.. breaking off a half of the mirrored machines
wouldn't kill the sessions. But, now we're getting into redundant
hardware type of setup, which may be a nuke to kill a flea type of
setup..
Sorry, we don't make any redundant
hardware/lockstep fault tolerant machines any
more, and less and less manufacturers are doing
this. It was just not cost effective for the last
fraction of a percent of RAS.
I wonder however, if it would be possible to do this sort of thing in
hardware, given a fast enough connection between the boxes, and a low
enough latency... but, this is a question for a PhD thesis, or a dozen
of them.. and well outside of the realm of SunRay :)
I'm imagining something like a "disconnect all"
capability that would redistribute all idle sessions
across the servers which are currently up and
online.
Ok.. I wasn't aware this was an issue.. I'm not running a large enough
environment yet to have run into that issue..
But you are, with your backup/dedicated scenario!
If you could "disconnect all" on the backup and
dedicated servers right now, you wouldn't have to
worry about the scenarios I describe at the top of
this mail. There would be no possibility of any
"orphaned sessions". We'd probably have to do
some coordination in SRSS to avoid immediately
granting sessions to give time for all the servers
to start participating in LB/SL.
Well, I won't see it, because I'm not really caring which server the
clients are on.. but that's above.. The only time I'd be turning a
server into a "backup" is for maintenance, and then broadcast to the
users that it's going down, give em an hour or something, and then
/etc/init.d/utsvc stop (or svcadm something maybe..), no orphaned
sessions at that point.
I'd be surprised as well.. I can't see that it's impossible, but I
will concede impractical, and probably not financially fesable to
build this for such a small problem.. it's not the end of the world
for a few users to loose their session in the case of a server
failure. They're able to use their session much quicker then if they
had the hardware failure on a desktop under their desk.
My assumption stated above is non-redundant
hardware, and I still maintain that with such an
assumption this problem is intractable for the
general case of processes. I agree it can be
solved with redundant hardware, but then your
price tag more than doubles, and the computer
manufacturers who tried to make a living producing
such hardware are long gone (or at least those
lines of computers are - Sun tried this also at
one point).
Yup, at some point, you have to ask, is the session worth the cost, and
the answer is probably no almost all of the time, if not all of the
time.. and it's a huge investment, and there are not enough customers
who NEED to have sessions up all of the time.. Plus, the hardware and
software really don't fail all that often in my experience, redundant
power, redundant mirrored disk, ecc ram.. most machines can take some
failures.. and if you really need it, go with an enterprise scale box,
so you can swap out most of the parts while the machine runs with
dynamic system domains and all that fun stuff..
_______________________________________________
SunRay-Users mailing list
[email protected]
http://www.filibeto.org/mailman/listinfo/sunray-users
