Linux, GPU, games and Google Chrome

Recently, I have been having a few issues with a few games: once in a while, I like to play a bit of FPS to de-stress, and my frame rate was just abysmally low, what used to be a good 60 FPS went down to 20-30, leaving me with barely playable games, although these were great under Linux Mint 17.

After a bit of searching, I have found something interesting: if Google Chrome is running, the frame rate will be bad. If it is not, my games are back to normal. As Google Chrome uses the GPU for various tasks, I guess this was either due to a conflict (the two applications fighting for GPU resources) or Google Chrome setting some parameters that are detrimental to the games. Looking at Google Chrome's GPU status shows that a few features are either disabled or not available.

Upgrade from Mint 18 to Mint 18.1

A few days ago, there were news that Mint 18.1 was out and ready for install. This morning, my update manager prompted me to install the MintUpdate package, a sign that the new version is ready for prime time.

The release notes do not show anything that would affect me, and so far, so good.

The overall feeling is that nothing really changed: visually this is still the same, the system does not seem to be faster or slower.

A good point: the upgrade did not remove my PPA and other additional depots. It was one of the many little things that made me cringe during the update from 17 to 18. It is not very hard to put back (all the information is in ~/Upgrade-Backup/APT/sources.list.d) though.

Comment if you have had any issue.

From Linux Mint 17.3 to 18

Linux Mint 18 has been out for the last few months, and I finally found the time to upgrade my computer.

The upgrade

As suggested, I started by using the Mint 18 ISO as a live USB, simply to make sure that every piece of equipment was supported. My biggest concern was my video card (NVIDIA GeForce 9600 GT, purchased eight years ago). The Live USB went without a hitch and the nouveau driver perfectly managed the card. However, I did not plan to use it: I had too much issues under Fedora and Linux Mint 17.2. Though it was good to know that, if need be, I could use that driver while shopping for a new video card.

The test with the Live USB being okay, I proceeded with the instructions provided by the Linux Mint team. Starting with the "take a backup." That step is often overlooked, but I really recommend it, especially that a TB external hard drive costs less than 100€. As a matter of fact, I have the habit of taking a weekly backup - usually on Friday evening, and whenever I import pictures from my camera. 

The check phase went fine, then the download - which I let run overnight. In the morning, I only had to go for the mintupgrade upgrade command, which performs the actual upgrade.

There, things were a bit less clear cut: several errors and tracebacks appeared related to mono, but it seems okay and can be ignored. However, when the process finished, several packages were reported has not being upgraded due to errors. I reran the upgrade process and the same result appeared. Here are the packages that were not updated:

• cron
• cups-browsed
• cups-daemon
• samba
• rsyslog
• ubuntu-minimal
• irqbalance
• acpid
• avahi-daemon
• avahi-utils
• bluez
• bluetooth
• cups-core-drivers
• cups
• printer-driver-hpcups
• hplip
• printer-driver-postscript-hp
• bluez-cups
• gnome-bluetooth
• gnome-user-share
• libnss-mdns:amd64
• nvidia-340
• nvidia-340-uvm
• printer-driver-gutenprint
• printer-driver-splix
• pulseaudio-module-bluetooth

Looking at the messages, it was pretty much the same for each: either the service could not be/was not restarted and the dpkg --configure failed (for example bluez), or the package depended on such a package (for example bluetooth). I manually ran the corresponding service xx stop / dpkg --configure and everything went fine.

Lastly, when I restarted, I had an issue when I logged in, with the following error message, before disconnecting me.

GLib-CRITICAL: g_key_file_free: assertion 'key_file != NULL' failed

After a few searches, it seems this is a known issue, and a "sudo apt-get purge cinnamon nemo && sudo apt-get install cinnamon" at the console later, I was back in business.

The first half-day

So far, so good. After the first restart, I reapplied the intel-microcode proprietary driver, and I re-added all my repositories and PPA (Google Chrome, Julia, Sagemath and Darktable), which were lost during the upgrade. This is not a major issue, and this was quickly corrected, but a minor annoyance, especially if you have a lot of PPAs and repositories. There is also a pro in not porting over the PPAs: some of the applications may be linked against the older versions of the libraries and might not work anymore after the upgrade, possibly resulting in broken dependencies and other errors.

I had to reboot once, to apply both the microcode driver, but also a kernel update that popped up and was not taken during the upgrade process. Not too bad.

Visually, this version is very clear, and the Mint-X theme is very readable. It is pleasant and easy on the eyes, and while this is something that never struck me as an issue with the 17.3, going to 18 makes a ton of difference.

During my first use, I was surprised: the active application appears highlighted in green in the task bar, which I thought was to request the user's attention. After a minute or so, I got used to it.

From a performance standpoint, I feel it is about the same as my previous Linux Mint 17.3 install. However, my machine is about eight years old and probably not the snappiest thing on earth. 

The aim of my upgrading was to be able to install some more recent applications, especially Julia and Jupyter. For the former, I opted to re-install the PPA instead. For Jupyter, unfortunately, still nothing in the official package. PIP install it is then.

Overall

Everything considered, I am very pleased: while there were a few hiccups, the upgrade went without any major issues and the few kinks I had after reboot were easily fixed. This new version is way clearer and visually easier on the eyes.

The upgrade process is still a bit too chaotic, and the hiccups along the way can be issues for people new to Linux. It is to be noted that upgrading a live system is not the way recommended by the Mint team, which favors using a fresh install. 

Firewalling with iptables

Almost everybody knows what a firewall is. And nobody disputes the need for them in a network design or to protect a host.

Linux has a very powerful firewall: iptables. It is actually more than just a firewall and can perform:

• Filtering
• NAT/PAT
• Packet mangling
• Packet marking

In this post, we will just look at the filtering aspect.

Historically, firewalls have started simply as filters: a firewall would drop or reject a packet based on the source and destination addresses, the protocol used (IP, ICMP, TCP, UDP) and the source and destination ports. However, this proved to have some serious limitations: for instance, an administrator would have had to put all rules both ways, such as

permit TCP 10.0.0.0 255.255.255.0 -> 192.168.0.0 255.255.255.0 port 80

and

permit TCP 192.168.0.0 255.255.255.0 port 80 -> 10.0.0.0 255.255.255.0

This unfortunately has a very serious side effect: any machine on the 192.168.0.0/24 network can access any machine on the 10.0.0.0/24 network on any TCP port, provided that the source is set to 80! 

To address that, certain vendors developed workarounds such as the "established" keyword, which check that the packet doesn't have only the SYN flag. However, while this prevents establishing a session, it still permits someone to scan the inside network by using the same trick as previously and forcing the TCP flags to Ack, Push or anything that is non SYN.

Came the stateful firewalls! The idea is simple: the firewall, having access to the packets, can track the state of each session and allow back only the frames leading to an adjacent valid state. For example, if host 192.168.0.1 has sent a SYN packet to 10.0.0.1 from port 3340 to port 80, the only valid replies are either a "RST" from 10.0.0.1 port 80 to 192.168.0.1 port 3340 (the port 80 on 10.0.0.1 is closed or the connection has been refused), or a SYN-ACK from 10.0.0.1 port 80 to 192.168.0.1 port 3340. In the latter case, the connection is "half open", and the only valid replies are a RST (the connection is being dropped) or an ACK from 192.168.0.1 port 3340 to 10.0.0.1 port 80, at which point the connection is fully open and the data transfer can start.

This brought a slight disadvantage: in order to be able to track the session, the firewall needs to see all the packets. Asymmetric routing is no longer possible and if load balancing between multiple firewalls is needed either the  state tables need to be shared between all the members or the load balancing needs to take the sessions into account.

There is also another issue: if the notion of state is defined for TCP, UDP and ICMP are connectionless, meaning that there is no notion of session. So how to proceed in this case? This usual answer is to consider that the first datagram "opens" the "session", and that anything in return on the same set of ports is to be accepted. For ICMP, it is a bit different: there is no notion of port, so the ICMP Type is used instead. For instance, an ICMP Type 8 indicates an "Echo Request", for which there are only a few valid replies: Type 0 (Echo Reply), Type 3 (Unreachable), Type 4 (Source Quench) or Type 11 (TTL Expired). 

TCP has a mechanism to indicate to a sender that a segment has been received out of state, or that the port is closed, by replying with the RST (reset) flag set. UDP doesn't have the same mechanism, and instead rely on ICMP Type 3 Code 3 ("Port Unreachable") to convey the information.

Okay, now that we set the scene, let's start with iptables.

As I said, iptables is also a firewall. It has a modular design that allows for the quick development and implementation of new protocols and services. More on this a bit later. It operates by using chains: a collection of rules whose possible actions are, for the packet filter, to accept, deny, reject a packet or even call another table. This feature allows an almost "programmatic" view of the rules, with calls and returns, code sharing and so forth.

Let's start with an example.

I have a small web, name and mail server exposed to the Internet. It has directly a public IP so I won't need NAT, and it doesn't provide access to a network: this is purely a server.

It needs to allow SMTP, POP/IMAP, DNS, HTTP and HTTPS access to the Internet, and SSH access only to a small number of IPs. The wish is also that it has a blacklist to put the undesirable IPs and a noise list to suppress the various unsolicited packets generated by neighboring machines (Netbios, DHCP, ...). Lastly, we want to keep track of the various regions as defined by the IANA.

The rule set will look like this:

No panic! It looks way more complex than it really is.

Note: iptables does more than filtering by the use of various tables. The "filter" is one table among many, the others include "nat"for address translation, "mangle" for various operations on packets and "raw" for very, very specialized treatment. In the following, we will use the "filter" table, which is also the default table.

The "filter" table comes with 3 chains:

• INPUT - for packets destined to local sockets
• OUTPUT - for packets locally generated 
• FORWARD - for packets that are routed between two subnets

Our server is not used as a router, so the only chains of concerns are INPUT and OUTPUT. These built-in chains also take a policy: this is the default action to take when none of the rules matches the packet. There are 4 built-in actions:

• ACCEPT - the packet is let through
• DROP - the packet is discarded
• QUEUE - the packet is put in the queue to the userspace. This won't be discussed here.
• RETURN - the process returns to the calling chain

For the INPUT chain,  the only two targets that make sense as a policy are ACCEPT and DROP. This is the equivalent of an implicit last rule.

To create a new chain, the -N <chain> switch is used. In our case, we need to create the chains NOISE, BLACKHOLE, REGIONS, APNIC, LACNIC, ARIN, RIPE, AFRINIC and SSH.

iptables -N NOISE
iptables -N BLACKHOLE
iptables -N REGIONS
iptables -N APNIC
iptables -N LACNIC
iptables -N ARIN
iptables -N RIPE
iptables -N AFRINIC
iptables -N SSH

To verify the chains and their content, the -L [<chain>] switch can be used. There are also the -n (numerical) and -v (verbose) switches. 

iptables -L -nv

iptables -L INPUT -n

iptables -L REGIONS

Let's populate the INPUT chain. The order in which I want the process to occur is:

1. Drop the NOISE
2. Drop the BLACKHOLE
3. Accept new HTTP sessions (go to REGIONS)
4. Accept new HTTPS sessions (go to REGIONS)
5. Accept new DNS sessions (go to REGIONS)
6. Accept new SSH sessions (go to SSH)
7. Accept already established sessions
8. Drop and log everything else

This translates to:

iptables -A INPUT -i eth0 -j NOISE

iptables -A INPUT -i eth0 -j BLACKHOLE

iptables -A INPUT -i eth0 -p tcp -m tcp --dport 80  \

                  -m state --state NEW -j REGIONS

iptables -A INPUT -i eth0 -p tcp -m tcp --dport 443 \

                  -m state --state NEW -j REGIONS

iptables -A INPUT -i eth0 -p tcp -m tcp --dport 53  \

                  -m state --state NEW -j REGIONS

iptables -A INPUT -i eth0 -p udp -m udp --dport 53  \

                  -m state --state NEW -j REGIONS

iptables -A INPUT -i eth0 -p tcp -m tcp --dport 22  \

                  -m state --state NEW -j SSH

iptables -A INPUT -i eth0 -m state --state ESTABLISHED \

                  -j ACCEPT

iptables -A INPUT -i eth0 -j LOG

iptables -A INPUT -i eth0 -j DROP

 

Note: the LOG target requires that the ipt_LOG module be loaded.

There are a few switches that I will describe later. 

If we let the firewall that way, nothing would go through. Why? Because the REGIONS and SSH chains are empty, and would just return back to INPUT. The process would go down to the DROP target, at which point the packet would be discarded.

Let's then populate REGIONS:

iptables -A REGIONS -j APNIC

iptables -A REGIONS -j LACNIC

iptables -A REGIONS -j ARIN

iptables -A REGIONS -j RIPE

iptables -A REGIONS -j AFRINIC

iptables -A REGIONS -j ACCEPT

The closing ACCEPT target is to make sure that IPs in subnets not allocated to a region are processed. At this point, our firewall let anyone on the Internet access the server on HTTP, HTTPS and DNS. The regions can be populated with the information from the IANA. 

That's also where an explicit RETURN target is needed: APNIC has been assigned the 202.0.0.0/8 subnets, but the 202.123.0.0/19 was transferred to AFRINIC. This would give the following rules:

[...]

iptables -A APNIC -s 202.123.0.0/19 -j RETURN

iptables -A APNIC -s 202.0.0.0/8 -j ACCEPT

[...]

Dropping the noise:

If the server is on a network where there are MS Windows machines, there is a good chance the firewall is going to log an incredible quantity of noise, mostly broadcasts due to Netbios.

A way to avoid that is to drop that noise early in the process, and that's the reason for the NOISE chain.

iptables -A NOISE -i eth0 -m udp --sport 138 -j DROP

iptables -A NOISE -i eth0 -m udp --dport 138 -j DROP

This is not to be confused with the role of the BLACKHOLE: that latter chain is to drop all traffic coming from certain sources. Technically, both could be in the NOISE chain, but I usually like to separate them.

An entry in the BLACKHOLE would be:

iptables -A BLACKHOLE -i eth0 -s 46.20.33.192/27 -j DROP

The reason for being in the BLACKHOLE, in my case, is too many logged attempts to access my machine on closed ports, or the presence in several blacklists.

Managing the server through SSH

In the current state, it is possible to access the server on HTTP, HTTPS and DNS, but not SSH. Again, to populate the table and assuming that only the RFC1918 192.168.0.0/16 network should be able to manage that server:

iptables -A SSH -i eth0 -s 192.168.0.0/16 -j ACCEPT

There is no need to duplicate the tcp/22 configuration: that chain is accessed only through the statement in INPUT that has the -j SSH, which already matches only new SSH connections.

These switches I haven't talked about yet

In the various examples, I mentioned a few switches I haven't described. That's the case for the -i <interface>, the -m tcp, -m udp or -m state. 

The -i <interface> adds a condition to the rule, namely that the packet entered through the mentioned interface. This allows to separate the roles, and for example have an interface dedicated to the management, another to the services provided. If this is not mentioned, the rule is applied to all interfaces, including the loopback. 

The -p switch specifies the protocol to match, in this case, tcp or udp. Other values are possible.

-m specifies a match: it gives access to command-line switches depending on the modules. For example, if the rule has to match a udp connection, there is no need to have the module responsible for inspecting tcp segments be used. I used three different modules: tcp, udp and state. The first two are used to inspect specific options of these protocols, such as source or destination ports, the last one is used to access the conntrack module information, which keeps track of all connections. This allows to differentiate between a new session (trying to establish), an established session (already initiated), an invalid session (for example out-of-state TCP segments) and RELATED sessions (sessions related to another session, for example FTP data ports).

With -m tcp or -m udp, two of the additional switches are --sport <port> and --dport <port>, which match respectively the source and the destination port. If they are not specified, any port is valid. With -m state, the --state <state> switch becomes available, to match specific conntrack information.

This was a short introduction to iptables, and going over all of its possibilities would require several books. A good starting point is the man page.

Fedora 17, Google Chrome and Citrix

Until recently, I have been using Firefox when I had to connect to a Citrix Desktop presented through HTTPS (CAG or other). Not anymore. I can now use my favorite Google Chrome.

In your home directory, go to .local/share/applications. Add a file - i will call it ica.desktop - containing:

[Desktop Entry]
Version=1.0
Name=Citrix ICA Viewer
GenericName=Citrix ICA Viewer
Comment=Access to Citrix Desktop
Type=Application
Vendor=Citrix
Exec=/opt/Citrix/ICAClient/wfica
MimeType=application/x-ica

The Exec line should reflect where your binary is installed. Now, modify mimeapps.list and add the line

application/x-ica=ica.desktop

Under [Added Associations].

Voila! Next time you will connect to a Citrix server through HTTP/HTTPS, it will automatically open the Citrix Viewer on your machine.

Enjoy!

BIND9, Ubuntu and Apparmor

While configuring a slave DNS server with bind9 on Ubuntu, I had a few issues. Looking in the log, I spotted:

Jun 25 15:25:19 nyhdns01 kernel: [ 1249.991165] type=1400 audit(1340652319.705:7): apparmor="DENIED" operation="mknod" parent=1 profile="/usr/sbin/named" name="/etc/bind/zones/tmp-aSrmPQ6y4K" pid=1776 comm="named" requested_mask="c" denied_mask="c" fsuid=106 ouid=106

The AppArmor profile for bind prevents writing under /etc/bind, however, my standard is to store all the zones under /etc/bind/zones. Editing  /etc/apparmor.d/usr.sbin.named to add

/etc/bind/zones/**,

solved the issue.

Upgrade to Linux Fedora 17

Fedora 17 was released on May 29, 2012. As a regular user of Fedora Linux since version 12 (after a long past with Redhat until version 6.2, followed by a trip to FreeBSD, Debian and Ubuntu), I try to stay abreast of the new versions.

My computer is nothing extravagant, neither bleeding edge nor old crap: it is a decent quad core, with 8GB of RAM, an Asus Motherboard purchased in 2008 and a NVIDIA GeForce 9600 video card. Concerning this last item, I know this forces me to either use the buggy nouveau driver (nv) or use the binary installer provided by NVIDIA.

So I decided to upgrade my Fedora 16 to a shiny new 17. Looking at the support forums, I found that there is a method called preupgrade to perform an upgrade without downloading and burning a media. So I decided to give it a shot.

Unfortunately, I missed the not so fine prints: my /boot partition is around 128MB, and after spending almost an afternoon downloading all the packages, the installer told me that unfortunately, there are things that are not supposed to be. In this case, using preupgrade. DVD it is, downloaded and burned.

The first issue is related to my video card. From a few pages and messages found on Google, it seems that the nv driver shipped with the install has a few issues. Mine is that my screen goes completely dark and nothing reacts short of a hard power off. The solution is quite easy: chose to edit the boot line and add "xmode=vesa nomodeset". This will force a compatible mode to be selected, with the detriment that the screen are larger than the display and will scroll.

For the quick and observant, two error messages flashes: the first one concerning the floppy - the installer loads the module but I do not have a floppy drive anymore, and the second one that I can't even read. Not important and the installer boots just fine.

The install (1422 packages in my case) seems to stall with SELinux. On my machine, it took about 10 minutes to go through that package, during which restorecon was using 100% of a core. Going from one virtual terminal to another gives you some information, the 2nd VT even gives you a shell. But if you do that, your upgrade screen will be completely white, except for the mouse pointer. Passed SELinux, the install continues at a decent rate and goes to the reboot. There, I was a bit surprised as the installer did not eject the DVD. Also, there was no offer to add a repository to do all the upgrades during the install phase.

First boot, the Fedora logo fills and ... nothing. It hangs. Pressing num lock shows that the machine is not frozen, but nothing seems to happen. So reboot and edit of the boot line: at the "linux" line, I removed the "quiet" and added "single" to force Linux to stop at runlevel 1. As soon as the Fedora Logo appeared, I also pressed ESC to continue seeing the messages. It boots OK and drops me at a shell. It, however, took a very long time with a message informing that the lp module was loaded, but no device was found. I do not know if that module is the actual cause of the temporary freeze or if the next module is.  Let's head for runlevel 3, to compile a new NVIDIA driver and do some upgrades.

The NVIDIA script died as the version used to compile the kernel (4.6) is different from the installed version (4.7). Surprising. So, I decided to upgrade the whole system.

The first "yum update" failed with "Cannot retrieve metalink for repository", which I solved using "yum makecache". The following "yum update" succeeded, with the minor exception of a timeout while trying to retrieve the information from a mirror hosted at the Princeton University. But boy! The upgrade totals 1048 packages summing 1.8GB! I accept and look at the first messages. After a while, this gets old and I decide to leave the machine alone. My alarm clock is set to ring in two hours, approximately the time needed to transfer the upgrades.

Two hours later, back to the computer. It displays an invite asking whether I want to accept the PGP key using in two repositories. Okay, that's good. From there, two things:

• Several packages are marked as duplicate of the same version ... for Fedora 16!
• Several packages failed the install due to a missing required: xserver-abi(videodrv-11) >= ('0','0',None) (This is an actual bug)

A quick rpm -qa tells me that almost half of my packages are actually Fedora 16 (2251 packages installed, of which 1456 packages are marked as Fedora 17). Worse, I also found packages belonging to Fedora 15, 14, 13, 12 and even 11!

To try to go further, I followed the instructions in the bug report before trying another "yum update".  Of course, one of the instructions nukes the package cache, which means that all the packages need to be downloaded ... again!

Time for desperate measures.

*** Warning - I this can completely ruin your install  - Don't do it unless you know exactly what you are doing ***

There are two types of issues here -

• Duplicate packages between FC17 and a previous release
• Missing dependencies for a package from a previous release

The duplicates packages is the easiest: rpm -e --nodeps <complete package name>. This removes the packages.

For the missing dependencies, I found that installing the package (without the version) works fine in most of the cases: yum install <package>. For a few package, I had to remove the package first, then add it.

I ended with "yum update" that almost worked, except for a few broken dependencies for a few packages. Nothing is critical, so I removed them (yum erase). After the update, I added them back.

Conclusion -

I am still a fan of Fedora, but I must admit that the upgrade to version 17 stinks. If you know what you are doing and have a day to kill, this is for you, otherwise, stick to FC16 and wait for all the bugs to be corrected!



Edit 1 -

After the reboot, I added "single" in the boot line, to drop to runlevel 1. I moved to runlevel 3, stopped a few services using systemctl (powerful tool!), recompiled my nvidia driver. I then issued "init 5" to move to the graphic interface and voila! Fedora 17.