docs April 2005

docs@lists.fedoraproject.org

36 participants
79 discussions

Updated Hardening guide.
by tuxxer 13 May '05

13 May '05

Beat me up again guys and gals. ;-) http://members.cox.net/tuxxer http://members.cox.net/tuxxer/fedora-hardening-guide-whole-en.xml XML also posted to bug #129957. -Charlie -- -tuxxer gpg: 57EB F948 76AE 25BC E340 EFA9 FAF6 E1AC F1E1 1EA1

6 15

[RFC] dumping the CED in favor of local variables
by Karsten Wade 04 May '05

04 May '05

I'd like to recommend we dump the usage of CED files in favor of the local variables designation. The CED file is a pre-compiled DTD subset. http://fedora.redhat.com/participate/documentation-guide/s1-emacs-cedfile.h… The only noticeable change that matters is that indenting is different by two characters overall. It's really no big thing to reindent entire files, or sections of them to avoid <screen> blocks. The CED files technically need to be recompiled with the introduction of each new tag. They are a hassle to load everytime you load the document. The local variables will load the parent file in the buffer, which is convenient, and does all this automatically when you open the file. You put one of these at the bottom of each XML file:  The small pain of converting our docs will be more than made up for in the not-so-long run. - Karsten -- 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 http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/selinux-guide/

4 6

Comments on Documentation Idea
by Thomas Jones 29 Apr '05

29 Apr '05

Hello all, I have been reviewing the progress of the Fedora project for over a year now. Honestly, I was a little reluctant to transition to another distribution. I had been a mainstay of SuSE since release 7.0; mainly because of the security oriented nature of the product(s). Now that I've made the plunge and am loving it; I want to provide my services to the community where I can. Here goes my idea: What about a documentation suite entitled --- Fedora Security Series? Here's a brief vision statement. The purpose of the series is to provide a security-related orientation of a great multitude of topics and how they relate to the Fedora distribution and its role in a network infrastructure. For instance, the first couple topics that I would like to write would be: - Risk Assessment of a Fedora Core Installation Scheme - Risk Analysis of an Desktop Installation - Risk Analysis of an Server Installation - Policy Development in a Multiuser System - etc...... As you can see, the topics are sequential in structure. Which alleviates any issues due to end-user initiated problems. i.e. in order to develop a complete operating system risk analysis and determine a control solution(s); you must first perform the risk assessment to determine probable threat agents, and safeguards The intended audience would be Power-Users, and individuals with Information Technology experience. However, with a good content model it should be easily understood by the general user. This series should be authored by individuals with relevant security experience. They don't need to be CISSP certified; just have first hand knowledge of the topic. I am inclined to get the series started in the right direction; so I would like to write the first few topics for a good base. Then it's up to the community! These should all be included in a series of related themes. I can start the first topic as soon as the community accepts the idea. I personally think this is great idea (of source I would!); but don't want to work on this idea; if it undermines the ideas of other team members. Thank you for your time. Thomas Jones

6 9

CVS now open
by Karsten Wade 29 Apr '05

29 Apr '05

Hi fellow writers and editors: We are mighty pleased to announce the opening of CVS for the Docs Project. Our intention is to have the lowest barrier to entry possible. After getting our grubby little hands, uh, I mean, fine Elven fists on the keys a few weeks ago, we have been formulating some philosophy and guidelines to help make our experience nicer. ## Quick Version of How To Get CVS Access: * Read the CVSAccess guidelines Wiki page[1] * Do a proper self-introduction to the list * Show that you have something to put in CVS: as an editor by picking something to edit, as a writer through producing a draft or working outline * Use the proper process[2] to get an account on cvs.fedora.redhat.com [3]. Put yourself in the 'cvsdocs' group and wait for approval. [1] http://www.fedoraproject.org/wiki/DocsProject/CvsUsage [2] http://www.fedoraproject.org/wiki/Extras/CvsAccess [3] https://admin.fedora.redhat.com/accounts/ This all presumes you have read the Documentation Quick Start[4] and are familiar with the Fedora Project Documentation Guide[5]. Don't worry about the DocBook/XML stuff right now. :) [4] http://fedora.redhat.com/participate/documentation-quick-start/ [5] http://fedora.redhat.com/participate/documentation-guide/ ## What Philosophy? Golden Rule in effect. Treat others and their directories in CVS as you would have them treat you and your files. Only truly vital resources will have CVS ACLs. You are on your best behavior as a community member to Do The Right Thing. Don't put any illegal stuff in CVS. That would be BAD. Don't attempt (or succeed) in cracking the CVS host systems, or use it as a launchpad for crack attempts. That would be VERY BAD. ## Who Gets to Go Where? Read the CVSAccess[1] page for details. The quick version is that assigned writer(s), editor(s), and a doc manager are the only ones who should be messing around in a particular directory. The doc manager is the single person accountable for what goes on in the directory. It can be one of the writers, editors, or third person otherwise not involved. To start, it's likely to be one of the FDSCo members, lending a wise and guiding hand where needed. *cues ethereal music* Each doc has one or more writers who must collaborate together within the same repository. Thank ye gods for revision control! An editor can edit for technical and grammatical/wordsmith details. The editor must know and enforce the style guidelines from the Doc Guide[6]. There may be more than one editor to fill all the roles. [6] Forthcoming URL _will_be_: http://fedora.redhat.com/participate/documentation-guide/ch-style.html NOTE: URL does not work. We're, uh, editing it for style. Long story. Coming Real Soon Now, with a shiny announcement. -- 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 http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/selinux-guide/

1 1

Kate - another editor
by Karsten Wade 28 Apr '05

28 Apr '05

Just had someone point me at Kate from KDE. It looks like quite a decent XML editor. It ships as part of the kdebase package. - Karsten -- 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 http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/selinux-guide/

2 1

docs CVS commits - new list
by Karsten Wade 28 Apr '05

28 Apr '05

Until it was recently changed, our CVS commit messages were being copied to a list for Fedora Extras. To highlight our own signal, I changed the commit messages to come to fedora-docs-commits. Currently our commit level is low, but as it ramps up, we are going to be glad that this is not coming to f-docs-l. :) https://www.redhat.com/mailman/listinfo/fedora-docs-commits This is an important part of having an open CVS, seeing what everyone is doing. Mistakes will be caught more quickly, and it will be easier to learn how and why writers and editors do as they do. For example, in the past I've collaborated with other writers on the same XML files, and I could watch the changelog messages to see what people did and why they did it (presuming their log was useful). I would know right away if I needed to fix anything. If you are writing or editing for the project, it is truly necessary to be on the commits list. cheers - Karsten -- 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 http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/selinux-guide/

1 0

[Fwd: [LINK] Open source projects for those on the dole (fwd)]
by Karsten Wade 28 Apr '05

28 Apr '05

Anyone in Australia want to see if there are potential doc writers in this program? DocBook/XML is much easier to learn than most programming, is a real world skill, and we sure could use docs from regular users for regular users. Open source projects for those on the dole Angus Kidman APRIL 26, 2005 The Australian http://australianit.news.com.au/articles/0,7204,15083420%5E15317%5E%5Enbv%5… A NEW "hack for the dole" scheme will allow unemployed people to meet their mutual obligation requirements by working on open-source software projects. Linux Australia has gained approval for the scheme being launched as part of its CommunityCode.org project to encourage software development. It is trying to attract skilled enthusiasts to work as mentors. Project developer Matthew Palmer said he had begun working with a mother who was developing educational software for children. He said early interest in the project, launched last week at Linux.conf.au 2005 in Canberra, had been strong. "I've talked to heaps of people and they've all been really keen on it," he said. As well as coding, other tasks under the scheme could include documenting and art. As a community organisation, Linux Australia meets government requirements for organising mutual-obligation projects for the long-term unemployed. Mr Palmer said, although Linux was easy to use as a desktop operating system, one goal for the Community Code.org project was to make contributing software modifications an equally straightforward task for everybody. -- We have yet to see the full impact of the open, global marketplace. By 1997 all raw materials and technology will be available everywhere in the world. The only differences between countries and markets will be skill levels, education, and the level of empowerment of the workplace. -- Sydney Smith Regards brd Bernard Robertson-Dunn Sydney Australia brd(a)iimetro.com.au _______________________________________________ Link mailing list Link(a)mailman.anu.edu.au http://mailman.anu.edu.au/mailman/listinfo/link _______________________________________________ Memo-list mailing list Memo-list(a)redhat.com http://post-office.corp.redhat.com/mailman/listinfo/memo-list -- 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 http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/selinux-guide/

3 2

toolchain master tracker bug
by Karsten Wade 27 Apr '05

27 Apr '05

When you expect that an area will get a lot of attention so that you need to do some project planning around it, it's nice to have a tracker bug. This bug is put in the "Bug ABCXYZ blocks" field. This allows you to create a dependency tree. This is the tracker bug for feature requests and bugs against the FDP toolchain: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=fdp-toolchain-traqr If you like numbers, because you'll need to use them too: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=156150 - Karsten -- 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 http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/selinux-guide/

2 2

HTML chunks/no-chunks changes
by Karsten Wade 27 Apr '05

27 Apr '05

James Laska (jlaska at redhat) submitted the following changes to our XSL to support no-chunks in HTML: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=156151 This was done for qa-docs work, but can apply to us. I've got this organized into a bugzilla, but don't have the time today to wrap my brain around the XSL changes. So I'm interested in feedback from you all. thx - Karsten -- 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 http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/selinux-guide/

1 0

Self Introduction: Just because it wasn't a practice when I joined! ;-)
by tuxxer 27 Apr '05

27 Apr '05

1. Full legal name Charles C Heselton 2. City, Country San Diego, CA, USA 3. Profession or Student status Security Engineer 4. Company or School Raytheon 5. Your goals in the Fedora Project * What do you want to write about? Security pertinent topics. * What other documentation do you want to see published? Security related documentation. ;-) * Do you want to edit for grammar/writing and/or technical accuracy? Sure. * Anything else special? I believe in the open source community and I want to contribute wherever, and however, I can. Plus, I like to drink beer. ;-) 6. Historical qualifications * What other projects or writing have you worked on in the past? Mainly proprietary stuff, SOP's etc. * What level and type of computer skills do you have? Gimme a scale. ;-) I can script (perl, shell, etc.), write web pages, etc. I've been in the industry for about 8 years, security specifically for about 3 years.... I've been working with Linux since Caldera OpenLinux 3.2?? (circa 1999-ish) * What other skills do you have that might be applicable? Not sure.....don't know fully what the requirements are yet. * What makes you an excellent match for the project? I'm interested, I want to contribute, and I have time to spare. (well.....some. ;-) 7. GPG KEYID and fingerprint pub 1024D/F1E11EA1 2004-05-02 Key fingerprint = 57EB F948 76AE 25BC E340 EFA9 FAF6 E1AC F1E1 1EA1 uid Tuxxer (Tuxxer) <tuxxer(a)cox.net> sub 1024g/A168232E 2004-05-02

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

docs April 2005