Re: Kmail offline

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.


[Index of Archives]     [Current Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [Yosemite Photos]     [KDE Users]     [Fedora Tools]     [Fedora Docs]

  Powered by Linux