Seit Juli 2017 unterstützt Hostsharing die automatische Verwaltung von Let’s Encrypt Zertifikaten für einzelne Domains und auch Subdomains.

In diesem Post soll es um die Wildcard Zertifikate gehen, die Let’s Encrypt seit März 2018 ausstellt. In meinem Fall brauche ich ein Wildcard Zertifikat für das Massenhosting von OpenPetra. Die Domain wird bei Hostsharing verwaltet, aber die Server laufen bei TBits.net, also muss ich die Zertifikate nicht bei Hostsharing einrichten. Wildcard Zertifikate werden nicht über HTTP authentifiziert, sondern über DNS. Daher muss ich also bei Hostsharing die Einträge im DNS vornehmen.

Ich habe nach einem leichtgewichtigen ACME Client gesucht, der Wildcard Domains unterstützt. Dabei bin ich auf acme.sh gestoßen, das als Shell Script (bash, dash, sh kompatibel) geschrieben ist, und auf Github gehostet ist.

Installiert wird es mit diesem Befehl:

curl https://get.acme.sh | sh

Es wird dadurch ein Verzeichnis ~/.acme.sh angelegt und mit entsprechenden Dateien gefüllt, weniger als ein MB.

Hier ist eine Anleitung für manuelle Konfiguration über DNS: https://github.com/Neilpang/acme.sh/wiki/dns-manual-mode

Der erste Aufruf sieht so aus, für die Domain openpetra.com:

~/.acme.sh/acme.sh  --issue  -d '*.openpetra.com'  --dns --yes-I-know-dns-manual-mode-enough-go-ahead-please
Die Ausgabe sieht dann in etwa so aus:
[Tue Sep 25 23:08:42 CEST 2018] Creating domain key
[Tue Sep 25 23:08:42 CEST 2018] The domain key is here: /home/pacs/tim00/users/.../.acme.sh/*.openpetra.com/*.openpetra.com.key
[Tue Sep 25 23:08:42 CEST 2018] Single domain='*.openpetra.com'
[Tue Sep 25 23:08:42 CEST 2018] Getting domain auth token for each domain
[Tue Sep 25 23:08:43 CEST 2018] Getting webroot for domain='*.openpetra.com'
[Tue Sep 25 23:08:43 CEST 2018] Add the following TXT record:
[Tue Sep 25 23:08:43 CEST 2018] Domain: '_acme-challenge.openpetra.com'
[Tue Sep 25 23:08:43 CEST 2018] TXT value: 'nrsGiN7Yb4R8eYxx7RNRAP8x6MA2zTrgbCLemD1t7aB'
[Tue Sep 25 23:08:43 CEST 2018] Please be aware that you prepend _acme-challenge. before your domain
[Tue Sep 25 23:08:43 CEST 2018] so the resulting subdomain will be: _acme-challenge.openpetra.com
[Tue Sep 25 23:08:43 CEST 2018] Please add the TXT records to the domains, and re-run with --renew.
[Tue Sep 25 23:08:43 CEST 2018] Please add '--debug' or '--log' to check more details.
[Tue Sep 25 23:08:43 CEST 2018] See: https://github.com/Neilpang/acme.sh/wiki/How-to-debug-acme.sh

Nun muss ich diesen TXT record für die Domain openpetra.com einrichten.

Ich muss zuerst eine Datei im Verzeichnis ~/doms/openpetra.com/etc einrichten, mit dem Namen pri.openpetra.com. Der Inhalt sieht in etwa so aus:

{DEFAULT_ZONEFILE}
$TTL 60M
 
_acme-challenge.openpetra.com.  3600  IN  TXT  "nrsGiN7Yb4R8eYxx7RNRAP8x6MA2zTrgbCLemD1t7aB" 
 
www       IN  A {DOM_IPNUMBER}
op012345  IN  A 178.123.12.123

Nach etwa 3 Minuten sieht man in der Datei /var/log/named/named.log, dass die eigene Domain aktualisiert wurde.

Dann kann der zweite Schritt mit acme.sh ausgeführt werden:

~/.acme.sh/acme.sh  --issue  -d '*.openpetra.com'  --dns --yes-I-know-dns-manual-mode-enough-go-ahead-please --renew

Die Ausgabe sieht wie folgt aus:

[Tue Sep 25 23:09:54 CEST 2018] Renew: '*.openpetra.com'
[Tue Sep 25 23:09:55 CEST 2018] Single domain='*.openpetra.com'
[Tue Sep 25 23:09:55 CEST 2018] Getting domain auth token for each domain
[Tue Sep 25 23:09:55 CEST 2018] Verifying:*.openpetra.com
[Tue Sep 25 23:09:58 CEST 2018] Success
[Tue Sep 25 23:09:58 CEST 2018] Verify finished, start to sign.
[Tue Sep 25 23:10:00 CEST 2018] Cert success.
-----BEGIN CERTIFICATE-----
...........entfernt.................
-----END CERTIFICATE-----
[Tue Sep 25 23:10:00 CEST 2018] Your cert is in  /home/pacs/tim00/users/..../.acme.sh/*.openpetra.com/*.openpetra.com.cer 
[Tue Sep 25 23:10:00 CEST 2018] Your cert key is in  /home/pacs/tim00/users/..../.acme.sh/*.openpetra.com/*.openpetra.com.key 
[Tue Sep 25 23:10:00 CEST 2018] The intermediate CA cert is in  /home/pacs/tim00/users/..../.acme.sh/*.openpetra.com/ca.cer 
[Tue Sep 25 23:10:00 CEST 2018] And the full chain certs is there:  /home/pacs/tim00/users/..../.acme.sh/*.openpetra.com/fullchain.cer 
[Tue Sep 25 23:10:01 CEST 2018] It seems that you are using dns manual mode. please take care: The dns manual mode can not renew automatically, you must issue it again manually. You'd better use the other modes instead.
[Tue Sep 25 23:10:01 CEST 2018] Call hook error.

Ich kopiere nun die Dateien *.openpetra.com.key nach wildcard.openpetra.com.key und fullchain.cer nach wildcard.openpetra.com.crt auf den Produktionsserver, und binde sie im Nginx ein:

    ssl_certificate /var/lib/certs/wildcard.openpetra.com.crt;  
    ssl_certificate_key /var/lib/certs/wildcard.openpetra.com.key;

Da das Zertifikat nur für 3 Monate gültig ist, habe ich eine automatische Erinnerung
in meinem Kalender eingerichtet, die mich alle 2 Monate daran erinnert, das Wildcard Zertifikat zu erneuern.

Tags: , , , ,
Posted in Hosting | Comments Closed

This is an update to the post http://www.pokorra.de/2014/12/packaging-nsis-nullsoft-installer-for-centos-rpm/

NSIS (Nullsoft Scriptable Install System) “is a professional open source system to create Windows installers.”

NSIS 3.0 has been released on 25th July 2016: http://nsis.sourceforge.net/News

I have now packages for CentOS7 and Fedora 24: https://lbs.solidcharity.com/package/tpokorra/nsis/nsis. You can find instructions on that page how to install the rpms.

The sources for the package are available here: https://github.com/tpokorra/lbs-nsis/tree/master/nsis

I am using this for example to build nightly installers for OpenPetra standalone for Windows, and the build happens on CentOS7: https://lbs.solidcharity.com/package/tpokorra/openpetra/openpetranow-standalone-nightly. The sources for the installer can be found here: standalone.nsi

 

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

OpenPetra standalone and SQLite   July 30th, 2014

I have seen on the OpenPetra IRC logs that there have been discussions about SQLite related to the new 0.3.0 release.

2 main points:

  1. functionality does work with PostgreSQL, but not with SQLite
  2. no documented upgrade path for SQLite, which is used in OpenPetra standalone

Regarding the first point:

I think it is good to support several databases, because it helps to find bugs, or unclean development. For example PostgreSQL is not so strict with transactions, but SQLite shows us when the transactions have not been opened correctly.

Another advantage: In the future there might be support for even more databases, for example MS-SQL. Then we will be in trouble with SQL code that uses PostgreSQL specific syntax. So it is good to find these problems now and solve them when the developer who wrote the SQL still knows about it.

To solve these issues, I think it is important to maintain automated integration for the winform screens. After all, we have a nightly build of the integration tests every night running against both PostgreSQL and SQLite separately. That way we should find such issues quite soon.

The second point, with the upgrade path:

There has been work on doing an upgrade of the database during the installation of the new OpenPetra standalone version, see http://www.openpetra.org/fifteenth-preview-release-of-openpetra-org and https://tracker.openpetra.org/view.php?id=113

Unfortunately, this caused too much trouble, and since the standalone installer is only intended for demo purposes, we did not support this upgrade functionality any longer.
For the longterm, the question is anyway whether the standalone installer should be maintained by the community and not by OM anymore, since OM focuses on the client/server solution with PostgreSQL rather than SQLite for production. When we had the discussions about the web services branch, support for the current standalone installer would have been dropped anyways by OM, because that would still quite some work to make it work with the single exe application.

Currently the only way is to export the data in the OpenPetra client of the previous version (login as user SYSADMIN, go to SystemManager, Database, Import/Export, Export all Data).

Then install the new OpenPetra standalone. You would get this message box when starting OpenPetra:

Unsupported upgrade: Please rename the file C:\Users\tpokorra\AppData\Roaming\OpenPetra.org0.2.28.1\db30\petra.db so that we can start with a fresh database!
Please restart the OpenPetra Client after that.

So follow this instruction, and start with a fresh database. Login with user SYSADMIN again, and import your database that you just exported earlier (SystemManager, Database, Import/Export, Restore Database from Backup)

I am personally more interested in hosting OpenPetra in the future on my own servers for free for individuals or a small hosting fee for organisations. Therefore I am not going to invest a lot into the Standalone installer.

Tags: ,
Posted in Software Development | Comments Closed

I have been reading the book “Producing Open Source Software – How to Run a Successful Free Software Project” by Karl Fogel over the past weeks. It is available for free here: http://producingoss.com/

I especially liked the chapters about being open:

Fogel’s point is that if you want to run your project as an open source project, it is better to start early with being open, ie. to have your code publicly available, have discussions in the public, offer demo data for everyone to use, etc.

Please read the short paragraphs linked above, they are well worth reading!

I think we have been quite ok with the OpenPetra project regarding these points:

  • we have a nightly build of the standalone installer
  • we have several demo databases
  • we have a public bug tracker
  • we have an IRC for immediate discussion (although only during working hours in Europe)
  • we have a public wiki and a public forum for discussions
  • we have quarterly (?) news updates on the announcement mailinglist
  • we have Twitter integrated on the website, which is irregularly updated with news items
  • the weekly phone conference is open on invitation basis
  • … and probably some more points that I did not think of at the moment but are still important!

Unfortunately, since Sourceforge did shutdown the hosted applications, our wiki and forum are available only read-only.

My suggestion for the future: Since the forum was not much frequented, I think it might be enough to have a mailinglist where all developers are subscribed. Sourceforge still offers free mailinglists. Mailinglists are the most common way of discussion among developers in the open source community. For users perhaps a forum is more common, but we are not there yet at this point. We can create a separate mailinglist or forum for users when the time comes that we have users of OpenPetra.

I also want to say why I think especially for OpenPetra it is very important to being open:

In the past years, there has been discouragement because the project has invested into potential volunteering developers a lot, but then they vanished before even committing a single line of code. Or they have committed code, that had to be reverted because of poor quality or other misunderstandings.
This makes my point: most of the time, the conversation with these people was in private, not in public. So there was no chance of a peer review from other developers. This might have excluded the new people from the developer community, and they did not get positive feedback. And all the conversation is lost, no other potential developer can learn from it, and for the next person you would have to do it all over again.

Please can we continue to be open in the OpenPetra project, and become better at it!

It saves us all a lot of time, and encourages everyone! You can see what is happening. This also makes the project interesting for outsiders and potential contributors.

I think, one single organisation needs to put in a lot of resources, to make such a huge project like OpenPetra happen. It is worth the effort of being open, if eventually other organisations or individuals get drawn in and share the work load.
This is a gradual process of course, but it is worth continuing it.

Tags: , ,
Posted in Software Development | Comments Closed

This is an updated version of the post Install OpenPetra.Now 2014-05 on CentOS5.

Now we are installing on CentOS6, and using my own LBS repository. OpenPetra.Now is now using the unmodified Mono-opt packages.

OpenPetra.Now is a tagged revision of the official OpenPetra, plus some patches which have not made it into the official OpenPetra yet. This includes a replacement of .Net remoting with https webservices, and a plugin system.

These are the instructions:

Install the Epel repository, the Postgresql repository and my OpenPetra repository.

For Postgresql, have a look here: http://yum.postgresql.org/repopackages.php#pg92

Epel Repo (for lighttpd): see http://mirror.de.leaseweb.net/epel/6/x86_64/repoview/epel-release.html

For the mono-opt repository, have a look here:
http://lbs.solidcharity.com/detail/tpokorra/mono/mono-opt

rpm -Uhv http://yum.postgresql.org/9.2/redhat/rhel-6-x86_64/pgdg-centos92-9.2-6.noarch.rpm
rpm -Uhv http://mirror.de.leaseweb.net/epel/6/x86_64/epel-release-6-8.noarch.rpm
cd /etc/yum.repos.d/
wget http://lbs.solidcharity.com/repos/tpokorra/mono/centos/6/lbs-tpokorra-mono.repo
wget http://lbs.solidcharity.com/repos/tpokorra/openpetra/centos/6/lbs-tpokorra-openpetra.repo

Now install the packages (this will automatically also install the packages mono-opt, postgresql92, lighttpd and some other dependencies):

yum install openpetranow-server

Now configure the OpenPetra server, and start it:

/etc/init.d/openpetra-server init
chkconfig openpetra-server on

To test the server, connect to http://<yourhostname>/openpetra9000/serverSessionManager.asmx

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

OpenPetra.Now is a tagged revision of the official OpenPetra, plus some patches which have not made it into the official OpenPetra yet. This includes a replacement of .Net remoting with https webservices, and a plugin system.

For an installation which involves upgrading from the old Petra 2.3 every night, I had to install OpenPetra.Now on a CentOS5 based system.

These are the instructions:

Install the Epel repository, the Postgresql repository and my OpenPetra repository.

If you have a 64 bit system, the links will be different.

For Postgresql, have a look here: http://yum.postgresql.org/

For the mono-openpetra repository, have a look here:
http://software.opensuse.org/download/package?project=home:tpokorra:openpetra&package=mono-openpetra

rpm -Uhv http://dl.fedoraproject.org/pub/epel/5/i386/epel-release-5-4.noarch.rpm
rpm -Uhv http://yum.postgresql.org/9.2/redhat/rhel-5-i386/pgdg-centos92-9.2-6.noarch.rpm
cd /etc/yum.repos.d/
wget http://download.opensuse.org/repositories/home:tpokorra:openpetra/CentOS_CentOS-5/home:tpokorra:openpetra.repo

Now install the packages (this will automatically also install the packages mono-openpetra, postgresql92, lighttpd and some other dependencies):

yum install openpetranow-server

Now configure the OpenPetra server, and start it:

/etc/init.d/openpetra-server init
chkconfig openpetra-server on
Tags: , , ,
Posted in Software Development | Comments Closed

This blog post is a repeat of an email that I sent to the Mono mailing list back in July 2013:
http://lists.ximian.com/pipermail/mono-list/2013-July/050114.html

The problem is that there are no recent packages for the major Linux distributions offered at http://www.go-mono.com/mono-downloads/download.html and http://monodevelop.com/Download

I personally use Mono and MonoDevelop for developing and deploying OpenPetra, an open source accounting and contact management system for charities and missions organisations.

I am using the OBS (Open Build Service) from build.opensuse.org to build recent packages of Mono and MonoDevelop for the Linux distributions CentOS, Fedora, Debian, Ubuntu, and openSUSE.

The installation for MonoDevelop is documented here:

http://software.opensuse.org/download/package?project=home:tpokorra:mono&package=monodevelop-opt
This will install Mono as well.

I also have builds of the Beta and the Alpha versions of MonoDevelop.

If you only want to install Mono, see here:

http://software.opensuse.org/download/package?project=home:tpokorra:mono&package=mono-opt

There are also packages for mono-xsp, mod_mono and mono-tools (including monodoc).

Package mono-libgdiplus makes sure that the libgdiplus is linked properly, which is important for GUI applications.

Since you have the right repo from installing Mono already, you can just run this:

#for RPM based distros:
yum install mono-libgdiplus-opt mod_mono-opt mono-xsp-opt mono-tools-opt

or (please note slightly different name for mod_mono-opt, somehow Debian does not like the underscore in the package name…)

#for Debian based distros:
apt-get install mono-libgdiplus-opt modmono-opt mono-xsp-opt mono-tools-opt

MonoDevelop and Mono (and the other mono specific packages) will be installed to /opt to avoid conflict with the Mono version that comes with your Linux distribution.

To run this Mono on the command line, you can add this line to your .bash_profile file:

 . /opt/mono/env.sh

If you are interested in the way how the packages are built, have a look here: https://build.opensuse.org/project/show/home:tpokorra:mono

Install OpenPetra on Linux   November 15th, 2013

Installing OpenPetra on Linux should be fairly easy.

Please note that the server works fine on Linux, but the client is not yet fully reliable. But the more interest and fixes it gets, the chances are higher that the client will become stable on Linux too.

We need for the server a patched version of Mono, for the .Net remoting. In the future we aim to switch away from .net remoting to https, but that is still experimental.
The client should be fine with Mono 2.10 upwards.

Install Mono 3.2.3 with OpenPetra patches:
The mono-openpetra package is available for Debian, Ubuntu and CentOS from http://software.opensuse.org/download.html?project=home%3Atpokorra%3Aopenpetra&package=mono-openpetra.
Please follow the instructions there for installing Mono.

I will do this tutorial with Ubuntu LTS 12.04 (precise):

wget http://download.opensuse.org/repositories/home:tpokorra:openpetra/xUbuntu_12.04/Release.key
apt-key add - &lt; Release.key echo 'deb http://download.opensuse.org/repositories/home:tpokorra:openpetra/xUbuntu_12.04/ /' &gt;&gt; /etc/apt/sources.list.d/mono-openpetra.list
apt-get update
apt-get install mono-openpetra

Next thing is to install Postgresql 9.1:

apt-get install postgresql

Now you download the latest release of OpenPetra for Linux from Sourceforge OpenPetra Downloads:

wget http://sourceforge.net/projects/openpetraorg/files/openpetraorg/OpenPetra.org%20Alpha%200.2/openpetraorg-server-debian-postgresql-MyOpenPetra-0.2.26.4.tar.gz/download -O openpetraorg-server-debian-postgresql-MyOpenPetra-0.2.26.4.tar.gz

There is also a package available for CentOS/RedHat based distributions:

wget http://sourceforge.net/projects/openpetraorg/files/openpetraorg/OpenPetra.org%20Alpha%200.2/openpetraorg-server-centos-postgresql-MyOpenPetra-0.2.26.4.tar.gz/download -O openpetraorg-server-centos-postgresql-MyOpenPetra-0.2.26.4.tar.gz

By the way, the code for this release is currently maintained here: https://github.com/openpetra/openpetra/tree/Alpha-0.2.26-Linux

Now, unpack your server tar.gz file:

tar xzf openpetraorg-server-debian-postgresql-MyOpenPetra-0.2.26.4.tar.gz
cd openpetraorg-0.2.26.4
# have a look at the INSTALL file
cat INSTALL
cp config-sample.sh config.sh
# have a look at config.sh; we are not configuring the .net remoting keys at the moment
cat config.sh
. config.sh
./setup.sh

Next thing, you initialise the database:

/etc/init.d/openpetraMyOpenPetra createdb
/etc/init.d/openpetraMyOpenPetra init
/etc/init.d/openpetraMyOpenPetra start

If you get an error like “Possible cause: Npgsql.NpgsqlException: Failed to establish a connection to ‘localhost’.”, try to edit /etc/postgresql/9.1/main/postgresql.conf and enable listen_addresses = '*'. Then service postgresql restart. I don’t currently know why this is necessary on my computer.

Now you should download an empty database, or a demo database from Sourceforge Demo Databases:

wget http://sourceforge.net/projects/openpetraorg/files/openpetraorg/demodata/demoWith1ledger.yml.gz/download -O /tmp/demoWith1ledger.yml.gz

Then load this database:

/etc/init.d/openpetraMyOpenPetra loadYmlGz /tmp/demoWith1ledger.yml.gz

Please note that the path for the demo file must be readable by the user that the openpetra server is running under, that is why I am using the /tmp directory.

For the OpenPetra client on Linux, you also need to install mono-openpetra-libgdiplus:

apt-get install mono-openpetra-libgdiplus

Get the linux client, and unpack it:

wget http://sourceforge.net/projects/openpetraorg/files/openpetraorg/OpenPetra.org%20Alpha%200.2/openpetraorg-client-MyOpenPetra-0.2.26.4.tar.gz/download -O openpetraorg-client-MyOpenPetra-0.2.26.4.tar.gz
tar xzf openpetraorg-client-MyOpenPetra-0.2.26.4.tar.gz
cd openpetraorg-0.2.26.4
./startClient.sh

At the moment, the communication between client and server is not encrypted. This can be enabled though, or you can use a VPN.
We are working on switching to https, replacing .Net remoting in the near future.

To connect the client to another server than localhost, you need to modify the file etc30/PetraClientRemote.config in the client directory, search for localhost and replace it with the hostname of your server! You might need to work on the firewall settings of the server, to allow communication on port 9000, or change to a more common port, eg. 80.

Known issues in the OpenPetra client for Linux:

  • There will be a message, that the patches cannot be found. Please ignore that, and try to login with user demo and password demo!
  • Partner Find layout of the window is broken.  Sometimes it does not find partners, says: no criteria. Workaround: tab out of current control. It worked for me the second time I opened the Find partner screen.
  • Partner Edit screen: also gives lots of errors. Cannot close without saving, when saving complains about empty address.
    The finance screens (Gift Batch, GL Batch, etc) might work better.

The question is: should we invest into the fat OpenPetra client to run on Linux and on Mac, or should we work on a client running in the browser, eg. based on Twitter Bootstrap, see the OpenPetra Demo with Twitter Bootstrap!

Tags: ,
Posted in Software Development | Comments Closed

Easy start for OpenPetra developers   October 18th, 2013

Steps to reproduce the video tutorial:

  1. See full instructions in OpenPetra Wiki
  2. Make sure .Net 4 is installed
  3. Install SharpDevelop
  4. Install NAnt
  5. Install 7zip
  6. Download and unzip nightly build of OpenPetra
    Update August 2015: the nightly build is now hosted at Github, we are not using Sourceforge for this anymore
  7. Start the Developers Assistant: Start the server, start the client, build OpenPetra
  8. Open the solution file delivery\projects\sharpdevelop4\OpenPetra.Server.sln in SharpDevelop
Tags: , , ,
Posted in Software Development | Comments Closed