Archiv der Kategorie: Linux

Linux Topics

Compile rtl8812au Driver on Raspbian (Kernel 3.18.5+)

I tried the everywhere mentioned method with https://github.com/gnab/rtl8812au, but this was not working as expcected. Therefor I tried the method mentioned on the Fedora Mailing List. This does not contain the patches for the Raspberry PI. The Makefile needs to get adopted, so that you can compile this driver on the Raspberry Pi.

The compile seems to work now. I have uploaded all sources to Github. In this repository is also the 8812au.ko, which is compiled on a Raspbian Box with Kernel 3.18.5+. Hope this will work out now.

Install Gollum with Unicorn and nginx

I just documented on how to install gollum on an ArchLinux machine using Unicorn and an nginx reverse proxy. This documentation provides detailed installation instructions as well as config files.

One of the requirements I had, was to be able to run multiple instances of gollum, as well as using systemd to start and stop these instances easily. There is a gollum package in the AUR, but this does use the webRick, and therefor I decided to start from scratch.

My UPNP Stack

Hello,

i have already witten, that I am ripping my whole CD collection (see discogs for the already ripped collection). I have written a for tagging my collection and this is working great.

To play music on my stereo, I thought, that UPNP is a great protocol for it. The stack I am currently using is involving the following toolset:

Please note, that parts of this stack are replaceable through other components, but this stack is right now the best working (at least for me). All components do use the UPNP enhancements from OpenHome, which is an OpenSource Project of Linn, IIRC.

The MediaRenderer could be replaced by UPMPDCli, a nice UPNP Frontend for MPD (my favourite Music Player. But then you should also use BubbleUPNPServer to enjoy all the benefits of the Openhome extensions.

MediaPlayer is using MPD or MPlayer to be able to play the music. MPD do offer quite some extensions, which still can be used with the above mentioned environment.

One Extension is LCD4Linux, which allows to show some information about the current played song on a small LCD. This is working on my Raspberry, but unfortunately this also seems to have some problems, in that the Display just freezes and the whole Box needs to get restarted. Since the used display is also very small (see Pearl Display) I decided to invest some more time and money into something slightly larger (see TaoTronics Display, Power Supply, HDMI to Component Adapter as well as a couple of additional needed cables (MiniHDMI, Component…)). I do hope that this is going to work out. For this stack, LCD4Linux is not needed anymore, since this is a „normal“ Screen. Therefor I plan to integrate a Full-Screen Display component into the MediaPlayer. As soon as this is finished, I will report back, right now I am still waiting, that all the above mentioned components do arrive.

On the beginning of my UPNP discoveries, I stumbled across the X10, which is also a nice toy, but unfortunately does not support gapless UPNP playback (see X10 Forum (German)). Unfortunately I needed to buy this device to discover this one ;-( It is still a nice playing toy, but right now is just used for Internet Radio Streaming, since even the Tagging I did with DiscogsTagger is totatlly screwed on this device and the X10 is showing me the albums in totally different format then shown eg. on minimserver.

So, you could buy yourself some expensive devices from Linn, Naim or …, or you spend you money on some decent Hardware like Raspberry PI (uh, the sound of this device is not realy good, without the addition of a good DAC like HifiBerry) or a Cubox-I and invest some time in installing the above mentioned stack, then all should be fine, without spending too much Money as well as time.

What do I want from my personal NAS

In this post I would like to gather some personal requirements for a NAS System I am going to build.

Right now, I am in the process of ripping all my CDs (around 950 unique releases – More than half of it is already finished). The target is to store all these releases on a personal NAS with the ability to stream those to my stereo. For this I have already selected minimserver as the UPNP-Server. This server has the requirement of a JDK to let it run. Therefore the NAS I am going to build must have the ability to run JAVA.

Since I am already using Linux quite heavily I do not like to let FreeNAS or NAS4Free run on this NAS, also I am very interested in the underlying File System (ZFS) and/or FreeBSD.

Since Linux offers a “similar” File System (btrfs) I would like to use this one for the NAS.

The services which I would like to run on the NAS are then the following:

There some other options, which would be nice, but are not as “necessary”. There is e.g. Ajenti, which provides a nice WebGUI for the administration of the NAS, but this does not really correspond to the way Arch Linux works 😉 A possibility would be to use e.g. CentOS or
Ubuntu as a distro, but I am unsure, if this is really going to work out, just for a nice GUI????

The above mentioned requirements are not really tough for todays hardware and therefor I would like to stick to the Stack provided in the nas-portal forum (see here).

Since I am going to use a filesystem, which seems to be picky about power outages, I am in need of a UPS, and I am currently thinking about this one.

So I am going to explain some more interesting stuff about the tagging of my FLACs for the minimserver and about the used tool (discogstagger) in some future posts. Stay seated, so that you can see how an absolute Hardware Noob tries to build his own NAS 😉

nodejs version 0.8.x instead of 0.10 on ArchLinux

Right now, I am developing a node application. Since we are using 0.8 and on ArchLinux 0.10 is installed if figured to install nave and n. This is all working fine, as long as I am not using a binary npm package, like node-expat. To install this, I needed to remove the node_modules folder after the change of the node version, and furthermore I needed to define the python-version. The install of packages is then possible with the following command:


npm install --python=/usr/bin/python2

Sympa Mailinglist Server on CentOS 6.4 using PostgreSQL

To install Sympa on a CentOS 6.4 machine is not as easy as one would expect. I found this entry in one of the mailing lists, and I have to admit, it works like a charm 😉

So, here once again, for reference:


cd /etc/yum.repos.d
wget http://sympa-ja.org/download/rhel/6/sympa-ja.org.rhel6.repo

cd /var/tmp
wget http://dl.fedoraproject.org/pub/epel/6/x86_64/epel-release-6-8.noarch.rpm
rpm -i epel-release-6-8.noarch.rpm

yum install sympa-httpd

Review /usr/share/doc/sympa-6.1.17/README.RPM-install

After this, I needed to install a RDBMS, and since I do prefer PostgreSQL I installed it (using the tutorial from here) via:


yum install postgresql postgresql-server postgresql-contrib postgresql-devel

# Initialize database directory
service postgresql init

# Start service
service postgresql start

# create sympa db
su postgres
>createdb sympa
>psql sympa
>>CREATE ROLE sympa WITH SUPERUSER LOGIN PASSWORD 'sympa';
>>\q
>exit

Furthermore, I adopted the file pg_hba.conf:


#host all all 127.0.0.1/32 ident
host all all 127.0.0.1/32 md5
#host all all ::1/128 ident
host all all ::1/128 md5

To check, if the connection is working, try:


psql -h localhost -U sympa sympa

Also the perl package DBI:Pg is needed for the connection of sympa to postgres.


yum install perl-DBD-Pg

After all these preparations, we are going to install sympa.


sympa_wizard.pl

Note, that it is possible to change the made settings in the /etc/sympa/sympa.conf file. Since we are using PostgreSQL we do have to adopt the setting db_port in this file to 5432.

To create the DB correctly (basically, the DB is already created above), I had to comment out the database creation in the file /usr/share/sympa/bin/create_db.Pg:


--CREATE DATABASE sympa;

Unfortunately the script sympa.pl --create_db was not working correctly for Postgresql, and therefor I tried to run the DB creation script manually:


psql -h localhost -U sympa sympa
>\i /usr/share/sympa/bin/create_db.Pg
>\q

After this, everything seemed to be alright 😉 And another thing, CentOS seems to be pretty restrictive, so please stop iptables or adopt the settings, otherwise it is not possible to connect to the server from the outside.

Not everything is alright here, I needed to change some of the premissions of the fcgi-Scripts in /usr/libexec/sympa as well as the description for the file /etc/sympa/sympa.conf. Furthermore centOs is making heavy use of SELinux, therefor some additional settings need to get applied:


setsebool -P httpd_can_sendmail 1

Since I am using this only in a virtual box, I disabled SELinux completely, therefor the above statement is not necessary at all anymore.

After all this, sympa is still running in maintenance mode, because of several permission restrictions of sympa (which are fine for productions environments, but for a development environment these are just nasty). Therefor I followed this guide (specifically: run apache as the user sympa).

Btw, if you wander, why the heck CentOS is now on my list of OSes, this is mainly to work with the same environment like my hoster and on ArchLinux I did have a lot of trouble to install Sympa as well ;-( I am working with Sympa now in a VBox, so that it does not disturb my normal system usage.

SparkleShare Dashboard

Today I wanted to install SparkleShare-Dashboard on my Linux Laptop. I was pretty glad, since it is a nodejs application and the target plattform, where I would like to install this application finally, will be a nodejs system (ArchLinux ARM) as well.

To install SparkleShare Dashboard on the latest nodejs-Version (v0.8.4) I had to adopt the Git-Child-Process creation in the backend/git.js-Module. For the full working version, please see .

There is also a little „difficulty“ and probably a miss-understanding in the community of how to create a „SparkleShare-Git-Repository“. I have done it, therefore please find a step-by-step guide:


mkdir -p /home/USERNAME/sparkle/public.git
cd /home/USERNAME/sparkle/public.git
git init --bare
mkdir /home/USERNAME/tmp
cd /tmp
git clone file:///home/USERNAME/sparkle/public.git
cd /tmp/public
touch README.txt
git add README.txt
git commit -m "Initial commit"
git push origin master
cd ..
rm /tmp/public -rf

This should be it, you do have an initial commit in the repository, and therefor SparkleShare can attach the id to the repository (the id is the SHA1-id of the first commit in the repository).

Java 7 – minor classloading difficulties

Since I am using Arch Linux, I am more then accustomed to using the latest and greates versions of all the stuff. Unfortunately this is not always very good. During the last couple of days I experienced a couple of class loading issues with Java 7 (as opposed to Java 6).
I am currently testing Broadleaf Commerce and had to report an issue to theses guys because of some problems I did receive during compilation and running this application. Something similar happened to me on my project at work as well. I call this „class loading issues“, but it is probably slightly more. I do have problems loading configuration data correctly. (see issue 96 on the Broadleaf JIRA)-
To work around this issue, I just installed Java 6 again. Now it is working like a charm.

Howto structure the Git-Repository (of ArchServer.org)

Hello,

a little while ago, I felt the urge to propose a new git structure to my fellows at the ArchServer.org team. I guess the explanation on the why could be helpful for others in the git community as well.

Currently we do have one repository with several packages in one git repository (server-core, server-extra, server-community). This was due to the fact, that the base-distribution (Arch Linux that is) uses SVN as their VCS and we were basically migrating their structure in an easy manner to our own systems.

Right now, we have one branch for each named release (e.g. redgum). Since we are planning to maintain at least two named releases (e.g. redgum and spruce) in parallel, and we have also a testing phase in each release, I suggested two branches for a named release (redgum, redgum-testing). This suggestion was accepted in the mailing list.

I have looked, how other distros with a named release are doing it, as well as for best practices in the git world (well, I really did this for the company I do work for). Fedora is using Git as their repository as well, and git is quite popular, so there is a wealth of information on this topic out there.

PROPOSAL

I propose to restructure the ArchServer.org git repositories to the following structure:

server-core.git/kernel26-lts –> server-core/kernel26-lts.git
server-core.git/aif –> server-core/aif.git

In each of those newly created repositories we will then create at least two branches (e.g. redgum and redgum-testing) for each release. The master-Branch is a special branch, in that it is a development branch. Changes in there will go into release branches, but packages from the master-branches will never be put into a release-version directly. Packages always need to get created from the corresponding release branch, to establish a clean workflow for sign-offs of packages.

To let this work, we will need to adapt our dbscripts slightly, but this should not be too much of a hassel. The git repository could be restructured pretty much automatically and the current already available history could be migrated as well.

Furthermore I suggest to use a tool like repo or fedpkg, adapt it to our needs and implement this into our workflow. Package Updates can then be still done via the usual git commands, but to get a friendlier workflow, this tool can be used.

EXPLANATION

Let me first explain, why do we want to separate each package into its own repository like suggested by git and other distros like e.g. Fedora.

Git suggests to use a single repository for each project/package (a short explantion of this issue can be found on StackOverflow). Basically it comes to the point, that the usage of a repository per package is a best-practice in the git world, and best-pratices do have a sense, like shown in the previous link.

So where is our benefit in splitting repositories (server-core, server-extra and server-community) into several smaller ones (e.g. server-core/kernel26-lts.git)? IMHO the benefit is ease-of-use.

A TU (Trusted User) can then easily get one package, switch to the correct branch (e.g. redgum-testing) make the changes and push these changes back to the main repository. As soon as the package is out of the testing phase, the TU or somebody else can sign-off the changes and merge the package into the release branch (e.g. redgum). We could even say, that only signed packages are allowed to cross the border of the branches, I am unsure, if this could be done by git itself, but it could be a step in the workflow.

So, where is the difference now to the current structure?

Right now, as soon as a TU has made changes and pushed them into the right branch, other TUs will most probably work on other (or even the same) packages, meaning that the TU cannot easily go to the package and merge it into the release branch, he would merge all changes in the whole repository into the branch. The TU has the burden to look up the right commit-ID in the log of the whole repository (remember, git looks on the whole repository and not on sub-folders) and cherry-pick this change (even worse: changes). This does not seem to be right IMHO and it is against the best-practice.

If we are going to split all our repos (server-core, …) into several smaller git repositories, the look and feel of our repository handling will change slightly. To provide a consistent approach for all repositories (e.g. make a new branch for a new release), we will have to provide some tool to make the life of the TUs easier, thats what google is doing with repo and Fedora is doing with fedpkg (see: https://fedorahosted.org/fedora-packager/browser/src/fedpkg.py). These tools offer some functionality not possible with git (at least as far as I know of, see: StackOverflow) like branching of several sub-projects, using the same branch for all sub-projects, committing changes in several sub-projects, etc. Also, there does exsits another alternatives (like git subtree, see: Git Subtree Documentation), these do not fit our needs very well.

Another advantage of this new structure is, that it could be used for automatic builds of packages as well. Right now, pkgbuild.com for example, starts a new build of a package by request. In the software engineering world there is something that is called Continuuous Integration (CI), which builds a package as soon as a change in the repository appears. The tool I am using for this right now (Hudson/Jenkins) does support the build of unix packages as well, so in the long run, it could be worthwhile to investigate this for our use-case as well.

So, WDYT? What are your thoughts on this one? I guess, that this is the way to go, even though it is not for RC4 or even redgum, but soon afterwards, I would suggest is the latest to implement this approach.