https://bugzilla.redhat.com/show_bug.cgi?id=982517
Bug ID: 982517
Summary: 4.4.1. Adding a New User
Product: Fedora Documentation
Version: devel
Component: system-administrator's-guide
Severity: unspecified
Priority: unspecified
Assignee: jhradile(a)redhat.com
Reporter: im_dracula(a)hotmail.com
QA Contact: docs-qa(a)lists.fedoraproject.org
CC: jhradile(a)redhat.com
Description of problem:
In section 4.4.1 at item number 6 explaining the user creation process, it is
inferred that the contents of /etc/skel are as follows:
.
..
.bash_logout
.bash_profile
.bashrc
.gnome2
.mozilla
They are in fact:
.
..
.bash_logout
.bash_profile
.bashrc
.mozilla
.zshrc
--
You are receiving this mail because:
You are the QA Contact for the bug.
Product: Fedora Documentation
https://bugzilla.redhat.com/show_bug.cgi?id=891931
Bug ID: 891931
Summary: Chapter 3
Product: Fedora Documentation
Version: devel
Component: uefi-secure-boot-guide
Severity: unspecified
Priority: unspecified
Reporter: jwboyer(a)redhat.com
Description of problem:
I wrote this a couple of weeks ago:
http://jwboyer.livejournal.com/46149.html
It details building a custom kernel. Feel free to use anything you'd like from
there. However, it doesn't cover:
- generating your own key/certs
- signing shim or grub2 (trivially derived from the existing kernel example)
- third party module signing
Peter is working on a tool to make generating certs that UEFI likes easier for
people. I was waiting for that tool to be available before really covering
those aspects, as that is what we want users to use.
--
You are receiving this mail because:
You are the QA Contact for the bug.
Product: Fedora Documentation
https://bugzilla.redhat.com/show_bug.cgi?id=892673
Bug ID: 892673
Summary: UEFI Secure Boot Guide: suggestions for edits
Product: Fedora Documentation
Version: devel
Component: uefi-secure-boot-guide
Severity: unspecified
Priority: unspecified
Reporter: fweimer(a)redhat.com
Replace: "With the planned release of Windows 8, Microsoft has decided that all
hardware that is marked "Windows 8 client ready" should"
With: "Microsoft requires that client devices carrying the Windows 8 logo must"
Replace: "This means that Fedora as it stands booted on such hardware will
refuse to boot until the user disables secure boot in the firmware."
With: "The UEFI boot loader on Fedora installation media and on the installed
system are signed with the Microsoft key, to enable booting and installation on
such systems."
Remove the following paragraph, ending in "This plan has been approved by the
Fedora Engineering Steering Committee as of 23-Jul-2012."
After: "any operations from userland which cause userland-defined DMA"
Insert: "disable support for hibernate/suspend-to-disk, and other features
which would allow executing arbitrary code in kernel mode (even for the root
user)."
--
You are receiving this mail because:
You are the QA Contact for the bug.
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.
Summary: value of security measures; no metric, no scope description
https://bugzilla.redhat.com/show_bug.cgi?id=782916
Summary: value of security measures; no metric, no scope
description
Product: Fedora Documentation
Version: devel
Platform: Unspecified
OS/Version: All
Status: NEW
Severity: unspecified
Priority: unspecified
Component: security-guide
AssignedTo: eric(a)christensenplace.us
ReportedBy: budden(a)nps.navy.mil
QAContact: docs-qa(a)lists.fedoraproject.org
CC: pkennedy(a)redhat.com, eric(a)christensenplace.us,
security-guide-list(a)redhat.com, oglesbyzm(a)gmail.com
Classification: Fedora
Story Points: ---
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Description of problem:
The juncture between computer security and network security is inadequate --
too many seams which leaves too many man-in-middle attack opportunities.
The most egregious omission in this (otherwise pretty good) document is
treatment of SCOPE. This probably belongs in the vicinity of 1.3.
Analysis first. Map each of the security solutions you have in the guide onto
the ISO Reference Model:
Layer 1/2 security measures (like WiFi security) protect frames. The scope of
the security is limited to a single segment. No security beyond the router and
no security within end systems.
Layer 3 security protected datagrams (VPNs do this, IPSec ....). The scope is
an enclave tunneled through an internetwork. The protection cannot extend
beyond the VPN boxes, so data is wholly unprotected within end systems (and LAN
if the VPN box is associated with the last router).
Layer 4/5 security includes SSL (aka TLS). You have a how-to for securing an
http server (good) but no admonitions regarding scope -- the security extends
from the TCP socket in one end system to the TCP socket at the other end of the
connection -- again no security inside the OS comes from SSL.
All of the above security measures protect infrastructure. But they do not
protect the data.
Layer 6/7 security measures protect the data. Here the scope _can be_ truly
end to end. S/MIME is a good example (so is ssh and XML sign/crypt) where the
data passes over the internet and through the OS in protected form. Only in a
fairly small space is the data unprotected. In Evolution, for example, only
the parts of the UA that deal with composing, reading, ... mail are places
where the authenticity and confidentiality of the data is possible. Most of
the rest of the UA (including all the filing system deals with data that has
been protected exactly the way it's been sent over the network. In the case of
Evolution (UAs differ in implementation) secured data is stored in the file
system exactly the way it was transmitted.
Recommendations:
1) include a mapping similar to above so users have an idea what the scope of
this or that security measure is.
2) emphasize those security measures that apply to applications (layer 6/7) as
Fedora distribution evolves and matures. (What got me here this morning is the
continuing frustration getting Evolution to properly play ball with DoD CAC
cards ... works, but doesn't 'just work').
Version-Release number of selected component (if applicable):
Security Guide 16.3 (doesn't have a date)
How reproducible:
The above analysis doesn't invent anything; it only organizes and sorts.
Anyone can reproduce it.
Steps to Reproduce:
1.
2.
3.
Actual results:
Expected results:
Additional info:
--
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=977063
Bug ID: 977063
Summary: New NetworkManager features should be documented
Product: Fedora Documentation
Version: devel
Component: system-administrator's-guide
Severity: unspecified
Priority: unspecified
Assignee: jhradile(a)redhat.com
Reporter: me(a)petetravis.com
QA Contact: docs-qa(a)lists.fedoraproject.org
CC: jhradile(a)redhat.com
NetworkManager now offers hotspot functionality, allowing users to easily share
a non-wireless connection over a wireless interface.
As of F19, NetworkManager allows the creation and usage of both bridge and bond
virtual devices.
These features should be documented in the System Administrator's guide.
--Pete
--
You are receiving this mail because:
You are the QA Contact for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=987669
Bug ID: 987669
Summary: Fedora has no support or support limits
Product: Fedora Documentation
Version: devel
Component: virtualization-deployment-and-administrative-guide
Assignee: lnovich(a)redhat.com
Reporter: me(a)petetravis.com
QA Contact: docs-qa(a)lists.fedoraproject.org
CC: lnovich(a)redhat.com
Created attachment 777472
--> https://bugzilla.redhat.com/attachment.cgi?id=777472&action=edit
Comments out support limit section
The section referencing RHEL/RHEV support limits does not apply to fedora
users. The attached patch comments out this section.
--
You are receiving this mail because:
You are the QA Contact for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=987710
Bug ID: 987710
Summary: section "Guest CPU models" needs updating
Product: Fedora Documentation
Version: devel
Component: virtualization-deployment-and-administrative-guide
Assignee: lnovich(a)redhat.com
Reporter: me(a)petetravis.com
QA Contact: docs-qa(a)lists.fedoraproject.org
CC: lnovich(a)redhat.com
The section "Guest CPU models" should be updated, comments below:
Background:
- http://wiki.qemu.org/Features/CPUModels has the QEMU roadmap for relevant
features
- rawhide/F20 is currently shipping qemu-1.5.1
- F19 is currently shipping qemu-1.4.2
- F18 is currently shipping qemu-1.2.2
- Fedora ships qemu-kvm as /usr/bin/qemu-kvm not /usr/libexec/qemu-kvm
The first part of the section states CPU configurations are defined in XML
files rather than hardcoded; per the roadmap, they are again hardcoded to allow
compatibility code and more unified processor definitions. There's no
indication of backwards compatibility from qemu, although virsh and friends may
still accept .conf definitions and Know What To Do when talking to qemu.
In F18 and F19, `qemu-kvm -cpu ?cpuid` and `qemu-kvm -cpu ?dump` do not
function.
In F18, `qemu-kvm -cpu ?` gives a terse list of definitions.
in F19, `qemu-kvm -cpu ?` gives a more descriptive list, and also includes a
comprehensive list of recognized CPU flags. This could possibly replace
`?cpuid`
In both, `qemu-kvm -cpu <name>,enforce` functions as expected; this content is
commented out.
Looking further into comparing guest CPU features, I find `virsh capabilities`
will generate xml representing the host. It also appears to represent other
architectures that the host could emulate - if the appropriate packages (ie
qemu-arm ) are installed, and I correctly understand what they do.
There's also `virsh cpu-baseline` to generate a cpu definition that would allow
migration between file-defined hosts, and `virsh cpu-compare` to compare a
defined host with the local host. Both of these rely on [deprecated] xml .conf
cpu definition files. I haven't been able to find a more elegant way to compare
cpu configurations than scripting together the above virsh commands, presuming
`virsh capabilities` works the way I suspect.
The qemu roadmap cites `-cpu best` as a way to get the best CPU definition when
creating a guest - but it doesn't work here, and I'm not sure how it would make
a determination if it did.
A lot of the information I've discovered deals directly with qemu, not libvirt.
With qemu moving back to hard coded cpu definitions, I think it would be good
to get some insight on if libvirt tools are affected and how they are handling
the change. In general, I think it would be better to present libvirt commands
rather than commands executing qemu directly.
I'm not submitting a patch for this one because I'm not sure where to go with
it. It *seems* like libvirt should have a simple way to compare the
capabilities of heterogeneous hosts and aid in creating the best definitions
for guests.
--
You are receiving this mail because:
You are the QA Contact for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=987674
Bug ID: 987674
Summary: KVM host verification is called KVM guest
compatibility, and does not have a direct link
Product: Fedora Documentation
Version: devel
Component: virtualization-deployment-and-administrative-guide
Assignee: lnovich(a)redhat.com
Reporter: me(a)petetravis.com
QA Contact: docs-qa(a)lists.fedoraproject.org
CC: lnovich(a)redhat.com
Created attachment 777474
--> https://bugzilla.redhat.com/attachment.cgi?id=777474&action=edit
Change title and add link
The section "KVM guest virtual machine compatibility" refers to verifying that
a machine is capable of acting as a KVM host, and references the Virtualization
Administration Guide.
The attach patch changes the title of that section to better reflect the
content, and provides a direct link to the referenced content.
--
You are receiving this mail because:
You are the QA Contact for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=987664
Bug ID: 987664
Summary: Guide intro references documnetnation that is not
available for Fedora
Product: Fedora Documentation
Version: devel
Component: virtualization-deployment-and-administrative-guide
Assignee: lnovich(a)redhat.com
Reporter: me(a)petetravis.com
QA Contact: docs-qa(a)lists.fedoraproject.org
CC: lnovich(a)redhat.com
Created attachment 777453
--> https://bugzilla.redhat.com/attachment.cgi?id=777453&action=edit
Patch commenting out unavailable guides.
The introduction to the Virtualization Deployment and Administration Guide
references related documentation that has been developed for RHEL/RHEV but is
not maintained for Fedora. The attached patch comments out those sections so
that only guides that are currently maintained for Fedora will be referenced.
--
You are receiving this mail because:
You are the QA Contact for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=831619
Bug ID: 831619
QA Contact: docs-qa(a)lists.fedoraproject.org
Severity: low
Version: devel
Priority: unspecified
CC: ddomingo(a)redhat.com, oglesbyzm(a)gmail.com
Assignee: r.landmann(a)redhat.com
Summary: Inaccuracy in Fedora 17 “Power Management Guide”
Regression: ---
Story Points: ---
Classification: Fedora
OS: Linux
Reporter: vaskodd(a)yahoo.com
Type: Bug
Documentation: ---
Hardware: x86_64
Mount Type: ---
Status: NEW
Component: power-management-guide
Product: Fedora Documentation
Created attachment 591487
--> https://bugzilla.redhat.com/attachment.cgi?id=591487&action=edit
The problem description in .pdf format - easy to follow
Hi,
First I want to notice I am a Linux newbie and my English is not that good.
Now straight to the point! (The same description is available in the attached
pdf file and is more easy to follow)
I've noticed some inaccuracy in Fedora 17 “Power Management Guide” (Fedora
Documentation), particularly in section “2.5. Tuned and ktune” including
“2.5.1. The tuned.conf file” and “2.5.2 Tuned-adm”.
In section “2.5. Tuned and ktune” right bellow the “yum install tuned”
command it's written:
“Installing the tuned package also sets up a sample configuration file at
/etc/tuned.conf and activates the default profile.”
There is no such file in /etc. I found a /etc/tuned/active_profile file
containing the following: “/usr/lib/tuned/balanced/tuned.conf”. I'm not sure
this file (/etc/tuned.conf) is missing only on my system or it has a new
location by default for each profile - /usr/lib/tuned/profileX/tuned.conf.
Bellow in this section and in “2.5.1. The tuned.conf file” it is pointed again
that the default location for the tuned.conf file is /etc/tuned.conf.
In section “2.5.2 Tuned-adm” in the first paragraph it is written “Fedora 17
includes a number of predefined profiles for typical use cases...”. Just to be
precise it is good to be mentioned that these profiles are not installed by
default with “yum install tuned” command (tuned-2.0.1-1.fc17 package), but can
be found in tuned-profile-compat-2.0.1-1.fc17 package (I found it in Gnome
Package Manager).
Another thing in this section is in the last third of the page where it is
written:
“All the profiles are stored in separate subdirectories under
/etc/tune-profiles. So /etc/tune-profiles/desktop-powersave contains all the
necessary files and settings for that profile. Each of these directories
contains up to four files:”
There /etc/tune-profiles directory does not exist. Instead I found the profiles
stored in /run/lib/tuned.
Each directory for the corresponding profile typically contains only 2 files -
script.sh and tuned.conf. The presence of script.sh is not mentioned in the
directories contains description – it is mentioned ktune.sh insetad.
That's all. I hope this is helpful.
Best regards
Vasil Draganov
Fedora 17 3.4.0-1.fc17.x86_64
P.S. “Power Management Guide” is great. It's really useful. The moment i run
tuned service i noticed how quieter my laptop became (less heat – less fan
needed :) ). The first thing I noticed about new Fedora installation was that
the laptop was noisier in comparison to Win7 (I dual-boot with Win7). Tuned
just fixed that :)
Many thanks to the creators of Fedora Documentation!!!
--
You are receiving this mail because:
You are the QA Contact for the bug.