hostname
by tony.chamberlain@lemko.com
Someone wants to use java and get a host name from an IP address.
I know how to do it lcoally through /etc/hosts BUT the host file does not
have names for every IP address reachable.
Someone found http://www.faqs.org/rfcs/rfc953.html which looks like you are supposed to be
able to use port 101 of a machine and connect to it and echo a command and it should respond.
It also says HNAME should give the host name so I tried (from 192.168.5.191)
echo HNAME | nc -e cat 192.168.5.15 101
which I would guess should return the host name for machine 192.168.5.15, but I got
no response and a return code of 1. There is probably something I am overlooking.
Anyone know how to query this port? (both machines are CentOS 4.5)
16 years, 5 months
Re: can't get Xnest to work against Fedora 7
by Hugh Caley
> *
>
> ______________________________________________________________________
> Frank Cox wrote:
>
> I was making a custom gdm theme a month or two back and couldn't get xnest to
> work for me then either. I eventually gave up and just installed my theme and
> logged out to see how it worked. Which was a lot more inconvenient than it
> needed to be but at least I got the job done.
>
> xnest used to work for that purpose -- the last time I made a gdm theme was in
> the FC6 or FC6 days, I think, and it worked fine then.
>
>
> For _that_, just enable more than one X. On typical systems, it will
> appear at VT8, and on.
I can get the Xnest login to succeed if I turn "Accessibility" off in
gdmsetup.
I've filed a bugzilla bug about this.
Hugh
--
Hugh Caley, Linux Administrator
Aldon Computer Group
6001 Shellmound St. Suite 600
Emeryville, CA 94608
(510) 285-8542 | hughc(a)aldon.com
16 years, 5 months
PCI: BIOS BUG #81[00000011] found
by Dan Barnes
Has anyone come across this problem when
booting Fedora 7? If so how did you fix it?
PCI: BIOS BUG #81[00000011] found
This is with kernel version "2.6.21-1.3194.fc7".
Thanks
Dan Barnes
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
16 years, 5 months
Problem with yum
by Timothy Murphy
I find yum a marvelous resource, so the following should not be taken
as even a mild criticism.
I recently tried to download gnokii-devel,
but I was told this required an older version of gnokii than I had,
as shown below.
I'm not sure where I got the "fc8" version I have -
I don't normally open any non-standard repositories,
but I might have done so in error.
I tested "yum remove gnokii" but this would have removed
dozens of packages.
I'm just wondering: what is the standard way of dealing with this
yum quandary, if indeed there is a way?
--------------------------------
[tim@elizabeth ~]$ sudo yum install gnokii-devel
...
Resolving Dependencies
...
--> Processing Dependency: gnokii = 0.6.14-3.fc7 for package: gnokii-devel
...
Error: Missing Dependency: gnokii = 0.6.14-3.fc7 is needed by package
gnokii-devel
[tim@elizabeth ~]$ grep gnokii /var/log/rpmpkgs
gnokii-0.6.17-1.fc8.i386.rpm
--------------------------------
16 years, 5 months
Opening .rar files
by Tony Crouch
Hi All,
A friend has sent me a file which I need to open which has a .rar file
format.
I was wondering if someone might be able to point me in the right
program direction to getting the file opened.
Thanks for your help.
All the best.
Cheers,
Tony Crouch
16 years, 5 months
speedy recompiles
by Michael D. Berger
On FC7, in compiling my libraries, I see that
re-compiles of C++ code goes much faster than
than the original compiles. I delete all *.o
between the compiles. How does that happen?
Thanks,
Mike.
16 years, 5 months
how does "du" deal with hard links?
by Robert P. J. Day
i'm wondering if i should be surprised about something i just
noticed WRT how "du" tries to avoid [re]counting files that it's
already seen via hard links.
given the following directories that are git repositories that i'm
playing with just to see the space savings i might get:
$ ls -ld git*
drwxrwxr-x 15 rpjday rpjday 12288 2007-11-01 07:53 git
drwxrwxr-x 15 rpjday rpjday 12288 2007-11-01 08:23 git.local
drwxrwxr-x 15 rpjday rpjday 12288 2007-11-01 08:23 git.nolinks
$
the first is the master repo, the second (git.local) was cloned
allowing hard links to save space, while the third (git.nolinks) was
explicitly cloned without allowing hard links (using --no-hardlinks).
if i check their disk usage individually, i get:
$ for r in git* ; do
> du -s $r
> done
26340 git
26292 git.local
26292 git.nolinks
$
but if i use wildcards, notice the difference:
$ du -s git*
26340 git
9672 git.local
26292 git.nolinks
$
as if du already knows which files it's seen under "git" and won't
recount them under "git.local" based on hard links. if that's the
case, then it won't be surprising to see the numbers on the first two
reversed if i explicitly change the order of the arguments:
$ du -s git.local git git.nolinks
26292 git.local
9720 git
26292 git.nolinks
$
i can see what's happening, i just didn't realize that that's how
"du" operated. is that deliberate?
rday
p.s. i can see the rationale here -- if du *didn't* do something like
that, then you might get results that were wildly out of sync with
reality. like i said, i just never noticed that before.
--
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA
http://crashcourse.ca
========================================================================
16 years, 5 months
Re: all x86_64 mirrors corrupted tonight?
by Antti J. Huhtala
ke, 2007-10-31 kello 02:06:40 -0700, Jonathan Ryshpan kirjoitti:
> On Tue, 2007-10-30 at 20:09 -0400, Tom Horsley wrote:
> > I tried running an update, and I get a large number
> > of these, followed by a message that there are no
> > more mirrors to try:
> >
> > 20:07:54 : Trying other mirror.
> > 20:07:57 : Failure getting http://mirror.stanford.edu/fedora/linux/updates/7/x86_64/repodata/comps-f...:
> > 20:07:57 : --> [Errno -1] Metadata file does not match checksum
> >
> > The i386 mirrors don't seem to have the same problem.
>
> I see had exactly the same problem for the last two days, running yumex.
> The x86_64 repos appear to be corrupt while the i386 repos are OK.
>
> Could this have something to do with FC8, which should be out in a week
> or so?
>
Googling a bit reveals that the same problem with comps-f7.xml has been
in existence at least since early June, ie. since the release of F7. See
for example: http://www.fedoraforum.org/forum/showthread.php?t=168232
It looks like update metadata is contained in comps-f7.xml - and GUI
updaters such as pup and yumex use this file to fetch information on
packages to be updated.
If comps-f7.xml is corrupted (like in this case for x86_64 systems), pup
and yumex visit every available mirror only to receive the same corrupt
file from each and everyone of them - which in each case results in
"incorrect checksum" error message. No wonder it takes ages to load the
same metadata file over and over again from various mirrors and find all
of them defective.
Although updates with pup have been unsuccessful in this way a couple of
times before, I haven't posted about it because yum has worked always
when pup has failed. From this I conclude that yum doesn't use
comps-f7.xml for anything. I can't help wondering, however, why should
pup or yumex use .xml files? Isn't it a M$ standard - and controversial
at that?
Regards
Antti
16 years, 5 months
selinux and udev problems after updates including latest kernel
by Claude Jones
I got a flood of messages this morning after rebooting into the latest kernel
2.6.23.1-10.fc7 #1 SMP this morning. These had to with udev being denied
whilst it was trying to do various things by Selinux:
**************************************************************************
Here's an example from SETroubleshooter:
Summary
SELinux is preventing /sbin/udevd (udev_t) "relabelfrom" to scsi-
SATA_WDC_WD5000YS-01_WD-WMANU1397503-part1 (device_t).
Detailed Description
SELinux denied access requested by /sbin/udevd. It is not expected that
this
access is required by /sbin/udevd and this access may signal an intrusion
attempt. It is also possible that the specific version or configuration of
the application is causing it to require additional access.
Allowing Access
Sometimes labeling problems can cause SELinux denials. You could try to
restore the default system file context for scsi-SATA_WDC_WD5000YS-01_WD-
WMANU1397503-part1, restorecon -v scsi-SATA_WDC_WD5000YS-01_WD-
WMANU1397503-part1 If this does not work, there is currently no automatic
way to allow this access. Instead, you can generate a local policy module
to allow this access - see http://fedora.redhat.com/docs/selinux-faq-
fc5/#id2961385 Or you can disable SELinux protection altogether. Disabling
SELinux protection is not recommended. Please file a
http://bugzilla.redhat.com/bugzilla/enter_bug.cgi against this package.
Additional Information
Source Context system_u:system_r:udev_t:SystemLow-SystemHigh
Target Context system_u:object_r:device_t
Target Objects scsi-SATA_WDC_WD5000YS-01_WD-WMANU1397503-part1
[
lnk_file ]
Affected RPM Packages udev-113-12.fc7 [application]
Policy RPM selinux-policy-2.6.4-48.fc7
Selinux Enabled True
Policy Type targeted
MLS Enabled True
Enforcing Mode Enforcing
Plugin Name plugins.catchall_file
Host Name tehogee1
Platform Linux tehogee1 2.6.22.9-91.fc7 #1 SMP Thu Sep 27
23:10:59 EDT 2007 i686 i686
Alert Count 1
First Seen Thu 01 Nov 2007 08:25:05 AM EDT
Last Seen Thu 01 Nov 2007 08:25:05 AM EDT
Local ID 21dae078-ca08-4ced-bf62-a09da895c7a4
Line Numbers
Raw Audit Messages
avc: denied { relabelfrom } for comm="udevd" dev=tmpfs egid=0 euid=0
exe="/sbin/udevd" exit=-13 fsgid=0 fsuid=0 gid=0 items=0 name="scsi-
SATA_WDC_WD5000YS-01_WD-WMANU1397503-part1" pid=24234
scontext=system_u:system_r:udev_t:s0-s0:c0.c1023 sgid=0
subj=system_u:system_r:udev_t:s0-s0:c0.c1023 suid=0 tclass=lnk_file
tcontext=system_u:object_r:device_t:s0 tty=(none) uid=0
***************************************************************
Is anyone else seeing anything like this? I probably got over 50 of these! The
machine is up, and seems to be running normally, though I haven't done much
beyond composing this email.
--
Claude Jones
Brunswick, MD, USA
16 years, 5 months