Matthias Runge - Fedorahttp://www.matthias-runge.de/2021-01-04T11:00:00+01:00Kubernetes on Raspberry Pi 4 on Fedora2021-01-04T11:00:00+01:002021-01-04T11:00:00+01:00mrungetag:www.matthias-runge.de,2021-01-04:/2021/01/04/k8s-raspi4-fedora/<p>Recently, I bought a couple of Raspberry Pi 4, one with 4 GB and 2
equipped with 8 GB of RAM. When I bought the first one, there was no
option to get bigger memory. However, I saw this as a game and thought
to give this a try. I …</p><p>Recently, I bought a couple of Raspberry Pi 4, one with 4 GB and 2
equipped with 8 GB of RAM. When I bought the first one, there was no
option to get bigger memory. However, I saw this as a game and thought
to give this a try. I also bought SSDs for these and USB3 to SATA
adapters. Before purchasing anything, you may want to take a look at
<a href="https://jamesachambers.com/raspberry-pi-4-usb-boot-config-guide-for-ssd-flash-drives/">James Archers page</a>.
Unfortunately, there are a couple on adapters on the marked, which
don't work that well.</p>
<h2>Deploying Fedora 33 Server</h2>
<p>Initially, I followed the <a href="https://fwmotion.com/blog/operating-systems/2020-09-04-installing-fedora-server-onto-pi4/">description</a>
to deploy Fedora 32; it works the same way for Fedora 33 Server (in my case here).</p>
<p>Because ceph requires a partition (or better: a whole disk), I used the
traditional setup using partitions and no LVM.</p>
<h2>Deploying Kubernetes</h2>
<div class="highlight"><pre><span></span><code>git clone https://github.com/kubernetes-sigs/kubespray
<span class="nb">cd</span> kubespray
</code></pre></div>
<p>I followed the documentation and created an inventory. For the container
runtime, I picked <code>crio</code>, and as <code>calico</code> as network plugin.</p>
<p>Because of <a href="https://github.com/projectcalico/calico/issues/4256">an issue</a>,
I had to patch <code>roles/download/defaults/main.yml</code>:</p>
<div class="highlight"><pre><span></span><code><span class="gh">diff --git a/roles/download/defaults/main.yml b/roles/download/defaults/main.yml</span><span class="w"></span>
<span class="gh">index a97be5a6..d4abb341 100644</span><span class="w"></span>
<span class="gd">--- a/roles/download/defaults/main.yml</span><span class="w"></span>
<span class="gi">+++ b/roles/download/defaults/main.yml</span><span class="w"></span>
<span class="gu">@@ -64,7 +64,7 @@ quay_image_repo: "quay.io"</span><span class="w"></span>
<span class="w"> </span># TODO(mattymo): Move calico versions to roles/network_plugins/calico/defaults<span class="w"></span>
<span class="w"> </span># after migration to container download<span class="w"></span>
<span class="gd">-calico_version: "v3.16.5"</span><span class="w"></span>
<span class="gi">+calico_version: "v3.15.2"</span><span class="w"></span>
<span class="w"> </span>calico_ctl_version: "{{ calico_version }}"<span class="w"></span>
<span class="w"> </span>calico_cni_version: "{{ calico_version }}"<span class="w"></span>
<span class="w"> </span>calico_policy_version: "{{ calico_version }}"<span class="w"></span>
<span class="gu">@@ -520,13 +520,13 @@ etcd_image_tag: "{{ etcd_version }}{%- if image_arch != 'amd64' -%}-{{ image_arc</span><span class="w"></span>
<span class="w"> </span>flannel_image_repo: "{{ quay_image_repo }}/coreos/flannel"<span class="w"></span>
<span class="w"> </span>flannel_image_tag: "{{ flannel_version }}"<span class="w"></span>
<span class="w"> </span>calico_node_image_repo: "{{ quay_image_repo }}/calico/node"<span class="w"></span>
<span class="gd">-calico_node_image_tag: "{{ calico_version }}"</span><span class="w"></span>
<span class="gi">+calico_node_image_tag: "{{ calico_version }}-arm64"</span><span class="w"></span>
<span class="w"> </span>calico_cni_image_repo: "{{ quay_image_repo }}/calico/cni"<span class="w"></span>
<span class="gd">-calico_cni_image_tag: "{{ calico_cni_version }}"</span><span class="w"></span>
<span class="gi">+calico_cni_image_tag: "{{ calico_cni_version }}-arm64"</span><span class="w"></span>
<span class="w"> </span>calico_policy_image_repo: "{{ quay_image_repo }}/calico/kube-controllers"<span class="w"></span>
<span class="gd">-calico_policy_image_tag: "{{ calico_policy_version }}"</span><span class="w"></span>
<span class="gi">+calico_policy_image_tag: "{{ calico_policy_version }}-arm64"</span><span class="w"></span>
<span class="w"> </span>calico_typha_image_repo: "{{ quay_image_repo }}/calico/typha"<span class="w"></span>
<span class="gd">-calico_typha_image_tag: "{{ calico_typha_version }}"</span><span class="w"></span>
<span class="gi">+calico_typha_image_tag: "{{ calico_typha_version }}-arm64"</span><span class="w"></span>
<span class="w"> </span>pod_infra_image_repo: "{{ kube_image_repo }}/pause"<span class="w"></span>
<span class="w"> </span>pod_infra_image_tag: "{{ pod_infra_version }}"<span class="w"></span>
<span class="w"> </span>install_socat_image_repo: "{{ docker_image_repo }}/xueshanf/install-socat"<span class="w"></span>
</code></pre></div>
<h2>Deploy Ceph</h2>
<p>Ceph requires a raw partition. Make sure, you have an empty partition available.</p>
<div class="highlight"><pre><span></span><code><span class="o">[</span>root@node1 ~<span class="o">]</span><span class="c1"># lsblk -f</span>
NAME FSTYPE FSVER LABEL UUID FSAVAIL FSUSE% MOUNTPOINT
sda
├─sda1
│ vfat FAT32 UEFI 7DC7-A592
├─sda2
│ vfat FAT32 CB75-24A9 <span class="m">567</span>.9M <span class="m">1</span>% /boot/efi
├─sda3
│ xfs cab851cb-1910-453b-ae98-f6a2abc7f0e0 <span class="m">804</span>.7M <span class="m">23</span>% /boot
├─sda4
│
├─sda5
│ xfs 6618a668-f165-48cc-9441-98f4e2cc0340 <span class="m">27</span>.6G <span class="m">45</span>% /
└─sda6
</code></pre></div>
<p>In my case, there are <code>sda4</code> and <code>sda6</code> not formatted. <code>sda4</code> is very
small and will be ignored, <code>sda6</code> will be used.</p>
<p>Using rook is pretty straightforward</p>
<div class="highlight"><pre><span></span><code>git clone --single-branch --branch v1.5.4 https://github.com/rook/rook.git
<span class="nb">cd</span> rook/cluster/examples/kubernetes/ceph
kubectl create -f crds.yaml -f common.yaml -f operator.yaml
kubectl create -f cluster.yaml
</code></pre></div>Pelican version 3.62015-06-22T20:00:00+02:002015-06-22T20:00:00+02:00mrungetag:www.matthias-runge.de,2015-06-22:/2015/06/22/pelican-3.6/<p>Today, I updated <a class="reference external" href="http://blog.getpelican.com">pelican</a> to version 3.6 and also added a python 3 subpackage.
You can test it in Fedora 22 by using</p>
<div class="highlight"><pre><span></span>dnf --enablerepo<span class="o">=</span>updates-testing install python3-pelican
</pre></div>
<p>If you're already using pelican,</p>
<div class="highlight"><pre><span></span>dnf --enablerepo<span class="o">=</span>updates-testing update python-pelican
</pre></div>
<p>Please leave <a class="reference external" href="https://admin.fedoraproject.org/updates/python-pelican-3.6.0-1.fc22">feedback</a></p>
<p>Upgrading from previous release might require a change …</p><p>Today, I updated <a class="reference external" href="http://blog.getpelican.com">pelican</a> to version 3.6 and also added a python 3 subpackage.
You can test it in Fedora 22 by using</p>
<div class="highlight"><pre><span></span>dnf --enablerepo<span class="o">=</span>updates-testing install python3-pelican
</pre></div>
<p>If you're already using pelican,</p>
<div class="highlight"><pre><span></span>dnf --enablerepo<span class="o">=</span>updates-testing update python-pelican
</pre></div>
<p>Please leave <a class="reference external" href="https://admin.fedoraproject.org/updates/python-pelican-3.6.0-1.fc22">feedback</a></p>
<p>Upgrading from previous release might require a change:</p>
<ol class="arabic simple">
<li>Delete the <cite>cache</cite> folder, if exists</li>
<li>Add the following to your settings file:</li>
</ol>
<div class="highlight"><pre><span></span><span class="nv">CACHE_CONTENT</span> <span class="o">=</span> True
<span class="nv">LOAD_CONTENT_CACHE</span> <span class="o">=</span> True
</pre></div>
<p>The full change list is available on <a class="reference external" href="http://blog.getpelican.com/category/news.html">pelicans news</a> page.</p>
Fedora 22 will contain Django-1.82015-04-17T11:45:00+02:002015-04-17T11:45:00+02:00mrungetag:www.matthias-runge.de,2015-04-17:/2015/04/17/django18-fedora22/<p>One of the new features in upcoming Fedora 22 will be <a class="reference external" href="https://fedoraproject.org/wiki/Changes/Django18">Django-1.8</a>.
Django project released its most recent version earlier this month, and
it's going to be a long term supported version after Django-1.4 became a
bit ancient nowadays.
Fedora had release 1.6 in which is now …</p><p>One of the new features in upcoming Fedora 22 will be <a class="reference external" href="https://fedoraproject.org/wiki/Changes/Django18">Django-1.8</a>.
Django project released its most recent version earlier this month, and
it's going to be a long term supported version after Django-1.4 became a
bit ancient nowadays.
Fedora had release 1.6 in which is now deprecated by Django upstream.</p>
<p>A few packages required patches to support Django-1.8 though:</p>
<ul class="simple">
<li>python-django-openstack-auth</li>
<li>python-django-compressor</li>
<li>python-django-nose</li>
<li>python-django-horizon</li>
</ul>
<p>Of course, they were fixed and included already in Fedora 22.</p>
Testing Horizon git snapshots2015-03-11T10:30:00+01:002015-03-11T10:30:00+01:00mrungetag:www.matthias-runge.de,2015-03-11:/2015/03/11/test-horizon-git/<div class="section" id="testing-horizon-git-checkouts">
<h2>Testing horizon git checkouts</h2>
<p>One of the cool things in Horizon is, one can easily try newest things out.
This assumes, you already have an OpenStack installation available somewhere.</p>
<p>If you haven't already installed git:</p>
<div class="highlight"><pre><span></span>yum install git
</pre></div>
<p>To clone horizons upstream git repository, run the command</p>
<div class="highlight"><pre><span></span>git clone https …</pre></div></div><div class="section" id="testing-horizon-git-checkouts">
<h2>Testing horizon git checkouts</h2>
<p>One of the cool things in Horizon is, one can easily try newest things out.
This assumes, you already have an OpenStack installation available somewhere.</p>
<p>If you haven't already installed git:</p>
<div class="highlight"><pre><span></span>yum install git
</pre></div>
<p>To clone horizons upstream git repository, run the command</p>
<div class="highlight"><pre><span></span>git clone https://github.com/openstack/horizon
<span class="nb">cd</span> horizon
cp openstack_dashboard/local/local_settings.py.example openstack_dashboard/local/local_settings.py
</pre></div>
<p>Then please edit the file <tt class="docutils literal">openstack_dashboard/local/local_settings.py</tt>
and adjust</p>
<div class="highlight"><pre><span></span><span class="n">ALLOWED_HOSTS</span> <span class="o">=</span> <span class="p">[</span><span class="s1">'*'</span><span class="p">]</span>
<span class="o">...</span>
<span class="n">OPENSTACK_HOST</span> <span class="o">=</span> <span class="s2">"127.0.0.1"</span>
</pre></div>
<p><tt class="docutils literal">OPENSTACK_HOST</tt> has to point to your keystone instance, in this case to
127.0.0.1.</p>
<p>The development server requires a dependencies. If you didn't already
install them, just run:</p>
<div class="highlight"><pre><span></span>yum install gcc python-devel python-virtualenv openssl-devel libffi-devel which
</pre></div>
<p>To start your development server:</p>
<div class="highlight"><pre><span></span>./run_tests.sh -m collectstatic
</pre></div>
<p>This will install all required dependencies in a virtual env inside your
horizon directory. Horizon spreads static files like images and
javascript files all around in its source tree. <tt class="docutils literal">collectstatic</tt> will
collect them and place those files in under a directory named static
inside the horizon checkout. When running the development server, they
will be served from that location.</p>
<p>Finally</p>
<div class="highlight"><pre><span></span>./run_tests.sh --runserver
</pre></div>
<p>will start your Horizon instance from your git checkout. It can be accessed
via <tt class="docutils literal"><span class="pre">http://<ip>:8000</span></tt>, in most cases, that is <a class="reference external" href="http://localhost:8000">http://localhost:8000</a> .</p>
</div>
<div class="section" id="updating-your-checkout">
<h2>Updating your checkout</h2>
<p>The following snippet will pull in latest changes from git, will copy
changed static files to the right places and will run your django development
server.</p>
<div class="highlight"><pre><span></span>git fetch <span class="o">&&</span> git pull
./run_tests.sh -m collectstatic
./run_tests.sh --runserver
</pre></div>
</div>
Fedora packaging workshop2015-02-07T21:32:00+01:002015-02-07T21:32:00+01:00mrungetag:www.matthias-runge.de,2015-02-07:/2015/02/07/fedora-packaging-2/<p>This part assumes, you already have the tools installed like described
in <a class="reference external" href="http://www.matthias-runge.de/2014/10/08/fedora-packaging/">earlier part</a>.</p>
<div class="section" id="using-a-tool-to-create-a-spec">
<h2>Using a tool to create a spec</h2>
<p>As first example, we'll use a tool to create a spec file, download
the sources.</p>
<div class="highlight"><pre><span></span>rpmdev-setuptree
<span class="nb">cd</span> ~/rpmbuild
pyp2rpm -n bleach > SPECS/python-bleach.spec
</pre></div>
<p>What this actually does is …</p></div><p>This part assumes, you already have the tools installed like described
in <a class="reference external" href="http://www.matthias-runge.de/2014/10/08/fedora-packaging/">earlier part</a>.</p>
<div class="section" id="using-a-tool-to-create-a-spec">
<h2>Using a tool to create a spec</h2>
<p>As first example, we'll use a tool to create a spec file, download
the sources.</p>
<div class="highlight"><pre><span></span>rpmdev-setuptree
<span class="nb">cd</span> ~/rpmbuild
pyp2rpm -n bleach > SPECS/python-bleach.spec
</pre></div>
<p>What this actually does is to create a file structure for your builds and
change into that directory.
Finally <tt class="docutils literal">pyp2rpm</tt> goes to <a class="reference external" href="https://pypi.python.org/pypi">pypi</a>, pulls down the required information,
downloads the sources, copies them to <tt class="docutils literal">~rpmbuild/SOURCES</tt> and writes
as much information as possible to the spec file.</p>
<div class="highlight"><pre><span></span><span class="c"># Created by pyp2rpm-1.1.2</span>
%global pypi_name bleach
<span class="gh">Name</span><span class="p">:</span> python-<span class="kc">%{pypi_name}</span>
<span class="gh">Version</span><span class="p">:</span> 1.4.1
<span class="gh">Release</span><span class="p">:</span> 1<span class="nv">%{?dist}</span>
<span class="gh">Summary</span><span class="p">:</span> An easy whitelist-based HTML-sanitizing tool
<span class="gh">License</span><span class="p">:</span> ASL %(TODO: version)s
<span class="gh">URL</span><span class="p">:</span> http://github.com/jsocol/bleach
<span class="gh">Source0</span><span class="p">:</span> https://pypi.python.org/packages/source/b/<span class="kc">%{pypi_name}</span>/<span class="kc">%{pypi_name}</span>-<span class="kc">%{version}</span>.tar.gz
<span class="gh">BuildArch</span><span class="p">:</span> noarch
<span class="gh">BuildRequires</span><span class="p">:</span> python2-devel
<span class="gh">BuildRequires</span><span class="p">:</span> python-nose >= 1.3
<span class="gh">Requires</span><span class="p">:</span> python-six
<span class="gh">Requires</span><span class="p">:</span> python-html5lib >= 0.999
<span class="nd">%description</span>
Bleach is an HTML sanitizing library
that escapes or strips markup and
attributes based on a white list.
<span class="nd">%prep</span>
<span class="k">%setup</span> -q -n <span class="kc">%{pypi_name}</span>-<span class="kc">%{version}</span>
<span class="c"># Remove bundled egg-info</span>
rm -rf <span class="kc">%{pypi_name}</span>.egg-info
<span class="nd">%build</span>
<span class="nf">%{__python</span>2} setup.py build
<span class="nd">%install</span>
<span class="nf">%{__python</span>2} setup.py install --skip-build --root <span class="kc">%{buildroot}</span>
<span class="nd">%check</span>
<span class="nf">%{__python</span>2} setup.py test
<span class="nd">%files</span>
<span class="k">%doc</span> README.rst LICENSE
<span class="kc">%{python2_sitelib}</span>/<span class="kc">%{pypi_name}</span>
<span class="kc">%{python2_sitelib}</span>/<span class="kc">%{pypi_name}</span>-<span class="kc">%{version}</span>-py?.?.egg-info
<span class="nd">%changelog</span>
<span class="gu">* Sat Feb 07 2015 - 1.4.1-1</span>
- Initial package.
</pre></div>
<p>Magic, isn't it? Unfortunately, that's not completely everything:</p>
<ul class="simple">
<li>Look at the license field. Actually, the license is <a class="reference external" href="https://github.com/jsocol/bleach/blob/master/LICENSE">ASL 2.0</a>.
To make it build, you'll also need <tt class="docutils literal"><span class="pre">python-setuptools</span></tt>.</li>
<li>The license should be marked as %license and not as %doc</li>
<li>run time requirements are required for testing as well. We should add them.
The builders are not connected to the internet, thus something like
<tt class="docutils literal">pip install</tt> does not work during package build or testing.</li>
<li>The changelog entry should contain a name and an email-address.</li>
</ul>
<p>Once that is fixed, let's issue a local build:</p>
<div class="highlight"><pre><span></span>rpmbuild -ba SPECS/python-bleach.spec
</pre></div>
<p>which will building a binary package and a Source RPM package.</p>
<p>Finally, one should try a mock build, which will build the same package
in a clean environment. This will discover any forgotten dependencies.</p>
<div class="highlight"><pre><span></span>mock --rebuild ./SRPMS/python-bleach-1.4.1-1.fc21.src.rpm
</pre></div>
<p>Now that is finished, we're nearly done. It's time to check for anything
other obviously forgotten:</p>
<div class="highlight"><pre><span></span><span class="o">[</span>rpmbuilder@turing rpmbuild<span class="o">]</span>$ rpmlint ./SPECS/python-bleach.spec ./RPMS/noarch/python-bleach-1.4.1-1.fc21.noarch.rpm ./SRPMS/python-bleach-1.4.1-1.fc21.src.rpm
python-bleach.noarch: W: spelling-error Summary<span class="o">(</span>en_US<span class="o">)</span> whitelist -> white list, white-list, whistle
python-bleach.src: W: spelling-error Summary<span class="o">(</span>en_US<span class="o">)</span> whitelist -> white list, white-list, whistle
<span class="m">2</span> packages and <span class="m">1</span> specfiles checked<span class="p">;</span> <span class="m">0</span> errors, <span class="m">2</span> warnings.
</pre></div>
<p><tt class="docutils literal">rpmlint</tt> is a quite powerful linter to check for common issues.</p>
<p>The finished spec for python-bleach can be found here: <a class="reference external" href="http://www.matthias-runge.de/fedora/python-bleach.spec">http://www.matthias-runge.de/fedora/python-bleach.spec</a>.</p>
</div>
Fedora packaging workshop2014-10-08T14:20:00+02:002014-10-08T14:20:00+02:00mrungetag:www.matthias-runge.de,2014-10-08:/2014/10/08/fedora-packaging/<p>On 17th and 18th this month, we'll have a local <a class="reference external" href="http://lit-ol.de/">Linux conference</a> here. As
part of this, I'll give a short introductory workshop on packaging. The
following series of posts helps me, to sort things for me and to provide a short
reference for others and myself as well.</p>
<div class="section" id="prerequisites">
<h2>Prerequisites …</h2></div><p>On 17th and 18th this month, we'll have a local <a class="reference external" href="http://lit-ol.de/">Linux conference</a> here. As
part of this, I'll give a short introductory workshop on packaging. The
following series of posts helps me, to sort things for me and to provide a short
reference for others and myself as well.</p>
<div class="section" id="prerequisites">
<h2>Prerequisites</h2>
<p>In order to package and build packages for Fedora and <a class="reference external" href="https://fedoraproject.org/wiki/EPEL">EPEL</a>, you'll
need a few packages installed</p>
<ul class="simple">
<li>@development-tools</li>
<li>@fedora-packager</li>
<li>rpmlint</li>
</ul>
<p>You'll install those packages via</p>
<pre class="literal-block">
dnf group install development-tools
dnf group install fedora-packager
dnf install rpmlint
</pre>
<p>You'll find several warnings about not to create packages as root user. Take
them serious. There's absolutely no reason to build as root user, it's
plainly risky and dumb to do so.</p>
<p>To separate your user account from the user building rpms a bit more,
add a new user to your system:</p>
<pre class="literal-block">
useradd makerpm
</pre>
<p>Finally, your user account should become a member of <tt class="docutils literal">mock</tt> user group.</p>
<pre class="literal-block">
usermod -a -G mock makerpm
</pre>
<p>The whole process is documented on <a class="reference external" href="https://fedoraproject.org/wiki/How_to_create_an_RPM_package">Fedora Wiki</a>.</p>
</div>
Truncating log files2014-09-11T13:20:00+02:002014-09-11T13:20:00+02:00mrungetag:www.matthias-runge.de,2014-09-11:/2014/09/11/logrotate-horizon/<p>Depending on your settings, OpenStack Dashboard produces lots of log
output. Fortunately there is already a tool in place, which cleans them up
for you. Looking at <tt class="docutils literal">/var/log/httpd/</tt> you'll probably notice
files like <tt class="docutils literal"><span class="pre">access_log-(date).gz</span></tt>. They were generated by logrotate by
compressing existent logs.</p>
<p>To use …</p><p>Depending on your settings, OpenStack Dashboard produces lots of log
output. Fortunately there is already a tool in place, which cleans them up
for you. Looking at <tt class="docutils literal">/var/log/httpd/</tt> you'll probably notice
files like <tt class="docutils literal"><span class="pre">access_log-(date).gz</span></tt>. They were generated by logrotate by
compressing existent logs.</p>
<p>To use the same mechanism for OpenStack Dashboard, create a file <tt class="docutils literal"><span class="pre">/etc/logrotate.d/openstack-dashboard</span></tt>:</p>
<pre class="literal-block">
/var/log/horizon/*.log {
weekly
rotate 4
missingok
delaycompress
postrotate
/bin/systemctl reload httpd.service > /dev/null 2>/dev/null || true
endscript
}
</pre>
<p>Make sure, your file has perms 644: <tt class="docutils literal">chmod 644 <span class="pre">/etc/logrotate.d/openstack-dashboard</span></tt>.
To test, if it works, issue <tt class="docutils literal">logrotate <span class="pre">-d</span> /etc/logrotate.conf</tt> and watch its output closely.</p>
<p>You should find lines like:</p>
<pre class="literal-block">
reading config file openstack-ceilometer
reading config file openstack-cinder
reading config file openstack-dashboard
reading config file openstack-glance
reading config file openstack-heat
</pre>
<p>and a bit further down:</p>
<pre class="literal-block">
rotating pattern: /var/log/horizon/*.log weekly (4 rotations)
empty log files are not rotated, old logs are removed
considering log /var/log/horizon/horizon.log
log does not need rotating
</pre>
How to use Django-1.5 via parallel installable python-django152014-03-26T13:00:00+01:002014-03-26T13:00:00+01:00mrungetag:www.matthias-runge.de,2014-03-26:/2014/03/26/fedora-django-1-6/<p>Last week, the package python-django15 was approved. It's a Django package
to be installed in parallel to e.g python-django. Once you installed it,
you can not use it directly.</p>
<p>For example for python-django-horizon aka. OpenStack Dashboard
I'd change the django.wsgi from <a class="reference external" href="https://github.com/openstack/horizon/blob/master/openstack_dashboard/wsgi/django.wsgi">github</a>
to</p>
<div class="highlight"><pre><span></span><span class="kn">import</span> <span class="nn">logging</span>
<span class="kn">import</span> <span class="nn">os</span>
<span class="kn">import …</span></pre></div><p>Last week, the package python-django15 was approved. It's a Django package
to be installed in parallel to e.g python-django. Once you installed it,
you can not use it directly.</p>
<p>For example for python-django-horizon aka. OpenStack Dashboard
I'd change the django.wsgi from <a class="reference external" href="https://github.com/openstack/horizon/blob/master/openstack_dashboard/wsgi/django.wsgi">github</a>
to</p>
<div class="highlight"><pre><span></span><span class="kn">import</span> <span class="nn">logging</span>
<span class="kn">import</span> <span class="nn">os</span>
<span class="kn">import</span> <span class="nn">sys</span>
<span class="c1">####</span>
<span class="c1"># explicitly require Django 1.5 or later</span>
<span class="kn">from</span> <span class="nn">pkg_resources</span> <span class="kn">import</span> <span class="n">require</span>
<span class="n">require</span><span class="p">(</span><span class="s1">'Django>=1.5,<1.6'</span><span class="p">)</span>
<span class="c1">####</span>
<span class="kn">import</span> <span class="nn">django.core.handlers.wsgi</span>
<span class="kn">from</span> <span class="nn">django.conf</span> <span class="kn">import</span> <span class="n">settings</span>
<span class="c1"># Add this file path to sys.path in order to import settings</span>
<span class="n">sys</span><span class="o">.</span><span class="n">path</span><span class="o">.</span><span class="n">insert</span><span class="p">(</span><span class="mi">0</span><span class="p">,</span> <span class="n">os</span><span class="o">.</span><span class="n">path</span><span class="o">.</span><span class="n">join</span><span class="p">(</span><span class="n">os</span><span class="o">.</span><span class="n">path</span><span class="o">.</span><span class="n">dirname</span><span class="p">(</span><span class="n">os</span><span class="o">.</span><span class="n">path</span><span class="o">.</span><span class="n">realpath</span><span class="p">(</span><span class="vm">__file__</span><span class="p">)),</span> <span class="s1">'../..'</span><span class="p">))</span>
<span class="n">os</span><span class="o">.</span><span class="n">environ</span><span class="p">[</span><span class="s1">'DJANGO_SETTINGS_MODULE'</span><span class="p">]</span> <span class="o">=</span> <span class="s1">'openstack_dashboard.settings'</span>
<span class="n">sys</span><span class="o">.</span><span class="n">stdout</span> <span class="o">=</span> <span class="n">sys</span><span class="o">.</span><span class="n">stderr</span>
<span class="n">DEBUG</span> <span class="o">=</span> <span class="bp">False</span>
<span class="n">application</span> <span class="o">=</span> <span class="n">django</span><span class="o">.</span><span class="n">core</span><span class="o">.</span><span class="n">handlers</span><span class="o">.</span><span class="n">wsgi</span><span class="o">.</span><span class="n">WSGIHandler</span><span class="p">()</span>
</pre></div>
<p>Note the two lines enclosed in the lines of hash signs. That's all you need
to use Django-1.5 from python-django15 and have Django-1.6 installed in parallel.</p>
Using pelican for serving this blog2014-02-19T15:40:00+01:002014-02-19T15:40:00+01:00mrungetag:www.matthias-runge.de,2014-02-19:/2014/02/19/deprecating-wordpress/<p>For my own blog, I recently deprecated wordpress, in favor of using pelican.
The package was recently added to Fedora. It's quite simple and does not
require php, mysql, and a memcached running on a webserver.</p>
<p>In the past, the number of attempts to get into this host increased
significantly …</p><p>For my own blog, I recently deprecated wordpress, in favor of using pelican.
The package was recently added to Fedora. It's quite simple and does not
require php, mysql, and a memcached running on a webserver.</p>
<p>In the past, the number of attempts to get into this host increased
significantly. During Linux-Tag-Oldenburg last year, we had a wordpress
installation to serve the schedule. It just failed when more persons tried
to edit the same document.</p>
<p>Pelican uses structured text files, which are being processed once to html
files. This means, one can use awesome tools like vim and git.</p>
OpenStack testing Event @Flock2013-07-29T11:48:00+02:002013-07-29T11:48:00+02:00mrungetag:www.matthias-runge.de,2013-07-29:/2013/07/29/openstack-testing-event-flock/<p>Sadly, I won't make it to the new Fedora users and developers conference
Flock this time. Back in may, I proposed an <a class="reference external" href="http://www.matthias-runge.de/wordpress/2013/05/18/openstack-testing-session-flock/">OpenStack testing
session</a>.</p>
<p>The more I'm delighted, that we have <a class="reference external" href="http://kashyapc.wordpress.com/">Kashyap Chamarthy</a>, who will
leading the session. He also added some news around the event to his
<a class="reference external" href="http://kashyapc.wordpress.com/2013/07/26/openstack-test-event-at-flock-fedora-contributors-conference-aug-9-12/">blog …</a></p><p>Sadly, I won't make it to the new Fedora users and developers conference
Flock this time. Back in may, I proposed an <a class="reference external" href="http://www.matthias-runge.de/wordpress/2013/05/18/openstack-testing-session-flock/">OpenStack testing
session</a>.</p>
<p>The more I'm delighted, that we have <a class="reference external" href="http://kashyapc.wordpress.com/">Kashyap Chamarthy</a>, who will
leading the session. He also added some news around the event to his
<a class="reference external" href="http://kashyapc.wordpress.com/2013/07/26/openstack-test-event-at-flock-fedora-contributors-conference-aug-9-12/">blog</a></p>
<p>This makes me sad another time, because I can not attend his session, so
if you're there, you should give OpenStack a try!</p>
OpenStack testing session @FLOCK2013-05-18T13:17:00+02:002013-05-18T13:17:00+02:00mrungetag:www.matthias-runge.de,2013-05-18:/2013/05/18/openstack-testing-session-flock/<p>As you might heard, we at Fedora had FUDCons (Fedora Users and
Developers conference), which is now replaced by a conference named
<a class="reference external" href="http://flocktofedora.com/">Flock</a>. The first one will be held in Charleston, South Carolina
between Aug. 9th and 12th. 2013. Coming there is a unique chance this
year, to meet many …</p><p>As you might heard, we at Fedora had FUDCons (Fedora Users and
Developers conference), which is now replaced by a conference named
<a class="reference external" href="http://flocktofedora.com/">Flock</a>. The first one will be held in Charleston, South Carolina
between Aug. 9th and 12th. 2013. Coming there is a unique chance this
year, to meet many Fedora users and developers to come together, discuss
new ideas, work to make those ideas a reality, and continue to promote
the core values of the Fedora Community: Freedom, Friends, Features, and
First.</p>
<p>OpenStack is a somehow complex thing to setup and to integrate into
Linux distributions. Thus, I proposed an <a class="reference external" href="http://flock-lmacken.rhcloud.com/proposals#50">OpenStack testing hackfest at
Flock</a>, to test the latest build for Fedora, and also to bring users
and developers together into one room. Currently, it is not decided, if
this session is accepted, so please stay tuned.</p>