My girlfriend has just gotten her master title in Science, "cum laude" -for exceptional achievement meaning she has 8.0 average on a 1 to 10 scale. Awesome!
I wonder whether any of our future kids -should we get any- turn out to be that smart and intelligent and how many of them are going to contribute to Fedora. At what age should I start pushing them? Any recommendations? ;-)
Saturday, October 6, 2007
Wednesday, October 3, 2007
Fedora Unity Re-Spins
While we (Fedora Unity) have barely released the 20070912 Re-Spin, containing all Fedora 7 updates released as of September 12th, we have decided to do another Re-Spin release with all updates released up until right now (October 3rd).
One of the major reasons is the new kernel (while the -76 had some libata and vulnerabilities), and because... well... we can.
We can, because creating the Re-Spin is just dead simple -although having any confidence in the Revisor programmer's skills seems to be difficult even when you haven't yet read a single line of code.
At zero hours, I ran:
i386-machine$ sudo revisor --cli --yes --config /etc/revisor/revisor-unity.conf --model f7-i386
and on another,
x86_64-machine$ sudo revisor --cli --yes --config /etc/revisor/revisor-unity.conf --model f7-x86_64
10 hours later, scp'ing bits from one box to another, I have 4 torrent seeds and a jigdo mirror.
We can, although it's just a handful of very dedicated volunteers do the testing. We have a Q&A test matrix containing all installation tests (NFS, HTTP/FTP, Hard Disk and CDROM -times two architectures, times two sets of media). You can only imagine the amount of work involved. Therefore, I'd like to thank those that test our Re-Spins before we release them to the general public. Awesome work!
We can also release CD sets of these Re-Spins, something apparently the Fedora Project hasn't been able to with Fedora 7 or 8 nor will it "bless" the community effort to create and distribute those (x86, x86_64) given that "blessed custom spins" will still need the approval of Red Hat's Release Engineering team, which just so happened to decide to only use their own tools.
We can, although GPL requires us to also distribute the sources of whatever binary we ship. This creates enormous overhead for any small project, or any project with limited resources. Because the Fedora Project distributes under GPL's section 3a [1], while, from a Re-Spin, Re-Mix or Rebrand perspective, it would be much easier for anyone if the Fedora Project distributed under GPL section 3b [2], so that others can use 3c [3]. However, some people try to prevent that from happening because of administrative overhead, disk space (cost) and other nonsense. If you can't store the source packages for a release including it's updates 4 years and one month [4] then ... what? Should the community (read: /me) do this just to show that if I can do it, the leading open source conglomerate should most definitely be able to?
Based on the number of downloads, the positive responses and number of times people come in #fedora-unity or walk up to us at an event, and ask when will we do another Re-Spin should not be underestimated, the community members that download and use our Re-Spins sure are satisfied. That should give anyone on some RH pedestal enough confidence start up a dialog instead of deciding on their own what tools can or cannot be used to create custom spins blessed by the Fedora Project.
[1] GPL Section 3a means offering the binary implies you offer the sources but as soon as you pull the binary offline you can also pull the source offline
[2] GPL Section 3b means you include a written offer with instructions to obtain the sources, valid for three years after releasing the binaries
[3] GPL Section 3c means (for non-commercial distribution) you have received the binaries with a written offer (3b), and you can re-issue that offer to anyone downloading your binaries.
[4] 4 years and one month is: from the moment of release N to the moment three years after the last update will be released for release N (based on a 13 month support frame).
One of the major reasons is the new kernel (while the -76 had some libata and vulnerabilities), and because... well... we can.
We can, because creating the Re-Spin is just dead simple -although having any confidence in the Revisor programmer's skills seems to be difficult even when you haven't yet read a single line of code.
At zero hours, I ran:
i386-machine$ sudo revisor --cli --yes --config /etc/revisor/revisor-unity.conf --model f7-i386
and on another,
x86_64-machine$ sudo revisor --cli --yes --config /etc/revisor/revisor-unity.conf --model f7-x86_64
10 hours later, scp'ing bits from one box to another, I have 4 torrent seeds and a jigdo mirror.
We can, although it's just a handful of very dedicated volunteers do the testing. We have a Q&A test matrix containing all installation tests (NFS, HTTP/FTP, Hard Disk and CDROM -times two architectures, times two sets of media). You can only imagine the amount of work involved. Therefore, I'd like to thank those that test our Re-Spins before we release them to the general public. Awesome work!
We can also release CD sets of these Re-Spins, something apparently the Fedora Project hasn't been able to with Fedora 7 or 8 nor will it "bless" the community effort to create and distribute those (x86, x86_64) given that "blessed custom spins" will still need the approval of Red Hat's Release Engineering team, which just so happened to decide to only use their own tools.
We can, although GPL requires us to also distribute the sources of whatever binary we ship. This creates enormous overhead for any small project, or any project with limited resources. Because the Fedora Project distributes under GPL's section 3a [1], while, from a Re-Spin, Re-Mix or Rebrand perspective, it would be much easier for anyone if the Fedora Project distributed under GPL section 3b [2], so that others can use 3c [3]. However, some people try to prevent that from happening because of administrative overhead, disk space (cost) and other nonsense. If you can't store the source packages for a release including it's updates 4 years and one month [4] then ... what? Should the community (read: /me) do this just to show that if I can do it, the leading open source conglomerate should most definitely be able to?
Based on the number of downloads, the positive responses and number of times people come in #fedora-unity or walk up to us at an event, and ask when will we do another Re-Spin should not be underestimated, the community members that download and use our Re-Spins sure are satisfied. That should give anyone on some RH pedestal enough confidence start up a dialog instead of deciding on their own what tools can or cannot be used to create custom spins blessed by the Fedora Project.
[1] GPL Section 3a means offering the binary implies you offer the sources but as soon as you pull the binary offline you can also pull the source offline
[2] GPL Section 3b means you include a written offer with instructions to obtain the sources, valid for three years after releasing the binaries
[3] GPL Section 3c means (for non-commercial distribution) you have received the binaries with a written offer (3b), and you can re-issue that offer to anyone downloading your binaries.
[4] 4 years and one month is: from the moment of release N to the moment three years after the last update will be released for release N (based on a 13 month support frame).
Tuesday, September 25, 2007
Yum behaviour change
When you want to ensure you have the latest version of a package installed, you would configure puppet as follows:
package { "ypbind":
ensure => latest
}
What puppet does, is execute yum as follows:
yum -d 0 -e 0 list available ypbind
If it gets any hits, the package is either available for installation, or eligible for an update, so it'll install the available package. If no packages are "available", it'll just continue like normal.
You will most likely have some file or service definitions depending on the "availability" of the package:
file { "/etc/yp.conf":
source => "puppet://$server/files/yp.conf",
require => Package["ypbind"]
}
service { "ypbind":
ensure => running,
require => Package["ypbind"]
}
When puppet ensures the package to be installed before executing any of the depending definitions, it assumes that yum exiting without any error code is equivalent to the (the most recent version of the) package being installed on the system, and any error code means it can't be done (and thus: not execute the depending statements).
Lately however, yum does throw an error code if there is no package "available" (for installation), and thus all puppet dependencies for that package fail.
package { "ypbind":
ensure => latest
}
What puppet does, is execute yum as follows:
yum -d 0 -e 0 list available ypbind
If it gets any hits, the package is either available for installation, or eligible for an update, so it'll install the available package. If no packages are "available", it'll just continue like normal.
You will most likely have some file or service definitions depending on the "availability" of the package:
file { "/etc/yp.conf":
source => "puppet://$server/files/yp.conf",
require => Package["ypbind"]
}
service { "ypbind":
ensure => running,
require => Package["ypbind"]
}
When puppet ensures the package to be installed before executing any of the depending definitions, it assumes that yum exiting without any error code is equivalent to the (the most recent version of the) package being installed on the system, and any error code means it can't be done (and thus: not execute the depending statements).
Lately however, yum does throw an error code if there is no package "available" (for installation), and thus all puppet dependencies for that package fail.
Wednesday, September 12, 2007
Updating anaconda between releases
Some people use a Fedora 7 DVD or the online release tree and then include updates in the installation media they compose using Revisor, so that when they install using this composed media, they do not have to pull in another couple of hundred megabytes of updates.
These people often report errors to Revisor; some fail to compose a multiple (spanned) media set -such as with CDs- because Revisor shits itself (at least from their perspective) during package ordering, or that the installation fails with a nasty RPM error.
One way or the other, both cases are related to a package being updated on which anaconda and anaconda-runtime depend. One of them is yum, the other RPM. Both important, base software without which Fedora wouldn't be Fedora. But so is anaconda.
What we do (as developers) to try and solve the issue, is;
These people often report errors to Revisor; some fail to compose a multiple (spanned) media set -such as with CDs- because Revisor shits itself (at least from their perspective) during package ordering, or that the installation fails with a nasty RPM error.
One way or the other, both cases are related to a package being updated on which anaconda and anaconda-runtime depend. One of them is yum, the other RPM. Both important, base software without which Fedora wouldn't be Fedora. But so is anaconda.
What we do (as developers) to try and solve the issue, is;
- exclude the updated package(s) that break their compatibility with anaconda from the updates and updates-testing repositories in our default yum configuration files. This obviously only gets to the end-users when Revisor releases another update, and since configuration files cannot just be replaced ends up in an unused .rpmnew file.
- exclude the packages that pull in the package we excluded previously to prevent broken dependencies
- work around the issues that may occur in case the updated RPM is installed on the system doing the compose, and it results in any of these errors (anaconda-runtime's pkgorder vs. the RPM update not allowing duplicates in the transaction).
Thursday, August 30, 2007
Revisor on Enterprise Linux
Although these are just preliminary results; Revisor (in CLI mode) now also runs on Enterprise Linux 5!
I've composed a minimal Fedora 7 installation CD which (while I'm writing this), is done formatting the partitions of a QEMU guest, and installing packages.
-some time later-
It's booting as well. In the meantime, I've been trying to get live media going on EL5 too, but I haven't managed to get it working, yet.
Tagged nonetheless and built: http://koji.fedoraproject.org/koji/packageinfo?packageID=4446
I've composed a minimal Fedora 7 installation CD which (while I'm writing this), is done formatting the partitions of a QEMU guest, and installing packages.
-some time later-
It's booting as well. In the meantime, I've been trying to get live media going on EL5 too, but I haven't managed to get it working, yet.
Tagged nonetheless and built: http://koji.fedoraproject.org/koji/packageinfo?packageID=4446
Friday, August 3, 2007
Spinning Fedora X, X-1 and X+1
In the past, I've been told building Fedora X would require the host doing the building to also run Fedora X. Not Fedora X+1 or Fedora X-1. Really Fedora X. It wouldn't be possible any other way. I assure you it wasn't my grandma or girlfriend telling me this.
Taking matters into my own hands, being the stubborn m-f that I am, I've been successfully building
on F7: FC6, F7 and F8t1 or rawhide
on F8t1 (rawhide): FC6, F7 and F8t1 or rawhide.
I've just not been able to build anything on X-1, but that's it. The rest, I did. And it's my very own application failing to do anything on FC6 because I've managed to create pretty hard requirements towards Fedora 7 or later.
Some of you think: "You didn't. It's impossible. I told you it was impossible. Period."
I'll add to that, that I've not only successfully built these spins -meaning that I didn't get any errors or warnings during the builds-, but they also successfully passed Q&A (although as we know FC6 had bugs in doing certain types of installations, so it didn't really /pass/ Q&A but it did anyway, and of course I'm not sure what Q&A requirements have been set for F8(t1)).
Bingo.
Taking matters into my own hands, being the stubborn m-f that I am, I've been successfully building
on F7: FC6, F7 and F8t1 or rawhide
on F8t1 (rawhide): FC6, F7 and F8t1 or rawhide.
I've just not been able to build anything on X-1, but that's it. The rest, I did. And it's my very own application failing to do anything on FC6 because I've managed to create pretty hard requirements towards Fedora 7 or later.
Some of you think: "You didn't. It's impossible. I told you it was impossible. Period."
I'll add to that, that I've not only successfully built these spins -meaning that I didn't get any errors or warnings during the builds-, but they also successfully passed Q&A (although as we know FC6 had bugs in doing certain types of installations, so it didn't really /pass/ Q&A but it did anyway, and of course I'm not sure what Q&A requirements have been set for F8(t1)).
Bingo.
NetworkManager and NetworkManagerDispatcher
Imagine you connect your laptop to your home network and you want to authenticate against nis.home.org, using automatically mounted home directories from fileserver.home.org. The following morning, you arrive at the office and connecting your laptop to the network there, you wait for ypbind to bind to nis.home.org (which just so happens to be unavailable), and you cannot log in directly as your home directory cannot be mounted (because fileserver.home.org just so happens to be unavailable too). In addition, your office uses LDAP authentication and has a group data share you want to mount.
I'm guessing you'll need to at least disable ypbind, and maybe change authentication configuration and start using LDAP. You're also probably gonna want to mount that group data share and not automount your home directory from some NFS share.
Are you performing all these changes by hand? Does your office allow you to change it all? How does the office manage to support all that? I don't know.
What I do know is that I personally have a similar use-case with my laptop that I want to be able to connect to my home network having NIS and autofs, while not having to change the system configuration when I'm 'offline' -not connected to my home network.
I've begun to use the NetworkManagerDispatcher: it allows me to execute some scripts that would be able to detect wherever I am and adjust my system configuration accordingly. I'll call it NetworkManagerDispatcherScripts (don't try and say that out loud very fast, twice). There's a proof of concept piece of code at http://git.kanarip.com/?p=nmdscripts/.git which you can get with;
git clone git://git.kanarip.com/nmdscripts/
Execute the ./nmdscript script and see if you're connected to one of the pre-configured networks (which all apply to my home networks). Until now, it's just detecting some network characteristics and not executing any system configuration changes, and I'm just curious what anyone thinks about it.
I'm guessing you'll need to at least disable ypbind, and maybe change authentication configuration and start using LDAP. You're also probably gonna want to mount that group data share and not automount your home directory from some NFS share.
Are you performing all these changes by hand? Does your office allow you to change it all? How does the office manage to support all that? I don't know.
What I do know is that I personally have a similar use-case with my laptop that I want to be able to connect to my home network having NIS and autofs, while not having to change the system configuration when I'm 'offline' -not connected to my home network.
I've begun to use the NetworkManagerDispatcher: it allows me to execute some scripts that would be able to detect wherever I am and adjust my system configuration accordingly. I'll call it NetworkManagerDispatcherScripts (don't try and say that out loud very fast, twice). There's a proof of concept piece of code at http://git.kanarip.com/?p=nmdscripts/.git which you can get with;
git clone git://git.kanarip.com/nmdscripts/
Execute the ./nmdscript script and see if you're connected to one of the pre-configured networks (which all apply to my home networks). Until now, it's just detecting some network characteristics and not executing any system configuration changes, and I'm just curious what anyone thinks about it.
Subscribe to:
Posts (Atom)