On Wed, Nov 26, 2014 at 03:13:59PM +1000, Noriko Mizumoto wrote:
> Hi Fedora developers
> Having the consensus with FESCo , we FLP (aka translation team) have
> started the process of migration to new fedora.zanata.org instance from
> Transifex . First all translators started to migrate in November 2014
> (still going on).
> Now it is time to migrate all projects. This is expected to start after
> F21 GA. For the owners of the projects, there are two options to choose
> for the migration below.
> One: Delegate us to implement migration
> If this option is chosen, partially automated migration will be
> performed by Zanata team. Once it completes, then the owner visits new
> place and confirms everything intact (Some manual adjustment may be
> Two: Manual migration
> If this option is chosen, the owner performs all the migration process
> by his/her self. Please advise the estimated completion date.
> I have attached the list of all the target projects below. If any
> package is missing and it should be added into the list, please let me know.
> Could all Fedora developers please go through the list and advise which
> option is preferred for your project, so that we will be able to
> schedule them? For option One, we need to know current
> maintainer's/owner's contact.
> Package Name Group
> Anaconda main
> Blivet main
> Firstboot main
> initial-setup main
> pykickstart main
> python-meh main
> system-config-kickstart main
These are all installer team projects. What are we required to do with the
move to Zanata?
David Cantrell <dcantrell(a)redhat.com>
Manager, Installer Engineering Team
Red Hat, Inc. | Westford, MA | EST5EDT
Sshd(8) daemon by default allows remote users to login as root.
1. Is that really necessary?
2. Lot of users use their systems as root, without even creating a non-root user.
Such practices need to be discouraged, not allowing remote root login could be
useful in that.
Does it make sense to disable remote root login by default? If so, do we need to just report it to the maintainer or it would be treated as a feature?
Today it happened a handful of times that my local rpm repository got
wiped out (except for the repodata folder), and owner/group changed to
root/root (including the repodata folder). After playing around a bit, I
noticed that a
$ pkcon refresh
will consistently wipe out my local repository . Putting an audit
watch on an rpm on the repo will actually confirm that PackageKit
removed the file, see below . However, the odd thing is that
PackageKit was last updated Nov 18 on my system, and also downgrading to
PackageKit-1.0.1-1.fc22 from Oct 21 does not help, so I'm wondering
whether it is really PackageKit who is responsible. Updates of yesterday
and today do not really seem to be of any relevance.
Anyone else seeing this? Any ideas how to debug this?
 If it matters, repo file is
$ cat /etc/yum.repos.d/local.repo
name=Local - Source
 $ sudo ausearch -f
type=CONFIG_CHANGE msg=audit(30.11.2014 01:15:48.332:497) : auid=unset
ses=unset op="updated rules"
key=repo list=exit res=yes
type=PROCTITLE msg=audit(30.11.2014 01:15:48.332:498) :
type=PATH msg=audit(30.11.2014 01:15:48.332:498) : item=1
inode=5505054 dev=08:03 mode=file,664 ouid=sandro ogid=sandro rdev=00:00
type=PATH msg=audit(30.11.2014 01:15:48.332:498) : item=0
name=/home/sandro/rpmbuild/repo/ inode=5513217 dev=08:03 mode=dir,775
ouid=sandro ogid=sandro rdev=00:00
type=CWD msg=audit(30.11.2014 01:15:48.332:498) : cwd=/
type=SYSCALL msg=audit(30.11.2014 01:15:48.332:498) : arch=x86_64
syscall=unlink success=yes exit=0 a0=0x7fd7401f88e0 a1=0xffffffff
a2=0x7fd7401f8801 a3=0x7fd763e53970 items=2 ppid=1 pid=1902 auid=unset
uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root
fsgid=root tty=(none) ses=unset comm=PK-Backend
exe=/usr/libexec/packagekitd (deleted) subj=system_u:system_r:rpm_t:s0
Resending this as a new thread, for increased visibility.
As explained in the older thread, the Mozilla project has started to
remove CA certificates that contain weak keys. Those removals cause
issues with software based on OpenSSL, and software based on older
versions of GnuTLS.
(A short description of the issue can be found in tracker bug
https://bugzilla.redhat.com/show_bug.cgi?id=1166614 - I intend to file a
ticket against OpenSSL shortly.)
For Fedora, we have decided to keep the legacy CA certificates included
and trusted by default, in order to avoid compatibility issues, until we
get functional updates to OpenSSL.
I'm documenting the changes on top of the Mozilla CA
list at: https://fedoraproject.org/wiki/CA-Certificates
However, we want to provide users/administrators with the ability to
change the default, by configuring the ca-certificates to strictly
follow the trust decisions made by Mozilla, thereby accepting the
compatibility issues (e.g. untrusted TLS connections, if certificates of
affected server configurations cannot be validated).
The above has been implemented for Fedora 21, it looks like it will be
included as part of the Fedora 21 release:
Using the new ca-legacy utility, it is possible to disable trust for the
legacy CA certificates as a systemwide configuration, by executing this
command as root:
The configuration will be remembered in /etc/pki/ca-trust/ca-legacy.conf
and will be used on future package upgrades, when additional
certificates are moved to the legacy state.
If required, it's possible to undo the configuration and revert to the
current default, using:
The current configuration can be shown using:
Regarding Fedora 19 and Fedora 20:
On F19/F20, GnuTLS is also affected by the breakage, when disabling
trust for the legacy CAs, because GnuTLS has been enhanced in Fedora 21
and later, only.
Updated packages for F19 and F20, that provide the update to version 2.1
of the ca-certificates list, and which also include the new ca-legacy
utility and configuration mechanism, have been pushed to
As you might know ABRT attaches 'environ' file to its Bugzilla bugs. The file
contains a full copy of /proc/[pid]/environ. Even though ABRT highlights
black-listed words and encourages users to review the data before submitting
them, it may happen that the reporter misses something and publishes his secrete
data in 'environ' file.
Do you find 'environ' attachment valuable or is ABRT just publishing personal
I was testing installing Fedora 21 Final RC1 in the free space on a GPT
drive with Windows 8.1 (Lenovo Z40). I'm installing from a USB stick made
from the ISO.
Every time I click "Begin Installation" in Anaconda, it locks up at the
screen where I'm supposed to be able to enter the root password and create
a user account. The message at the bottom is something like "Initializing
setup configuration" (sorry, I can't recall the exact words). I can't click
on anything in Anaconda, but I can switch to a terminal and "kill -9 <pid
of anaconda>" to drop me back to the Live desktop.
I do not get the same problem if I delete all the existing partitions on
the drive and install only Fedora. That proceeds fine. The problem only
seems to exist if I try to install alongside Windows.
My question is: how might I go about troubleshooting this?
Christopher L Tubbs II
This is about bug #1136905 , discussed previously on the systemd list
 and also on our desktop list .
The issue is that systemd-timedated now supports only systemd-timesyncd
for NTP and ignores other NTP services installed on the system. It doesn't
know that chronyd or ntpd is enabled (usually by system-config-date after
the installation) and switching NTP in timedate clients such as
timedatectl and GNOME control center is broken.
If we want to have this working correctly with chronyd/ntpd, at this point
it seems the only reasonable option is to replace systemd-timedated.
timedatex is a new implementation of the timedate interface that was
recently added to Fedora. It reads the list of NTP units from a directory
as systemd-timedated used to do. When installed, systemd will start it for
the timedate bus name instead of systemd-timedated. The timedate clients
should work as expected, please report bugs if not.
One suggestion was to install it as a dependency of the NTP packages.
Is this a good idea? Should this first go through the Fedora change
process or at least be documented somewhere?
I've got a TV schedule grabber script that needs to be run on a more or
less daily basis. That would be good enough, but the script suggests a next
start time in it's output when it completes.
If I can figure out a way to pull that time from the script, is there a way
to pass that to systemd?