noexec on /dev/shm
by John Reiser
How did /dev/shm get noexec in Fedora 15 rawhide?
$ grep /dev/shm /proc/mounts
tmpfs /dev/shm tmpfs rw,seclabel,nosuid,nodev,noexec,relatime 0 0
$ grep -srl noexec /etc
/etc/alternatives/ld
/etc/fstab ## derived from /proc/mounts
/etc/mtab ## derived from /proc/mounts
This is a change from Fedora 14, and I cannot find documentation.
The only 'noexec' that I can find in the source to systemd-15
is two mentions in units/var-{lock,run}.mount.
As a site administrator, how can I change the default to omit 'noexec'?
As a project leader, how can I get my project's programs working again
if I do not have the privileges of a site administrator?
The project is a database system that creates and dlopen()s
plugins on-the-fly, for better performance on ["long-running"] queries.
We like the speed of creat+write+close+open+read+mmap on /dev/shm.
If /dev/shm and /tmp both become off limits, then what is
the recommended replacement location?
--
13 years, 3 months
Deltarpm python3 build failure
by Jonathan Dieter
I noticed an announcement that Python3 has made some changes in how C
modules are built.
I now seem to be running into some problems building deltarpm for
Rawhide and it seems to be tied into this. See
http://koji.fedoraproject.org/koji/buildinfo?buildID=212117 for more
details.
Not sure if I need to change the Makefile to adjust for this, or just
the spec. Some advice would be greatly appreciated.
Jonathan
13 years, 3 months
Heads-up: Audacious 2.4.2 hitting Rawhide
by Michael Schwendt
I'm building Audacious 2.4.2 in Rawhide, and once available in the koji build
root, this will require rebuilds of the separate _plugin_ packages.
The tools/apps linked with Audacious' core libraries are not affected:
audtty
conky
2.4.2 is the first maintenance release in the [supposed to be stable] 2.4
branch, but bumped the generic plugin API to version 17 nevertheless.
Quite early in 2.4.x development actually. Plugins, if not rebuilt, would
refuse to load.
The rebuilds should be possible without problems. If run you into
anything unexpected, feel free to contact me.
13 years, 3 months
HEADS UP! Ohloh Fedora repositories
by Peter Lemenkov
Hello All!
I'm currently in process of automatic enlisting of all ~10K Fedora Git
repos at Ohloh. Right now roughly 7% of repositories were added and
overall process will be finished in a 20-30 hours (it takes me about
5-10 seconds to properly add repository, and I don't want to speedup
this process - to prevent Ohloh from accidental DoS).
Just FYI.
--
With best regards, Peter Lemenkov.
13 years, 3 months
[HEADS-UP] MySQL 5.5 coming soon to rawhide
by Tom Lane
Since MySQL AB^W^WSun^WOracle has now declared the mysql 5.5.x release
series to be GA status, I'm planning to push it into rawhide shortly to
replace the 5.1.x series. Theoretically, this will go pretty smoothly.
I'm aware of a couple of ABI-level issues:
1. libmysqlclient.so, which is linked into all manner of stuff, is
supposed to be ABI-compatible with the previous releases. However,
I got tired of the amount of visible churn in exported-symbols-you're-
not-supposed-to-use. The new release will use a linker --version-script
to hide everything except the documented API functions. This might
break any apps that are relying on non-API functions. If so, I'm
willing to consider on a case-by-case basis whether to add those symbols
back to the ABI or fix the callers.
2. libmysqlclient_r.so is gone altogether; there's no need for it since
the regular libmysqlclient.so library is supposed to be thread safe.
AFAIK this will require rebuilding only the following packages:
mysql++
mysql-connector-c++
nekovm
qt-mysql
For now I'll include a symlink libmysqlclient_r.so -> libmysqlclient.so,
so that a simple rebuild with no source-code changes should be
sufficient. Eventually we'll probably want to fix the source code to
not refer to libmysqlclient_r, but that might take awhile if upstreams
are worried about portability.
There are also some SQL-level incompatibilities called out here:
http://dev.mysql.com/doc/refman/5.5/en/upgrading-from-previous-series.html
I'm not sure to what extent these may affect Fedora applications,
but it seems like the easiest way to find out is to try them.
Any objections? Anything people think should be tested before pushing?
regards, tom lane
13 years, 3 months
Fedora default services (was: Re: F15 Feature - convert as many service init files as possible to the native SystemD services)
by Michał Piotrowski
Hi,
W dniu 3 grudnia 2010 09:14 użytkownik Michał Piotrowski
<mkkp4x4(a)gmail.com> napisał:
[..]
> What services are installed by default when installong form Live
> GNOME/KDE/etc and DVD?
Ok, let's ask the question differently - what services should be run
by default to provide working system for desktop user?
IMO ssh can be off by default and should be started only if user tries
to connect over port 22.
Do we really need to install iptables/ip6tables by default (it's in core group)?
--
Best regards,
Michal
Sent from my iToaster
13 years, 3 months
Fedora as semantic desktop (nautilus and tracker integration) ?
by Valent Turkovic
https://bugzilla.redhat.com/show_bug.cgi?id=501227
I'm writing to devel list just if anybody can say will there be any
chance to get nautilus and tracker integration working? Is this on
anybody's radar?
Thanks,
Valent.
--
pratite me na twitteru - www.twitter.com/valentt
blog: http://kernelreloaded.blog385.com
linux, anime, spirituality, windsurf, wireless, ronjenje, pametne kuće, zwave
registered as user #367004 with the Linux Counter, http://counter.li.org.
ICQ: 2125241, Skype: valent.turkovic, MSN: valent.turkovic(a)hotmail.com
13 years, 3 months
firewalld - A firewall daemon with D-BUS interface providing a dynamic firewall (test version)
by Thomas Woerner
Hello,
as discussed some time ago, I worked on the proof of concept
implementation of firewalld. FirewallD is a service daemon with a D-BUS
interface that provides a dynamic managed firewall.
For more information on firewalld, please have a look at:
https://fedoraproject.org/wiki/FirewallD/
About this version:
This is mostly the proof of concept implementation with some changes and
is feature complete for F-15 as a firewalld preview version. It will not
be enabled per default and will also not get installed per default. The
system-config-firewall with static firewall model will still be the
default firewall solution for Fedora 15.
What this firewalld version can do:
- It supports most of the firewall features system-config-firewall had,
but there are three limitations:
1) custom firewall rule files (iptables save format) are not
supported and most likely will never be, but there is support for
custom rules (limited functionality).
2) sysctl changes for ip_forward are not done, yet.
3) There are no permanent firewall settings, this means that all
settings are lost after a service restart or reboot. Permanent
firewall settings will be added later on.
- The firewall daemon manages the firewall dynamically. This means that
changes are done without recreating the whole firewall. Also there is
no need to reload all firewall modules anymore. Firewall helpers are
loaded and unloaded if needed.
- A simple tray applet (firewall-applet) shows the status of the public
firewall and is makes it simple to enable and disable firewall
services. The applet does not show firewall configuration settings
done with the libvirt interface.
- firewall-cmd is the command line client that makes it possible to
enable, disable, query and list firewall features. firewall-cmd is
also not able to show firewall settings of the libvirt interface.
- There is an rule and chain interface for libvirt, but the PolicyKit
policy is not in place, yet.
What this version can not do (future features):
- firewall-config, the firewall configuration utility, is not functional
- System vs. User/Session configuration
- Zone support
- NetworkManager firewall rule support
firewalld made it into a fedorahosted repo at:
git://git.fedorahosted.org/git/firewalld.git
The fedoraproject wiki page at
https://fedoraproject.org/wiki/FirewallD/
exists and will get more updates soon. The feature request page for
Fedora 15 is also up to date:
https://fedoraproject.org/wiki/Features/DynamicFirewall#How_To_Test
For test packages, please have a look at
http://twoerner.fedorapeople.org/firewalld/
firewalld has a requirement for system-config-firewall-1.2.28. This
version has checks for an active firewalld in the tools.
Please have a look at
http://koji.fedoraproject.org/koji/buildinfo?buildID=211013
for the Fedora 15 packages of this version. It is usable on fedora
versions < 15.
How To Test
- Install firewalld and firewall-applet
- Start the firewalld service
- Start the tray applet firewall-applet
- Use firewall-cmd to enable for example ssh:
firewall-cmd --enable --service=ssh
- Enable samba for 10 seconds:
firewall-cmd --enable --service=samba --timeout=10
- Enable ipp-client:
firewall-cmd --enable --service=ipp-client
- Disable ipp-client:
firewall-cmd --disable --service=ipp-client
- To restore your static firewall with lokkit again simply use:
lokkit --enabled
You can also use the D-BUS interface directly. This is required for
libvirt (and later on also NetworkManager). The D-BUS interface
documentation is work in progress and will be added later on.
Comments and additional information is highly welcome.
Thanks in advance,
Thomas
--
Thomas Woerner
Software Engineer Phone: +49-711-96437-310
Red Hat GmbH Fax : +49-711-96437-111
Hauptstaetterstr. 58 Email: Thomas Woerner <twoerner(a)redhat.com>
D-70178 Stuttgart Web : http://www.redhat.de/
13 years, 3 months
Package-specific test case and critical path test case project: drafts for review
by Adam Williamson
Hi, everyone. So, in the recent debate about the update process it again
became clear that we were lacking a good process for providing
package-specific test instructions, and particularly specific
instructions for testing critical path functions.
I've been working on a process for this, and now have two draft Wiki
pages up for review which together describe it:
https://fedoraproject.org/wiki/User:Adamwill/Draft_QA_SOP_test_case_creation
https://fedoraproject.org/wiki/User:Adamwill/Draft_QA_SOP_package_test_pl...
the first isn't particularly specific to this, but it was a prerequisite
that I discovered was missing: it's a guide to test case creation in
general, explaining the actual practical process of how you create a
test case, and the best principles to consider in doing it.
The second is what's really specific to this subject. It describes how
to create a set of test cases for a particular package, and a proposed
standardized categorization scheme which will allow us to denote test
cases as being associated with specific packages, and also denote them
as concerning critical path functionality.
Given that mediawiki has a handy API which also allows you to deal with
categories, this should make it easy to both manually and
programmatically derive a list of test cases for a given package, and a
list of *critical path* test cases for a given package. You can do this
manually, but I also envision Bodhi and fedora-easy-karma utilizing the
API so that when an update is pushed for a package for which test cases
have been created under this system, they will link to those test cases;
and when an update is pushed for a critical path package, they will be
able to display separately (and more prominently, perhaps) the list of
test cases relevant to the critical path functionality of the package.
Comments, suggestions and rotten fruit welcome :) I'm particularly
interested in feedback from package maintainers and QA contributors in
whether you feel, just after reading these pages, that you'd be
confident in going ahead and creating some test cases, or if there's
stuff that's scary or badly explained or that you feel like something is
missing and you wouldn't know where to start, etc.
The trac ticket on this is probably valuable for background, explaining
why some things in the proposal are the way they are:
https://fedorahosted.org/fedora-qa/ticket/154
it also mentions one big current omission: dependencies. For instance,
it would be very useful to be able to express 'when yum is updated, we
should also run the PackageKit test plan' (because it's possible that a
change in yum could be fine 'within itself', and all the yum test cases
pass, but could break PackageKit). That's rather complex, though,
especially with a Wiki-based system. If anyone has any bright ideas on
how to achieve this, do chip in! Thanks.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
13 years, 3 months
F14 OOo deltarpms not being generated on releng2
by Jonathan Dieter
I'm not sure if there's a better list for this to go to, but there seems
to be a problem generating deltarpms for F14 OOo (and a few other
packages) on releng2. Specifically, the updates->updates deltarpms
aren't being generated, while the GA->updates deltarpms are.
When I checked the mash.out log for the 101202.1757 push, there are
loads of error messages following the form of:
Error genDeltaRPM for openoffice.org-langpack-pt_PT: exitcode was 256 -
Reported Error: bad cpio archive
The problem is that this error normally comes up when one of the rpms is
corrupt, but manually running deltarpm between an rpm from the
101201.1909 push and the update from the 101202.1757 push results in a
proper drpm and no errors.
As far as I can see, this only affected the openoffice.org* and
autocorr* packages in the 101202 push, and the rest of the packages in
the push had all the proper deltarpms generated.
I'm not sure where to go from here. Any ideas on how to track this
down?
Jonathan
13 years, 3 months
