Fedora 25

This evening I arrived home from work and began to update my machines to the latest version of Fedora. I am pleased to say the update has gone smoothly. This has been the easiest update I think I have had in recent years.

Now the bad. Wayland has become the default display server replacing X11. It works, by which I mean I have a usable display. The bad is that it has broken my workflow. I have a few simple scripts that tweak my environment. These have always loaded when the display server starts. Ok, how do I do this with Wayland? I did some reading. The issue has been known about for 2 years, Bug 736660. The workaround for the moment is to logout and then log in with an X11 session. Logging into the X11 session everything works again and I can continue. Hopefully issues like this will get resolved quickly.

Fedora 24

This week I have been updating my machines to run Fedora 24. Two out of 3 updated without any issues and continue to run normally. One machine however has decided to cause me some issues.

My old Toshiba X200 laptop had followed the upgrade instructions to the point where it needed to reboot. So I rebooted the machine and left it to do its work. Returning some time later expecting it to have completed I was disappointed to see it stuck doing nothing. After some investigation it appeared I was getting an error to do with an Invalid PCI ROM Header, the value didn't match what was expected. I couldn't boot the machine without this occurring and left me scratching my head for a bit. There doesn't appear to be an obvious solution online. Others have reported similar issues but apart from seeing the error their machines have fully booted.

I decided to try adding a few flags to my kernel boot parameters. Finally I go one to work. Adding "pci=norom" seems to have done the trick and allowed the machine to continue to update. I won't know until the upgrade is complete if I will need to add this option back in permanently. But hopefully it won't be anything more than that.

Termux – Custom Prompt

Termux is a terminal emulator and Linux environment for Android. I wanted to customise my prompt in the same way that I have done on my desktop/laptop machines. Ordinarily I would have a .bashrc in my home directory where I would make the changes to the prompt (PS1). However Termux doesn't recognise this.

I found a reference to configuring this: http://blog.ataboydesign.com/2015/12/01/termux-is-the-one-for-android/

Following this method the changes to PS1 are made in "/data/data/com.termux/files/usr/etc/bash.bashrc". I had been successfully using this method for a while with no ill effects. That was until today when I realised an update to Termux had overwritten the changes. Not what I wanted.

So after some searching I have found a solution that should survive future updates. In your Termux home directory save the following as ".profile". This will be run when Termux is started and make Termux look for a ".bashrc" file in the home directory.

# .profile
if [ -n "BASH_VERSION" ]; then
  # Echo msg to indicate file is run - can be removed later
  echo "Profile load.bashrc"
  # include .bashrc if it exists
  if [ -f "$HOME/.bashrc" ]; then
  . "$HOME/.bashrc"
  fi
fi

Create and edit ".bashrc" with any custom options. Exit and restart Termux and your custom configuration should be loaded.

Bash Exploit

Bash Code Injection Vulnerability via Specially Crafted Environment Variables (CVE-2014-6271, CVE-2014-7169)
https://access.redhat.com/node/1200223

Well I read this article whilst I was at work. Upon getting home I started up my Fedora machine and ran the following check to see if I was vulnerable.

To test if your version of Bash is vulnerable to this issue, run the following command:

$ env x='() { :;}; echo vulnerable' bash -c "echo this is a test"

If the output of the above command looks as follows:

vulnerable
this is a test

you are using a vulnerable version of Bash. The patch used to fix this issue ensures that no code is allowed after the end of a Bash function. Thus, if you run the above example with the patched version of Bash, you should get an output similar to:

$ env x='() { :;}; echo vulnerable' bash -c "echo this is a test"
bash: warning: x: ignoring function definition attempt
bash: error importing function definition for `x'
this is a test

I was vulnerable. But that is what I expected. Knowing that the fix might take a little time I added the suggested workaround to my firewall script.

Workaround: Using IPTables:

A note on using IPTables string matching:

iptables using -m string --hex-string '|28 29 20 7B|'

Is not a good option because the attacker can easily send one or two characters per packet and avoid this signature easily. However, it may provide an overview of automated attempts at exploiting this vulnerability.

In full knowledge that this vulnerability was/is going to get exploited I was monitoring my firewall logs. I had set the rules to log and drop the packets. Note that the work around says it can be bypassed. A couple of hours with the rule in place and nothing unusuall was being logged and I was carrying on as normal. All of a sudden 4-5 packets were caught by the rule. My system was shutdown seconds later. I susspect that this is some opportunistic scanning taking place, however I am not taking any chances until a patch is ready.

On the plus side it has given me the opportunity to boot and update my Windows machine.

Cooling Things Down

Summer is approaching and the weather is getting slowly warmer. This brings with it the annual problem of having a computer in the bedroom kicking out heat and making it too warm. Another issue that had been causing me some bother for a few years is the power settings on my graphics card, a Radeon HD6850, when running Linux. I use the open source radeon driver as keeps improving overtime and has enough of the performance of the closed source official driver for my needs. The one thing that has been lacking in my particular case has been the dynamic adjustment (radeon.dpm) of the card to keep it running cool. I have been forced to manually set the card to a low power state each time I reboot the machine. Failing to do this means the card boots up running full speed and quite happy to warm the place up. The downside is that I am always in the low power state and any tasks that might make use of a bit of extra power never get it unless its specifically enabled.

Today was time for a bit of research and a test. I had a Radeon 7850 in my other machine and decided to swap them over. It means that I have a weaker card for gaming on Windows but I don't play that many games and out of the two machines it is the one next due an upgrade. So has it made a difference? The simple answer is yes. I found that after rebooting the Linux machine with the HD7850 that it had automatically switched to using the dynamic adjustments and all was working well, one problem solved.

The heat output was the thing I really wanted to improve and I am pleased to also report a successful change (results below). I am happy with a slight decrease in temperatures along side the enabling dynamic adjustment. I continued to experiment and discovered that it can get even better. I have 2 24" Dell monitors and these can both kick out a bit of heat. Whilst I like a dual screen setup I often switch to just one (mainly to boot the Windows machine on the other). Driving just a single monitor I have noticed a further drop in temperatures (results below). This apparent temperature drop with a single monitor was not noticed when using the HD6850.

Test Conditions:
- Ambient Temperature: 22C
- System settled on normal desktop, no user activity.
- 2 connected displays @ 1920x1200

Before (HD6850 in Low Power Mode):
- GPU Temp: 65.0C
- CPU Temp: 41.4C

After (HD7850 radeon.dpm=1 balanced profile dual display):
- GPU Temp: 47.0C
- CPU Temp: 37.1C

After (HD7850 radeon.dpm=1 balanced profile single display):
- GPU Temp: 39.0C
- CPU Temp: 36.0C

An upgrade to some slightly newer, better driver supported hardware can result in a gpu temperature drop of around 18-26C (depending on setup). It might not make a huge improvement in room temperature alone, but it is a step in the right direction.

Tmux – Solving The Problem Of Window Names

I was lucky enough to get a book on using tmux for Christmas. Following through the examples I noticed that I was not getting the expected behaviour when attempting to set window names.

Commandline

1
$ tmux new-window -n console

What this should do is create a new tmux window and within it a window called "console". What I was getting was a tmux window containing a window named after my command prompt e.g. 'bob@computer ~'. This was bothering me so I set about researching the problem, unluckily for me its not one that is that common. By chance I located a post linking to a RedHat bug report https://bugzilla.redhat.com/show_bug.cgi?id=969429. The report outlines a problem regarding a change in terminal escape codes and highlighted an identical problem with screen as I am having with tmux. I checked the escape codes in my .bashrc file, nothing wrong there. Next stop was /etc/bashrc.

/etc/bashrc

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
  if [ -z "$PROMPT_COMMAND" ]; then
    case $TERM in
    xterm*|vte*)
      if [ -e /etc/sysconfig/bash-prompt-xterm ]; then
          PROMPT_COMMAND=/etc/sysconfig/bash-prompt-xterm
      elif [ "${VTE_VERSION:-0}" -ge 3405 ]; then
          PROMPT_COMMAND="__vte_prompt_command"
      else
          PROMPT_COMMAND='printf "\033]0;%s@%s:%s\007" "${USER}" "${HOSTNAME%%.*}" "${PWD/#$HOME/~}"'
      fi
      ;;
    screen*)
      if [ -e /etc/sysconfig/bash-prompt-screen ]; then
          PROMPT_COMMAND=/etc/sysconfig/bash-prompt-screen
      else
          PROMPT_COMMAND='printf "\033k%s@%s:%s\033\\" "${USER}" "${HOSTNAME%%.*}" "${PWD/#$HOME/~}"'
      fi
      ;;
    *)
      [ -e /etc/sysconfig/bash-prompt-default ] && PROMPT_COMMAND=/etc/sysconfig/bash-prompt-default
      ;;
    esac
  fi

/etc/bashrc contained the above code section. It comprises two different sections for different terminals, each has its own prompt with different escape codes. The but report highlighted that the problem lay with the 033k escape code where as 033]0 worked. I should only be using the problematic escape code if I am using a screen terminal. So which am I using?

Commandprompt

1
$ echo $TERM

The result from running the above command in my gnome-terminal was "xterm-256color". This was expected and what I assumed I was using. Running it from inside a tmux session I got "screen-256color". Tmux using a screen terminal is pointing back to the problematic escape code. Time to go back to the .tmux.conf and check my settings.

.tmux.conf

1
2
# Use 256 term colours
set -g default-terminal "screen-256color"

There is my problem line, I have set it to use the screen terminal, oops.

.tmux.conf - Correct

1
2
# Use 256 term colours
set -g default-terminal "xterm-256color"

By using the xterm-256color terminal I correct the problem with the escape code. Rerunning my initial tmux command tmux opens with a window named 'console'. Problem solved.

Fedora 19 – Initial Impressions

I have just upgraded both my laptop and desktop machines to Fedora 19. Having had a few issues with the past couple of releases this upgrade has been almost flawless. The only issue I have noticed so far is some missing fonts/images for the grub 2 bootloader but everything works otherwise.

The biggest improvement from my point of view is in graphics performance. I have an ATI card running the opensource radeon driver. I had noticed stuttering during video playback on Fedora 17 & 18. This release however it has vanished and smooth video has returned. So far so good.

Update:

/boot/grub2/themes/system/DejeVuSans-10.pf2 not found
/boot/grub2/themes/system/DejeVuSans-12.pf2 not found
/boot/grub2/themes/system/DejeVuSans-Bold-14pf2 not found

/boot/grub2/themes/system/theme.txt not found

The boot message about grub not finding the fonts or theme is due to the starfield theme nolonger being the default. Install grub2-starfield-theme and then it works as before. The default for new installs appears to be a plain console theme.

Keeping My Hat On

In my previous post I outlined my thinking about moving from Fedora to OpenSuse. I installed OpenSuse 12.3 onto mylaptop and had a play about. The installer was clean and easy to use and everything was setup with the minimum of effort.

Two issues with Fedora prompting a move were the control over the firewall and the Arduino software not being up to date. I was disappointed to that the installation of the Arduino software didn't come with a desktop icon setup but the latest version was there to use. Now onto the firewall; things were not good.

OpenSuse has completely removed the iptables scripts for managing the firewall. It seems you will use their firewall daemon and associated setup program. So basically the future looks like I will be being forced into using a wrapper of some sort around the iptables rules for my firewall. What's more, after doing some reading it would appear that more applications will rely on this dynamic functionality in the future. So what do I do? I can, on Fedora at least, use my existing script in the short term but need to migrate it. Alternatively I can change distro, waiting a little longer for the inevitable push towards dynamic firewalls.

Where does this leave me now then? I'm thinking of staying with Fedora at the moment. Fedora 19 will be due out in around 3-4 months time. At this point I think a clean installation of my main machine will probably be in order. In the mean time I can work on migrating my current firewall script over to the Firewalld system. It will mean I have to manually install the latest Arduino software but that is at least a manageable task.

OpenSuse was removed from the laptop and Fedora 18 reinstalled. A clean installation does appear to have changed a few things. A series of upgrades over the years had left a few legacy options it seems. The Fedora installer was not as user friendly as the OpenSuse installer, especially when it came to creating the dual boot with Windows on a separate hard disk. That said it did install and I'm sure it will improve in the future.