[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]
Re: disabling the rhn applet without removing it
- From: Don Buchholz <buchholz easystreet com>
- To: "Discussion of Red Hat Enterprise Linux 3 (Taroon)" <taroon-list redhat com>
- Subject: Re: disabling the rhn applet without removing it
- Date: Thu, 29 Jul 2004 08:59:28 -0700
David Grierson wrote:
Chris Kloiber wrote:
On Wed, 2004-07-28 at 17:47 -0700, Akop Pogosian wrote:
Is there a way to prevent the RHN applet from showing up by default on
the desktop without actually removing the whole rhn-applet package?
...
On a per-user basis. Log in as the user, right click the icon and select
"exit". Then log out, this time selecting the "Save Current Setup"
button. I think that will work for you.
So if you've got a network of n-users (where n is a suitably large
number) all logging into RHEL desktops ... your work-around is for the
admin to login as each user?
...
This may be suitable if you've only got 5-10 users but if say you've
got 100's or 1000's?
Hmmm, 10 users x 10 workstations ==> 100 logins.
Nope. "Homey don't play dat game." In fact, homey
don't play dat game for 5 users x 5 workstations!
My plan would be:
1) don't install 'rhn-applet'
2) those who want it (and, I believe Alex said they
would all be admins) can install the package on
their own.
Best advice I've seen so far on this thread is David's suggestion:
David Aquilina wrote:
While helping deploy RHEL at my former University in a lab situation
(we didn't want normal users seeing the applet) we just removed
other's read and execute permissions. While it would be tedious to do
on multiple systems if you're installing by hand, a line in a
Kickstart %post section should do the trick nicely.
# for h in `cat hostlist` ; do echo ==== $h ==== ; ssh $h chmod o-rwx
/usr/bin/rhn-applet* ; done
Now, that will scale. :-)
I certainly haven't figured out the mysteries of all
this Gnome/KDE eye-candy configuration. It would be
nice to have a deeper understanding of where/how the
configurations are stored/managed. I've had a few
instances of users calling with "KDE won't start" ...
The end result has been along the lines of
# rm -rf ~user/.kde* ~user/gnom* ~user/Desktop
A little too draconian for my (and my customers') taste.
- Don
[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]