Skip to content

uberspace and let's encrypt

Nichts besonderes, ich habe einfach nur das Wissen aus dem wiki und dem blog genommen und ich ein shell script gepackt.

Das Resultat ist folgender Cronjob, der einmal aller 60 Tage läuft.

!/bin/bash -l



@author: stev leibelt <[email protected]>

@since: 2015-12-28


begin of local parameters

LOCALROOTPATH='/home/<user name>' LOCALLOGPATH=$LOCALROOTPATH'/<path to your log files>' LOCAL_ACCOUNT='<your.domain.tld>'

end of local parameters

begin of parameters for letsencrypt-renewer


end of parameters for letsencrypt-renewer

begin of parameters for uperspace-prepare-certificate

LOCALKEYPATH=$LOCALROOTPATH'/.config/letsencrypt/live/'$LOCALACCOUNT'/privkey.pem' LOCALCERTIFICATEPATH=$LOCALROOTPATH'/.config/letsencrypt/live/'$LOCALACCOUNT'/cert.pem'

end of parameters for uperspace-prepare-certificate

letsencrypt-renewer --config-dir $LOCALCONFIGURATIONPATH --logs-dir $LOCALLOGGINGPATH --work-dir $LOCALWORINGPATH &>$LOCALLOGPATH uberspace-prepare-certificate -k $LOCALKEYPATH -c $LOCALCERTIFICATEPATH &>>$LOCALLOGPATH

In schön gibt es das script auch noch einmal hier.
Großen Dank an uberspace und lets encrypt.

Damit das script funktioniert, müsst ihr natürlich zu erst lets encrypt aufsetzen:

letsencrypt certonly
Ich bin recht faul. Aus diesem Grund lass ich mir die Zertifikate einmal im Monat neu generieren. Um die Infrastruktur nicht zu sehr zu belasten, habe ich mir einen anderen Tag, als den Ersten im Monat ausgesucht. Das gleiche gilt für die Uhrzeit.

Translate to de es fr it pt ja

php utilites lock and shutdown available

While i am dealing with cronjobs inside a private project, i run into some trouble with parallelism of cronjobs.

A simple example would clear up this problem. Assume you have cronjob that generates cachefiles (like product descriptions or semi dynamic webcontent like cached rss feeds). You will end up by running a creation cronjob in an interval of x minutes.

The problem that could happen is that a cronjob is already running while the next one is ready to go. You can deal with that problem by setting a maximum execution time in you script but this can lead into strange data and side effects.

I want to solve this problem with two interfaces you can use.

The first interface, called "Lock", is solving the problem with parallelism. If a lock is aquired you are not able to aquire a second one, meaning one cronjob not more.

The second interface, called "Shutdown", is solving the problem with an early and controlled termination of a running cronjob. If the cronjob receives a shutdown, the cronjob can terminate itself i a good way.

Both interfaces have a file based implementation. Unittests and also examples can be found inside the projects.

The next idea I want to realize is an implementation of the Subject-Observer-Pattern. The general idea is that the first call of the cronjob is acting as a observer. The observer itself is chunking the work and split the work by calling (and observing) a number of cronjobs (of its own) as subjects.

Translate to de es fr it pt ja