Using Flockport with Jiffybox   December 18th, 2014

I am interested in the idea of Flockport: providing ready built LXC containers for download. So I wanted to try to see how I can actually download a Flockport container and install it on a Jiffybox (the German equivalent to the American Linode…)

See also my old post: LXC Linux containers on JiffyBox running CentOS on Ubuntu

So, I install a Jiffybox with Ubuntu 14.04 64 bit operating system, 2 GB RAM.

Install lxc (currently 1.0.6) from the default Ubuntu repositories:

apt-get install lxc

Now to Flockport: Check out these pages, my next steps are based on the instructions there:

I chose the WordPress container as an example. See http://www.flockport.com/apps/wordpress/

I wanted to download the Debian Wheezy 64 Bit package called wordpress.tar.xz, but that does not work like that, because you need to be logged in.

Here comes the Flockport utility into play. It is currently in Alpha, but it works ok, even on Ubuntu, though it is only advertised for Debian:

To install the Flock utility, follow these steps:

wget http://repo.flockport.com/flockport.gpg.key
apt-key add flockport.gpg.key
echo "deb http://repo.flockport.com/debian wheezy main" > /etc/apt/sources.list.d/flockport.list
apt-get update
apt-get install flockport

Note that I am not installing lxc from the Flockport repository, but only the Flockport utility.

Some useful commands with the Flockport utility:

#shows all Flockport containers available
flockport list 
 
# login with your username and password for http://www.flockport.com/
flockport login
 
# download a container, the names were displayed by the list command above
flockport get wordpress

The Flockport utility will download the container, and extract it to /var/lib/lxc.

# shows the new container
lxc-ls -f
 
# start the container
lxc-start -d -n wordpress 
 
# now show the running container, and the currently used IP address:
lxc-ls -f 
 
#output:
#NAME      STATE   IPV4        IPV6  AUTOSTART
#-----------------------------------------------
#wordpress RUNNING 10.0.3.227  -     NO

To make this container accessible to the outside, you can use iptables:

containerIP=`lxc-ls -f -F name,ipv4 | grep wordpress | awk '{ print $2 }'`
interface=`cat /etc/network/interfaces | grep "auto" | grep -v "auto lo" | awk '{ print $2 }'`
HostIP=`ifconfig ${interface} | grep "inet addr" | awk '{ print $2 }' | awk -F ':' '{ print $2 }'`
iptables -t nat -A PREROUTING -d ${HostIP}/32 -i ${interface} -p tcp -m tcp --dport 80 -j DNAT --to-destination ${containerIP}:80
echo "make sure that mywordpress.org resolves to this HostIP: " ${HostIP}

If mywordpress.org resolves to the IP of your Jiffybox, then you can visit the WordPress installation by browsing to http://mywordpress.org

To change the domain name from mywordpress.org to the actual domain name that you want to use, you have to first go into http://mywordpress.org/wp-login.php, login with username admin and password flockport, change the password, and change in General Settings the WordPress URL and the Site URL to your desired domain name, eg. helloworld.org

You also have to change the Nginx configuration inside the container to replace the domain name with your actual domain name for your website:

# switch inside the container
lxc-attach -n wordpress
 
# unfortunately no vi available, but nano will do as well:
nano /etc/nginx/sites-available/mywordpress.org
 
# add helloworld.org or your domain name to the 4th line:
#    server_name mywordpress.org www.mywordpress.org helloworld.org;
# leave nano with Ctrl-X, and don't forget to save...
 
# reload nginx for the change of configuration to take effect
service nginx reload

Now you can reach the server on your own domain name, that points to your Jiffybox!

Tags: , ,
Posted in Software Development | Comments Closed

For OpenPetra, I wanted to build the installer for the Windows Remote Client on CentOS.

I know that NSIS (Nullsoft Scriptable Install System) is available for Debian, but I could not find a recent RPM package of NSIS for CentOS.

So I built my own RPM package for the latest stable version of NSIS, version 2.46, using the LightBuildServer. You can see the project here: http://lbs.solidcharity.com/package/tpokorra/nsis/nsis

The sources for the package are hosted at Github: https://github.com/tpokorra/lbs-nsis/tree/master/nsis.

You can install the RPM on CentOS 6 like this:

cd /etc/yum.repos.d/
wget http://download.lbs.solidcharity.com/repos/tpokorra/nsis/centos/6/lbs-tpokorra-nsis.repo
yum install nsis

I use this NSIS RPM package to build OpenPetra in this LBS job: openpetra-server-test, and the sources are available at Github: openpetra-server-test sources.

By the way, the installer source for the OpenPetra remote client can be found here: remote.nsi

Please let me know if you want me to build NSIS for other CentOS versions too.

The source rpm is available here: http://download.lbs.solidcharity.com/repos/tpokorra/nsis/centos/6/src/

Tags: , , ,
Posted in Software Development | Comments Closed

When I noticed that Novell does not offer RPMS of Mono 2.0 for RedHat Linux, I had a look at the Fedora 10 Beta and found that there is a Mono 2.0 Source RPM:
mono-2.0-6.fc10.src.rpm
Update: mono-2.0.1-12.fc10.src.rpm

Because we work with CentOS4/RedHat Enterprise Linux 4, I installed the source package on that system, and tried to build the rpms.

Building the code was fine after I deactivated a couple of dependencies.
But I ran into some problems at the file checking stage. I wondered if I can prevent the build stage to happen again and again. That way I should be able to debug the file list check etc.

Reading the man page, these parameters are interesting:

--short-circuit
--nobuild
-bi
-bl

So with rpmbuild -bl mono.spec I was able to just run the file checking stage.

The errors I got were like this:
rpm build errors: File not found: /var/tmp/mono-2.0-6-root-root/usr/bin/certmgr/usr/bin/chktrust/usr/bin/gacutil/usr/bin/gmcs/usr/bin/mcs/usr/bin/mcs1

But the files do exist in the /var/tmp/mono-2.0-6-root-root/ directory

I finally realised that the problem was caused by the Macros.
see also http://rpm.org/wiki/PackagerDocs/Macros
I had to first add curly brackets to each Macro call:
%{macro parameters}
But even then only the first line of the Macro had an effect.
This command was helpful in the files section to see that the Macros just were not resolved correctly:
%{echo: %{your_macro_here}}

In the end, I ended up adding the missing files to my own mono.spec file.
I also had a look at the last available RedHat spec file from Novell for Mono 1.9.x, and I guess there is a different rpm version for RHEL 4 and RHEL 5.

Here is my modified mono.spec file that works for RHEL4/CentOS4 for Mono 2.0:
http://download.pokorra.de/mono/mono.spec

Please download the src.rpm file from the Fedora 10 Beta, or later, and install it:
rpm -i mono-2.0-6.fc10.src.rpm
Then copy my modified mono.spec to /usr/src/redhat/SPECS, and build the packages:
rpmbuild -ba mono.spec

Alternatively, here is a zip file with the compiled RPM files for CentOS4/RHEL4:
mono-2.0-6.i386.rhel4.rpm.zip
I cannot guarantuee that it actually works, but feel free to use it for your own experiments!

Config files in RPM files   November 19th, 2007

see this very helpful description of RPM, %config, and (noreplace) by Jon Warbrick

all about when files are stored with extension .rpmnew or .rpmsave, and when the current file is actually replaced with the new file

Tags: , ,
Posted in Software Development | Comments Closed

Use patched files in RPMs   November 17th, 2007

see Packaging software with RPM

diff -uNr the_package/the_file \
the_package/the_file.new > the_file.patch

copy the patch file to /usr/src/redhat/SOURCES

The spec file has those lines:

After Sources:
Patch0: the_file.patch

After %setup, before %build

%patch -p1

To get your new version from the original file:
patch slapd.conf.template \
../../slapd.conf.template.patch \
-o slapd.conf.template.new

Tags: , ,
Posted in Software Development | Comments Closed

Package a Perl module   November 17th, 2007

First check if somebody did already the job, e.g. on artfiles.org RPMS (SRPMS) or just for RPMS: RPMPan or this search site: Linux Software Directory .

You need to install perl-Archive-Tar-1.08-2.noarch.rpm and perl-RPM-Specfile-1.17-1.noarch.rpm.
A description of the module perl-RPM-Specfile can be found on cpan.
Download this perl script, called cpan-to-rpm.pl. It is described as followed: “Grab a module from CPAN and sock it into an RPM using cpanflute2”
Call it this way:
perl cpan-to-rpm.pl \
authors/id/M/MU/MUIR/modules/Net-Netmask-1.9011.tar.gz
perl cpan-to-rpm.pl \
authors/id/D/DJ/DJKERNEN/Mail-IMAPClient-2.2.9.tar.gz

That will create
/usr/src/redhat/SRPMS/perl-Net-Netmask-1.9011-1.src.rpm
If you install it with
rpm -i /usr/src/redhat/SRPMS/perl-Net-Netmask-1.9011-1.src.rpm
you can build the rpm from it with
rpmbuild -ba /usr/src/redhat/SPECS/perl-Net-Netmask.spec
to see what an rpm provides: rpm -qlp --provides perl-LDAP-0.31-4.noarch.rpm

Tags: , , ,
Posted in Software Development | Comments Closed

The file list conversion from OpenPKG   November 17th, 2007

rpmtool:
One idea could be, to download the file from the OpenPKG CVS and save it to /usr/bin/rpmtool; you need to change the first line of that file to #!/bin/bash
Also add at the top of the spec file:

%define l_rpmtool /usr/bin/rpmtool

The other idea is, to install the OpenPKG source rpm of the package concerned:

/kolab/bin/openpkg rpm -i kolab-webadmin-0.4.0-20050318.src.rpm

In the /kolab/RPM/SRC/kolab-webadmin/kolab-webadmin.spec
insert after the l_rpmtool line:
cp files /usr/src/redhat/SOURCES/kolab-webadmin.files

Rebuild the package, which will create the kolab-webadmin.files:
/kolab/libexec/openpkg/rpmbuild -ba /kolab/RPM/SRC/kolab-webadmin/kolab-webadmin.spec

Perhaps need to change the paths, e.g. for perl:
in vi:

:%s/\/kolab\/lib\/perl\/vendor_perl\/5.8.5/\/usr\/lib\/perl5\/vendor_perl\/5.8.3/g

You need to put it into an archive:
cd /usr/src/redhat/SOURCES/
tar cvf kolab-webadmin.files.tar kolab-webadmin.files

In the fedora spec file, /usr/src/redhat/SPECS/kolab-webadmin.spec, you would add in the sources:
Source1: kolab-webadmin.files.tar

In the %prep section, insert:
%setup1 -D -T -b 1 -n kolab-webadmin-%{version}
As the parameter for -n, give the name of a directory that is created for the main tar file anyway.

In the %install section, remove the rpmtool lines; instead, you change the %files line:
%files -f ../kolab-webadmin.files

Tags: , , , ,
Posted in Software Development | Comments Closed

have a look at Building Packages with OpenPKG
See /usr/local/kolabopenpkg/etc/openpkg/rpmmacros to know what the macros (e.g. %l_musr) mean.

To get the spec file, install the OpenPKG source package:

/kolab/bin/openpkg rpm -i kolab-webadmin-0.4.0-20050318.src.rpm

Copy the /kolab/RPM/SRC/kolab-webadmin/kolab-webadmin.spec to /usr/src/redhat/SPECS;
Copy the other files (e.g. .tar.gz archives) to /usr/src/redhat/SOURCES

One special thing is that the required packages in OpenPKG don’t only include the package name and required version number, but often also options that were included when configuring and building the package.
For example, cyrus-sasl::with_ldap would require that the cyrus-sasl::with_ldap is advertised in the Provides: tag in the spec file.
A common approach is not to advertise all compiling options, but to know the packages and test them thoroughly.

Remove the line:
Class: JUNK

To understand some of the macros, in the form %{something}, have a look at /usr/lib/rpm/macros and /usr/local/kolab/etc/openpkg/rpmmacros.

Insert these lines near the top:

%define l_prefix /kolab
%define l_make %{__make}
%define l_mflags -m
# m actually is ignored, compatibility

Replace all occurances of “apache” with “httpd” in your spec file.

It seems, the spaces before the %setup -q are not correct. Remove them!

Lines like %{l_shtool} install: just remove all the %{l_shtool}; install should work fine;
remove also the %{l_value -s -a} (though I am not sure what those characters stand for)

Tags: , , , ,
Posted in Software Development | Comments Closed

Quick RPM lookaround   November 17th, 2007

April 2005:
That is how I learnt about RPM packaging of software for Fedora Linux.
My goal was to create Fedora packages for Kolab, which is packaged with OpenPKG.

Links to RPM introductions

Basic Idea of SRPMS

rpm -i some-package-0.0.1.src.rpm
will put some tar file(s) and patches in /usr/src/redhat/SOURCES; and will put the some-package.spec file in /usr/src/redhat/SPECS
to build the src.rpm and the rpm, run
rpmbuild -ba /usr/src/redhat/SPECS/some-package.spec
That will create the files /usr/src/redhat/SRPMS/some-package.src.rpm and /usr/src/redhat/RPMS/i386/some-package.rpm.

Tags: , ,
Posted in Software Development | Comments Closed

Kolab Groupware Calendaring   January 18th, 2004

January 2004
See my kolab groupware calendaring pages

I wrote this documentation while trying to setup a working groupware calendaring solution. It is basically a log of this process, including the problems that I came across, and how I solved it, often with help from helpful people from the associated projects. I hope this text can help other people who will have the same problems. Some portions of this text are tailored for the server environment (SLS) of OM, the organisation that I work for.

Tags: , , ,
Posted in Software Development | Comments Closed