23 May 2019

feedFedora People

Remi Collet: PHP extensions status with upcoming PHP 7.4

With PHP 7.4 entering stabilization phase, time to check the status of most commonly used PHP extensions (at least, the ones available in my repository).

Here is the (not yet) exhaustive list.

1. Compatible

The last published version is compatible

# Name Version State
ahocorasick 0.0.6 OK
amqp 1.9.4 OK
apcu 5.1.17 OK
apcu_bc 1.0.5 OK
apfd 1.0.1 OK
ast 1.0.1 OK
base58 0.1.3 OK
bitset 3.0.1 OK
brotli 0.7.0 OK
couchbase 2.6.0 OK
dio 0.1.0 OK
ds 1.2.9 OK
event 2.5.0 OK
fann 1.1.1 OK
gearman 2.0.5 OK
geoip 1.1.1 OK
horde_lz4 1.0.10 OK
igbinary 3.0.1 OK
inotify 2.0.0 OK
json_post 1.0.1 OK
krb5 1.1.2 OK
libvirt 0.5.4 OK
lzf 1.6.7 OK
mailparse 3.0.3 OK
maxminddb 1.4.1 OK
memcache 4.0.3 OK
memcached 3.1.3 OK
mongodb 1.6.0alpha1 OK
msgpack 2.0.3 OK
phpiredis 1.0.0 OK
pcov 1.0.3 OK
pq 2.1.5 OK
propro 2.1.0 OK
psr 0.6.1 OK
radius 1.4.0b1 OK
raphf 2.0.0 OK
redis 4.3.0 OK
rpminfo 0.2.1 OK
rrd 2.0.1 OK
selinux 0.4.2 OK
smbclient 1.0.0 OK
ssdeep 1.1.0 OK
ssh2 1.1.2 OK
stomp 1.2.10 OK
timecop 2.0.2 Some failed tests since 7.2 (related to timelib changes)
uuid 1.0.4 OK
xattr 1.3.0 OK
xmldiff 1.1.2 OK
yac 2.0.2 OK
yaml 2.0.4 OK
zstd 0.7.3 OK

2. Work in progress

These extensions have been fixed upstream (or PR are available) but no official release.

# Name Version State
cassandra 1.3.2 Fixed by PR #126 and PR #132, awaiting review
interbase 1.0.0-dev Dropped from 7.4, not released yet
oauth 2.0.4-dev Fixed upstream
solr 2.4.0 Fixed upstream (still pending for 7.3)
sphinx 1.4.0-dev Fixed upstream (still pending for 7.0)
zip 1.15.5-dev Fixed upstream
zmq 1.1.3 Fixed upstream

3. Not compatible for now (only from 7.3 compatible extensions)

# Name Version State
cmark 1.1.0 Segfault
http 3.2.0 Segfault
uopz 6.0.1 Don't build
xdebug 2.7.2 Not supported

4. Conclusion

Too soon for a statement, alpha1 is not yet released.

Last updated on May 23th 2019

23 May 2019 11:44am GMT

Fedora Community Blog: Shaily and Zubin: Building CI pipelines and helping testers

Fedora Summer Coding 2019

This post is the third introduction to the Fedora Summer Coding interns Class of Summer 2019. In this interview, we'll meet Shaily Sangwan and Zubin Choudhary, who are both working on projects to improve quality assurance processes in the Fedora community.

Shaily Sangwan: CentOS CI User Frontend

<figure class="alignright is-resized">Shaily Sangwan: Selected for CentOS CI user front-end for Google Summer of Code 2019 with Fedora Project<figcaption>Shaily Sangwan</figcaption></figure>

Shaily Sangwan (shaily) is working to create a user front-end for CentOS CI. This project involves building a web app to replace the current user on-boarding flow for ci.centos.org. She was selected for Google Summer of Code 2019.

We asked Shaily a few questions as she prepares for her next three months working with Brian Stinson and Siddharth Vipul, her mentors for the summer.

Tell us a bit about yourself!

I'm a graduate student in Political Science at Delhi University, India. Fun fact - I have previously worked with Fedora Project during Outreachy Round 15 in 2017-18.

How did you hear about GSoC?

Since GSoC is usually conducted in parallel with Outreachy, I had heard about it during my last internship, which in turn I had read about on Quora.

What caught your attention about Fedora? How does it align with your personal interests?

I learned a great deal about writing good quality code while working on Fedora Hubs, so Fedora was at the top of my list in choosing an organization to work with during GSoC. This project aligns well with my personal interests since I get to develop an application from scratch that is meant to serve a large number of users on completion.

What are you looking forward to most during this GSoC round?

I want to use this opportunity in learning how to build and deploy web apps using CI/CD and organize deployments using container run-times like Docker and Kubernetes. While my focus was earlier on learning the building blocks for these applications, now after adequate experience in this domain, I want to explore how they are deployed to production in a scalable manner.

Where do you see yourself after you complete this GSoC round?

After completing this project, I want to work in a role that involves taking more responsibility around the end to end development of web apps.

Who is your favorite Marvel superhero / superheroine?

Thanos. 🙂

Anything you want to add?

I wish there was a community meetup for Fedora interns and mentors, maybe at Flock 2019!

Editor's note: Starting last year, Flock features a Summer Coding Project Showcase. More details will come soon. Hope to see you at Flock, Shaily!

Zubin Choudhary: Fedora Gooey Karma

Zubin Choudhary (imzubin/iamzubin) is working on Fedora Gooey Karma. This is a GUI client for the Fedora Quality Assurance (QA) team for testing and reviewing package updates. He was selected for Google Summer of Code 2019.

We asked Zubin a few questions as he prepares for his next three months working with Sumantro Mukherjee, his mentor for the summer.

Tell us a bit about yourself!

I'm a computer science student from India, there's not much anyone cannot guess about me after talking to for like 5 minutes.

How did you hear about GSoC?

I was looking for summer internships and stumbled upon GSoC.

What caught your attention about Fedora? How does it align with your personal interests?

Once you switch to Linux, there's no turning back. Contributing to a huge Linux community like Fedora is something anyone would do to give back to the community.

What are you looking forward to most during this GSoC round?

Making some good contacts, a great product, getting stuck and finding a solution.

Where do you see yourself after you complete this GSoC round?

FLOCK conference! I haven't planned anything about my future, let's see where GSoC takes me. 🙂

Who is your favorite Marvel superhero / superheroine?

Our friendly neighborhood spider guy.

Thanks and good luck to Shaily and Zubin as they begin their project work next week!

The post Shaily and Zubin: Building CI pipelines and helping testers appeared first on Fedora Community Blog.

23 May 2019 8:00am GMT

22 May 2019

feedFedora People

Hans de Goede: Better support for running games under Wayland (with GNOME3/mutter as compositor)

First of all I do not want people to get their hopes up about $subject of this blogpost. Improving gaming support is a subjects which holds my personal interest and it is an issue I plan to spend time on trying to improve. But this will take a lot of time (think months for simple things, years for more complex things).

As I see it there are currently 2 big issues when running games under Wayland:

1. Many games show as a smal centered image with a black border (letterbox) around the image when running fullscreen.

For 2D games this is fixed by switching to SDL2 which will transparently scale the pixmap the game renders to the desktop resolution. This assumes that 2D games in general do not demand a lot of performance and thus will not run into performance issues when introducing an extra scaling step. A problem here is that many games still use SDL1.2 (and some games do not use SDL at all).

I plan to look into the recently announced SDL1.2 compatibility wrapper around SDL2. If this works well this should fix this issue for all SDL1.2 2D games, by making them use SDL2 under the hood.

For 3D games this can be fixed by rendering at the desktop resolution, but this might be slow and rendering at a lower resolution leads to the letterbox issue.

Recently mutter has has grown support for the WPviewport extension, which allows Wayland apps to tell the compositor to scale the pixmap the app gives to the compositor before presenting it. If we add support to SDL2's Wayland backend for this then, this can be used to allow rendering 3D apps at a lower resolution and still have them fill the entire screen.

Unfortunately there are 2 problems with this plan:

  1. SDL2 by default uses its x11 backend, not its wayland backend. I'm not sure what fixes need to be done to change this, at a minimum we need a fix at either the SDL or mutter side for this issue, which is going to be tricky.
  2. This only helps for SDL2 apps, again hopefully the SDL1.2 compatibility wrapper for SDL2 can help here, at least for games using SDL.

2. Fullscreen performance is bad with many games.

Since under Wayland games cannot change the monitor resolution, they need to either render at the full desktop resolution, which can be very slow; or they render at a lower resolution and then need to do an extra scaling step each frame.

If we manage to make SDL2's Wayland backend the default and then add WPviewport support to it then this should help by reducing an extra memcpy/blit of a desktop-sized pixmap. Currently what apps which use scaling do is:

  1. render lower-res-pixmap;
  2. scale lower-res-pixmap to desktop-res-pixmap
  3. give desktop-res-pixmap to the compositor;
  4. compositor does a hardware blit of the desktop-res-pixmap to the framebuffer.

With viewport support this becomes:

  1. render lower-res-pixmap;
  2. give low-res-pixmap to the compositor;
  3. compositor uses hardware to do a scaling blit from the low-res-pixmap to the desktop-res framebuffer

Also with viewport support, the compositor could in the case of there only being the one fullscreen app even keep the framebuffer in lowres and use a hardware scaling drm-plane to send the low-res framebuffer scaled to desktop-res to the output while only reading the low-res framebuffer from memory saving a ton of memory bandwidth. But this optimization is going to be a challenge to pull off.

22 May 2019 4:44pm GMT

Hans de Goede: Wayland itches summary

Thank you all for the large amount of feedback I have received after my previous Wayland Itches blog post. I've received over 40 mails, below is an attempt at summarizing all the mails.


1. Middle click on title / header bar to lower the Window does not work for native apps. Multiple people have reported this issue to me. A similar issue was fixed for not being able to raise Windows. It should be easy to apply a similar fix for the lowering problem. There are bugs open for this here, here and here.

2. Running graphical apps via sudo or pxexec does not work. There are numerous examples of apps breaking because of this, such as lshw-gui and usbivew. At least for X11 apps this is not that hard to fix. But sofar this has deliberately not been fixed. The reasoning behind this is described in this bug. I agree with the reasoning behind this, but I think it is not pragmatic to immediately disallow all GUI apps to connect when run as root starting today.

We need some sort of transition period. So when I find some time for this, I plan to submit a merge-requests which optionally makes gnome-shell/mutter start Xwayland with an xauth file, like how it is done when running in GNOME on Xorg mode. This will be controlled by a gsettings option, which will probably default to off upstream and then distros can choice to override this for now, giving us a transition period

Requests for features implemented as external programs on X11

There are various features which can be implemented as external programs
on X11, but because of the tighter security need to be integrated into the
compositor with Wayland:

App specific problems

Miscellaneous problems

Hard to fix issues

Problems with other compositors then GNOME3 / mutter

I've also received several reports about issues when using another Wayland compositor as GNOME / mutter (Weston, KDE, Sway). I'm sorry but I have not looked very closely into these reports. I believe that it is great that Linux users have multiple Desktop Environments to choose from and I wish for the other DEs to thrive. But there are only so many hours in a day so I've chosen to mainly focus on GNOME.

22 May 2019 4:26pm GMT

Kushal Das: Game of guessing colors using CircuitPython

Every participant of PyCon US 2019 received a CircuitPython Playground Express (cpx) in the swag bag from Digikey and Adafuit, which is one of the best swag in a conference. Only another thing which comes in my mind was Yubikeys sponsored by Yubico in a rootconf a few years ago.

I did not play around much with my cpx during PyCon, but, decided to go through the documents and examples in the last week. I used Mu editor (thank you @ntoll) to write a small game.

The goal is to guess a color for the next NeoPixel on the board and then press Button A to see if you guessed right or not. Py and I are continuously playing this for the last weeks.

The idea of CircuitPython, where we can connect the device to a computer and start editing code and see the changes live, is super fantastic and straightforward. It takes almost no time to start working on these, the documentation is also unambiguous and with many examples. Py (our 4 years old daughter) is so excited that now she wants to learn programming so that she can build her things with this board).

22 May 2019 9:54am GMT

Remi Collet: PHP 7.4 as Software Collection

Version 7.4.0-alpha1 will be soon released. It's now enter the stabilization phase for the developers, and the test phase for the users.

RPM of this upcoming version of PHP 7.4, are available in remi repository for Fedora 29, 30 and Enterprise Linux 7, 8 (RHEL, CentOS, ...) in a fresh new Software Collection (php74) allowing its installation beside the system version.

As I strongly believe in SCL potential to provide a simple way to allow installation of various versions simultaneously, and as I think it is useful to offer this feature to allow developers to test their applications, to allow sysadmin to prepare a migration or simply to use this version for some specific application, I decide to create this new SCL.

I also plan to propose this new version as a Fedora 32 change (as F31 should be released a few weeks before PHP 7.4.0).

Installation :

yum install php74

emblem-important-2-24.pngTo be noticed:

emblem-notice-24.pngAlso read other entries about SCL. especially description of my My PHP workstation.

$ module load php74
$ php --version
PHP 7.4.0-dev (cli) (built: May 21 2019 14:14:52) ( NTS )
Copyright (c) The PHP Group
Zend Engine v3.4.0-dev, Copyright (c) Zend Technologies
     with Zend OPcache v7.4.0-dev, Copyright (c), by Zend Technologies

As always, your feedback is welcome, a SCL dedicated forum is open.

Software Collections (php74)

22 May 2019 8:55am GMT

Fedora Magazine: Securing telnet connections with stunnel

Telnet is a client-server protocol that connects to a remote server through TCP over port 23. Telnet does not encrypt data and is considered insecure and passwords can be easily sniffed because data is sent in the clear. However there are still legacy systems that need to use it. This is where stunnel comes to the rescue.

Stunnel is designed to add SSL encryption to programs that have insecure connection protocols. This article shows you how to use it, with telnet as an example.

Server Installation

Install stunnel along with the telnet server and client using sudo:

sudo dnf -y install stunnel telnet-server telnet

Add a firewall rule, entering your password when prompted:

firewall-cmd --add-service=telnet --perm
firewall-cmd --reload

Next, generate an RSA private key and an SSL certificate:

openssl genrsa 2048 > stunnel.key
openssl req -new -key stunnel.key -x509 -days 90 -out stunnel.crt

You will be prompted for the following information one line at a time. When asked for Common Name you must enter the correct host name or IP address, but everything else you can skip through by hitting the Enter key.

You are about to be asked to enter information that will be
incorporated into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
Country Name (2 letter code) [XX]:
State or Province Name (full name) []:
Locality Name (eg, city) [Default City]:
Organization Name (eg, company) [Default Company Ltd]:
Organizational Unit Name (eg, section) []:
Common Name (eg, your name or your server's hostname) []:
Email Address []

Merge the RSA key and SSL certificate into a single .pem file, and copy that to the SSL certificate directory:

cat stunnel.crt stunnel.key > stunnel.pem
sudo cp stunnel.pem /etc/pki/tls/certs/

Now it's time to define the service and the ports to use for encrypting your connection. Choose a port that is not already in use. This example uses port 450 for tunneling telnet. Edit or create the /etc/stunnel/telnet.conf file:

cert = /etc/pki/tls/certs/stunnel.pem
sslVersion = TLSv1
chroot = /var/run/stunnel
setuid = nobody
setgid = nobody
pid = /stunnel.pid
socket = l:TCP_NODELAY=1
socket = r:TCP_NODELAY=1
accept = 450
connect = 23

The accept option is the port the server will listen to for incoming telnet requests. The connect option is the internal port the telnet server listens to.

Next, make a copy of the systemd unit file that allows you to override the packaged version:

sudo cp /usr/lib/systemd/system/stunnel.service /etc/systemd/system

Edit the /etc/systemd/system/stunnel.service file to add two lines. These lines create a chroot jail for the service when it starts.

Description=TLS tunnel for network daemons
After=syslog.target network.target

ExecStartPre=-/usr/bin/mkdir /var/run/stunnel
ExecStartPre=/usr/bin/chown -R nobody:nobody /var/run/stunnel


Next, configure SELinux to listen to telnet on the new port you just specified:

sudo semanage port -a -t telnetd_port_t -p tcp 450

Finally, add a new firewall rule:

firewall-cmd --add-port=450/tcp --perm
firewall-cmd --reload

Now you can enable and start telnet and stunnel.

systemctl enable telnet.socket stunnel@telnet.service --now

A note on the systemctl command is in order. Systemd and the stunnel package provide an additional template unit file by default. The template lets you drop multiple configuration files for stunnel into /etc/stunnel, and use the filename to start the service. For instance, if you had a foobar.conf file, you could start that instance of stunnel with systemctl start stunnel@foobar.service, without having to write any unit files yourself.

If you want, you can set this stunnel template service to start on boot:

systemctl enable stunnel@telnet.service

Client Installation

This part of the article assumes you are logged in as a normal user (with sudo privileges) on the client system. Install stunnel and the telnet client:

dnf -y install stunnel telnet

Copy the stunnel.pem file from the remote server to your client /etc/pki/tls/certs directory. In this example, the IP address of the remote telnet server is

sudo scp myuser@

Create the /etc/stunnel/telnet.conf file:

cert = /etc/pki/tls/certs/stunnel.pem

The accept option is the port that will be used for telnet sessions. The connect option is the IP address of your remote server and the port it's listening on.

Next, enable and start stunnel:

systemctl enable stunnel@telnet.service --now

Test your connection. Since you have a connection established, you will telnet to localhost instead of the hostname or IP address of the remote telnet server:

[user@client ~]$ telnet localhost 450
Trying ::1...
telnet: connect to address ::1: Connection refused
Connected to localhost.
Escape character is '^]'.

Kernel 5.0.9-301.fc30.x86_64 on an x86_64 (0)
server login: myuser
Password: XXXXXXX
Last login: Sun May 5 14:28:22 from localhost
[myuser@server ~]$

22 May 2019 8:00am GMT

Fedora Community Blog: Alisha and Shraddha: Positive feedback loops in Fedora

Fedora Summer Coding 2019

This post is the second introduction to the Fedora Summer Coding interns Class of Summer 2019. In this interview, we'll meet Alisha Mohanty and Shraddha Agrawal, who are both working on Fedora Happiness Packets to promote positive feedback loops in the Fedora community.

About Happiness Packets

Fedora Happiness Packets is a fork of happinesspackets.io. The goals of the forked site are as follows:

  1. fedora-happiness-packets is a fork: The upstream project is also active and still in use. As a considerate downstream, if a change could also help upstream, we should direct changes there.
  2. fedora-happiness-packets supports changes required for deployment in Fedora community: Changes to fedora-happiness-packets should generally be Fedora-specific. This includes fedora-messaging support, Fedora-related design changes, or integrating into other parts of the Fedora community.
  3. Good code is tested code: Introducing new code means introducing new tests. If writing code that could be tested, it is code that should be tested.

The overall purpose of Fedora Happiness Packets is to celebrate the accomplishments and achievements by our colleagues, fellow contributors, and friends by letting them know of our appreciation for them.

Alisha Mohanty: Fedora Happiness Packets

<figure class="alignright is-resized">Alisha Mohanty: Selected for Fedora Happiness Packets for Outreachy 2019 with Fedora Project<figcaption>Alisha Mohanty</figcaption></figure>

Alisha Mohanty (alishapapun/freaky_mortal) is working on Fedora Happiness Packets. She was selected for Outreachy Summer 2019.

We asked Alisha a few questions as she prepares for her next three months working with the FHP mentor team: Justin W. Flory, Jona Azizaj, Alberto Rodríguez Sánchez, Anxhelo Lushka, and Sachin Kamath.

Tell us a bit about yourself!

I am B-Tech student from Odisha, India pursuing engineering degree from College of Engineering and Technology, Bhubaneswar. I strongly believe dreams can be fulfilled by breaking it into smaller tasks and working on it consistently. I believe in understanding people before casting my own judgement and will.

How did you hear about Outreachy?

From Twitter.

What caught your attention about Fedora? How does it align with your personal interests?

Fedora as an open source community is very well known for its friendliness to the new comers and encourages a wide range of participation from people especially students. From the very introduction of operating system, I was anxious to know more about it. While surfing the internet, to know more about it, I came to know about Fedora community and it being open source. It caught my attention and I planned to contribute to something.

What are you looking forward to most during this Outreachy round?

I am looking forward to explore more projects in Fedora that align my interest.

Where do you see yourself after you complete this Outreachy round?

I plan to see myself as a confident programmer, being able to write clean and readable code and proficient in Django.

Who is your favorite Marvel superhero / superheroine?

Captain America.

Shraddha Agrawal: Fedora Happiness Packets

<figure class="alignright is-resized">Shraddha Agrawal: Selected for Fedora Happiness Packets for Outreachy 2019 with Fedora Project<figcaption>Shraddha Agrawal</figcaption></figure>

Shraddha Agrawal (shraddhaag) is also working on Fedora Happiness Packets. She was selected for Outreachy Summer 2019.

We also asked Shraddha a few questions as she prepares for her next three months working with the FHP mentor team: Justin W. Flory, Jona Azizaj, Alberto Rodríguez Sánchez, Anxhelo Lushka, and Sachin Kamath.

Tell us a bit about yourself!

I am a second year undergraduate student at Indian Institute of Information Technology, Surat studying Bachelors of Electronic and Communication Engineering. I am a creative spirit, who loves to make elegant and innovative solutions to everyday life problems more accessible to everyone.

How did you hear about Outreachy?

I am part of LinuxChix India user group based in Delhi, India. Last year, when I attended their meetup for the first time Shivangi Bharadwaj, a previous Outreachy alum, mentioned about this opportunity when I asked her about how could I get into FOSS development.

What caught your attention about Fedora? How does it align with your personal interests?

From the plethora of things Fedora does best, the thing I love the most about Fedora is its community. Hands down, its the best Open Source community I have had the chance to work with. 🙂

What are you looking forward to most during this Outreachy round?

I am looking forward to learning in abundance while working with the best set of people!

Where do you see yourself after you complete this Outreachy round?

I hope to carry forward active community involvement and contribution way beyond this internship period.

Who is your favorite Marvel superhero / superheroine?

Mr. Stark. :'( Endgame did not fare well with me (just like a million other geeks 'round the globe).

Anything you want to add?

I would like to acknowledge the immense help and guidance my mentors Justin and Jona have provided me. Their constant encouragement really helped me along during my application period. 🙂

Thanks and good luck to Alisha and Shraddha as they begin their project work this week!

The post Alisha and Shraddha: Positive feedback loops in Fedora appeared first on Fedora Community Blog.

22 May 2019 8:00am GMT

Remi Collet: HEIC / HEIF images support

The HEIF image format (High Efficiency Image File Format) is now widely used, especially since iOS 11, so it make sense to be able to process these images.

1. libheif library

This library is an ISO/IEC 23008-12:2017 HEIF file format decoder and encoder.

Site : https://github.com/strukturag/libheif

It is available in the RPM Fusion repository which provides good quality package, following the same rules than Fedora, for software which are compatib le with official repository but are not distribuable byFedora / Red Hat (patent encumbered or non free algorithm).

2. ImageMagick

Site : https://imagemagick.org/

This tool supports this format, it is available in the optional package ImageMagick6-heic (or ImageMagick7-heic)

Example, using my repository and RPM Fusion :

$ sudo dnf install ImageMagick6 ImageMagick6-heic
$ convert Example1.heic Example1.jpg
$ eog Example1.jpg

3. libvips

Site : https://libvips.github.io/libvips/

This tools supports this format since version 8.8.0 released yesterday.

The vips-full package have this support enable (while vips pac kage don't have it).

Exemple :

$ sudo dnf install vips-full-tools
$ vips pngsave Example2.heic Example2.png

4. PHP with imagick extension

Site : https://pecl.php.net/package/imagick

Using the php-pecl-imagick and ImageMagick6-heic packages

$imagick = new Imagick();

5. PHP with vips extension

Using the php-pecl-vips and vips-full packages

$x = vips_image_new_from_file('Example4.heic');
vips_image_write_to_file($x['out'], 'Example4.jpg');

6. Conclusion

This widely used format is now perfectly supported, and easy to install for users of my repository.

22 May 2019 7:20am GMT

Fedora Infrastructure Status: All systems go

New status good: Everything seems to be working. for services: Ipsilon, Badges, Blockerbugs, Package Updates Manager, Fedora Infrastructure Cloud, COPR Build System, Documentation website, Fedora elections, Account System, Fedora Messaging Bus, Fedora Calendar, Fedora pastebin service, The Koji Buildsystem, Koschei Continuous Integration, Kerberos, Mailing Lists, Mirror List, Mirror Manager, Fedora Packages App, Pagure, Fedora People, Package Database, Package maintainers git repositories, Fedora Container Registry, Tagger, Fedora websites, Fedora Wiki, Zodbot IRC bot

22 May 2019 12:52am GMT

21 May 2019

feedFedora People

Fedora Infrastructure Status: Major service disruption

New status major: Update/Reboot of Fedora Services for services: Ipsilon, Badges, Blockerbugs, Package Updates Manager, Fedora Infrastructure Cloud, COPR Build System, Documentation website, Fedora elections, Account System, Fedora Messaging Bus, Fedora Calendar, Fedora pastebin service, The Koji Buildsystem, Koschei Continuous Integration, Kerberos, Mailing Lists, Mirror List, Mirror Manager, Fedora Packages App, Pagure, Fedora People, Package Database, Package maintainers git repositories, Fedora Container Registry, Tagger, Fedora websites, Fedora Wiki, Zodbot IRC bot

21 May 2019 9:16pm GMT

Solanch96: FLISoL 2019 Ica – Peru

El Festival Latinoamericano de Instalación de Software Libre (FLISoL) es el evento de difusión de Software Libre más grande en Latino-américa. Su principal objetivo es promover el uso del software libre. Esto fue lo que se realizó en el FLISoL 2019-Peru

<script type="text/javascript"> __ATA.cmd.push(function() { __ATA.initSlot('atatags-26942-5ce6c39d5513d', { collapseEmpty: 'before', sectionId: '26942', location: 120, width: 300, height: 250 }); }); </script>

21 May 2019 8:00pm GMT

Zach Oglesby

Currently reading: The Cardinal of the Kremlin by Tom Clancy 📚

21 May 2019 1:11pm GMT

Brian "bex" Exelbierd: Contributors are Empowered When They Know the Process

Fedora LogoThere is a saying in the legal profession that you should never ask a question you don't already know the answer to. Despite how this sounds, it is actually a rule most people follow in life. This is the source of that feeling you get when you're too scared to raise your hand and ask a question. In Open Source we need to make sure that contributors feel like they already "know" the answers, so they will feel confident in making the request.

Read more at the Red Hat Community Blog where this was originally posted.

21 May 2019 12:45pm GMT

Dan Walsh: Container Domains (Types)

One of the things people have always had a hard time understanding about SELinux is around different types. In this blog, I am going to discuss Contianer Domains.

Recently I had someone questioning me about specifying types to run containers inside of Kubernetes. Basically he wanted to run a locked down container that could read and write content inside of /var/log. He saw that the content in /var/log was labeled var_log_t, and made the assumption that he would run the container with var_lot_t and it would be able to manage content with that label.

This is not a crazy assumption, after all in DAC, if a file is owned by the user dwalsh, usually processes owned by dwalsh are able to read and write them. (If the permission flags allow it). But in SELinux type enforcement is different. CRI-O failed to execute the container process for Kubernetes and an AVC was generated that looked like:

type=AVC msg=audit(1558135492.958:247182): avc: denied { transition } for pid=22423 comm="runc:[2:INIT]" path="/usr/bin/pod" dev="sda1" ino=570425443 scontext=system_u:system_r:container_runtime_t:s0 tcontext=system_u:object_r:var_log_t:s0 tclass=process permissive=0

SELinux differentiates process types, it calls them domains, from file types, it calls them file_types. SELinux also controls process type changing via something called transitions. Processes can not just execute a new process in any process type. SELinux only allows certain process types to transition to other process types via policy. The AVC above shows that runc, which was executed via CRI-O running as container_runtime_t, is attempting to launch the container as var_log_t. SELinux blocks the transition and generates the AVC.

Container Domains

SELinux policy for containers defines the types that a container_runtime_t process can transition to and groups them with the policy attribute `container_domain`.

You can see these domains by executing `seinfo -acontainer_domain -x`.

seinfo -acontainer_domain -x
Type Attributes: 1
attribute container_domain;

Currently we only define these 4 types for containers to run with. The default is container_t, which almost everyone in the world runs with. The only type that container_t can write is container_file_t. Since the original idea of the user was the need to read/write content in /var/log. Someone suggested relabeling the content in /var/log as container_file_t. This would be a very bad idea, because other process types like syslogd_t or other domains that need to write to files under /var/log, would not be allowed to write to container_file_t. We have another type we have written container_logreader_t, but this would not work, since this is only allowed to read content under /var/log not write it.

Sadly the only option with the way container policy allows the container to write to /var/log is running as spc_t. spc_t is for "Super Privileged Containers", basically unconfined containers from an SELinux point of view that can read/write any file type.

That is what I told the user to run with.


But their is help coming. Lukas Vrabec has written a new tool called udica.

Udica: A tool for generating SELinux security profiles for containers.

Lukas came up with a great idea to examine the volumes mounted into a container and generate policy off of it. You can create a container using a tool like Podman, with a command like

podman create -ti --name logwriter -v /var/log:/var/log fedora

Now you can use the generated container as input to udica, to generate an SELinux policy type that could read/write content under /var/log.

# podman inspect logwriter > container.json
# udica -j container.json container_logwriter

This generates a new policy file container_logwriter.cil

Now you can load the policy into the kernel.

# semodule -i container_logwriter.cil /usr/share/udica/templates/{base_container.cil,net_container.cil,home_container.cil}

Udica generated a new policy type, container_logwriter.process, which is defined as a container_domain, but also gets all of the allow rules to read/write all file types stored under the /var/log directory. Now you can run the container with a policy type as container_logwriter.process and it will be continue to be confined in the same way as contianer_t, except that it will be allowed to read/write all labels in /var/log directories.

podman run -ti --security-opt label:type=container_logwriter.cil -v /var/log:/var/log fedora

With this tool, you could distribute the policy files to all nodes that you want to run these containers on, and tell kubernetes to launch containers with this type.

You can read a lot more about Udica at github, or in Fedora Magazine.


SELinux is an awesome tool for keeping containers contained, it prevents containers from escaping and causing havoc on the file system. It has proven its self many times when container breakouts have happened. But sometimes, you need to customize your container to allow it limited access to files on your host. If those files need to be accessed by other confined domains other the then containers, then relabeling them is not an option. You either need to turn off SELinux confinement or start using the new Udica tool to generate new policy types.

21 May 2019 11:59am GMT

Hans de Goede: Improved Logitech wireless device support in kernel 5.2

The just released 5.2-rc1 kernel includes improved support for Logitech wireless keyboards and mice. Until now we were relying on the generic HID keyboard and mouse emulation for 27 MHz and non-unifying 2.4 GHz wireless receivers.

Starting with the 5.2 kernel instead we actually look at the devices behind the receiver. This allows us to provide battery monitoring support and to have per device quirks, like device specific HID-code to evdev-code mappings where necessary. Until now device specific quirks where not possible because the receivers have a generic product-id which is the same independent of the device behind the receiver.

The per device key-mapping is especially important for 27MHz wireless devices, these use the same HID-code for Fn + F1 to Fn + F12 for all devices, but the markings on the keys differ per model. Sofar it was impossible for Linux to get the mapping for this right, but now that we have per device product-ids for the devices behind the receiver we can finally fix this. As is the case with other devices with vendor specific mappings, the actual mapping is done in userspace through hwdb.

If you have a 27 MHz device (often using this receiver, keyboard marked as canada 210 or canada 310 at the bottom). Please give 5.2 a try. Download the latest 60-keyboard.hwdb file and place it in /lib/udev/hwdb.d (replacing the existing file) and then run "sudo udevadm hwdb --update", before booting into the 5.2 kernel. Then run "sudo evemu-record" select your keyboard and try Fn + F1 to Fn + F12 and any other special keys. If any keys do not work, edit 60-keyboard.hwdb, search for Logitech and add an entry for your keyboard, see the existing Logitech entries. After editing you need to re-run "sudo udevadm hwdb --update", followed by "sudo udevadm trigger" for the changes to take effect. Once you have a working entry, submit a pull-req to systemd to get the changes upstream. If you need any help drop me an email.

We still have some old code for the generic HID emulation for 27 MHz receivers with a product-id of c50c, these should work fine with the new code, but we've been unable to test this. I would really like to move the c50c id over to the new code and remove all the old code. If you've a 27 MHz Logitech device, please run lsusb, if your device has a product-id of c50c and you are willing to test, please drop me an email.

Likewise I suspect that 2.4GHz receivers with a product-id of c531 should work fine with the new support for non-unifying 2.4 GHz receivers, if you have one of those also please drop me an email.

21 May 2019 8:25am GMT