New Security Vulnerabilities channel on Comcast channel 997. Fedora Core 10 was EOLed in 2009...
Human, Dustcake, Engineer
Doing my best to make the world a little better every day.
❤️ J9
news.ycombinator.com/user?id=lindner
@exk4ji+mpb4mdiCG5KVHxIMCo0as4k4/cIwRoxt3Aw4=.ed25519
www.openhub.net/accounts/plindner
dl.acm.org/profile/99659334862
Being a glutton for punishment I converted the Dawarich docker compose config to quadlets using podlet. I still run my Fedora home server that I've upgraded in place since 1999...
https://
Upgraded to Fedora 17 "Beefy Miracle" in-place on the same image I've had since Redhat 6.2.
Upgraded to Fedora 17 "Beefy Miracle" in-place on the same image I've had since Redhat 6.2. It was a little more challenging than some upgrades due to moving everything into /usr, but overall it's working well.
And the origin of the name is pretty interesting, check it out:
Fedora has always had odd names, but Beefy Miracle ventures into Ubuntu territory...
Fedora has always had odd names, but Beefy Miracle ventures into Ubuntu territory...
Originally shared by Fedora Project
Its that time again where we celebrate a new #Fedora release!!.
Fedora 17 : Beefy Miracle is released!!
Check out the Fedora 17 release video : Fedora 17: Beefy Miracle release
And don't forget to check out the release announcement at : http://
Could either of you recommend someone associated with the Fedora cvs->git transition that can talk to the Apache...
Could either of you recommend someone associated with the Fedora cvs->git transition that can talk to the Apache folks? There's so much drama going on over there regarding git and their infra people are moving way slow...
Hey look, it's the Fedora Project! On Google+
Hey look, it's the Fedora Project! On Google+
Check out Fedora 16 if you're into Linux distros. I just finished upgrading the home server last night and it's running smooth. (even if systemctl reminds me way too much of solaris SMF)
Fun fact: I've been upgrading the same system image since Red Hat 6.0. No reinstalls.. and since I never had a CD/dvd all upgrades were via rpm/yum.
You can stop reading now if you don't care about software that keeps the internet from falling over.
You can stop reading now if you don't care about software that keeps the internet from falling over.
Memcached 1.4.10 is now out and this release looks to be the best yet. Check out the release notes and send some kudos over to http://
To do my part I just built the fedora RPMs for f15/f16/rawhide. Try it out on your favorite high-volume server.
Now upgrading Fedora memcached to 1.4.6.
Now upgrading Fedora memcached to 1.4.6. I really do like the fedpkg system -- so much better than the old CVS based build system.
Fedora 12, Dracut, dmraid, mdadm, oh my!
It appears that Fedora 12 moved to a new boot init system called dracut. Sadly due to a number of odd circumstances this has caused me much pain. Here's my basic config
- /boot and / on /dev/sda
- /var and /home on a partitioned software raid on /dev/sd{cd}
After an yum-based upgrade to Fedora 12 I rebooted. We get to the point where we initialize the software raid and boom. failure. I'd seen this before, partitioned raid has always had some trouble in fedora. Previously I had to modify the rc.sysinit script to reset the raid partitions, so I tried that again, moving that init to later in the boot sequence. Reboot and yes, it works..
However then I noticed some odd things. I was only getting a single drive in my mirrored RAID. Further investigation revealed that I had a device dm-1 instead of sdc or sdd listed in /proc/mdstat... Uh oh..
Looking more closely it appears that my drives were getting set up by dmraid as a fake-raid mirror:
# dmraid -r
/dev/sdd: sil, "sil_aiabafajfgba", mirror, ok, 488395120 sectors, data@ 0
/dev/sdc: sil, "sil_aiabafajfgba", mirror, ok, 488395120 sectors, data@ 0
I tried adding the nodmraid option to grub.conf but then the new dracut system started an infinite spew of messages generated by this mdadm error message string (lifted from Assemble.c)
fprintf(stderr, Name ": WARNING %s and %s appear"
" to have very similar superblocks.\n"
" If they are really different, "
"please --zero the superblock on one\n"
" If they are the same or overlap,"
" please remove one from %s.\n",
devices[best[i]].devname, devname,
inargv ? "the list" :
"the\n DEVICE list in mdadm.conf"
Drats! the mirrored fake raid had already mangled my second drive by duplicating the superblock! Plus since all this was going on in dracut I couldn't fix it. So I removed the nodmraid option in grub during boot and dug a little deeper. I found that I could keep dracut from doing all this nonsense by adding the following kernel options:
rd_NO_MD rd_NO_DM nodmraid
This allows for a minimal boot without dmraid or mdadm. After that I was dropped into single user mode with the dupe superblock message. To fix this required zeroing the superblock of sdd
mdadm --zero-superblock /dev/sdd1
And then rebooting (again!)
Once past this things started working somewhat normally. To get my raid mirrored again I did the normal thing:
# mdadm --manage /dev/md_d0 --add /dev/sdd1
To get rid of the false-positive fake raid setup I found that you can do this with the dmraid tool itself:
[root@mirth ~]# dmraid -E -r /dev/sdd
Do you really want to erase "sil" ondisk metadata on /dev/sdd ? [y/n] :y
[root@mirth ~]# dmraid -E -r /dev/sdc
Do you really want to erase "sil" ondisk metadata on /dev/sdc ? [y/n] :y
The really odd thing about this whole incident is that I never had these drives in a fake raid setup before.
In any case, hope this helps the few other people who might have this same problem.
Fixing CVE-2009-1255 in Fedora -- come get your new 1.2.8 memcached rpms everyone! http://