Gene Heskett wrote:
On Monday 24 April 2006 16:27, Paul Howarth wrote:
[...]
Where does one find this info since java normally runs silently? I
have copied the java ns7 plugin to the firefox plugins dir, but its
still not found, and running firefox from the shell and doing an
about:plugins leaves a blank shell when firefox is then quit.
You might find selinux denial messages in /var/log/messages - search
for the string "avc: denied" (note the two spaces after the colon).
You can also check to make sure it's an SELinux problem by doing
"setenforce 0" and see if there's still a problem.
You might also try my Java HOWTO:
http://www.city-fan.org/tips/JpackageJava
I followed that, and the first mistake I'd made was in getting the one
with netbeans included, which didn't fly at all. I should have known
when it was 127 megabytes it was the wrong one, but...
Then once I'd fetched the right file and stepped thru all the procedures
in your link above, includeing almost an hour to get 2 of the 3 new
filelists yum needed to get while executing yum-com, and an equally
slow download of the OBDC stuff, it eventually said it was done with an
exit 0. Then I cleaned up the links and files in the plugins dirs,
loaded filefox both as root and as a common user, and voila!
about:plugins now reports a whole screenfull of java stuff.
Splendid!
You could actually have saved on the OBDC download by not installing the
particular java package that required it - as long as you know you're
not going to need it - but it keeps things simpler just to install
everything.
The only place I'll fault the instructions in the above link is that in
the case of FC5, one must change the use of the ~/downloads directory
quoted every so often to be /usr/src/redhat in actual fact, then
everything Just Works(TM).
Hmm, the ~/download directory just represents wherever your browser puts
stuff you've downloaded (sometimes that would be ~/Desktop).
/usr/src/redhat is a very strange place for that to be since that's only
writable by root. You don't run a browser as root do you?
And I have yet another very big grin on my face for a few minutes, till
I run into the next showstopper anyway.
Which isn't this, but this is a slight worry from the log:
Apr 24 21:34:07 diablo kernel: hdc: cdrom_pc_intr: The drive appears
confused (ireason = 0x01)
Apr 24 21:34:09 diablo kernel: hdc: cdrom_pc_intr: The drive appears
confused (ireason = 0x01)
There is no disk in the drive, and its been reading disks just fine.
Could be a hardware issue.
http://lists.xiph.org/pipermail/paranoia/2004-May/001271.html
Now, maybe I'm slow this morning, but my reading of the semanage
manpage makes no mention of setting a 'default' that a relabel will
leave alone.
Using semanage you can change policy for file contexts amongst other
things. This affects the contexts applied to files using restorecon
etc.
Are you saying that if I change it with chcon, its temporary, but if I
change it with semanage its permanent?
'scuse me, but these manpages suck dead toads through soda straws!
(Thats plagerizing a longtime friend of mine you all know)
They seriously need a rewrite in much plainer language. These are
concise to the point of obtuse. WTDO=Way Too Damned Obtuse.
Have to agree there.
SELinux file contexts get set in one of two ways.
1. By an SELinux-aware application manually setting the context based on
the pathname of the object concerned. This is, for example, what rpm
does when new packages are installed, and it uses the file contexts
configured in the SELinux policy you're using. The command "semanage
fcontext -l" lists a bunch of regular expressions matching pathnames,
which rpm searches to find the correct context to use for each
file/directory etc. being installed. The same process happens if you use
"restorecon" or relabel the entire system.
2. By the kernel when a file/directory etc. is created. This does not
use pathnames at all; instead, the context is based on the SELinux
domain that the process is running in and the file context of the inode
for the directory that the item is to be created in. The contexts to be
used in these cases are defined in the SELinux policy and can be changed
by building and installing an SELinux policy module. But that's outside
the scope of this discussion.
The latter is the "normal" and "preferred" way to establish contexts
because pathname-based contexts are a bad idea generally (e.g. supposing
you have multiple links to the same file using different paths - which
should be used to set the context?). The former method is there so that
an initial sane state can be created or reverted to in the event of
policy changes, cock-ups etc.
So, what you're doing with "chcon" is manually setting file context,
just like rpm would do, except you're setting the context to the value
you believe to be correct instead of the one the policy writer believes
to be correct. Since the policy writer may be ignorant of your
requirements, this is a good thing.
How, when you do a "restorecon" or "relabel", what you're doing is
saying "I've got a bunch of files with contexts that may or may not be
correct fow whatever reason, and I'd like them restored to the system
default context". So that overrides the changes you made manually using
"chcon". Well, actually that doesn't happen if the type you've used is
defined as a "customisable type" - that will not be touched, but that's
a side issue here.
Now if you're really sure that you've got the right contexts, you can
actually change the policy itself so that a "restorecon" or "relabel"
will restore the contexts to the ones you've specified. This is done
using semanage to add additional file context objects to the policy. It
doesn't change any file contexts itself, it just sets up the defaults
that will be used if "restorecon" is used or you relabel the system.
Paul.
