Posts for: #Fedora

Installing pyspatialite on Fedora

If you should find yourself wanting to install pyspatialite on Fedora – perhaps because you want to use the Processing plugin for QGIS – you will first need to install the following dependencies:

  • gcc
  • python-devel
  • sqlite-devel
  • geos-devel
  • proj-devel
  • python-pip
  • redhat-rpm-config

After which you can install pyspatialite using pip by running:

CFLAGS=-I/usr/include pip install pyspatialite

At this point, you should be able to use the “Processing” plugin.

[read more]

Bootstrapping Ansible on Fedora 23

If you’ve tried running Ansible against a Fedora 23 system, you may have run into the following problem:

fatal: [myserver]: FAILED! => {"changed": false, "failed": true,
"msg": "/bin/sh: /usr/bin/python: No such file or directory\r\n",
"parsed": false}

Fedora has recently made the switch to only including Python 3 on the base system (at least for the cloud variant), while Ansible still requires Python 2. With Fedora 23, Python 3 is available as /usr/bin/python3, and /usr/bin/python is only available if you have installed the Python 2 interpreter.

[read more]

Booting cloud images with libvirt

Most major distributions now provide “cloud-enabled” images designed for use in cloud environments like OpenStack and AWS. These images are usually differentiated by (a) being relatively small, and (b) running cloud-init at boot to perform initial system configuration tasks using metadata provided by the cloud environment.

Because of their small size and support for automatic configuration (including such useful tasks as provisioning ssh keys), these images are attractive for use outside of a cloud environment. Unfortunately, when people first try to boot them they are met with frustration as first the image takes forever to boot as it tries to contact a non-existent metadata service, and then when it finally does boot they are unable to log in because the images typically only support key-based login.

[read more]

Fedora Atomic, OpenStack, and Kubernetes (oh my)

While experimenting with Fedora Atomic, I was looking for an elegant way to automatically deploy Atomic into an OpenStack environment and then automatically schedule some Docker containers on the Atomic host. This post describes my solution.

Like many other cloud-targeted distributions, Fedora Atomic runs cloud-init when the system boots. We can take advantage of this to configure the system at first boot by providing a user-data blob to Nova when we boot the instance. A user-data blob can be as simple as a shell script, and while we could arguably mash everything into a single script it wouldn’t be particularly maintainable or flexible in the face of different pod/service/etc descriptions.

[read more]

Fedora and OVS Bridge Interfaces

I run OpenStack on my laptop, and I’ve been chasing down a pernicious problem with OVS bridge interfaces under both F19 and F20. My OpenStack environment relies on an OVS bridge device named br-ex for external connectivity and for making services available to OpenStack instances, but after rebooting, br-ex was consistently unconfigured, which caused a variety of problems.

This is the network configuration file for br-ex on my system:

DEVICE=br-ex
DEVICETYPE=ovs
TYPE=OVSBridge
BOOTPROT=static
IPADDR=192.168.200.1
NETMASK=255.255.255.0
ONBOOT=yes
NM_CONTROLLED=no
ZONE=openstack

Running ifup br-ex would also fail to configure the interface, but running ifdown br-ex; ifup br-ex would configure things appropriately.

[read more]

Private /tmp directories in Fedora

I ran into an odd problem the other day: I was testing out some configuration changes for a web application by dropping files into /tmp and pointing the application configuration at the appropriate directory. Everything worked out great when testing it by hand…but when starting up the httpd service, the application behaved as if it was unable to find any of the files in /tmp.

My first assumption was that had simply missed something obvious like file permissions or that I had a typo in my configuration, but after repeated checks and lots of testing it was obvious that something else was going on.

[read more]