Lars Tunkrans schrieb:
Damon Getsman skrev:
I am currently administering a Sun Ray cluster utilizing SRSS for a
WAN with approximately 40 users. I hope you will forgive me for my
neophyte level of knowledge on this setup. Their desktops are all
GNOME 2.22, and the cluster is set up to allow their access with
individual smart cards.
I have had a problem described to me for a project by the
administrator who is still training me on the admin of this system, as
my previous knowledgebase is basically all networked linux PC
administration. The problem is, as I have been told, an issue with
the enlightened sound daemon when the users login multiple times at
once
Of course there is problems if you use the same login account
simultaneously by several individuals.
I don't think that is what he is doing. On a Sun Ray system one user can
easily have multiple graphical sessions on one system, just as you can
have multiple simultaneous non-graphical (e.g. ssh) sessions.
This happens if:
- A user logs in both with and without a smartcard
(this may happen inadvertently, if the card or a card reader is broken)
- A user logs in with multiple smartcards
- A user logs into multiple DTUs without a smartcard (possibly
inadvertently, see above). As they are on Linux, they can't be using
NSCM, which would prevent that.
[Of course in all cases the user does not log out when moving away from
the initial sessions - this would be normal if hotdesking is the intent.]
1) Your Audit Trail becomes utterly useless. You wont be able
to tie an action to a unique
individual.
Doesn't apply, if it is the same individual every time.
2) Security becomes a nightmare. People is careless with
protecting their passwords because -
everyone knows them anyway.
Not an issue in the mentioned case.
3) Unix was not designed for this purpose .
Unix can very well accomodate multiple simultaneous sessions (of
whatever kind) for the same user.
4) Gnome was not designed to do this.
I'm not so sure. Much in Gnome is designed to clearly distinguish
between 'user' and 'session'. But there may be some parts that aren't.
Gnome creates multiple sockets in /var/tmp that connects
the gnome system to the
devices it is attached to. This setup is supposed to be one
user to one set of devices for each login ID.
What kind of 'devices' do you mean? Several of these /var/tmp files are
generated with unique names and transported into the session by
environment variables, so they are per-session rather than per-user.
Other files - most notably bonobo and gconf lock files - are in fact per
user. Apparently that is intentional (at least for gconf it actually
makes sense). Whether clients of these services always properly take
this into account is another issue.
From this mail it appears that ESD is one example of a session service
that doesn't properly support multiple sessions per user. But then most
Gnome software is probably developed by people who only ever use systems
with a single attached console to which all I/O hardware is associated.
It certainly is the case that some applications (e.g. OpenOffice.org or
Mozilla/Firefox/Thunderbird) don't support multiple instances for one
user on the same machine (at least not without special effort to use
multiple different 'profiles').
FWIW I often use additional, short-lived sessions on my Sun Ray under
the same account for testing purposes (with multiple cards), but I don't
heavily exercise the desktop functionality on the secondary sessions, so
I don't know what breaks.
(I'm not even sure how this is possible with smart card logins;
I'm just running with what I've been told at this point). There are
three servers which the user logs into from the various terminals.
Evidently they are set up to round-robin the resources. Anyway, when
a user is logged into all three machines and attempts another login,
obviously it goes back to the first server in the list. When this
happens, the /tmp/.esd socket and/or lockfiles prevent sound
capability from the most recently authenticated terminal.
I was wondering if this is a common setup and if there are any
resources that I can use to try to find information on this setup to
fix the issue. I could write a python script to be invoked at some
point while gdm is starting up, but I'd like to find a fix that isn't
as kludgy, if at all possible.
NO dont try that - fix the root cause of the problem. If you have
an application with
only a common login for all users. It should be reinvented. This old
style app will never make it through any kind of Security Audit.
You simply got to know, Who made what at which point in time.
As pointed out above, I don't think that is the issue.
OTOH it may very well be the case that having multiple sessions for the
same user is not the intent. So it still does make sense to find out why
this happens.
Being as I'm going to be administering this system for some time in
the future, I'm also interested in any resources you could point me at
that would be relevant to this sort of setup. I haven't had much luck
finding documentation on the sun website relevant as of yet.
Thank you for your time and help. :)
HTH
- Jörg
_______________________________________________
SunRay-Users mailing list
[email protected]
http://www.filibeto.org/mailman/listinfo/sunray-users
