Firewalld

Stephen Wadeley swadeley at redhat.com
Tue Aug 26 19:40:22 UTC 2014


On 08/26/2014 09:22 PM, Pete Travis wrote:
> On 08/26/2014 09:43 AM, Eric H. Christensen wrote:
>> On Mon, Aug 25, 2014 at 03:40:10PM -0600, Pete Travis wrote:
>> > On 08/25/2014 02:17 PM, Eric H. Christensen wrote:
>> >> On Mon, Aug 25, 2014 at 01:13:46PM -0600, Pete Travis wrote:
>> >>> Here's my idea:  In the security guide, give an overview, instructions
>> >>> on how to lock down to deny-all, general instructions on adding back,
>> >>> and link out to the Networking Guide. In the NG, give a full
>> overview -
>> >>> network security should be an inherent part of network configuration.
>> >>> In others, include the command to open a port for the service being
>> >>> documented where appropriate.
>> >>
>> >> I really dislike the idea of spreading information out into different
>> >> guides.  Users think they've got the entire story only to miss another
>> >> aspect elsewhere.
>> >>
>> > Right, it's the spreading out that bothers me too. Service config here,
>> > network config here, firewall config there.  I *don't* like the idea of
>> > managing similar content in different places, though.  The wiki doesn't
>> > really fix that problem; includes work there just as well as in docbook,
>> > there's just a broader scope.  There are valid concerns about the
>> > administrative overhead of our publishing stack, vs the 'just write'
>> > ethos of a wiki - but I think that even with a wiki we would need to
>> > have discussions about structure and scope.
>>
>> So how about this...  Instead of having these big, fat guides that
>> contain a lot of information on a lot of different topics, we start
>> breaking down these guides into smaller chunks.  Think "Firewall
>> Guide" which would talk specifically about iptables and firewalld.
>> They likely would be less work to maintain (although there would be
>> more of them) since, potentially, it would have less stuff to deal with.
>>
>> -- Eric
>>
>> --------------------------------------------------
>> Eric "Sparks" Christensen
>> Fedora Project
>>
>> sparks at fedoraproject.org - sparks at redhat.com
>> 097C 82C3 52DF C64A 50C2  E3A3 8076 ABDE 024B B3D1
>> --------------------------------------------------
>
> I like it. More manageable chunks sounds.. more manageable. Until we get
> to the part where you have to read the httpd guide to set up a web
> server, then the SELinux guide for file contexts for a web server, then
> the firewall guide for firewall rules for a webserver -

Now now now Pete, steady on, having a small guide on firewall topics 
open while editing the firewall rules and then alt-tabing back to the 
guide you were using to set up httpd is not so bad. Could even be better 
than having a huge guide a having to search three or ten chapters 
forward and back all the time,

or we maintain
> the same content in different guides and try to keep track of it all.

No, please, no duplication. Links with scripts to check links are valid 
is better.
> Yeah, I know you're saying "start here", but I think we've come back
> around to the question about most suitable formats.
>
> The idea of modularized documentation is*really*  appealing, but the
> actual implementation isn't going to come for free.  Will
> publican/docbook work? What formats would enable the built-for-purpose
> articles that Dylan is envisioning?  We should explore some
> possibilities before putting in the work to migrate the copy into new books.
>
> ( He says, hoping the conversation doesn't die there )
>
> --
> -- Pete Travis
>   - Fedora Docs Project Leader
>   - 'randomuser' on freenode
>   - immanetize at fedoraproject.org
>
>
>

-- 
Stephen Wadeley
Content Author | Red Hat, Inc.
Purkynova 99 | Brno, Czech Republic



More information about the docs mailing list