Fedora Community Blog: Test Day: Fedora Silverblue

Share Button

Fedora Test Days help provide concentrated testing efforts on important software

Why test Fedora Silverblue

Fedora Silverblue is a new variant of Fedora Workstation with rpm-ostree at its core to provide fully atomic upgrades. Furthermore, Fedora Silverblue is immutable and upgrades as a whole, providing easy rollbacks from updates if something goes wrong. Fedora Silverblue is great for developers using Fedora with good support for container-focused workflows.

Additionally, Fedora Silverblue delivers desktop applications as Flatpaks. This provides better isolation/sandboxing of applications, and streamlines updating applications — Flatpaks can be safely updated without reboot.

When

On September 20, 2018 Team Silverblue and Fedora QA are holding a Test Day for users to try out and test this new Fedora Workstation variant.

Where

The wiki page for the silverblue has a lot of good information on what and how to test. After you’ve done some testing, you can log your results in the test day result page.
You can also file bugs on silverblue issue tracker.

Details are available on the wiki page. We need your help, please share this post with others.

The post Test Day: Fedora Silverblue appeared first on Fedora Community Blog.

Powered by WPeMatico

Share Button

Fedora Magazine: Understand Fedora memory usage with top

Share Button

Have you used the top utility in a terminal to see memory usage on your Fedora system? If so, you might be surprised to see some of the numbers there. It might look like a lot more memory is consumed than your system has available. This article will explain a little more about memory usage, and how to read these numbers.

Memory usage in real terms

The way the operating system (OS) uses memory may not be self-evident. In fact, some ingenious, behind-the-scenes techniques are at play. They help your OS use memory more efficiently, without involving you.

Most applications are not self contained. Instead, each relies on sets of functions collected in libraries. These libraries are also installed on the system. In Fedora, the RPM packaging system ensures that when you install an app, any libraries on which it relies are installed, too.

When an app runs, the OS doesn’t necessarily load all the information it uses into real memory. Instead, it builds a map to the storage where that code is stored, called virtual memory. The OS then loads only the parts it needs. When it no longer needs portions of memory, it might release or swap them out as appropriate.

This means an app can map a very large amount of virtual memory, while using less real memory on the system at one time. It might even map more RAM than the system has available! In fact, across a whole OS that’s often the case.

In addition, related applications may rely on the same libraries. The Linux kernel in your Fedora system often shares memory between applications. It doesn’t need to load multiple copies of the same library for related apps. This works similarly for separate instances of the same app, too.

Without understanding these details, the output of the top application can be confusing. The following example will clarify this view into memory usage.

Viewing memory usage in top

If you haven’t tried yet, open a terminal and run the top command to see some output. Hit Shift+M to see the list sorted by memory usage. Your display may look slightly different than this example from a running Fedora Workstation:

There are three columns showing memory usage to examine: VIRT, RES, and SHR. The measurements are currently shown in kilobytes (KB).

The VIRT column is the virtual memory mapped for this process. Recall from the earlier description that virtual memory is not actual RAM consumed. For example, the GNOME Shell process gnome-shell is not actually consuming over 3.1 gigabytes of actual RAM. However, it’s built on a number of lower and higher level libraries. The system must map each of those to ensure they can be loaded when necessary.

The RES column shows you how much actual (resident) memory is consumed by the app. In the case of GNOME Shell, that’s about 180788 KB. The example system has roughly 7704 MB of physical memory, which is why the memory usage shows up as 2.3%.

However, of that number, at least 88212 KB is shared memory, shown in the SHR column. This memory might be, for example, library functions that other apps also use. This means the GNOME Shell is using about 92 MB on its own not shared with other processes. Notice that other apps in the example share an even higher percentage of their resident memory. In some apps, the shared portion is the vast majority of the memory usage.

There is a wrinkle here, which is that sometimes processes communicate with each other via memory. That memory is also shared, but can’t necessarily be detected by a utility like top. So yes — even the above clarifications still have some uncertainty!

A note about swap

Your system has another facility it uses to store information, which is swap. Typically this is an area of slower storage (like a hard disk). If the physical memory on the system fills up as needs increase, the OS looks for portions of memory that haven’t been needed in a while. It writes them out to the swap area, where they sit until needed later.

Therefore, prolonged, high swap usage usually means a system is suffering from too little memory for its demands. Sometimes an errant application may be at fault. Or, if you see this often on your system, consider upgrading your machine’s memory, or restricting what you run.


Photo courtesy of Stig Nygaard, via Flickr (CC BY 2.0).

Powered by WPeMatico

Share Button

Lukas “lzap” Zapletal: Delivering cron and logwatch emails to gmail in RHEL

Share Button

Delivering cron and logwatch emails to gmail in RHEL

One of my servers has no real DNS name, there is no MX record and I can hardly
confiture postfix for e-mail delivery. While relaying e-mails to another SMTP
server is an option, it’s actually not needed to configure MTA in order to get
emails delivered from cron and logwatch. One can use MUA called mailx to do
the job.

The goal is to avoid more complex configuration of postfix or (jeeeez)
sendmail, so this is an alternative approach. I am not telling you this is
the best thing you should do. It just works for few of my Linux servers. This
will work both on RHEL6 and RHEL7 and probably even older or newer versions.
And of course CentOS as well.

Vixie cron, the default cron in RHEL, uses sendmail command for all emails.
This is actually part of postfix package, delivery is handled by the MTA
which I actually wanted to avoid. In this tutorial, we will configure vixie
cron in RHEL7 to send e-mails via mailx user agent. First of all, get mailx
installed:

# yum -y install mailx

Then edit either /etc/mail.rc or /root/.mailrc as follows:

# cat /root/.mailrc
set name="Server1234"
set from="username@gmail.com"
set smtp=smtps://smtp.gmail.com
set smtp-auth=login
set smtp-auth-user=username@gmail.com
set smtp-auth-password=mysecretpassword
set ssl-verify=ignore
set nss-config-dir=/etc/pki/nssdb

Make sure that from address is same as smtp-auth-user address, gmail
servers will insist on this. Server certificate is ignored, you may want to
install it into the NSS database. We are ready to send a test e-mail:

# mailx -r username@gmail.com username@gmail.com
Subject: Test

This is a test
.
EOT

There will be a warning on the standard error about unkonwn certificate. I
suggest to put google server CA into the NSS database, but it’s harmless and
you can keep it as is if you don’t mind man-in-the-middle.

Error in certificate: Peer's certificate issuer is not recognized.

Now, create a wrapper script that will explicitly set from and to addresses:

# cat /usr/local/sbin/mailx-r
#!/bin/sh
exec mailx -r username@gmail.com username@gmail.com

Make sure the script is executable. Finally, set it via crond command line
option:

# cat /etc/sysconfig/crond
CRONDARGS="-m /usr/local/sbin/mailx-r"

And restart crond:

# service crond restart

You are now receiving e-mails from cron, congratulations. The next step I
usually do is installing logwatch. Since it also uses sendmail we want to
disable it and run it manually from our own cron script feeding the output to
the mailx command:

# yum -y install logwatch

Disable the built-in daily report because this one uses sendmail. While it
could be possible to change this via some configuration option, I actually like
my very own cron script.

# cat /etc/logwatch/conf/logwatch.conf
DailyReport = no

Now, create your own script and feed the output into mailx. For a weekly report
do something like:

# cat /etc/cron.weekly/logwatch
#!/bin/bash
logwatch --print --range 'between -7 days and today' | mailx -s "Logwatch from XYZ" -r username@gmail.com username@gmail.com 2>/dev/null

For a daily report do this:

# cat /etc/cron.daily/logwatch
#!/bin/bash
logwatch --print --range yesterday | mailx -s "Logwatch from XYZ" -r username@gmail.com username@gmail.com 2>/dev/null

Make sure the cron script is executable and test it first. That’s all, enjoy
all the e-mails!

Powered by WPeMatico

Share Button

Understand Fedora memory usage with top

Share Button

Have you used the top utility in a terminal to see memory usage on your Fedora system? If so, you might be surprised to see some of the numbers there. It might look like a lot more memory is consumed than your system has available. This article will explain a little more about memory usage, and how to read these numbers.

Memory usage in real terms

The way the operating system (OS) uses memory may not be self-evident. In fact, some ingenious, behind-the-scenes techniques are at play. They help your OS use memory more efficiently, without involving you.

Most applications are not self contained. Instead, each relies on sets of functions collected in libraries. These libraries are also installed on the system. In Fedora, the RPM packaging system ensures that when you install an app, any libraries on which it relies are installed, too.

When an app runs, the OS doesn’t necessarily load all the information it uses into real memory. Instead, it builds a map to the storage where that code is stored, called virtual memory. The OS then loads only the parts it needs. When it no longer needs portions of memory, it might release or swap them out as appropriate.

This means an app can map a very large amount of virtual memory, while using less real memory on the system at one time. It might even map more RAM than the system has available! In fact, across a whole OS that’s often the case.

In addition, related applications may rely on the same libraries. The Linux kernel in your Fedora system often shares memory between applications. It doesn’t need to load multiple copies of the same library for related apps. This works similarly for separate instances of the same app, too.

Without understanding these details, the output of the top application can be confusing. The following example will clarify this view into memory usage.

Viewing memory usage in top

If you haven’t tried yet, open a terminal and run the top command to see some output. Hit Shift+M to see the list sorted by memory usage. Your display may look slightly different than this example from a running Fedora Workstation:

There are three columns showing memory usage to examine: VIRT, RES, and SHR. The measurements are currently shown in kilobytes (KB).

The VIRT column is the virtual memory mapped for this process. Recall from the earlier description that virtual memory is not actual RAM consumed. For example, the GNOME Shell process gnome-shell is not actually consuming over 3.1 gigabytes of actual RAM. However, it’s built on a number of lower and higher level libraries. The system must map each of those to ensure they can be loaded when necessary.

The RES column shows you how much actual (resident) memory is consumed by the app. In the case of GNOME Shell, that’s about 180788 KB. The example system has roughly 7704 MB of physical memory, which is why the memory usage shows up as 2.3%.

However, of that number, at least 88212 KB is shared memory, shown in the SHR column. This memory might be, for example, library functions that other apps also use. This means the GNOME Shell is using about 92 MB on its own not shared with other processes. Notice that other apps in the example share an even higher percentage of their resident memory. In some apps, the shared portion is the vast majority of the memory usage.

There is a wrinkle here, which is that sometimes processes communicate with each other via memory. That memory is also shared, but can’t necessarily be detected by a utility like top. So yes — even the above clarifications still have some uncertainty!

A note about swap

Your system has another facility it uses to store information, which is swap. Typically this is an area of slower storage (like a hard disk). If the physical memory on the system fills up as needs increase, the OS looks for portions of memory that haven’t been needed in a while. It writes them out to the swap area, where they sit until needed later.

Therefore, prolonged, high swap usage usually means a system is suffering from too little memory for its demands. Sometimes an errant application may be at fault. Or, if you see this often on your system, consider upgrading your machine’s memory, or restricting what you run.


Photo courtesy of Stig Nygaard, via Flickr (CC BY 2.0).

Powered by WPeMatico

Share Button

Daniel Pocock: What is the relationship between FSF and FSFE?

Share Button

Ever since I started blogging about my role in FSFE as Fellowship representative, I’ve been receiving communications and queries from various people, both in public and in private, about the relationship between FSF and FSFE. I’ve written this post to try and document my own experiences of the issue, maybe some people will find this helpful. These comments have also been shared on the LibrePlanet mailing list for discussion (subscribe here)

Being the elected Fellowship representative means I am both a member of FSFE e.V. and also possess a mandate to look out for the interests of the community of volunteers and donors (they are not members of FSFE e.V). In both capacities, I feel uncomfortable about the current situation due to the confusion it creates in the community and the risk that volunteers or donors may be confused.

The FSF has a well known name associated with a distinctive philosophy. Whether people agree with that philosophy or not, they usually know what FSF believes in. That is the power of a brand.

When people see the name FSFE, they often believe it is a subsidiary or group working within the FSF. The way that brands work, people associate the philosophy with the name, just as somebody buying a Ferrari in Berlin expects it to do the same things that a Ferrari does in Boston.

To give an example, when I refer to “our president” in any conversation, people not knowledgeable about the politics believe I am referring to RMS. More specifically, if I say to somebody “would you like me to see if our president can speak at your event?”, some people think it is a reference to RMS. In fact, FSFE was set up as a completely independent organization with distinct membership and management and therefore a different president. When I try to explain this to people, they sometimes lose interest and the conversation can go cold very quickly.

FSFE leadership have sometimes diverged from FSF philosophy, for example, it is not hard to find some quotes about “open source” and one fellow recently expressed concern that some people behave like “FSF Light”. But given that FSF’s crown jewels are the philosophy, how can an “FSF Light” mean anything? What would “Ferrari Light” look like, a red lawnmower? Would it be a fair use of the name Ferrari?

Some concerned fellows have recently gone as far as accusing the FSFE staff of effectively domain squatting or trolling the FSF (I can’t link to that because of FSFE’s censorship regime). When questions appear about the relationship in public, there is sometimes a violent response with no firm details. (I can’t link to that either because of FSFE’s censorship regime)

The FSFE constitution calls on FSFE to “join forces” with the FSF and sometimes this appears to happen but I feel this could be taken further.

FSF people have also produced vast amounts of code (the GNU Project) and some donors appear to be contributing funds to FSFE in gratitude for that or in the belief they are supporting that. However, it is not clear to me that funds given to FSFE support that work. As Fellowship representative, a big part of my role is to think about the best interests of those donors and so the possibility that they are being confused concerns me.

Given the vast amounts of money and goodwill contributed by the community to FSFE e.V., including a recent bequest of EUR 150,000 and the direct questions about this issue I feel it is becoming more important for both organizations to clarify the issue.

FSFE has a transparency page on the web site and this would be a good place to publish all documents about their relationship with FSF. For example, FSFE could publish the documents explaining their authorization to use a name derived from FSF and the extent to which they are committed to adhere to FSF’s core philosophy and remain true to that in the long term. FSF could also publish some guidelines about the characteristics of a sister organization, especially when that organization is authorized to share the FSF’s name.

In the specific case of sister organizations who benefit from the tremendous privilege of using the FSF’s name, could it also remove ambiguity if FSF mandated the titles used by officers of sister organizations? For example, the “FSFE President” would be referred to as “FSFE European President”, or maybe the word president could be avoided in all sister organizations.

People also raise the question of whether FSFE can speak for all Europeans given that it only has a large presence in Germany and other organizations are bigger in other European countries. Would it be fair for some of those other groups to aspire to sister organization status and name-sharing rights too? Could dozens of smaller FSF sister organizations dilute the impact of one or two who go off-script?

Even if FSFE was to distance itself from FSF or even start using a new name and philosophy, as a member, representative and also volunteer I would feel uncomfortable with that as there is a legacy of donations and volunteering that have brought FSFE to the position the organization is in today.

That said, I would like to emphasize that I regard RMS and the FSF, as the original FSF, as having the final authority over the use of the name and I fully respect FSF’s right to act unilaterally, negotiate with sister organizations or simply leave things as they are.

If you have questions or concerns about this topic, I would invite you to raise them on the LibrePlanet-discuss mailing list or feel free to email me directly.

Powered by WPeMatico

Share Button

Ben Cotton: Linus’s awakening

Share Button

It may be the biggest story in open source in 2018, a year that saw Microsoft purchase GitHub. Linus Torvalds replaced the Code of Conflict for the Linux kernel with a Code of Conduct. In a message on the Linux Kernel Mailing List (LKML), Torvalds explained that he was taking time off to examine the way he led the kernel development community.

Torvalds has taken a lot of flak for his style over the years, including on this blog. While he has done an excellent job shepherding the technical development of the Linux kernel, his community management has often — to put it mildly — left something to be desired. Abusive and insulting behavior is corrosive to a community, and Torvalds has spent the better part of the last three decades enabling and partaking in it.

But he has seen the light, it would seem. To an outside observer, this change is rather abrupt, but it is welcome. Reaction to his message has been mixed. Some, like my friend Jono Bacon, have advocated supporting Linus in his awakening. Others take a more cynical approach:

Oh look, an abusive OSS maintainer finally admitted, after *decades* of abusive and toxic behavior, that his behavior *might* be an issue.

And a bunch of people I follow are tripping all over themselves to give him cookies for that. 🙄🙄🙄

— Kelly Ellis (@justkelly_ok) September 17, 2018


I understand Kelly’s position. It’s frustrating to push for a more welcoming and inclusive community only to be met with insults and then when someone finally comes around to have everyone celebrate. Kelly and others who feel like her are absolutely justified in their position.

For myself, I like to think of it as a modern parable of the prodigal son. As tempting as it is to reject those who awaken late, it is better than them not waking at all. If Linus fails to follow through, it would be right to excoriate him. But if he does follow through, it can only improve the community around one of the most important open source projects. And it will set an example for other projects to follow.

I spend a lot of time thinking about community, particularly since I joined Red Hat as the Fedora Program Manager a few months ago. Community members — especially those in a highly-visible role — have an obligation to model the kind of behavior the community needs. This sometimes means a patient explanation when an angry rant would feel better. It can be demanding and time-consuming work. But an open source project is more than just the code; it’s also the community. We make technology to serve the people, so if our communities are not healthy, we’re not doing our jobs.

The post Linus’s awakening appeared first on Blog Fiasco.

Powered by WPeMatico

Share Button

Martin Stransky: Thunderbird 60 with title bar hidden

Share Button

Many users like hidden system titlebar as Firefox feature although it’s not finished yet. But we’re very close and I hope to have Firefox 64 in shape that the title bar can be disabled by default at least on Gnome and matches Firefox outfit at Windows and Mac.

Thunderbird 60 was finally released for Fedora and comes with a basic version of the feature as it was introduced at Firefox 60 ESR. There’s a simple checkbox at “Customize” page at Firefox but Thunderbird is missing an easy switch.

To disable the title bar at Thunderbird 60, you need to go to system menu Edit -> Preferences and choose Advanced tab. Then click at Config Editor at page left bottom corner, open it and look for mail.tabs.drawInTitlebar. Double clik on it and your bird should be titleless 🙂

Powered by WPeMatico

Share Button

Fedora Community Blog: Say thank you this November during Fedora Appreciation Week 2018

Share Button

Fedora Appreciation Week is a new event this year organized by the Fedora Community Operations (CommOps) team. Fedora Appreciation Week, abbreviated as FAW, is a week-long event to celebrate the efforts of Fedora Project contributors and to say “thank you” to each other. Fedora Appreciation Week begins Monday, November 5, 2018 and runs until Sunday, November 11, 2018.

What is it?

The Ubuntu Community Appreciation Day inspired the CommOps team to organize a similar event of appreciation for contributors who make Fedora what it is. This includes all types of contributors, from development, design, infrastructure, marketing, engineering, and more.

During this time of appreciation, users and contributors alike are highly encouraged to select either an individual or a group of contributors to thank for their efforts in Fedora. Appreciation can be given as a karma cookie in IRC, a short note of thanks on a mailing list, or a longer form appreciation such as a Fedora Happiness Packet.

This year’s Fedora Appreciation Week will occur during the 15th anniversary of the Fedora Project on November 6, 2018.

Why have an Appreciation Week?

Most Fedora contributors do not get to work together in the same building or office. Our daily interactions are usually in text (e.g. IRC, emails, wikis, etc.). Even though these work well and we accomplish our goals, we lose touch with the human side of contributing. Fedora contributors aren’t robots, but real people! Fedora Appreciation Week is a chance to remember the Fedora community is a community of people, and to thank our colleagues and friends who might be halfway across the room or halfway across the planet.

How to participate in Appreciation Week

More information about how to participate will come in October. In the meanwhile, consider writing a Contributor Story! Contributor Stories are just that: the record of our best moments with our Fedora friends. The story can be about our work in Fedora or something personal or unique which you would like to share with the community. Selected stories will be shared on the Community Blog every day during Fedora Appreciation Week.

See some examples and consider writing one of your own before Fedora Appreciation Week rolls around on Monday, November 5, 2018.


Photo by “My Life Through A Lens” on Unsplash.

The post Say thank you this November during Fedora Appreciation Week 2018 appeared first on Fedora Community Blog.

Powered by WPeMatico

Share Button

Justin W. Flory: How to fix missing Python for Ansible in Fedora Vagrant

Share Button

Recently, I started to use Vagrant to test Ansible playbooks on Fedora machines. I’m using the Fedora 28 cloud base image. However, when I tried to provision my Vagrant box, I was warned the Python binary is missing.

$ vagrant provision
==> default: Running provisioner: ansible...
    default: Running ansible-playbook...

PLAY [all] *********************************************************************

TASK [Gathering Facts] *********************************************************
fatal: [default]: FAILED! => {"changed": false, "module_stderr": "Shared connection to 192.168.121.3 closed.rn", "module_stdout": "rn/bin/sh: /usr/bin/python: No such file or directoryrn", "msg": "MODULE FAILURE", "rc": 127}
	to retry, use: --limit @playbook.retry

Problem: Python 3 by default

This error appears because Fedora 28 does not provide a Python 2 binary by default. Only Python 3 is provided on the base cloud image. I verified this by SSHing into the Vagrant box.

[jflory@vagrant-host vagrant]$ vagrant ssh
[vagrant@localhost ~]$ dnf list installed | grep -i python

Annoyingly, I must install Python 2 manually in the box each time it fails to provision. Surely, there is an easier way? Fortunately, StackOverflow came to the rescue.

Solution: ansible.extra_vars

It’s possible to tell Vagrant where the Python binary is located. You can pass the path to the python3 binary manually in your Vagrantfile.

# Provisioning configuration for Ansible.
config.vm.provision :ansible do |ansible|
  ansible.playbook = "playbook.yml"
  ansible.extra_vars = { ansible_python_interpreter:"/usr/bin/python3" }
end

Adding these changes to your Vagrantfile allows Ansible to successfully run on the Fedora Vagrant guest. Python is successfully located.

This is an annoying workaround, but it solves the issue and lets you successfully test and iterate changes on Fedora systems. Here’s hoping the Fedora cloud image maintainers add a default binary for /usr/bin/python to point to /usr/bin/python3 in the future.

The post How to fix missing Python for Ansible in Fedora Vagrant appeared first on Justin W. Flory’s Blog.

Powered by WPeMatico

Share Button

Bodhi: Bodhi 3.10.0 released

Share Button

Dependency changes

The composer now requires hawkey.

Server upgrade instructions

This release contains database migrations. To apply them, run::

$ sudo -u apache /usr/bin/alembic -c /etc/bodhi/alembic.ini upgrade head

Features

  • It is no longer an error if a developer tries to create an override for a build that already had
    an override. Instead, Bodhi helpfully edits the old override automatically (#2030).
  • The UI displays the date that expired overrides became expired (#2136).
  • Security updates now require severity to be set (#2206).
  • The Waiver UI now gives the user more context (#2270 and #2363).
  • The CLI can be used to edit Release mail templates (#2475).
  • A new clean_old_composes setting allows admins to disable the automatic compose cleanup
    feature that was new in Bodhi 3.9.0 (#2561).
  • The API can filter releases by state (beb69a0).
  • The CLI now has a --debug flag on a couple of commands (1bd7617).
  • The bindings have some debug level logging when retrieving Greenwave status (b55fa45).
  • The UI now makes it clear that only authenticated users can leave karma on updates
    (3b551c3).
  • Bodhi can now manage Flatpaks (1a6c4e8).
  • Bodhi now ships a /usr/bin/bodhi-skopeo-lite, which is intended to be an alternative for use
    with the skopeo.cmd setting. It allows for multi-arch containers and Flatpaks to be managed by
    Bodhi (a0496fc).
  • The composer now uses librepo/hawkey to do much more extensive testing on the produced yum
    repositories to ensure they are valid (7dda554).

Bug fixes

  • More space was added around some buttons so they don’t touch on small screens (#1902).
  • The bodhi releases subcommands no longer prompt for password when not necessary
    (#2496).
  • The submit feedback button now appears on low resolution screens (#2509).
  • Articles were fixed in a tooltip on the update page (075f8a9).
  • The CLI can again display missing required tests (cf75ff8).
  • Fix a failure that sometimes occurred when editing multi-build updates (d997ed4).
  • Unknown Koji tags will no longer cause an Exception when creating new updates
    (78dd4aa).

Development improvements

  • Line test coverage has reached 100% (2477fc8).
  • A fake Pungi is used in the Vagrant environment to speed up vagrant up (1b4f5fc).
  • No tests are skipped on Python 3 anymore (44d46e3).

Contributors

The following developers contributed to Bodhi 3.10.0:

  • Anatoli Babenia
  • Clement Verna
  • Mattia Verga
  • Owen W. Taylor
  • Patrick Uiterwijk
  • Pierre-Yves Chibon
  • Ralph Bean
  • Rick Elrod
  • Vismay Golwala
  • Randy Barlow

Powered by WPeMatico

Share Button