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:
gccpython-develsqlite-develgeos-develproj-develpython-pipredhat-rpm-configAfter 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.
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.
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.
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.
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.
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.