Ingvar Hagelund: Packages of varnish-6.2.0 with matching vmods, for el6 and el7

Share Button

The Varnish Cache project recently released a new upstream version 6.2 of Varnish Cache. I updated the fedora rawhide package yesterday. I have also built a copr repo with varnish packages for el6 and el7 based on the fedora package. A snapshot of matching varnish-modules (based on Nils Goroll’s branch) is also available.

Packages are available at https://copr.fedorainfracloud.org/coprs/ingvar/varnish62/.

vmods included in varnish-modules:
vmod-bodyaccess
vmod-cookie
vmod-header
vmod-saintmode
vmod-tcp
vmod-var
vmod-vsthrottle
vmod-xkey

Powered by WPeMatico

Share Button

Fedora Community Blog: AskFedora refresh: we’ve moved to Discourse!

Share Button

The Fedora Project community

We have been working on moving AskFedora to a Discourse instance after seeing how well the community took to discussion.fedoraproject.org. After working on it for a few weeks now, we’re happy to report that the new AskFedora is now ready for use at https://askbeta.fedoraproject.org.

The new AskFedora!

The new AskFedora is a Discourse instance hosted for us by Discourse, similar to discussion.fedoraproject.org. However, where discussion.fedoraproject.org is meant for development discussion within the community, AskFedora is meant for end-user troubleshooting. While we did toy with the idea of simply using discussion.fedoraproject.org for both purposes, we felt it was a bit of a risk of the mix hampering both use cases. So, the decision was made to stick to the current organisation and use a separate Discourse instance for user queries.

Getting started: logging in and language selection

The new AskFedora is limited to FAS (Fedora Account System) logins only. This is unlike the Askbot instance where we also permitted social media and other logins. Limiting the logins to FAS permits us to have better control over the instance, and makes it much easier to gather data on usage and so on. Setting up a new FAS instance is quite trivial, so we do not expect this to be an issue to end-users either.

Another way in which AskFedora on Discourse is different from AskFedora on Askbot, is that we chose not to host per-language subsites. Instead, we’ve leveraged Discourse categories and user-groups to support languages.

When you login for the first time, you will only see the general categories:

  • Start here!
  • Community
  • Site Feedback

These are common to all users. Based on interest from the community, and after verifying that we had community members willing to oversee these languages, the new AskFedora currently supports English, Spanish, Italian, and Persian. Here is how:

Each language has an associated user-group. All users can join and leave these language user-groups at any time. Membership to each user-group gives access to “translated” categories, i.e., identical categories set up for users of the particular language group. Users can join as many language groups as they wish!

Categories are loosely based on the lifecycle of a Fedora release. The top levels ask the question “what stage of the Fedora life-cycle are you at?”. The next level tries to be more specific to ask something on the lines of “what tool are you using?”. These categories are only meant to help organise the forum somewhat. They are not set in stone, and of course, lots of topics may fit into a multitude of categories. We leave it up to the users of the Forum to choose the appropriate category for their query.

  • Announcements (for each language group: can be used by regional teams, for example)
  • Installing Fedora
    • “General” for standard installations using Anaconda with near to default settings, and “Advanced” for more complex use cases such as kickstarts. 
    • A “Hardware” category dedicated for queries related to hardware support.
  • Customising a Fedora installation: for queries related to personalisation:
    • Either “General” for simpler tasks like changing defaults and so on mostly using tools provided by the community or “Advanced” for well, anything else really.
  • Using Fedora, with subcategories for the different platforms that Fedora runs on:
    • Desktops/Servers/Containers/Cloud/Others.
  • Upgrading a Fedora installation:
    • Either using the supported methods: DNF and DNF based methods; or any other ways that we tend to cook up each cycle.

So, when you do login, please do go to the “Start here” category as the banner requests. We have a topic in each supported language documenting what we’ve written here—how to join the appropriate language group and get started.

Feedback and next steps

At this time, we are only announcing the new instance to the community. Hence, this post on the community blog first. The forum will be announced to the wider user-base on the Fedora magazine a week or two later. This gives us time to have a set of community members on the forum already to help end-users when they do get started. This also gives us time to collect feedback from the community and make tweaks to improve the user-experience before the “official launch”. Please use the “Site Feedback” category to drop us comments. Before the forum is announced to the wider audience, we will also update the URL to use https://ask.fedoraproject.org and a redirect from https://askbeta.fedoraproject.org will be put in place to ensure a smooth transition for current users.

The usual reminders

The forum (all forums, channels) are extensions of the Fedora community. They are tools that enable us to communicate with each other. Therefore, everything that occurs on these must follow our Code of Conduct. In short, please remember to “be excellent to each other“. There will always be disagreements, and us being us, tempers will flare. However, before you type out a reply, repeat to your self: “be excellent to each other” again and again, until your draft has lost its aggression/annoyance/negative connotations. This also applies to trolling—even when pointing it out, let’s stay excellent to each other. If you need any help, the forum staff are always there to step in—just drop us a message.

As a closing word, we’re grateful to everyone that put the work in to make this refresh happen—especially the Askbot developers that have hosted AskFedora for us till now, and the Discourse team that will host it for us from now. It has taken quite a few hours of discussion, planning, and work to set things up the way we felt it would help users most. All of this happened on the Fedora Join SIG’s pagure project. We are always looking for more hands to help, and we are even happier if we can pass on some of what we have learned in our time in the Fedora community to other members. Please, do get in touch!

The post AskFedora refresh: we’ve moved to Discourse! appeared first on Fedora Community Blog.

Powered by WPeMatico

Share Button

Peter Hutterer: Using hexdump to print binary protocols

Share Button

I had to work on an image yesterday where I couldn’t install anything and the amount of pre-installed tools was quite limited. And I needed to debug an input device, usually done with libinput record. So eventually I found that hexdump supports formatting of the input bytes but it took me a while to figure out the right combination. The various resources online only got me partway there. So here’s an explanation which should get you to your results quickly.

By default, hexdump prints identical input lines as a single line with an asterisk (‘*’). To avoid this, use the -v flag as in the examples below.

hexdump’s format string is single-quote-enclosed string that contains the count, element size and double-quote-enclosed printf-like format string. So a simple example is this:


$ hexdump -v -e '1/2 "%dn"'
-11643
23698
0
0
-5013
6
0
0

This prints 1 element (‘iteration’) of 2 bytes as integer, followed by a linebreak. Or in other words: it takes two bytes, converts it to int and prints it. If you want to print the same input value in multiple formats, use multiple -e invocations.


$ hexdump -v -e '1/2 "%d "' -e '1/2 "%xn"'
-11568 d2d0
23698 5c92
0 0
0 0
6355 18d3
1 1
0 0

This prints the same 2-byte input value, once as decimal signed integer, once as lowercase hex. If we have multiple identical things to print, we can do this:


$ hexdump -v -e '2/2 "%6d "' -e '" hex:"' -e '4/1 " %x"' -e '"n"'
-10922 23698 hex: 56 d5 92 5c
0 0 hex: 0 0 0 0
14879 1 hex: 1f 3a 1 0
0 0 hex: 0 0 0 0
0 0 hex: 0 0 0 0
0 0 hex: 0 0 0 0

Which prints two elements, each size 2 as integers, then the same elements as four 1-byte hex values, followed by a linebreak. %6d is a standard printf instruction and documented in the manual.

Let’s go and print our protocol. The struct representing the protocol is this one:


struct input_event {
#if (__BITS_PER_LONG != 32 || !defined(__USE_TIME_BITS64)) && !defined(__KERNEL__)
struct timeval time;
#define input_event_sec time.tv_sec
#define input_event_usec time.tv_usec
#else
__kernel_ulong_t __sec;
#if defined(__sparc__) && defined(__arch64__)
unsigned int __usec;
#else
__kernel_ulong_t __usec;
#endif
#define input_event_sec __sec
#define input_event_usec __usec
#endif
__u16 type;
__u16 code;
__s32 value;
};

So we have two longs for sec and usec, two shorts for type and code and one signed 32-bit int. Let’s print it:


$ hexdump -v -e '"E: " 1/8 "%u." 1/8 "%06u" 2/2 " %04x" 1/4 "%5dn"' /dev/input/event22
E: 1553127085.097503 0002 0000 1
E: 1553127085.097503 0002 0001 -1
E: 1553127085.097503 0000 0000 0
E: 1553127085.097542 0002 0001 -2
E: 1553127085.097542 0000 0000 0
E: 1553127085.108741 0002 0001 -4
E: 1553127085.108741 0000 0000 0
E: 1553127085.118211 0002 0000 2
E: 1553127085.118211 0002 0001 -10
E: 1553127085.118211 0000 0000 0
E: 1553127085.128245 0002 0000 1

And voila, we have our structs printed in the same format evemu-record prints out. So with nothing but hexdump, I can generate output I can then parse with my existing scripts on another box.

Powered by WPeMatico

Share Button

Ben Williams: F29-20190319 updated Live isos released

Share Button

The Fedora Respins SIG is pleased to announce the latest release of Updated F29-20190319 Live ISOs, carrying the 4.20.16-200 kernel.

This set of updated isos will save considerable amounts  of updates after install.  ((for new installs.)(New installs of Workstation have 1.2GB of updates)).

This set also includes a updated iso of the Security Lab. 

A huge thank you goes out to irc nicks dowdle, Southern-Gentlem for testing these iso.

We would also like to thank Fedora- QA  for running the following Tests on our ISOs.:

Powered by WPeMatico

Share Button

Fedora Magazine: 4 cool terminal multiplexers

Share Button

The Fedora OS is comfortable and easy for lots of users. It has a stunning desktop that makes it easy to get everyday tasks done. Under the hood is all the power of a Linux system, and the terminal is the easiest way for power users to harness it. By default terminals are simple and somewhat limited. However, a terminal multiplexer allows you to turn your terminal into an even more incredible powerhouse. This article shows off some popular terminal multiplexers and how to install them.

Why would you want to use one? Well, for one thing, it lets you logout of your system while leaving your terminal session undisturbed. It’s incredibly useful to logout of your console, secure it, travel somewhere else, then remotely login with SSH and continue where you left off. Here are some utilities to check out.

One of the oldest and most well-known terminal multiplexers is screen. However, because the code is no longer maintained, this article focuses on more recent apps. (“Recent” is relative — some of these have been around for years!)

Tmux

The tmux utility is one of the most widely used replacements for screen. It has a highly configurable interface. You can program tmux to start up specific kinds of sessions based on your needs. You’ll find a lot more about tmux in this article published earlier:

Already a tmux user? You might like this additional article on making your tmux sessions more effective.

To install tmux, use the sudo command along with dnf, since you’re probably in a terminal already:

$ sudo dnf install tmux

To start learning, run the tmux command. A single pane window starts with your default shell. Tmux uses a modifier key to signal that a command is coming next. This key is Ctrl+B by default. If you enter Ctrl+B, C you’ll create a new window with a shell in it.

Here’s a hint: Use Ctrl+B, ? to enter a help mode that lists all the keys you can use. To keep things simple, look for the lines starting with bind-key -T prefix at first. These are keys you can use right after the modifier key to configure your tmux session. You can hit Ctrl+C to exit the help mode back to tmux.

To completely exit tmux, use the standard exit command or Ctrl+D keystroke to exit all the shells.

Dvtm

You might have recently seen the Magazine article on dwm, a dynamic window manager. Like dwm, dvtm is for tiling window management — but in a terminal. It’s designed to adhere to the legacy UNIX philosophy of “do one thing well” — in this case managing windows in a terminal.

Installing dvtm is easy as well. However, if you want the logout functionality mentioned earlier, you’ll also need the abduco package which handles session management for dvtm.

$ sudo dnf install dvtm abduco

The dvtm utility has many keystrokes already mapped to allow you to manage windows in the terminal. By default, it uses Ctrl+G as its modifier key. This keystroke tells dvtm that the following character is going to be a command it should process. For instance, Ctrl+G, C creates a new window and Ctrl+G, X removes it.

For more information on using dvtm, check out the dvtm home page which includes numerous tips and get-started information.

Byobu

While byobu isn’t truly a multiplexer on its own — it wraps tmux or even the older screen to add functions — it’s worth covering here too. Byobu makes terminal multiplexers better for novices, by adding a help menu and window tabs that are slightly easier to navigate.

Of course it’s available in the Fedora repos as well. To install, use this command:

$ sudo dnf install byobu

By default the byobu command runs screen underneath, so you might want to run byobu-tmux to wrap tmux instead. You can then use the F9 key to open up a help menu for more information to help you get started.

Mtm

The mtm utility is one of the smallest multiplexers you’ll find. In fact, it’s only about 1000 lines of code! You might find it helpful if you’re in a limited environment such as old hardware, a minimal container, and so forth. To get started, you’ll need a couple packages.

$ sudo dnf install git ncurses-devel make gcc

Then clone the repository where mtm lives:

$ git clone https://github.com/deadpixi/mtm.git

Change directory into the mtm folder and build the program:

$ make

You might receive a few warnings, but when you’re done, you’ll have the very small mtm utility. Run it with this command:

$ ./mtm

You can find all the documentation for the utility on its GitHub page.

These are just some of the terminal multiplexers out there. Got one you’d like to recommend? Leave a comment below with your tips and enjoy building windows in your terminal!


Photo by Michael on Unsplash.

Powered by WPeMatico

Share Button

4 cool terminal multiplexers

Share Button

The Fedora OS is comfortable and easy for lots of users. It has a stunning desktop that makes it easy to get everyday tasks done. Under the hood is all the power of a Linux system, and the terminal is the easiest way for power users to harness it. By default terminals are simple and somewhat limited. However, a terminal multiplexer allows you to turn your terminal into an even more incredible powerhouse. This article shows off some popular terminal multiplexers and how to install them.

Why would you want to use one? Well, for one thing, it lets you logout of your system while leaving your terminal session undisturbed. It’s incredibly useful to logout of your console, secure it, travel somewhere else, then remotely login with SSH and continue where you left off. Here are some utilities to check out.

One of the oldest and most well-known terminal multiplexers is screen. However, because the code is no longer maintained, this article focuses on more recent apps. (“Recent” is relative — some of these have been around for years!)

Tmux

The tmux utility is one of the most widely used replacements for screen. It has a highly configurable interface. You can program tmux to start up specific kinds of sessions based on your needs. You’ll find a lot more about tmux in this article published earlier:

Already a tmux user? You might like this additional article on making your tmux sessions more effective.

To install tmux, use the sudo command along with dnf, since you’re probably in a terminal already:

$ sudo dnf install tmux

To start learning, run the tmux command. A single pane window starts with your default shell. Tmux uses a modifier key to signal that a command is coming next. This key is Ctrl+B by default. If you enter Ctrl+B, C you’ll create a new window with a shell in it.

Here’s a hint: Use Ctrl+B, ? to enter a help mode that lists all the keys you can use. To keep things simple, look for the lines starting with bind-key -T prefix at first. These are keys you can use right after the modifier key to configure your tmux session. You can hit Ctrl+C to exit the help mode back to tmux.

To completely exit tmux, use the standard exit command or Ctrl+D keystroke to exit all the shells.

Dvtm

You might have recently seen the Magazine article on dwm, a dynamic window manager. Like dwm, dvtm is for tiling window management — but in a terminal. It’s designed to adhere to the legacy UNIX philosophy of “do one thing well” — in this case managing windows in a terminal.

Installing dvtm is easy as well. However, if you want the logout functionality mentioned earlier, you’ll also need the abduco package which handles session management for dvtm.

$ sudo dnf install dvtm abduco

The dvtm utility has many keystrokes already mapped to allow you to manage windows in the terminal. By default, it uses Ctrl+G as its modifier key. This keystroke tells dvtm that the following character is going to be a command it should process. For instance, Ctrl+G, C creates a new window and Ctrl+G, X removes it.

For more information on using dvtm, check out the dvtm home page which includes numerous tips and get-started information.

Byobu

While byobu isn’t truly a multiplexer on its own — it wraps tmux or even the older screen to add functions — it’s worth covering here too. Byobu makes terminal multiplexers better for novices, by adding a help menu and window tabs that are slightly easier to navigate.

Of course it’s available in the Fedora repos as well. To install, use this command:

$ sudo dnf install byobu

By default the byobu command runs screen underneath, so you might want to run byobu-tmux to wrap tmux instead. You can then use the F9 key to open up a help menu for more information to help you get started.

Mtm

The mtm utility is one of the smallest multiplexers you’ll find. In fact, it’s only about 1000 lines of code! You might find it helpful if you’re in a limited environment such as old hardware, a minimal container, and so forth. To get started, you’ll need a couple packages.

$ sudo dnf install git ncurses-devel make gcc

Then clone the repository where mtm lives:

$ git clone https://github.com/deadpixi/mtm.git

Change directory into the mtm folder and build the program:

$ make

You might receive a few warnings, but when you’re done, you’ll have the very small mtm utility. Run it with this command:

$ ./mtm

You can find all the documentation for the utility on its GitHub page.

These are just some of the terminal multiplexers out there. Got one you’d like to recommend? Leave a comment below with your tips and enjoy building windows in your terminal!


Photo by Michael on Unsplash.

Powered by WPeMatico

Share Button

Kiwi TCMS: Kiwi TCMS 6.6

Share Button

We’re happy to announce Kiwi TCMS version 6.6! This is a
medium severity security update, improvement and bug-fix update.
You can explore everything at
https://demo.kiwitcms.org!

Supported upgrade paths:

5.3   (or older) -> 5.3.1
5.3.1 (or newer) -> 6.0.1
6.0.1            -> 6.1
6.1              -> 6.1.1
6.1.1            -> 6.2 (or newer)

Docker images:

kiwitcms/kiwi       latest  c4734f98ca37    971.3 MB
kiwitcms/kiwi       6.2     7870085ad415    957.6 MB
kiwitcms/kiwi       6.1.1   49fa42ddfe4d    955.7 MB
kiwitcms/kiwi       6.1     b559123d25b0    970.2 MB
kiwitcms/kiwi       6.0.1   87b24d94197d    970.1 MB
kiwitcms/kiwi       5.3.1   a420465852be    976.8 MB

Changes since Kiwi TCMS 6.5.3

Security

  • Explicitly require marked v0.6.1 to fix medium severity ReDoS vulnerability. See
    SNYK-JS-MARKED-73637

Improvements

  • Update python-gitlab from 1.7.0 to 1.8.0
  • Update django-contrib-comments from 1.9.0 to 1.9.1
  • More strings marked as translatable (Christophe CHAUVET)
  • When creating new TestCase you can now change notification settings.
    Previously this was only possible during editing
  • Document import-export approaches. Closes
    Issue #795
  • Document available test automation plugins
  • Improve documentation around Docker customization and SSL termination
  • Add documentation example of reverse rroxy configuration for HAProxy (Nicolas Auvray)
  • TestPlan.add_case() will now set the sortkey to highest in plan + 10 (Rik)
  • Add LinkOnly issue tracker. Fixes
    Issue #289
  • Use the same HTML template for both TestCase new & edit
  • New API methods for adding, removing and listing attachments. Fixes
    Issue #446:

    • TestPlan.add_attachment()
    • TestCase.add_attachment()
    • TestPlan.list_attachments()
    • TestCase.list_attachments()
    • Attachments.remove_attachment()

Database migrations

  • Populate missing TestCase.text history.
    In version 6.5 the TestCase model was updated to store the text
    into a single field called text instead of 4 separate fields.
    During that migration historical records were updated to have
    the new text field but values were not properly assigned.

    The “effect” of this is that in TestCaseRun records you were not
    able to see the actual text b/c it was None.

    This change ammends 0006_merge_text_field_into_testcase_model for
    installations which have not yet migrated to 6.5 or later. We also
    provide the data-only migration 0009_populate_missing_text_history
    which will inspect the current state of the DB and copy the text to
    the last historical record.

Removed functionality

  • Remove legacy reports. Closes
    Issue #657

  • Remove “Save & Continue” functionality from TestCase edit page

  • Renamed API methods:

    • TestCaseRun.add_log() -> TestCaseRun.add_link()
    • TestCaseRun.remove_log() -> TestCaseRun.remove_link()
    • TestCaseRun.get_logs() -> TestCaseRun.get_links()

    These methods work with URL links, which can be added or removed to
    test case runs.

Bug fixes

  • Remove hard-coded timestamp in TestCase page template, References
    Issue #765
  • Fix handling of ?from_plan URL parameter in TestCase page
  • Make TestCase.text occupy 100% width when rendered. Fixes
    Issue #798
  • Enable markdown.extensions.tables. Fixes
    Issue #816
  • Handle form erros and default values for TestPlan new/edit. Fixes
    Issue #864
  • Tests + fix for failing TestCase rendering in French
  • Show color-coded statuses on dashboard page when seen with non-English
    language
  • Refactor check for confirmed test cases when editting to work with
    translations
  • Fix form values when filtering test cases inside TestPlan. Fixes
    Issue #674 (@marion2016)
  • Show delete icon for attachments. Fixes
    Issue #847

Refactoring

  • Remove unused .current_user instance attribute
  • Remove EditCaseForm and use NewCaseForm instead, References
    Issue #708,
    Issue #812
  • Fix “Select All” checkbox. Fixes
    Issue #828 (Rady)

Translations

How to upgrade

If you are using Kiwi TCMS as a Docker container then:

cd Kiwi/
git pull
docker-compose down
docker pull kiwitcms/kiwi
docker pull centos/mariadb
docker-compose up -d
docker exec -it kiwi_web /Kiwi/manage.py migrate

Don’t forget to backup
before upgrade!

WARNING: kiwitcms/kiwi:latest and docker-compose.yml will
always point to the latest available version! If you have to upgrade in steps,
e.g. between several intermediate releases, you have to modify the above workflow:

# starting from an older Kiwi TCMS version
docker-compose down
docker pull kiwitcms/kiwi:
edit docker-compose.yml to use kiwitcms/kiwi:
docker-compose up -d
docker exec -it kiwi_web /Kiwi/manage.py migrate
# repeat until you have reached latest

Happy testing!

Powered by WPeMatico

Share Button

Red Hat Security: The Product Security Blog has moved!

Share Button

Red Hat Product Security has joined forces with other security teams inside Red Hat to publish our content in a common venue using the Security channel of the Red Hat Blog. This move provides a wider variety of important Security topics, from experts all over Red Hat, in a more modern and functional interface. We hope everyone will enjoy the new experience!


English

Category

Secure

Tags

security

Powered by WPeMatico

Share Button

Michael Catanzaro: Epiphany Technology Preview Upgrade Requires Manual Intervention

Share Button

Jan-Michael has recently changed Epiphany Technology Preview to use a separate app ID. Instead of org.gnome.Epiphany, it will now be org.gnome.Epiphany.Devel, to avoid clashing with your system version of Epiphany. You can now have separate desktop icons for both system Epiphany and Epiphany Technology Preview at the same time.

Because flatpak doesn’t provide any way to rename an app ID, this means it’s the end of the road for previous installations of Epiphany Technology Preview. Manual intervention is required to upgrade. Fortunately, this is a one-time hurdle, and it is not hard:

$ flatpak uninstall org.gnome.Epiphany

Uninstall the old Epiphany…

$ flatpak install gnome-apps-nightly org.gnome.Epiphany.Devel org.gnome.Epiphany.Devel.Debug

…install the new one, assuming that your remote is named gnome-apps-nightly (the name used locally may differ), and that you also want to install debuginfo to make it possible to debug it…

$ mv ~/.var/app/org.gnome.Epiphany ~/.var/app/org.gnome.Epiphany.Devel

…and move your personal data from the old app to the new one.

Then don’t forget to make it your default web browser under System Settings -> Details -> Default Applications. Thanks for testing Epiphany Technology Preview!

Powered by WPeMatico

Share Button

Roland Wolters: Of debugging Ansible Tower and underlying cloud images

Share Button

Ansible Logo

Recently I was experimenting with Tower’s isolated nodes feature – but somehow it did not work in my environment. Debugging told me a lot about Ansible Tower – and also why you should not trust arbitrary cloud images.

Background – Isolated Nodes

Ansible Tower has a nice feature called “isolated nodes”. Those are dedicated Tower instances which can manage nodes in separated environments – basically an Ansible Tower Proxy.

An Isolated Node is an Ansible Tower node that contains a small piece of software for running playbooks locally to manage a set of infrastructure. It can be deployed behind a firewall/VPC or in a remote datacenter, with only SSH access available. When a job is run that targets things managed by the isolated node, the job and its environment will be pushed to the isolated node over SSH, where it will run as normal.

Ansible Tower Feature Spotlight: Instance Groups and Isolated Nodes

Isolated nodes are especially handy when you setup your automation in security sensitive environments. Think of DMZs here, of network separation and so on.

I was fooling around with a clustered Tower installation on RHEL 7 VMs in a cloud environment when I run into trouble though.

My problem – Isolated node unavailable

Isolated nodes – like instance groups – have a status inside Tower: if things are problematic, they are marked as unavailable. And this is what happened with my instance isonode.remote.example.com running in my lab environment:

Ansible Tower showing an instance node as unavailable

I tried to turn it “off” and “on” again with the button in the control interface. It made the node available, it was even able to executed jobs – but it became quickly unavailable soon after.

Analysis

So what happened? The Tower logs showed a Python error:

# tail -f /var/log/tower/tower.log
fatal: [isonode.remote.example.com]: FAILED! => {"changed": false,
"module_stderr": "Shared connection to isonode.remote.example.com
closed.rn", "module_stdout": "Traceback (most recent call last):rn
File "/var/lib/awx/.ansible/tmp/ansible-tmp-1552400585.04
-60203645751230/AnsiballZ_awx_capacity.py", line 113, in rn
_ansiballz_main()rn  File "/var/lib/awx/.ansible/tmp/ansible-tmp
-1552400585.04-60203645751230/AnsiballZ_awx_capacity.py", line 105, in
_ansiballz_mainrn    invoke_module(zipped_mod, temp_path,
ANSIBALLZ_PARAMS)rn  File "/var/lib/awx/.ansible/tmp/ansible-tmp
-1552400585.04-60203645751230/AnsiballZ_awx_capacity.py", line 48, in
invoke_modulern    imp.load_module('__main__', mod, module, MOD_DESC)rn
File "/tmp/ansible_awx_capacity_payload_6p5kHp/__main__.py", line 74, in
rn  File "/tmp/ansible_awx_capacity_payload_6p5kHp/__main__.py",
line 60, in mainrn  File
"/tmp/ansible_awx_capacity_payload_6p5kHp/__main__.py", line 27, in
get_cpu_capacityrnAttributeError: 'module' object has no attribute
'cpu_count'rn", "msg": "MODULE FAILUREnSee stdout/stderr for the exact
error", "rc": 1}

PLAY RECAP *********************************************************************
isonode.remote.example.com : ok=0    changed=0    unreachable=0    failed=1  

Apparently a Python function was missing. If we check the code we see that indeed in line 27 of file awx_capacity.py the function psutil.cpu_count() is called:

def get_cpu_capacity():
    env_forkcpu = os.getenv('SYSTEM_TASK_FORKS_CPU', None)
    cpu = psutil.cpu_count()

Support for this function was added in version 2.0 of psutil:

2014-03-10
Enhancements
424: [Windows] installer for Python 3.X 64 bit.
427: number of logical and physical CPUs (psutil.cpu_count()).

psutil history

Note the date here: 2014-03-10 – pretty old! I check the version of the installed package, and indeed the version was pre-2.0:

$ rpm -q --queryformat '%{VERSION}n' python-psutil
1.2.1

To be really sure and also to ensure that there was no weird function backporting, I checked the function call directly on the Tower machine:

# python
Python 2.7.5 (default, Sep 12 2018, 05:31:16) 
[GCC 4.8.5 20150623 (Red Hat 4.8.5-36)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import inspect
>>> import psutil as module
>>> functions = inspect.getmembers(module, inspect.isfunction)
>>> functions
[('_assert_pid_not_reused', ), ('_deprecated', ),
('_wraps', ), ('avail_phymem', ), ('avail_virtmem', ), ('cached_phymem', ), ('cpu_percent', ),
('cpu_times', ), ('cpu_times_percent',
), ('disk_io_counters',
), ('disk_partitions', ), ('disk_usage', ), ('get_boot_time', ), ('get_pid_list', ),
('get_process_list', ),
('get_users', ), ('namedtuple',
), ('net_io_counters', ), ('network_io_counters', ), ('phymem_buffers', ), ('phymem_usage', ), ('pid_exists', ),
('process_iter', ), ('swap_memory',
), ('test', ), ('total_virtmem', ), ('used_phymem', ),
('used_virtmem', ), ('virtmem_usage',
), ('virtual_memory', ), ('wait_procs', )]

Searching for a package origin

So how to solve this issue? My first idea was to get this working by updating the entire code part to the multiprocessor lib:

# python
Python 2.7.5 (default, Sep 12 2018, 05:31:16) 
[GCC 4.8.5 20150623 (Red Hat 4.8.5-36)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import multiprocessing
>>> cpu = multiprocessing.cpu_count()
>>> cpu
4

But while I was filling a bug report I wondered why RHEL shipped such an ancient library. After all, RHEL 7 was released in June 2014, and psutil had cpu_count available since early 2014! And indeed, a quick search for the package via the Red Hat package search showed a weird result: python-psutil was never part of base RHEL 7! It was only shipped as part of some very, very old OpenStack channels:

access.redhat.com package search, results for python-psutil

Newer OpenStack channels in fact come along with newer versions of python-psutil.

So how did this outdated package end up on this RHEL 7 image? Why was it never updated?

The cloud image is to blame! The package was installed on it – most likely during the creation of the image: python-psutil is needed for OpenStack Heat, so I assume that these RHEL 7 images where once created via OpenStack and then used as the default image in this demo environment.

And after the initial creation of the image the Heat packages were forgotten. In the meantime the image was updated to newer RHEL versions, snapshots were created as new defaults and so on. But since the package in question was never part of the main RHEL repos, it was never changed or removed. It just stayed there. Waiting, apparently, for me 😉

Conclusion

This issue showed me how tricky cloud images can be. Think about your own cloud images: have you really checked all all of them and verified that no package, no start up script, no configuration was changed from the Linux distribution vendor’s base setup?

With RPMs this is still manageable, you can track if packages are installed which are not present in the existing channels. But did someone install something with pip? Or any other way?

Take my case: an outdated version of a library was called instead of a much, much more recent one. If there would have been a serious security issue with the library in the meantime, I would have been exposed although my update management did not report any library to be updated.

I learned my lesson to be more critical with cloud images, checking them in more detail in the future to avoid having nasty surprises during production. And I can just recommend that you do that as well.

Advertisements

Powered by WPeMatico

Share Button