> The preview site has been updated. You can check it
> out at
" Most of the threats on the Internet typically target
Microsoft Windows systems. As more and more users
start trying and using linux, it will become more and
more important for the common user to know how to
harden his or her system against these threats. "
this suggests that Linux has no security threats at
present which is not true. I would prefer a guide on
hardening Linux talk about Linux rather than start by
a comparison with Windows
The parts about using gpg or md5 requires more
explanation. If you are explaning it in a later part
refer to that
If you are including abbrevations such as NAT it would
be better to provide the expansion, explanation or a
afaik I know yum is the recommended command line
program to use instead of up2date in fedora. if you
have sections on both yum and up2date you probably
need to explain the differences too which I would
consider out of scope for this article
" The services that you can *safely* disable will
depend upon the role of your system."
if you need to emphasise on safely use italics or what
the style guide recommends.
yum - Enable daily run of yum, a program updater.
(This will depend on your environment.)"
since every service is pretty much dependant on the
role of the system special emphasis for the yum deamon
" Below is a list of user accounts that most Fedora
Core users will want to disable."
The above wording suggests that most users of Fedora
do not run the services that follows it. It would be
better to say something like this
"The following are some of the services that you might
want to disable in the system depending on the your
Since this is out of scope for your document by your
own admission it would be better to just drop this.
Kernel recompilation or additional hardening is
unnecessary for the large majority of users and worse
gives the idea that the kernel requires active manual
intervention to make it secure.
I am not sure what the policy is for linking to
external documents but permissions are much better
Either link to this document or copy and paste with
attribution (The license is compatible)
you can mention that these program exist in fedora
extras. fc4 will have extras repo enabled by default.
previous versions will require more explanation or how
to add the repo (steps are different between fc2 and
a related sshd configuration change is disable ssh1
protocol which is prone to man-in-the-middle attack
this section seems to be redundant
this can probably be clubbed together with the section
this section requires more information. if you are
going to just point to external links convert this
section into a note
it is possible to provide a port range here. More
information is available in the redhat docs.
redhat.com/docs. you cannot copy and paste (license
restrictions) but you very well gather the information
I would prefer a link to the SELinux faq and guide and
provide references and a bibliography.
Do you Yahoo!?
Yahoo! Mail - now with 250MB free storage. Learn more.
> The below items in bold are Required while the other items are
optional but highly recommended.
WTF!!?? People volunteer to help and get rather long list of *required*
information!!?? I reserve further comment and decided it would be bad
form for a new user to edit the wiki... I won't even start talking about
right to privacy and the idea of a meritocracy!
1. Duncan Lithgow
2. I'm in the city of Århus in Denmark (pronounced 'oar-huus'), but
New Zealander by birth and taste in breakfast cereals.
3. I'm trained as an architect, self taught so-so php programmer
but good with html/css. Currently doing boring labour temping.
Done lot's of other irrelevant stuff. Oh, one relevant thing is
I'm a trained 'english as a foreign language' (efl/esl) teacher
- so i'm passionate on the need for docs written in easy to
understand english - far too much is written for advanced
english speakers - think how many non english speakers try to
make use of these docs.
5. Your goals in the Fedora Project
* What do you want to write about?
* - don't know yet. Maybe 'Why should your non-nerd
girlfriend/boss/college use linux and how to convince
them and them her'
* What other documentation do you want to see published? -
* Do you want to edit for grammar/writing and/or technical
* - yes/yes/no
* Anything else special?
* - editing for friendliness to esl readers.
6. Historical qualifications
* What other projects or writing have you worked on in the
* - while learning postnuke cms I wrote this about the
theme system, I thought it was poorly documented and
neede to keep track of what I was learning. I've since
turned the xml file over to the postnuke docs team ( i
don't use postnuke any more) http://www.lithgow-
* What level and type of computer skills do you have?
* - modest, just starting to learn the command line. Long
time semi-power-user of windows.
* What other skills do you have that might be applicable?
User interface design, other so-called soft skills
(people skills), programming, etc.
* - good at cross-culture communication, constructive
critic of design quality of gui's in terms of logical
structure and intuitiveness.
* Why should we trust you? <--- too blunt?
* You shouldn't until I've proved myself, but hey, get
over it, we're talking about writing docs!
7. GPG KEYID and fingerprint
* Be sure that your GPG key is uploaded to pgp.mit.edu.
Use "gpg --keyserver pgp.mit.edu --send-key KEYID".
* Your GPG fingerprint is 40 hexadecimal characters long,
while your KEYID is the last 8 digits.
* Below is an example of a block of text suitable for cut
& paste into your self-introduction e-mail.
* sounds like a hastle, follow the link, it's easier:
So, that's me on a good day, in an impatient tone. ;-)
I am new to this list. the reason I'm posting here is the following:
At the 'fedora-list' there has been a recent community effort to
formulate a document with the "guidelines" for posting to that list.
After a number of drafts and discussions, this document has reached a
more mature form, and has been put in the form of a web page:
It is already considered "official", in the sense that it grew from
discussions in the list that have reached a consunsus. As a next step,
we would like to make this document know for most users of the list.
For this, the suggestions we have are:
1. Monthly reminder: having a link or a text-only
version of this document sent automatically
monthly to all subscribers;
2. Part of a welcoming message: Either include a
link in the welcoming message, or send a separate
e-mail with the text-only version of the document
to every new subscriber;
3. Linked to sign-up page: maybe there could be a link
in the sign in page?
4. Link in the sugnature. (in **MY** opinion, this would
likely be the most effective of all.) It would help if
there could be a link in the signature added by RedHat
to all messages distributed. The signature could then
look something like:
fedora-list mailing list
To unsubscribe: http://www.redhat.com/mailman/listinfo/fedora-list
Before posting to this list, please check << link here >>
4. Submission to Fedora-docs: That last suggestion was made
to make this documet more "official".
So, that's where we are now. Please consider this message as a
"submission" Unless there's another way to do it). We would really
appreciate if the people responsibe could take a look at the page and
consider accepting it, if it seems appropriate.
Thank you very much,
Gustavo Seabra Graduate Student
Chemistry Dept. Kansas State University
Registered Linux user number 381680
If at first you don't succeed...
...skydiving is not for you.
Thanks to everyone who has helped with the Fedora docs project. After a
slow start, I think we are steadily gaining momentum.
>From the Red Hat side, Karsten Wade has really stepped up and
demonstrated leadership potential. So much potential in fact, that I
have decided to turn over leadership of the project to him. Most
projects change leadership once a year or more, and I think this is a
great idea for our project as well. In the future, the project leader
will change on a yearly basis, if not sooner.
I will take more of a technical perspective, offering editing assistance
and programming skills should any of our custom DocBook scripts and
stylesheets need updating or modifications.
In the next few weeks, Karsten will put together a steering committee
for the Fedora docs. The committee will meet on a regular basis to
discuss tasks that need to be done to move the project forward. Expect
to hear more about it from him shortly.
I 've read this interessant message and would be happy to get involved
in the docs project.
I'm French,29,Linux user (and addict) since a long time. In my free
time, i like to contribute to free softwares projects (as developer or
I am a Fedora user since last year and it's very wonderful (with my 64
bits,that's amazing ).That's for why i want to contribute to Fedora as
writer (and developer if i have enough time).It would be for me a very
good and learnful experience.
So,tell me what i can (or could) do.
We definitely need more writers and content. Here is a summary of my
recruiting spiel, and I encourage all of you to look for opportunities
to recruit new writers:
* When someone complains about the docs, ask if they are interesting in
helping to make them better.
* When someone posts any kind of doc, ask if they are interested in
making it a Fedora doc (such as Rahul just did on f-devel-l).
* When someone expresses a desire to help a particular project or just
open source in general, use the arguments below to see if they might
like being a doc writer.
Where to look:
* The LUG you are a member of and related technical groups (IEEE, SANS,
* IRC and other help forums.
* Within existing upstream projects, e.g. GNOME, Samba, etc.
In the latter case, a person might be able to get a document into Fedora
that wouldn't fit or be accepted in an upstream project.
Here is a modified spiel I sent out recently. It's a bit long, but it
embodies all the ideas I've thought of. I've used this same kind of
content in IRC to recruit folks.
The Fedora Project is looking for more writers.
You don't need to be a great writer. That's why we have editors.
Look upon it as a chance to improve your writing skills while
contributing to the Fedora community.
If this intrigues you at all, please read on.
Maybe you've wanted to be involved with Fedora but don't know a way.
Or you want to expand your involvement. Consider writing or editing
for the Fedora Docs Project (FDP):
* Have closer contact with your favorite developers and projects.
* Become or further expand into being a subject matter expert for
your favorite topics.
* Gain reputation within the community.
* Learn to be a better writer, editor, and technical reviewer.
What might you write about?
* Be the release notes subject expert.
* Installation or configuration of any software or hardware under
Fedora Core, including any of the sub-projects such as Fedora
Extras, Fedora Directory Server, and so forth.
* General or security best practices, even abstracted from the OS
but still relevant to Fedora Core.
* Whatever interests you.
What is there to worry about?
"The toolchain is hard."
If you don't know DocBook, it's definitely time for you to learn.
Meanwhile, project members have volunteered to help anyone get their
document converted into DocBook. From there, you can teach yourself
as you continue writing and maintaining.
We are using the Wiki at http://www.fedoraproject.org/ and remain
open to further toolchain/publishing considerations. Heck, if you
want to get fedoraproject.org to host a blog that to publish
tips-n-tricks, that would be a great Fedora documentation effort.
"The amount of content is a lot to write and maintain."
The FDP is geared to small how-to and tutorial documentation. If
you know your subject area, you can likely write a usable draft that
is 80% complete content within a few hours. Give it a try.
You can contribute to a larger guide, such as a chapter or even a
section. This is currently true for the release notes, and may be
how the Fedora Installation Guide is handled in the future.
If you are writing about what you know and alrady use, then the odds
are that you will be using it in the future and can easily maintain
a document on the subject. This is the difference between Fedora
docs and the kind of documentation that Red Hat Enterprise Linux
does: massive guides are hard to maintain, while small tutorials
and how-to docs can be practically painless to maintain.
"I hate writing."
We need technical editors, especially if more writers start joining.
We may need your help in an area you know about already, in terms of
the toolchain, automation, CVS management, project management and so
Since effective communication is a part of all of our lives, perhaps
this is an opportunity for you to get free editing and writing
advice. This is especially helpful for non-native writers who would
like to improve their English writing skills.
Interested? Drop a note to fedora-docs-list(a)redhat.com and tell us
whatever you want.
 To see what this has done for one Fedora wirter, google for
"selinux" and see the second full return. The Fedora SELinux FAQ has
a lot of googlejuice.
## 30 ##
^^^^^^^^ -- This is an old newspaper usage for "that's all, stop setting
Karsten Wade, RHCE * Sr. Tech Writer * http://people.redhat.com/kwade/
gpg fingerprint: 2680 DBFD D968 3141 0115 5F1B D992 0E06 AD0E 0C41
Red Hat SELinux Guide
Does anyone have any experience of these, as they are doing my head in?
T +44 (0) 1467 624141
M +44 (0) 7930 323266
F +44 (0) 1224 742001
Open Source. Open Solutions(tm).
Regarding this thread... I signed up for the mailing list right when my job was
terminated and I was laid off from SGI.
Once I can land myself a job, I'll be an active contributor. I have one heck of
a mail queue to look through!
Show us what our next emoticon should look like. Join the fun.
Recently I've been taking a look at how far along the xmlroff project
is (http://sourceforge.net/projects/xmlroff), and whether it can meet
the needs of the Fedora Project documentation yet.
The short answer is that it cannot yet do all that we need; most
notably, the implementation of images is in flux and so they do not
work at the moment. The upstream maintainer looks to have a good idea
of how it should be done, and has posted a step-by-step list on the
xmlroff mailing list:
However, aside from images, what other things would we need from an
XSL-FO processor? My thinking is that if "all" that's missing for us
in xmlroff is the images rewrite, it might be quite a nice project to
> * I hope the gpg key isn't a bad hurdle for writers
> and editors who are
> new to open source projects.
It wouldnt be if the process of gpg key generation is
documented or an external link is provided on the
exact steps including the specific path where the key
Do you Yahoo!?
Make Yahoo! your home page