Strange ssh / openldap linking problem
by Richard W.M. Jones
I'm not sure whether or not this is a bug, but it sure looks strange.
$ rpm -qf /usr/bin/ssh
openssh-clients-6.1p1-6.fc18.x86_64
$ ldd /usr/bin/ssh|grep ldap
libldap-2.4.so.2 => /lib64/libldap-2.4.so.2 (0x00007fad274fc000)
/usr/lib64/libldap-2.4.so.2 is a symbolic link to a symbolic link
which passes through a -devel package.
/usr/lib64/libldap-2.4.so.2 -> libldap.so # openldap-2.4.34-1.fc18
/usr/lib64/libldap.so -> libldap-2.4.so.2.9.0 # openldap-devel-2.4.34-1.fc18
/usr/lib64/libldap-2.4.so.2.9.0 is a real file # openldap-2.4.34-1.fc18
To cut a long story short, I fixed this by uninstalling openldap-devel
and reinstalling it. Now there is no -devel package in the chain:
$ ldd /usr/bin/ssh | grep ldap
libldap-2.4.so.2 => /lib64/libldap-2.4.so.2 (0x00007fe8caf69000)
/lib64/libldap-2.4.so.2 -> libldap-2.4.so.2.9.0
I'd like to understand how the original situation happened, because it
broke a supermin-built appliance (RHBZ#954185). I assume ldconfig
must have something to do with it. There is nothing unusual in the
%scripts of openldap (it just runs ldconfig as you'd expect), nor is
there any special openssh/openldap config file in /etc/ld.so.conf.d.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine. Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/
10 years, 1 month
F21 System Wide Change: Ruby 2.1
by Jaroslav Reznik
= Proposed System Wide Change: Ruby 2.1 =
https://fedoraproject.org/wiki/Changes/Ruby_2.1
Change owner(s): Vít Ondruch <vondruch(a)redhat.com>
Ruby 2.1 is the latest stable version of Ruby, with major increases in speed,
memory efficiency and reliability. With this major update from Ruby 2.0.0 in
Fedora 20 to Ruby 2.1 in Fedora 21, alongside JRuby, Fedora becomes the
superior Ruby development platform.
== Detailed Description ==
Ruby 2.1 is upstream's new major release of Ruby. Notable changes are:
* VM (method cache)
* RGenGC
* refinements
* syntax changes
** Rational/Complex Literal
** def’s return value
* Bignum use GMP
* String#scrub
* Socket.getifaddrs
* RDoc 4.1.0 and RubyGems 2.2.0
* “literal”.freeze is now optimized
* add Exception#cause
* update libraries like BigDecimal, JSON, NKF and Rake
* remove curses
Please also note, that Ruby moved to semantic versioning since this version.
Yet, it is source level backward compatible with Ruby 2.0.0, so your software
will continue to work.
== Scope ==
* Proposal owners:
** Update of Packaging Guidelines for Ruby packages. This needs to reflect
recent changes introduced by recent version of RubyGems shipped with Ruby 2.1.
** Rebuilding of Ruby packages providing native extensions (i.e. packages
which depends on libruby), including changes needed by updated packaging
guidelines.
* Other developers: N/A
* Release engineering:
** Rebuilding of Ruby packages providing native extensions (i.e. packages
which depends on libruby), including changes needed by updated packaging
guidelines.
* Policies and guidelines:
** Update of Packaging Guidelines for Ruby packages. This needs to reflect
recent changes introduced by recent version of RubyGems shipped with Ruby 2.1.
_______________________________________________
devel-announce mailing list
devel-announce(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
10 years, 1 month
Java headless bugs
by Jerry James
I've got a few comments and questions about the recently filed bugs asking
us to switch from Requires: java to Requires: java-headless. First, the
bugs list some web pages to view for more information. Number two on that
list is this:
https://fedoraproject.org/wiki/Packaging:Java\#BuildRequires_and_Requires
which has a really unfortunate backslash in it. People clicking on that
link get a "sorry, no such page" message from the web server. It should
have been this:
https://fedoraproject.org/wiki/Packaging:Java#BuildRequires_and_Requires
Second, the bugs talk about this as a proposed guidelines change, yet
https://fedoraproject.org/wiki/Packaging:Java now talks about it. Doesn't
that mean that this is an official guideline, not a proposed change to the
official gudelines?
Third, developers are offered two options in those bugs: (1) don't do
anything and an automatic tool will make the change for you on or after
March 17, or (2) make the change to java-headless yourself. I have one
package for which I need a third option: tell the automated tool that this
bug was filed in error, the package really doesn't work with java-headless,
and don't touch the package. I realize that I can mark the bug as assigned
and leave it open indefinitely, but I'd rather have some option for closing
the bug, please.
Slightly off-topic: fedora-review is telling packagers NOT to add
"Requires: jpackage-utils" to javadoc subpackages because that is added
automatically, but I see no mention of this on
https://fedoraproject.org/wiki/Packaging:Java.
Thanks,
--
Jerry James
http://www.jamezone.org/
10 years, 1 month
Packages installing files to /etc/rpm
by Ville Skyttä
A number of packages install files to /etc/rpm in Rawhide; the proper
place for macros.* is /usr/lib/rpm/macros.d for rpm >= 4.11. And no
matter what the location, these files should not be marked as %config.
Specfiles not targeting EL < 7 can simply replace %{_sysconfdir}/rpm
with %{_rpmconfigdir}/macros.d and ones that wish to stay compatible
with EL5 and 6 can do something like this to find the proper dir:
%global macrosdir %(d=%{_rpmconfigdir}/macros.d; [ -d $d ] ||
d=%{_sysconfdir}/rpm; echo $d)
List of affected packages follows (maintainer package comaintainers):
bkabrda python3 amcnabb,bkabrda,mstuchli,tomspur
bkabrda python bkabrda,dmalcolm,ivazquez,jsteffan,mstuchli,tomspur,tradej
cicku ldc bioinfornatics
deji mpich (none)
dledford openmpi dajt,deji,orion
epienbro mingw-filesystem ivanromanov,kalev,rjones
erikos sugar-toolkit erikos,pbrobinson,sdz,tomeu
erikos sugar-toolkit-gtk3 dsd,pbrobinson
jakub prelink mjw
jcapik octave alexlan,fkluknav,jussilehtola,mmahut,orion,rakesh
jjames ffcall salimma
jjames gap (none)
jjames xemacs stevetraylen
jnovy texlive pertusus,than
jorton httpd hubbitus,jkaluza
jorton php-pear remi,timj
jorton php remi
jplesnik perl corsepiu,cweyl,iarnell,jplesnik,kasal,perl-sig,ppisar,psabata,spot
jussilehtola libint (none)
jzeleny scl-utils bkabrda,jzeleny
kanarip ruby bkabrda,jstribny,kanarip,mmorsi,mtasaka,skottler,tagoh,vondruch
kanarip rubygems kanarip,mtasaka,skottler,stahnma,vondruch
kwizart color-filesystem rhughes
limb drupal7 asrob,pfrields,siwinski
mmorsi jruby bkabrda,goldmann,vondruch
mstuchli pypy tomspur
msuchy rhn-client-tools mzazrive
nim fontpackages fonts-sig,frixxon,tagoh
orion hdf5 davidcl,pertusus
patches nodejs-packaging humaton,jamielinux,mrunge,sgallagh
patches nodejs-tap jamielinux
peter erlang-rpm-macros erlang-sig
petersen ghc-rpm-macros haskell-sig,petersen
phracek emacs jgu,phracek
pjones pesign (none)
pmatilai redhat-rpm-config jcm,pmatilai
ppisar perl-srpm-macros mmaslano,perl-sig
rdieter ggz-base-libs (none)
rdieter polkit-qt mbriza,rnovacek,than
remi php-horde-Horde-Role nb
rmattes ros-release (none)
rombobeorn fedora-gnat-project-common (none)
rstrode GConf2 walters
s4504kr blender fcami,hobbes1069,kwizart,roma
s4504kr gnustep-make s4504kr,salimma
smani keyrings-filesystem (none)
sochotni javapackages-tools java-sig,mizdebsk,msimacek,msrb
spot generic-release bruno
spot R salimma
than sip kkofler,ltinkl,rdieter
twaugh cups jpopelka
10 years, 1 month
F20 Self Contained Change: Snapshot and Rollback Tool
by Jaroslav Reznik
= Proposed Self Contained Change: Snapshot and Rollback Tool =
https://fedoraproject.org/wiki/Changes/Rollback
Change owner(s): Stephen Gallagher <sgallagh(a)redhat.com>, Colin Walters
<walters(a)redhat.com>
With the advent of thinly-provisioned LVM pools, it has become possible for us
to implement full-system LVM snapshotting for recording rollback points. We
are planning to support this for yum updates and eventually fedup upgrades
going forwards. This change request notes the addition of new tools provided
by the roller-derby project to present an interface and a CLI for managing and
initiating rollbacks.
== Detailed description ==
The roller-derby project will be providing a library and a CLI for creating,
labeling and managing LVM snapshots (plus non-LVM backups of /boot), oriented
primarily towards rpm-managed data, but useful beyond that. The yum plugin
"yum-plugin-fs-snapshot" will be updated to consume this library and save the
system state in a compatible format. The roller-derby CLI tool will provide an
interactive and scriptable interface for manipulating these snapshots and
determining when to remove older ones. It will also allow the tagging of
snapshots as "known-good", to be skipped when automatically-trimming for
space. The roller-derby project will likely provide a small daemon to keep
track of the available space in the LVM pool to proactively clean up snapshots
before the system runs out of space.
In order to prevent "loss" of data when rebooting into an snapshot, the
roller-derby CLI will allow saving a snapshot of the current state before
rolling back and will provide tools to allow mounting of that current state to
recover changes that have occurred since the rollback point.
== Scope ==
The scope of this project is the completion of the initial release of the
roller-derby project and the inclusion of thinly-provisioned LVM as an option
in the Anaconda installer [1].
Proposal owners: We need to complete the roller-derby project. Other than the
Anaconda change referenced above, all dependencies are available in Fedora
already.
Other developers: OS Installer Support for LVM Thin Provisioning
Release engineering: N/A (not a System Wide Change)
Policies and guidelines: N/A (not a System Wide Change)
[1] https://fedoraproject.org/wiki/Changes/InstallerLVMThinProvisioningSupport
_______________________________________________
devel-announce mailing list
devel-announce(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
10 years, 1 month
Sshd getting 'dyntransition' AVC's in SElinux enforcing mode
by Philip Prindeville
I’m seeing the following after an update (via yum) from F19 to F20:
----
time->Tue Dec 24 16:05:44 2013
type=SYSCALL msg=audit(1387926344.492:5867): arch=c000003e syscall=1 success=no exit=-13 a0=6 a1=7f4e5e7afbb0 a2=20 a3=7fff44c2c550 items=0 ppid=686 pid=693 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 ses=4294967295 tty=(none) comm="sshd" exe="/usr/sbin/sshd" subj=system_u:system_r:init_t:s0 key=(null)
type=AVC msg=audit(1387926344.492:5867): avc: denied { dyntransition } for pid=693 comm="sshd" scontext=system_u:system_r:init_t:s0 tcontext=system_u:system_r:sshd_net_t:s0 tclass=process
----
time->Tue Dec 24 16:05:45 2013
type=SYSCALL msg=audit(1387926345.093:5883): arch=c000003e syscall=1 success=no exit=-13 a0=7 a1=7f4e5e7acef0 a2=2a a3=666e6f636e753a72 items=0 ppid=686 pid=706 auid=1000 uid=1000 gid=1000 euid=1000 suid=1000 fsuid=1000 egid=1000 sgid=1000 fsgid=1000 ses=627 tty=(none) comm="sshd" exe="/usr/sbin/sshd" subj=system_u:system_r:init_t:s0 key=(null)
type=AVC msg=audit(1387926345.093:5883): avc: denied { dyntransition } for pid=706 comm="sshd" scontext=system_u:system_r:init_t:s0 tcontext=unconfined_u:unconfined_r:unconfined_t:s0 tclass=process
Is this a known issue? I’m running:
selinux-policy-devel-3.12.1-106.fc20.noarch
selinux-policy-targeted-3.12.1-106.fc20.noarch
selinux-policy-doc-3.12.1-106.fc20.noarch
selinux-policy-3.12.1-106.fc20.noarch
openssh-clients-6.4p1-3.fc20.x86_64
openssh-6.4p1-3.fc20.x86_64
openssh-server-6.4p1-3.fc20.x86_64
Thanks,
-Philip
10 years, 1 month
Packages with missing %check
by Alexander Todorov
Hi guys,
I have identified 551 packages on the Fedora 20 source DVD which are missing a
%check section in their spec files but are very likely to have a test suite. See
https://github.com/atodorov/fedora-scripts/blob/master/sample-data/fedora...
For a few of them I already had bug open previously (will filter the list later
when I run my scripts against latest Rawhide).
I have the following questions:
1) Do we consider this a bug and if yes what priority do you give it? From last
week discussions it looks like most people prefer to have tests executed in %check.
2) Last week Alexander Kurtakov brought up the issue of packages executing their
test suite during build. How to detect such packages? OTOH we can have some
false negatives (also see 3).
3) Another proposal (sorry don't remember who proposed it) was to have %check
with a comment why the test suite is not executed (e.g. requires network) or why
it is executed in %build.
I support this as it makes it clear to the QA person what is happening.
This comment can be later extended to explain why a particular package is
missing test suite (e.g. man pages or packages containing data files).
How about making %check a packaging requirement in all cases - run tests or add
a comment explaining why not, how to run them (e.g. make test) or why there are
no tests for this package.
--
Alex
10 years, 1 month
Re: default file system, was: Comparison to Workstation Technical Specification
by Chris Murphy
On Feb 26, 2014, at 8:13 AM, Michael Cronenworth <mike(a)cchtml.com> wrote:
> Ext4 has its btrfs conversion tool. Changing from ext4 to XFS, for arguably negligible benefits for Workstations, will make it more difficult for Fedora users to transition to btrfs.
It's an unlikely path because a.) by default we put ext4 on LVM; b.) the convert tool uses ext4 block size to set btrfs leaf size; c.) the convert tool doesn't set extref, although it easily could. The last two are a cake walk to change compared to the first.
On Feb 26, 2014, at 8:20 AM, Josh Boyer <jwboyer(a)fedoraproject.org> wrote:
> I agree switching from ext4 to XFS is likely not worthwhile.
Whether Server WG goes with ext4 or XFS on LVM, it's worthwhile for Workstation WG to mimic it merely due to simplicity because then we don't need separate installers or composes.
On Feb 26, 2014, at 8:24 AM, David Cantrell <dcantrell(a)redhat.com> wrote:
>
> I think filesystem variance across different Fedoras really impacts QA more
> than us. We already support a lot of filesystems, but the real hit is the
> QA test matrix.
QA already tests the file system layouts being discussed. Perhaps the least tested is XFS on LVM only because the XFS test case doesn't specify LVM, so testers probably split and do some plain partition and some on LVM.
If Server WG decides on XFS, it effectively increases the Automatic/Guided/easy/default installer path's "Partition Scheme" pop-up from four to five options, and that is a problem. Adamw and I are working on a proposal to reduce these options to one or two: i.e. a WG chosen product specific default, and maybe "one other" which is decided by Base WG or FESCo.
Chris Murphy
10 years, 1 month
F21 System Wide Change: System-wide crypto policy
by Jaroslav Reznik
= Proposed System Wide Change: System-wide crypto policy =
https://fedoraproject.org/wiki/Changes/CryptoPolicy
Change owner(s): Nikos Mavrogiannopoulos <nmav(a)redhat.com>
Unify the crypto policies used by different applications and libraries. That is
allow setting a consistent security level for crypto on all applications in a
Fedora system.
== Detailed Description ==
The idea is to have some predefined security levels such as LEVEL-80,
LEVEL-128, LEVEL-256,
or ENISA-LEGACY, ENISA-FUTURE, SUITEB-128, SUITEB-256. These will be the
security levels
that the administrator of the system will be able to configure by modifying
/usr/lib/crypto-profiles/config
/etc/crypto-profiles/config
and being applied after executing update-crypto-profiles.
(Note: it would be better to have a daemon that watches those files and
runs update-crypto-profiles automatically)
After that the administrator should be assured that any application
that uses the system settings will follow a policy that adheres to
the configured profile.
Ideally setting a profile should be setting:
* the acceptable TLS/SSL (and DTLS) versions
* the acceptable ciphersuites and the preferred order
* acceptable parameters in certificates and key exchange, i.e.:
** the minimum acceptable size of parameters (DH,ECDH,RSA,DSA,ECDSA)
** the acceptable elliptic curves (ECDH,ECDSA)
** the acceptable signature hash functions
* other TLS options such as:
** safe renegotiation
An idea of how this will be implemented is to have each Fedora application's
configuration
file or compilation option will set a system default option. That is for
example for
applications that use GnuTLS or OpenSSL a priority string or cipher named
"SYSTEM".
Then the shipped library will make sure that once the "SYSTEM" option is
encountered
the preconfigured system settings will be applied.
The preconfigured settings for each SSL library will be auto-generated
from the default profile in
/etc/crypto-profiles/generated/$(libname)/config
== Scope ==
There are changes required in GnuTLS, OpenSSL and NSS libraries. On a second
phase non-SSL crypto libraries could use these settings.
* Proposal owners: For GnuTLS and OpenSSL the "SYSTEM" cipher needs to be
understood and behave as described. For NSS the NSS_SetDomesticPolicy() can be
overloaded to behave as above.
After that a mechanism to specify crypto policies for Fedora has to be
devised, as well as the extraction to each libraries' settings.
* Other developers: Packages that use SSL crypto libraries should, after the
previous change is complete, start replacing the default cipher strings with
SYSTEM.
* Release engineering: This feature does not require coordination with release
engineering.
* Policies and guidelines: After the change is complete the packaging
guidelines, should mention above replacing the default cipher strings with
"SYSTEM". This of course need not affect programs that do not have a mechanism
for setting ciphers/modes that is already in wide use (e.g., browsers). It
mostly targets applications that use some reasonable (or unreasonable)
defaults and the user/administrator has little control of them.
_______________________________________________
devel-announce mailing list
devel-announce(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
10 years, 1 month
