Kmail offline
Gene Heskett
gene.heskett at verizon.net
Sat Jan 27 01:35:10 UTC 2007
On Friday 26 January 2007 17:37, Craig White wrote:
>On Fri, 2007-01-26 at 15:59 -0500, Gene Heskett wrote:
>> OTOH this FC6 system has been strange from the gitgo, like having to
>> go find a bunch of cron related files from the old FC2 install and
>> copy them over before cron would run. None of its config and
>> reference files were installed by anaconda. They simply weren't
>> there. And all the rpm checking I could get it to do said the install
>> was all right. Yeah, sure.
>
>----
>which came first, the chicken or the egg?
>
A very good question.
>Little doubt in my mind that copying the files over from an FC-2 box to
>a new FC-6 install would create a bunch of problems with selinux which
>of course you can't solve because the man pages aren't up to your
>standards. While you ***may*** have solved the problems by disabling
>selinux (I say may because as of yesterday, you were still uncertain
>whether you had actually disabled selinux), I am reasonably convinced by
>your recollections of what you have done to your install that most of
>these problems are self inflicted.
Nope, in this case by anaconda. I did NOT delete the cron stuff, and in
fact wasn't aware of it until I I tried to run kcron and add my scheduled
stuff to the new install. No common crontab file=kcron crash.
So I started comparing the cron stuff installed on /dev/hda with the stuff
on /dev/hdb, which was, and still is, my old FC2 system disk. Everytime
I found something on hdb that wasn't on hda, it got copied. Just text
files, all of them.
Cron itself would start, but 5 seconds later a service crond status said
it wasn't running.
>To that end, the fonts in /root - they didn't get there from installing
>the msttcorefonts package because even if you build the rpm as root,
>they would be put into /usr/src/redhat/SOURCES, and when you install the
>rpm (obviously as root), they go into /usr/share/fonts/msttcorefonts
>directory and the only way for them to get into /root is to manually
>copy them there...and by your post yesterday, the security contexts
>would have changed exactly as they had by doing something similar to...
>cp -r /usr/share/fonts/msttcorefonts /root
A, they never were in /root/.fonts even on the FC2 install.
B, they are in /usr/share/fonts/msttcorefonts, on both the FC6 install on
hda, and on the FC2 install thats now mounted from hdb.
C, there are some fonts in the old FC2 disks /root/.fonts dir, and those
were copied to hda's /root/.fonts for with mc, which probably duplicates
the cp performance.
D, I'd run fixfiles a week, maybe 10 days ago, which took several hours
because it walked through every disk mounted instead of staying on its
filesystem. That's a bug to me, but a shrug ATM.
E, It had all worked, including pulling in some fonts from extras with
yumex quite early after I put FC6 on this box. I had also used mc to
copy over a dozen or more fonts I'd downloaded from goldenweb.it, putting
them in /usr/share/fonts where they were instantly available to OOo with
no intervention on my part.
F, printing dies 3+ days ago after putting in a ready made rpm of
msttcorefonts-2.x.noarch. I've taken that rpm apart and looked at 99% of
its bytes with various editors and AFAICT, that rpm is clean and legal.
G, 2.5 days later, after I had deleted some font.dir and font-cache files
of 0 length, printing starts working again.
H, /var/log/secure contains nothing from selinux since the logrotation
sunday morning.
I, fc-cache is still broken.
>It is clear that your pattern continues to take the easy path -
>regardless of the implications for system safety, whether it is how you
>log in, use the Desktop as root, build packages as root, install
>directly from tarballs instead of building rpms, etc. and thus, it is of
>little surprise that you claim a disproportionate amount of problems
>related to packaging. The thing about packaging is the consistency...and
>if there was a problem with the packaging, everyone who installed the
>same packages (which is basically everyone since we are talking about
>vixie cron), would have had the same problem - unless of course, the
>packagers had some means to single you out at installation time.
I have NDI why cron wasn't fully installed. I did not do anything to
intervene in anaconda's feeble minded attempts to build me a working
system. Humm, another ugly thought come to mind, that install was done
from a dvd I burnt, from a torrent download, so the kernel bug that has
existed for many versions that effects pre-allocated file writes on a
random LSB offset, exactly the way a torrent operates, and which was
finally fixed in 2.6.20-rc3(IIRC, maybe if was rc4) might have munged
that dvd. But IIRC the checksum was good. But its got me thinking.
sha1sum of FC-6-i386-DVD.iso:
6722f95b97e5118fa26bafa5b9f622cc7d49530c FC-6-i386-DVD.iso
from SHA1SUM file:
6722f95b97e5118fa26bafa5b9f622cc7d49530c FC-6-i386-DVD.iso
So that idea is well and truly shot down, and I always have k3b check the
sum of the burned disk.
Idea, maybe the crontab and supporting files are in a different package?
Nice idea but rpm says its installed from crontabs.noarch which srcs in
crontabs-1.10-8
And several dozen other packages according to a yum provides crontab
listing.
So I have NDI where the heck they went, all I know for sure is that they
weren't there when I went looking to see why cron driven stuff wasn't
working the next morning after the install of FC6.
>Craig
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2007 by Maurice Eugene Heskett, all rights reserved.
More information about the fedora-list
mailing list