Self introduction: Lamar Owen
by Lamar Owen
While I have been contributing to Red Hat's development (through maintenance
of the PostgreSQL RPMset) for some years now, I'll go ahead with the self
intro as requested on the fedora.us site.
Lamar Randall Owen
USA, Rosman, NC
Director of Information Technology
Pisgah Astonomical Research Institute
I currently maintain the community packages for PostgreSQL, as well as
building packages for other programs, including the SWORD project and
BibleTime (Bible software for KDE using the SWORD libraries and modules).
While I do some QA testing now, I am mostly interested in making the Fedora
PostgreSQL packages the best they can be.
Historical Qualifications.
Over four years maintaining the PostgreSQL RPMs and contributing to
discussions there and on the RPM list. I've beta tested Red Hat for right at
four years, since the 6.2 cycle. I have programmed in numerous languages
over the years: see my sourceforge profile (user lowen). I maintain the
postgresql database driver for the AOLserver project. Red Hat trusts me (Red
Hat 6.1 shipped with rebuilt versions of my PostgreSQL packages, and they
have been the base packages ever since, even though RH has their own internal
maintainer (currently David Jees, previously Andrew Overholt and before that
Trond Eivind Glomsrød)), so I guess you should too. :-)
Key fingerprint (fresh key, as I've not used one before for public
consumption):
pub 1024D/25C6AF5B 2003-12-04 Lamar Owen <lowen(a)pari.edu>
Key fingerprint = 3142 7AB1 F9AA 5D14 BBB3 FC4A 073D 25BA 25C6 AF5B
sub 2048g/C1F9E9DA 2003-12-04
I guess I'll begin signing the PostgreSQL RPM's at ftp.postgresql.org; they
haven't previously been signed.
--
Lamar Owen
Director of Information Technology
Pisgah Astronomical Research Institute
1 PARI Drive
Rosman, NC 28772
(828)862-5554
www.pari.edu
20 years, 4 months
The RULE project, was: Fedora minimal install option
by M. Fioretti
Greetings,
I did not formally introduce myself on the list because I just
planned to lurk for a bit. However, I am following with the
greatest interest the thread " Fedora minimal install option".
I strongly invite every Fedora developer interested in these issues
to look closely at the RULE project (http://www.rule-project.org/en/).
We work to install *really* barebones version of Red Hat Linux first,
Fedora in the future, on:
really old/limited machines but also
state of the art HW which must not be cluttered with unnecessary
packages, to simplify installation, maintenance, running from
pen drives and such
Installation of standard Red Hat 8/9 packages with the RULE SW developed by M.
Fratoni
(Michael, are you on this list?) have succeeded on less than 16 MB of RAM, taking
(IIRC) 350/400 MB of disk.
As the project coordinator, I hope, especially after this thread, to see as much
interwork/integration as possible between FC and RULE. No need to reinvent
the wheel. I am willing to contribute to Fedora on these issues, if you are
interested.
Please browse the site, download and study the installer and scripts and don't
hesitate
to come back with questions and proposals, either here or off list.
We could definitely use more developers: should Fedora itself take from RULE and
make it unnecessary, all the better.
Ciao,
Marco Fioretti
20 years, 4 months
AMD64 Preview Release Updates
by Justin M. Forbes
For those of you running the AMD64 preview release, please download and
install the updated yum located at:
http://fedora.linux.duke.edu/fc1_x86_64/updates
I will be posting updates there as they are available (with announcements
here of course). Currently there are 2 updates.
- kernel: is just an AMD64 build of the FC1 errata kernel, please see the
changelog posted by Dave for changes here. One extra note, the preview
release kernel has libata merged, the updated FC1 kernel does not, so do
not update if you are currently dependant on it.
- yum: Yum is taken from the latest yum daily snapshot RPM. The only
modification here is the yum.conf. You will need to replace your
yum.conf with the one included in this package or add its entries. The
largest change here of note is that this yum actually works with AMD64.
I will post more as they are available.
Justin M. Forbes
20 years, 4 months
Red Carpet ?
by Nils O. Selåsdal
Ximian just released a new version of Red-Carpet. Would it be an idea
to make RC channels of fedora.us(and Fedora for that matter) ?
RedCarpet does in my opinion make software installation a no brainer
for most people.
http://www.ximian.com/products/redcarpet/
http://www.opencarpet.org/
--
Vennlig hilsen/Best Regards
Nils Olav Selåsdal
System Engineer
UtelSystems a/s
w w w . u t e l s y s t e m s . c o m
20 years, 4 months
Re: Fedora LiveCD : Looking for Betatesters - Port of redhat 9.0base to fedora core 1
by Jef Spaleta
Colin Charles:
>Hmm, Debian is a USA based project, and Knoppix, it's spin-off is
>based in Germany.
The KEY to this statement of fact is that Knoppix is spelled differently
than Debian, and I would hope Knoppix refrains from using Debian's
trademarks and logos inside the Knoppix isos. There is more than enough
room for a derivative work that begins with software provided by Fedora
to create a liveCD that is legal in other countries. BUT, it should not
use trademarked Fedora images or logos. In fact if you read through the
trademark guidelines at fedora.redhat.com ... I'm really not sure that
you should use the Fedora name associated at all, even to say its a
derivative work, with a livecd that is rolled up outside of the
'official' structure.
What if the LiveCD I roll up..totally sucks? I assure you it would.
Should I be allowed to say that its based on Fedora Core? I don't think
so, because my crappy attempt at liveCD building would tarnish the
official work done as part of the official Fedora community effort. And
don't try to argue that people using and reviewing my crappy little
liveCD should know better than to link the very bad craftmanship of MY
customized work to the craftsmanship of the Fedora project in general.
In an effort to avoid tarnishing the reputation of the Fedora name...i
should NOT be allowed to use or even to refer to Fedora when advertising
my co-mingled customized liveCD image. In fact... i would suggest(from a
fairplay point of view) that ALL custom liveCD's should have to live
outside the allowable usage of the Fedora trademarks because the liveCD
distribution format makes it very difficult to distiguish what is
customized and what is original Fedora craftsmanship. Which is very
different than something like an OEM pre-install, where the OEM can give
the customer a set of Fedora Core disks as well as a seperate piece of
media for the OEM addon packages making up the full OEM pre-install of
Fedora.
Of course pulling out ALL the text that refers to the distro as
Fedora(not to mention all the lingering Red Hat references) is probably
a non trivial task at the moment....maybe there is room in the
continuing dialog for an official liveCD image, but somehow i doubt an
officially blessed liveCD image would fill the niche well, considering
the non-technical limitations being 'officially' blessed would carry.
-jef"if the point of a liveCD is to demo a distro...but the liveCD ends
up having many custom features the base distro does not have like ntfs
support...what's the point again?"spaleta
20 years, 4 months
Self Introduction: Mike Avery
by Mike Avery
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Following the suggestion at http://www.fedora.us/wiki/SelfIntroduction
Here is my info! I'm answering the questions posted at the page above..
Mike Avery
Ottawa, Canada
IT Manager
Can't post Company name in public
I'd like to help out with the system-config tools. I've send a note to
Brent regarding creation of a system-config-nis. I have begun work on
this now.
My goal in contributing to The Fedora Project is aiding in the creation
and refinement of powerful but intuitive tools for both GUI and CLI users.
I'd like to see system-config-nis incorporated in the stable Fedora
releases eventually. I'd also like to get involved in lower level
systems programing for Fedora, but I'll get my feet wet with something
new first.
I don't mind doing QA as time permits.
Here come the qualifications since I have to list them..
I have been a UNIX administrator for 11 years. I've used Linux and
other free operating systems anywhere possible (exclusively when
possible) since 1994. Same goes for the software that runs on those systems.
I have deployed and administered many flavours on several hardware
platforms. My strength in this area has been in the development and
maintenance of UNIX development environments (GNU tools) on HP-UX,
Linux, AIX, Solaris, and BSD(s). I can manage Windows environments as
well, although I don't enjoy doing it.
I consider myself a lucky person, who has been paid to work with free
software for nearly 10 years.
I have contributed to the (former) UCD-SNMP project in the form of a GUI
for SNMP management of network devices. It was an experimentation in
GUI design for me. I still use it today, although I doubt anyone else
does :) It can be found here: http://savannah.nongnu.org/projects/x-snmp
I have done some combat and play mechanics development for Adonthell, a
graphical RPG written in C/C++. This work is/was experimental, but very
fun and challenging.
I have done quite a bit of work related coding. Mostly systems
programing. I have developed Linux/UNIX hardware detection routines for
PCI controllers, PnP, SMBios, and NICs. This was proprietary work and
is not freely available.
I have also developed some proprietary tools for UNIX application
inventory a detection. These are also proprietary and not available.
I have good experience in UNIX/C, somewhat less in C++. I know several
interpreted languages (Tcl/tk, awk, shells, Python, perl, yadda yadda)
in varying degrees, although I can get what I need done in all of them.
I have used a few GUI different tool kits. I have limited experience
with GTK, but I think my limitations at this point are syntax and
familiarity.
Why should you trust me? Don't until convinced to.
Thanks,
Mike Avery
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
iD8DBQE/zi6lN3sECpyP0qERAnFwAKDGPeiILcTxLa8ns0LFXQFYbNNaswCg6XlO
HtENkk66mCRl69CG/cVojHo=
=85ve
-----END PGP SIGNATURE-----
20 years, 4 months
I gotta ask this ...
by Fezzik Giant
Hi everyone,
I have seen several posts in the past where someone asks about building
Fedora ISO images. I have yet to see a response.
Surely _someone_ must know how this is done. Why is there never a response?
Is this knowledge a 'secret sauce' that nobody wishes to share?
F
_________________________________________________________________
The new MSN 8: advanced junk mail protection and 2 months FREE*
http://join.msn.com/?page=dept/bcomm&pgmarket=en-ca&RU=http%3a%2f%2fjoin....
20 years, 4 months
The current fedora.us buildsystem and future directions
by Enrico Scholz
Hello,
the Fedora Project will need a buildsystem which features[1]:
Process separation:
it MUST be impossible to kill or ptrace processes of other buildroots
or of the system. Hiding of foreign processes SHOULD be provided.
Device/kernel protection:
Direct hardware access through /dev/* entries or modification of
kernel parameters through /proc MUST be impossible. Forbidding the
creation of such special files is one way to reach it, access
restriction another one.
Unbreakable chroots:
it MUST be impossible for a process in a buildroot to have any kind
of access on objects of the systems (e.g. ssh-keys), or write-access
on other buildroots.
No buildroot-reusing:
each build MUST happen in an environment which can not be influenced
by previous builds in this environment. This includes both
filesystem-objects, and processes.
Resource-restrictions:
excessive resource-usage (memory, diskspace,...) of a build SHOULD
be prevented. Usage of certain resources (e.g. network) MUST be
prohibited
Good performance:
the buildsystem SHOULD should have only a small or non-existing
impact on the performance.
Working environment:
building of common packages MUST succeed. This requires certain /dev
entries, and a mounted /proc filesystem at least.
Mature userinterface:
the system SHOULD assist the buildmaster and automate the most
tasks, so that the spent time will be reduced to a minimum.
The reasons for these items and how they are solved in the current
fedora.us buildsystem are described in
http://www.tu-chemnitz.de/~ensc/fedora.us-build/html
[HTML], respectively
http://www.tu-chemnitz.de/~ensc/fedora.us-build/files/buildsystem.pdf
[PDF, 204 KiB]
The described buildsystem is in use for a short time only, but it
seems to be secure and to work well (it was used in the rh9* -> fc1
mass-rebuild for the most packages). There were some cases which
needed manual intervention (e.g. manual disttags), but these were
exceptions.
A core part is a vserver[2] capable kernel. Unfortunately, it is not
ported to the kernels which are shipped with Fedora yet, and chances are
only low that it comes into the official 2.6 kernel.
Since Red Hat wants a selfhosting buildsystem, alternatives must be
investigated. SELinux offers interesting features, but it is new and
there are lot of open questions[3]:
1. SELinux can protect foreign processes. But is it possible to hide
them in /proc also?
2. Is chroot(2) implemented in a safe manner? Or, can parent directories
of build-roots be protected with SELinux policies? Is a safe chroot(2)
required at all?
3. What is the performance impact of the policy checking?
4. How can disk/memory usage restricted with SELinux? Would CKRM be an
option?
5. Can special mount-operations (e.g. /proc filesystem) be allowed by
the policy, or does this require userspace helper also?
6. Setup of an SELinux policy seems to be very complicated. How possible
are holes in a setup?
It would be nice when an SELinux expert could take a look at this
questions and how it can be used in the buildsystem.
UML might be another option, but its status (chances to come into
official 2.6) and performance impact is not clear.
Enrico
Footnotes:
[1] http://www.tu-chemnitz.de/~ensc/fedora.us-build/html/index.html#id2503177
[2] http://linux-vserver.org
[3] http://www.tu-chemnitz.de/~ensc/fedora.us-build/html/ar01s02.html#sec:com...
20 years, 4 months
Re: Fedora LiveCD : Looking for Betatesters - Port of redhat 9.0base to fedora core 1 / Legal issue Discussion
by Jef Spaleta
Dirk Westfal wrote:
> That's why I'm using the term 'based on' or 'uses packages of'.
> Currently (and also in future) my cd does not use any official logos of
> neither redhat nor fedora.
Personally, I'd be wary of even doing that. The right answer of course
is, trademark is a crappy legal issue..and therefore the only way to
really settle it is to talk to a lawyer. The src code is of course there
to be used...but the point at which one can claim a specialized distro
is 'based on' Fedora is a not well defined in layspeak. Nothing I've
read so far in the trademark section of the fedora.redhat.com website
jumps out and says yes/no to this specific sort of 'based on' or
'packages from' advertising. My reading of
http://fedora.redhat.com/about/trademarks/guidelines/ tells me
you should get clarification from some form of legal counsel.
But stepping back from the legalese arguments for a moment. Are you
prepared to remove advertising that says your liveCD was based on
Fedora, if the Fedora leadership made that request? Legally binding
trademark issues aside. I think there are pros/cons to having
experimental development to be able to use 'based on' Fedora
advertising. On the pro side...its a PR win for Fedora to be seen as
enabling a range of experimental development, thats a PR win for a more
open process. On the con side... any problems with a custom distro
picking up and using pieces of Fedora make it harder to distinguish
where bug reports go and could become a drag on the official development
process. What happens if your patched kernel exposes a bug in a fedora
package that you are using in your liveCD? Where do those bug reports
live? Is it even appropriate for users of your liveCD to report back any
problems to the Fedora development process? Is the real value in the
Fedora brand going to be the bits and pieces or is it going to be the
development process and structure? If the value is in the development
process...the saying 'based on' Fedora would be interpreted as 'based
on' the development process.
>>
>> There exists ntfs read support apparently.
>>
>> Actually, veering from this, maybe we should be creating a Fedora non-us
>> archive of sorts? Or is Fedora Extras a project that'll keep the NTFS
>> stuff, and the non-blessed Core stuff? (currently, that seems to be the
>> case, with the mplayer/divx/mp3 archives).
>That could be a great idea - especially for a non us customer...
Again there are going to be issues with calling anything 'Fedora.'
There is clearly a place and a demand for a 'freeworld' shadow community
process and repository structure that builds on top of
the base Fedora process to provide open-source solutions that a US based
organization is prohibited from providing for non-technical reasons. But
for the same non-technical reasons, it will be very difficult for the
official Fedora process to even link or to talk about the 'freeworld'
structure that springs up.
-jef
20 years, 4 months
