18 Sep 2018

feedFedora People

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

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.

18 Sep 2018 11:21pm GMT

Ben Cotton: Linus’s awakening

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:

<figure class="wp-block-embed-twitter wp-block-embed is-type-rich is-provider-twitter">

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

<script async="async" charset="utf-8" src="https://platform.twitter.com/widgets.js"></script> </figure>

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.

18 Sep 2018 12:02pm GMT

Martin Stransky: Thunderbird 60 with title bar hidden

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 🙂

18 Sep 2018 8:58am GMT

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

Say thank you this November during Fedora Appreciation Week 2018

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.

18 Sep 2018 8:30am GMT

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

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.\r\n", "module_stdout": "\r\n/bin/sh: /usr/bin/python: No such file or directory\r\n", "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.

18 Sep 2018 8:30am GMT

Fedora Magazine: How to install more wallpaper packs on Fedora Workstation

Every release, the Fedora Design team creates a new default wallpaper for Fedora. In addition to the default wallpaper, the Fedora repositories also contain a set of extra Supplemental Wallpapers for each release. These older wallpapers are not installed by default, but are easily installed from the Fedora Repositories. If you have just set up a fresh install of Fedora, and want to expand your choices for your desktop wallpaper, the older Fedora wallpapers are a great choice.

This post lists out the older wallpapers available in the Fedora repositories, and how to install them on your current Fedora install. On Fedora Workstation, after you have installed your desired pack, they will show up in the Wallpapers tab in the Background chooser in the Settings.

Note: If you are using a desktop environment other than the default for Fedora Workstation (GNOME), there are also packages tailored to some of the more popular alternative desktops. In most of the examples below, simply change

gnome

in the dnf install line to

kde

or

mate

or

xfce

when installing the package.

Fedora 28 Wallpapers

Fedora 28 Default Wallpaper

To install the Fedora 28 default wallpaper, use the following command in the Terminal:

sudo dnf install f28-backgrounds-gnome

Fedora 28 Supplemental Wallpapers

To install the Fedora 28 supplementary wallpapers, use the following command in the Terminal:

sudo dnf install f28-backgrounds-extras-gnome

Fedora 27 Wallpaper

To install the Fedora 27 default wallpaper, use the following command in the Terminal:

sudo dnf install f27-backgrounds-gnome

Fedora 26 Wallpapers

Fedora 26 Default Wallpaper

To install the Fedora 26 default wallpaper, use the following command in the Terminal:

sudo dnf install f26-backgrounds-gnome

Fedora 26 Supplemental Wallpapers

To install the Fedora 26 supplementary wallpapers, use the following command in the Terminal:

sudo dnf install f26-backgrounds-extras-gnome

Fedora 25 Wallpapers

Fedora 25 Default Wallpaper

To install the Fedora 25 default wallpaper, use the following command in the Terminal:

sudo dnf install f25-backgrounds-gnome

Fedora 25 Supplemental Wallpapers

To install the Fedora 25 supplementary wallpapers, use the following command in the Terminal:

sudo dnf install f25-backgrounds-extras-gnome

Fedora 24 Wallpapers

Fedora 24 Default Wallpaper

To install the Fedora 24 default wallpaper, use the following command in the Terminal:

sudo dnf install f24-backgrounds-gnome

Fedora 24 Supplemental Wallpapers

To install the Fedora 24 supplementary wallpapers, use the following command in the Terminal:

sudo dnf install f24-backgrounds-extras-gnome

Fedora 23 Wallpapers

Fedora 23 Default Wallpaper

To install the Fedora 23 default wallpaper, use the following command in the Terminal:

sudo dnf install f23-backgrounds-gnome

Fedora 23 Supplemental Wallpapers

To install the Fedora 23 supplementary wallpapers, use the following command in the Terminal:

sudo dnf install f23-backgrounds-extras-gnome

Fedora 22 Wallpapers

Fedora 22 Default Wallpaper

To install the Fedora 22 default wallpaper, use the following command in the Terminal:

sudo dnf install f22-backgrounds-gnome

Fedora 22 Supplemental Wallpapers

To install the Fedora 22 supplementary wallpapers, use the following command in the Terminal:

sudo dnf install f22-backgrounds-extras-gnome

Fedora 21 Wallpapers

Fedora 21 Default Wallpaper

To install the Fedora 21 default wallpaper, use the following command in the Terminal:

sudo dnf install f21-backgrounds-gnome

Fedora 21 Supplemental Wallpapers

To install the Fedora 21 supplementary wallpapers, use the following command in the Terminal:

sudo dnf install f21-backgrounds-extras-gnome

Fedora 20 Wallpapers

Fedora 20 Default Wallpaper

To install the Fedora 20 default wallpaper, use the following command in the Terminal:

sudo dnf install heisenbug-backgrounds-gnome

Fedora 20 Supplemental Wallpapers

To install the Fedora 20 supplementary wallpapers, use the following command in the Terminal:

sudo dnf install heisenbug-backgrounds-extras-gnome

Fedora 19 Wallpapers

Fedora 19 Default Wallpaper

To install the Fedora 19 default wallpaper, use the following command in the Terminal:

sudo dnf install schroedinger-cat-backgrounds-gnome

Fedora 19 Supplemental Wallpapers

To install the Fedora 19 supplementary wallpapers, use the following command in the Terminal:

sudo dnf install schroedinger-cat-backgrounds-extras-gnome

Fedora 18 Wallpapers

Fedora 18 Default Wallpaper

To install the Fedora 18 default wallpaper, use the following command in the Terminal:

sudo dnf install spherical-cow-backgrounds-gnome

Fedora 18 Supplemental Wallpapers

To install the Fedora 18 supplementary wallpapers, use the following command in the Terminal:

sudo dnf install spherical-cow-backgrounds-extras-gnome

Fedora 17 Default Wallpaper

To install the Fedora 17 default wallpaper, use the following command in the Terminal:

sudo dnf install beefy-miracle-backgrounds-gnome

Fedora 16 Wallpapers

Fedora 16 Default Wallpaper

To install the Fedora 16 default wallpaper, use the following command in the Terminal:

sudo dnf install verne-backgrounds-gnome

Fedora 16 Supplemental Wallpapers

To install the Fedora 16 supplementary wallpapers, use the following command in the Terminal:

sudo dnf install verne-backgrounds-extras-gnome

Fedora 15 Wallpapers

Fedora 15 Default Wallpaper

The default wallpaper for Fedora 15 was a remix of the default GNOME wallpaper at the time. To install the Fedora 15 default wallpaper, use the following command in the Terminal:

sudo dnf install lovelock-backgrounds-stripes-gnome

Fedora 15 Alternate Wallpaper

Fedora 15 also shipped with an alternate wallpaper, that was used by default on non-GNOME spins. To get this wallpaper, use the following command in the Terminal:

sudo dnf install lovelock-backgrounds-gnome

Fedora 14 Wallpapers

Fedora 14 Default Wallpaper

To install the Fedora 14 default wallpaper, use the following command in the Terminal:

sudo dnf install laughlin-backgrounds-gnome

Fedora 14 Supplemental Wallpapers

To install the Fedora 14 supplementary wallpapers, use the following command in the Terminal:

sudo dnf install laughlin-backgrounds-extras-gnome

Fedora 13 Default Wallpaper

To install the Fedora 13 default wallpaper, use the following command in the Terminal:

sudo dnf install goddard-backgrounds-gnome

Fedora 12 Default Wallpaper

To install the Fedora 12 default wallpaper, use the following command in the Terminal:

sudo dnf install constantine-backgrounds

Fedora 11 Default Wallpaper

To install the Fedora 11 default wallpaper, use the following command in the Terminal:

sudo dnf install leonidas-backgrounds-lion

Fedora 10 Default Wallpaper

To install the Fedora 10 default wallpaper, use the following command in the Terminal:

sudo dnf install solar-backgrounds

Fedora 9 Default Wallpaper

To install the Fedora 9 default wallpaper, use the following command in the Terminal:

sudo dnf install desktop-backgrounds-waves

Fedora 8 Default Wallpaper

To install the Fedora 8 default wallpaper, use the following command in the Terminal:

sudo dnf install fedorainfinity-backgrounds

18 Sep 2018 2:50am GMT

Lukas "lzap" Zapletal: Switching to Universal Ctags

Switching to Universal Ctags

After some time spent with exuberant-ctags and ripper-tags, I am switching over to universal-ctags. Ruby language and other languages like Golang is vastly improved over to exuberant-ctags and even ripper-tags. Here are my git hooks which I use for all my project checkouts. It's fast, fluent and works across all my projects.

For navigation I stick with Vim, sometimes I use fzf.vim plugin together with fzf for terminal.

For longer coding sessions, I am trying GNOME Builder which looks great and every single release it is catching up with Submlime Text 3, except it is fully open source and it has usable Vim emulation. I've tried Atom and VSCode but these slow things are not for me.

18 Sep 2018 12:00am GMT

17 Sep 2018

feedFedora People

Martin Stransky: Fedora Firefox – GCC/CLANG dilemma

After reading Mike's blog post about official Mozilla Firefox switch to LLVM Clang, I was wondering if we should also use that setup for official Fedora Firefox binaries.

The numbers look strong but as Honza Hubicka mentioned, Mozilla uses pretty ancient GCC6 to create binaries and it's not very fair to compare it with up-to date LLVM Clang 6.

Also if I'm reading the mozilla bug correctly the PGO/LTO is not yet enabled for Linux, only plain optimized builds are used for now…which means the transition at Mozilla is not so far than I expected.

I also went through some Poronix tests which indicates there's no black and white situation there although Mike claimed that LLVM Clang is generally better that GCC. But it's possible that Firefox codebase somehow fits better LLVM Clang than GCC.

After some consideration I think we'll stay with GCC for now and I'm going compare Fedora GCC 8 builds with the Mozilla LLVM Clang ones when there are available. Both builds can't use -march=native so It may be an equal comparsion. Also Fedora should enable the PGO+LTO GCC setup to get the best from GCC.

[Update] I was wrong and PGO+LTO should be enabled also for Linux builds now. The numbers looks very well and I wonder if we can match them with GCC8! 🙂

17 Sep 2018 9:00pm GMT

Bodhi: Bodhi 3.10.0 released

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

Bug fixes

Development improvements

Contributors

The following developers contributed to Bodhi 3.10.0:

17 Sep 2018 3:50pm GMT

Marios Andreou: My summary of the OpenStack Stein PTG in Denver


My summary of the OpenStack Stein PTG in Denver

After only 3 take off/landings I was very happy to participate in the Stein PTG in Denver. This is a brief summary with pointers of the sessions or rooms I attended in the order they happened (Stein PTG Schedule)

Upgrades CI with the stand-alone deployment

We had a productive impromptu round table (weshay++) in one of the empty rooms with the tripleo ci folks present (weshay, panda, sshnaidm, arxcruz, marios) the tripleo upgrades folks present (chem and holser) as well emeritus PTL mwahaha around the stand-alone and how we can use it for upgrades ci. We introduced the proposed spec and one of the main topics discussed was, ultimately is it worth it, to solve all of these subproblems to only end up with some approximation of the upgrade?

The consensus was yes since we can have 2 types of upgrades job: use the stand-alone to ci the actual tasks, i.e. upgrade_tasks and deployment_tasks for each service in the tripleo-heat-templates, and another job (the current job which will be adapted) to ci the upgrades workflow tripleoclient/mistral workflows etc. There was general consensus in this approach between the upgrades and ci representatives so that we could try and sell it to the wider team in the tripleo room on wednesday together.

Upgrades Special Interest Group

Room etherpad.

Monday afternoon was spent in the upgrades SIG room. There was first discussion of the placement api extraction and how this would have to be dealt with during the upgrade, with a solution sketched out around the db migrations required.

This lead into discussion around pre-upgrade checks that could deal with things like db migrations (or just check if something is missing and fail accordingly before the upgrade). As I was reminded during the lunchtime presentations pre upgrade checks is one of the Stein community goals (together with python-3). The idea is that each service would own a set of checks that should be performed before an upgrade is run and that they would be invoked via the openstack client (sthing along the lines of 'openstack pre-upgrade-check nova' - I believe there is already some implementation (from the nova team) but I don't readily have details.

There was then a productive discussion about the purpose and direction of the upgrades SIG. One of the points raised was that the SIG should not be just about the fast forward upgrade even though that has been a main focus until now. The pre-upgrade checks are a good example of that and the SIG will try and continue to promote these with adoption by all the OpenStack services. On that note I proposed that whilst the services themselves will own the service specific pre-upgrade checks, it's the deployment projects which will own the pre-upgrade infrastructure checks, such as healthy cluster/database or responding service endpoints.

There was ofcourse discussion around the fast forward upgrade with status updates from the deployment projects present (kolla-ansible, TripleO, charms, OSA). TripleO is the only project with an implemented workflow at present. Finally there was a discussion about whether we're doing better in terms of operator experience for upgrades in general and how we can continue to improve (e.g. rolling upgrades was one of the discussed points here).

Edge room

Room etherpad Room etherpad2 Use cases Edge primer

I was only in attendance for the first part of this session which was about understanding the requirements (and hopefully continuing to find the common ground). The room started with a review of the various proposed use cases from dublin and any review of work since then. One of the main points raised by shardy is that in TripleO whilst we have a number of exploratory efforts ongoing (like split controlplane for example) it would be good to have a specific architecture to aim for and that is missing currently. It was agreed that the existing use cases will be extended to include the proposed architecture and that these can serve as a starting point for anyone looking to deploy with edge locations.

There are pointers to the rest of the edge sessions in the etherpad above.

TripleO room

Room etherpad Team picture

The order of sessions was slightly revised from that listed in the etherpad above because the East coast storms forced folks to change travel plans. The following order is to the best of my recollection ;)

TripleO and Edge cloud deployments

Session etherpad

There was first a summary from the Edge room from shardy and then tripleo specific discussion around the current work (split controlplane). There was some discussion around possibly using/repurposing "the multinode job" for multiple stacks to simulate the Edge locations in ci. There was also discussion around the networking aspects (though this will depend on the architecture which we don't yet have fully targetted) with respect to the tripleo deployment networks (controlplane/internalapi etc) in an edge deployment. Finally there was consideration of the work needed in tripleo-common and the mistral workflows needed for the split controlplane deployment.

OS / Platform

(tracked on main tripleo etherpad linked above)

The main items discussed here were Python 3 support, removing instack-undercloud and "that upgrade" to Centos8 on Stein.

For Python3 the discussion included the fact that in TripleO we are bound by whatever python the deployed services support (as well as what the upstream distribution will be i.e. Centos 7/8 and which python ships where).

For the Centos8/Stein upgrade the upgrades folks chem and holser lead the discussion outlining how we will need a completely new workflow, which may be dictated in large by how the Centos8 is delivered. One of the approaches discussed here was to use a completely external/distinct upgrade workflow for the OS, versus the TripleO driven OpenStack upgrade itself. We got into more details about this during the Baremetal session see below).

TripleO CI

Session etherpad

One of the first items raised was the stand-alone deployment and its use in ci. The general proposal is that we should use a lot more of it! In particular to replace existing jobs (like scenarios 1/2) with a standalone deployement.

There was also discussion around the stand-alone for the upgrades ci as we agreed with the upgrades folks on Monday (spec). The idea of service vs workflow upgrades was presented/solidified here and I have just updated v8 of the spec accordingly to emphasise this point.

Other points discussed in the CI session were testing ovb in infra and how we could make jobs voting. The first move will be towards removing te-broker.

There was also some consideration of the involvement of the ci team with other squads and vice versa. There is a new column in our trello board called "requests from other DFG".

A further point raised was the reproducer scripts and future directions including running and not only generating this in ci. As related side note it sounds like folks are using the reproducer and having some successes.

Ansible / Framework

(tracked on main tripleo etherpad linked above)

In this session an overview of the work towards splitting out the ansible tasks from the tripleo-heat-templates into re-usable roles was given by jillr and slagle. More info and pointers in the the main tripleo etherpad above.

Security

Session etherpad

Discussion around the workflow to change overcloud/service passwords (this is currently borked!). In particular problems around trying to CI this since the deploy takes too long to have deploy + stack update for the passwords and validation within the timeout. Possibly could be a 3rd party (but then non voting) job for now. There was also an overview of work towards using Castellan with TripleO, as well as discussion around selinux and locking down ssh.

UX / UI

Session etherpad

CLI/UI feature parity is a main goal for this cycle (and further probably it seems there is a lot to do) and plan management operations around this. Also good discussion around validations with Tengu joining remotely via Bluejeans to champion the effort of providing a nice way to run these via the tripleoclient.

Baremetal

Session etherpad

This session started with discussion around metalsmith vs nova on the undercloud and the required upgrade path to make this so. Also considered were the overcloud image customization and discussions around network automation (ansible with python-networking-ansible ml2 driver ).

However unexpectedly and the most interesting part of this session personally was an impromptu design session started by ipilcher (prompted by a question from phuongh who I believe was new to the room). The session was about the upgrade to Centos8 and three main approaches were explored, the "big bang" (everything off upgrade everything back), "some kind of rolling upgrade" and finally supporting either Centos8/Rocky or Centos7/Stein. The first and third were deemed unworkable but there was a very lively and well engaged group design session trying to navigate to a workable process for the 'rolling upgrade' aka split personality. Thanks to ipilcher (via bandini) the whiteboards looked like this.

17 Sep 2018 3:00pm GMT

Alexander Larsson: Flatpak on windows

As I teased about last week I recently played around with WSL, which lets you run Linux applications on Windows. This isn't necessarily very useful, as there isn't really a lack of native applications on Windows, but it is still interesting from a technical viewpoint.

I created a wip/WSL branch of flatpak that has some workarounds needed for flatpak to work, and wrote some simple docs on how to build and test it.

There are some really big problems with this port. For example, WSL doesn't support seccomp or network namespaces which removes some of the utility of the sandbox. There is also a bad bug that makes read-only bind-mounts not work for flatpak, which is really unsafe as apps can modify themselves (or the runtime). There were also various other bugs that I reported. Additionally, some apps rely on things on the linux host that don't exist in the WSL environment (such as pulseaudio, or various dbus services).

Still, its amazing that it works as well as it does. I was able to run various games, gnome and kde apps, and even the linux versions of telegram. Massive kudos to the Microsoft developers who worked on this!

I know you crave more screenshots, so here is one:

17 Sep 2018 2:44pm GMT

Open Source Security Podcast: Episode 114 - Review of "Click Here to Kill Everybody"

Josh and Kurt review Bruce Schneier's new book Click Here to Kill Everybody. It's a book everyone could benefit from reading. It does a nice job explaining many existing security problems in a simple manner.

<iframe allowfullscreen="" height="90" mozallowfullscreen="" msallowfullscreen="" oallowfullscreen="" scrolling="no" src="https://html5-player.libsyn.com/embed/episode/id/7052800/height/90/theme/custom/autoplay/no/autonext/no/thumbnail/yes/preload/no/no_addthis/no/direction/backward/render-playlist/no/custom-color/6e6a6a/" style="border: none;" webkitallowfullscreen="" width="100%"></iframe>

Show Notes

Comment on Twitter with the #osspodcast hashtag



17 Sep 2018 12:13am GMT

16 Sep 2018

feedFedora People

mythcat: Fedora 28 : Using AdonisJs web framework.

AdonisJs is a Node.js web framework with a breath of fresh air and drizzle of elegant syntax on top of it.
We prefer developer joy and stability over anything else.
I tested today this web framework named AdonisJs with Fedora 28.
The main goal was to use mysql with mariadb from Fedora 28 distro.
Let's start with instalation of AdonisJs on Fedora 28:

[root@desk mythcat]# npm i --global @adonisjs/cli
/usr/bin/adonis -> /usr/lib/node_modules/@adonisjs/cli/index.js
...
+ @adonisjs/cli@4.0.7
added 406 packages from 182 contributors in 33.533s

Go to default user:

[root@desk mythcat]# exit
exit

Create the application , I named myapp:

[mythcat@desk ~]$ adonis new myapp
    _       _             _         _     
   / \   __| | ___  _ __ (_)___    | |___ 
  / _ \ / _` |/ _ \| '_ \| / __|_  | / __|
 / ___ \ (_| | (_) | | | | \__ \ |_| \__ \
/_/   \_\__,_|\___/|_| |_|_|___/\___/|___/

  [1/6] 🔬  Requirements matched [node & npm]
  [2/6] 🔦  Ensuring project directory is clean [myapp]
  [3/6] đź“Ą  Cloned [adonisjs/adonis-fullstack-app]
  [4/6] 📦  Dependencies installed
  [5/6] đź“–  Environment variables copied [.env]
  [6/6] 🔑  Key generated [adonis key:generate]

🚀   Successfully created project
👉   Get started with the following commands

Let's test the default myapp with this commands:

$ cd myapp
$ adonis serve --dev

[mythcat@desk ~]$ cd myapp
[mythcat@desk myapp]$ adonis serve --dev

 SERVER STARTED 
> Watching files for changes...

2018-09-16T09:47:46.799Z - info: serving app on http://127.0.0.1:3333

This is the result of the running myapp on 127.0.0.1:3333 web address:
Let's see the folders and files from AdonisJS:

[mythcat@desk myapp]$ ls
ace  config    node_modules  package-lock.json  README.md  server.js
app  database  package.json  public             resources  start

The configuration for web files can be see here:

[mythcat@desk myapp]$ vim  start/routes.js 
'use strict'

/*
|--------------------------------------------------------------------------
| Routes
|--------------------------------------------------------------------------
|
| Http routes are entry points to your web application. You can create
| routes for different URL's and bind Controller actions to them.
|
| A complete guide on routing is available here.
| http://adonisjs.com/docs/4.1/routing
|
*/

/** @type {import('@adonisjs/framework/src/Route/Manager'} */
const Route = use('Route')

Route.on('/').render('welcome')
~

This is telling Adonis that when the root of the site is loaded, render a template/view called welcome.
That welcome template can be found in /resources/views/welcome.edge.

[mythcat@desk myapp]$ cd resources/
[mythcat@desk resources]$ ll
total 0
drwxrwxr-x. 2 mythcat mythcat 26 Sep 16 12:46 views
[mythcat@desk resources]$ cd views/
[mythcat@desk views]$ ll
total 4
-rw-rw-r--. 1 mythcat mythcat 339 Sep 16 12:46 welcome.edge

Let's see the source code of this default webpage:

[mythcat@desk views]$ vim welcome.edge 
...

For example , if you change into start/routes.js from welcome to index then you need to rename the welcome.edge to index.edge .
About css files you can make changes into public/style.css :

[mythcat@desk myapp]$ cd public/
[mythcat@desk public]$ vim  style.css


@import url('https://fonts.googleapis.com/css?family=Montserrat:300');

html, body {
  height: 100%;
  width: 100%;
}

body {
  font-family: 'Montserrat', sans-serif;
  font-weight: 300;
  background-image: url("/splash.png");
  background-color: #220052;
}

* {
  margin: 0;
  padding: 0;
}
...

Using the mysql database is simple. Into Fedora 28 distro you can use mariadb, let's install it.

[mythcat@desk myapp]$ su
Password: 
[root@desk myapp]# dnf install mariadb mariadb-server
...
Complete!
[root@desk myapp]# systemctl start mariadb
[root@desk myapp]# systemctl status mariadb
â—Ź mariadb.service - MariaDB 10.2 database server
...

You need to make changes into .env file into your project folder.

[mythcat@desk myapp]$ vim .env
HOST=127.0.0.1
PORT=3333
NODE_ENV=development
APP_URL=http://${HOST}:${PORT}
CACHE_VIEWS=false
APP_KEY=xxxxxxxxxxxxxxxx
DB_CONNECTION=sqlite
DB_HOST=127.0.0.1
DB_PORT=3306
DB_USER=root
DB_PASSWORD=
DB_DATABASE=adonis
SESSION_DRIVER=cookie
HASH_DRIVER=bcrypt
~

Use this changes for mariadb:

DB_CONNECTION=mysql

Install into AdonisJs with this command:

[mythcat@desk myapp]$ adonis install mysql
  [1/1] 📦  Dependencies installed [mysql]

Use this mysql commands to create the database:

[mythcat@desk myapp]$ mysql -u root
Welcome to the MariaDB monitor.  Commands end with ; or \g.
Your MariaDB connection id is 18
Server version: 10.2.17-MariaDB MariaDB Server

Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

MariaDB [(none)]> create database adonis;
Query OK, 1 row affected (0.11 sec)

MariaDB [(none)]> exit;
Bye

Let's test migration command for files to allow you to create and delete tables.

[mythcat@desk myapp]$ adonis migration:run
migrate: 1503248427885_user.js
migrate: 1503248427886_token.js
Database migrated successfully in 4.11 s
[mythcat@desk myapp]$ adonis make:migration jobs
> Choose an action undefined
âś” create  database/migrations/1537095058367_jobs_schema.js

Now that our database and tables have been created, I can create a model for handling jobs table and associated data.
The next tasks to follow depends by your website:

16 Sep 2018 11:15am GMT

15 Sep 2018

feedFedora People

Didier Fabert (tartare): Configuration, initialisation et utilisation de tripwire

Avec la sortie de la nouvelle version de tripwire, j'en profite pour rédiger un tutoriel sur la configuration, l'initialisation et l'utilisation de tripwire.
Tripwire ne peut que constater la modification des fichiers et doit donc être installé/configuré juste après l'installation de la distribution.

Configuration initiale

L'initialisation consiste à créer deux paires de clés, et à chiffrer le fichier de configuration, ainsi que celui de définition de la politique. La paire nommée site servant à chiffrer/déchiffrer les fichiers de configuration et de définition de la politique, et la paire nommée local servant à chiffrer/déchiffrer la base de données et les rapports.

MĂ©thode manuelle pas Ă  pas

Générer la paire de clés nommée site:

sudo twadmin -m G -v -S /etc/tripwire/site.key

Générer la paire de clés nommée local:

sudo twadmin -m G -v -L /etc/tripwire/$(hostname --fqdn)-local.key

Chiffrer le fichier de configuration avec la paire de clés nommée site:

sudo twadmin -m F -c /etc/tripwire/tw.cfg -S /etc/tripwire/site.key /etc/tripwire/twcfg.txt

Chiffrer le fichier de politique avec la paire de clés nommée site:

sudo twadmin -m P -p /etc/tripwire/tw.pol -S /etc/tripwire/site.key /etc/tripwire/twpol.txt

Avec le script qui va bien

Ce script interactif est présent dans le paquet RPM. Dans le cas d'un déploiement automatique (via ansible ou autre), il faudra utiliser la méthode manuelle.

sudo tripwire-setup-keyfiles


----------------------------------------------
The Tripwire site and local passphrases are used to sign a  variety  of
files, such as the configuration, policy, and database files.

Passphrases should be at least 8 characters in length and contain  both
letters and numbers.

See the Tripwire manual for more information.

----------------------------------------------
Creating key files...

(When selecting a passphrase, keep in mind that good passphrases typically
have upper and lower case letters, digits and punctuation marks, and are
at least 8 characters in length.)

Enter the site keyfile passphrase:
Verify the site keyfile passphrase:
Generating key (this may take several minutes)...Key generation complete.

(When selecting a passphrase, keep in mind that good passphrases typically
have upper and lower case letters, digits and punctuation marks, and are
at least 8 characters in length.)

Enter the local keyfile passphrase:
Verify the local keyfile passphrase:
Generating key (this may take several minutes)...Key generation complete.

----------------------------------------------
Signing configuration file...
Please enter your site passphrase: 
Wrote configuration file: /etc/tripwire/tw.cfg

A clear-text version of the Tripwire configuration file:
/etc/tripwire/twcfg.txt
has been preserved for your inspection.  It  is  recommended  that  you
move this file to a secure location and/or encrypt it in place (using a
tool such as GPG, for example) after you have examined it.


----------------------------------------------
Signing policy file...
Please enter your site passphrase: 
Wrote policy file: /etc/tripwire/tw.pol

A clear-text version of the Tripwire policy file:
/etc/tripwire/twpol.txt
has been preserved for  your  inspection.  This  implements  a  minimal
policy, intended only to test  essential  Tripwire  functionality.  You
should edit the policy file to  describe  your  system,  and  then  use
twadmin to generate a new signed copy of the Tripwire policy.

Once you have a satisfactory Tripwire policy file, you should move  the
clear-text version to a secure location  and/or  encrypt  it  in  place
(using a tool such as GPG, for example).

Now run "tripwire --init" to enter Database Initialization  Mode.  This
reads the policy file, generates a database based on its contents,  and
then cryptographically signs the resulting  database.  Options  can  be
entered on the command line to specify which policy, configuration, and
key files are used  to  create  the  database.  The  filename  for  the
database can be specified as well. If no  options  are  specified,  the
default values from the current configuration file are used.

Initialisation

On va créer un petit script afin de modifier notre fichier de politique. Celui-ci commentera en direct, dans le fichier de politique, les fichiers absents de notre système.

Fichier /tmp/configure-tripwire.sh
#/bin/bash

while read line
do
        if [ "${line:0:13}" == "### Filename:" ]
        then
                key=$(echo ${line:14} | sed "s;/;\\\\/;g")
                sudo sed -i -e "/${key}/ s/^/#/" /etc/tripwire/twpol.txt
        fi
done

On lance une première fois l'initialisation en envoyant la sortie sur notre script.

sudo tripwire --init | /tmp/configure-tripwire.sh

Une fois notre fichier de politique modifier, on va chiffrer ce fichier, encore une fois

sudo twadmin -m P -p /etc/tripwire/tw.pol -S /etc/tripwire/site.key /etc/tripwire/twpol.txt

Et on relance l'initialisation

sudo tripwire --init

Utilisation

Tripwire n'utilise que la version chiffrée des fichiers de configuration et de définition de la politique. On peut tout à fait supprimer/vider les fichiers en clair. On peut toutefois les récupérer à partir de leur version chiffrée.

Tâches usuelles:

15 Sep 2018 3:00pm GMT

Joe Brockmeier: Stop using GitHub as a measure of open source contributions

With Microsoft and the rest of the tech industry trying to flaunt their open source bona fides, people keep trotting out deeply flawed analyses of "who contributes most to open source" based on … what they can measure on GitHub. For many reasons, using GitHub as the gold standard for open source contributions is extremely biased and doesn't […]

15 Sep 2018 2:04pm GMT

14 Sep 2018

feedFedora People

Fedora Community Blog: FPgM report: 2018-37

Fedora Program Manager weekly report on Fedora Project development and progress

Here's your report of what has happened in Fedora Program Management this week. The Fedora 29 Beta was declared No-Go and will move to the alternate target date of 25 September. Also, the Respins SIG announced an updated set of live ISOs for Fedora 28.

I've set up weekly office hours in #fedora-meeting. Drop by if you have any questions or comments about the schedule, Changes, elections or anything else.

Upcoming meetings

Schedule

Fedora 29

Fedora 30

Fedora 29 Status

Changes

The numbers below reflect the current state of Bugzilla tracking bugs.

NEW/ASSIGNED 2
MODIFIED 0
ON_QA 39
(total) 41

Deferred to Fedora 30

Fedora 30 Changes

Fedora 30 includes a Change that will cause ambiguous python shebangs to error. A list of failing builds is available on Taskotron.

Approved

The post FPgM report: 2018-37 appeared first on Fedora Community Blog.

14 Sep 2018 8:21pm GMT