asciibinder and RPM
by Matthew Miller
It looks like asciibinder isn't packaged as an RPM. In general I'm not
*super* excited about the overall endeavor of taking gems and making
RPMs, but if we're making asciibinder core infrastructure for docs, I
think we should get it packaged up for easy consumption.
Should we ask the Ruby sig to help with this? I wouldn't mind packaging
just asciibinder itself, but it looks to have a number of dependencies
that I'm not really qualified to own.
(For the curious,
https://github.com/redhataccess/ascii_binder/blob/master/ascii_binder.gem...
lists the dependencies. Looks like we're missing diff_dirs,
asciibinder-diagram, guard, guard-shell, guard-livereload, pandoc-ruby,
sitemap_generator, and yajl-ruby. Plus something called "trollop" which
needs to be a version in f27/rawhide but not yet in f26.)
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
6 years, 7 months
[Bug 1198984] New: firewalld: please improve documentation on using it on a RedHat/Fedora/CentOS router
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1198984
Bug ID: 1198984
Summary: firewalld: please improve documentation on using it on
a RedHat/Fedora/CentOS router
Product: Fedora Documentation
Version: devel
Component: cookbook
Assignee: docs(a)lists.fedoraproject.org
Reporter: razvan.sandu(a)mobexpert.ro
QA Contact: docs-qa(a)lists.fedoraproject.org
CC: docs(a)lists.fedoraproject.org
Hello,
Description of problem:
Even using the rich-language feature, it is still rather difficult to figure
out
how to use firewalld on a RedHat/Fedora/CentOS system that is used as a router
(a "transparent" system).
That's because:
a. administrators will need *different* sets of rules/restrictions for access
to the router itself and to the various services that run beyond the router
(using or non using NAT).
b. It is not very clear how/where the predefined firewalld zones implement
their policies (ACCEPT or DROP) and when these policies apply to traffic
bounded *to* the router system or to traffic that *traverses* the router.
For example, an administrator needs an *easy* method to restrict VNC access
*to* the router itself (INPUT), but may want free VNC access to some server
located *behind* the router (FORWARD). In the second case, forwarding may (or
may not) imply NAT, depending if he goes on the Internet via the external
interface or simply goes in another LAN segment beyond the router.
c. It is not very clear how/where the predefined firewalld zones implement
their trafic rules ( *exceptions* to ACCEPT or DROP default policies) and when
these rules apply to traffic bounded *to* the router system or to traffic that
*traverses* the router.
Additional info:
Even it is not dynamic, the Shorewall application (http://shorewall.net/) acts
as a higher-level language over iptables, offering the same concepts of "zones"
for interfaces. Much of its conceptual architecture is directly applicable
("portable") to firewalld, if accepted by developers.
Somewhat different from conceptual point of view, the "zones" are "levels of
trust surrounding the router", including thr FW zone for the router itself.
(unlike firewalld, the shorewall zones have no "sources" or "services" embedded
in them).
IPv4 and IPv6 zones are completely separated (they actually represent different
levels of trust).
Administrators may directly define policies, i.e. allow *default* actions to be
done when an packet travels from a zone to another (ACCEPT, REJECT). The most
sane policy between any two zones is REJECT (with further exceptions defined as
rules, see below).
Rules are *exceptions to policies* , explicitly defined (based on various
criteria such as source IP, destination IP, ports, etc.)
Rules may be expressed via predefined (or customised) "macros" (which are the
direct equivalent of firewalld's "services").
IPv4 and IPv6 policy and rules are completely separated (IMHO that's good,
since the use of global IPv6 addresses pose completely different security
problems than NATted & externally firewalled IPv4).
Best regards,
Răzvan
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
6 years, 7 months
[Bug 755744] New: typo in PV-Configuring_Additional_Devices
by Red Hat Bugzilla
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.
Summary: typo in PV-Configuring_Additional_Devices
https://bugzilla.redhat.com/show_bug.cgi?id=755744
Summary: typo in PV-Configuring_Additional_Devices
Product: Fedora Documentation
Version: devel
Platform: Unspecified
OS/Version: Unspecified
Status: NEW
Severity: unspecified
Priority: unspecified
Component: virtualization-guide
AssignedTo: docs(a)lists.fedoraproject.org
ReportedBy: shaiton(a)fedoraproject.org
QAContact: nobody(a)fedoraproject.org
CC: kwade(a)redhat.com, oglesbyzm(a)gmail.com
Classification: Fedora
Story Points: ---
Type: ---
>From the file available in transifex,
Now you can configure the new network interfaces using
<command>redhat-config-network</command> or Red Hat Enterprise Linux3 or
<command>system-config-network</command> on Red Hat Enterprise Linux 4 and Red
Hat Enterprise Linux 5.
that should be "on" Red Hat.
I could have corrected that now that I have git access, but this git is still
for F14… There were plenty of update about virt since F14, is it outdated?
http://fedoraproject.org/wiki/Docs_Project_meetings#Guides
--
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
6 years, 7 months
