Tag: software

backup der owncloud kalender per cron

für den export bzw backup mehrerer kalender einfach das script fuer das backup des adressbuches abwandeln. das funktioniert nach dem gleichen prinzip wie beim adressbuch. da ich aber mehrere kalender habe, musste dazu noch eine for schleife rein.

sofern man mehrere adressbuecher hat, kann man mit anpassungen dieses scriptes auch diese sichern.

#!/bin/bash

OCUSER=meinusername
OCPASS=meinpasswort
OCHOST=https://owncloud.domain.tld
# die calid am ende wird in der for schleife angehaengt
OCCALENDARURL=$OCHOST'/index.php/apps/calendar/export.php?calid='
# das "--no-check-certificate" ist unschoen
WGETPARAMS='--no-check-certificate --auth-no-challenge'
WGETAUTH='--http-user='$OCUSER' --http-password='$OCPASS
MYDATE=`date +%Y%m%d%H%M%S`
# in diesen ordner werden die backups abgelegt
OUTFOLDER=/home/ich/ocbackup

# array mit den calendar id's
declare -a array=(2 3 4 5 6 9 10 11 12)

# einfuegen der calid in dateiname und url. dann runterladen und packen
for i in ${array[@]}
do
    OUTFILE=$OUTFOLDER'/calendar_'$OCUSER'_id'$i'_'$MYDATE'.ics'
    wget $WGETPARAMS $WGETAUTH -O $OUTFILE $OCCALENDARURL$i
    gzip $OUTFILE
done

# backups aelter 30 tage loeschen
find $OUTFOLDER -maxdepth 1 -type d -name 'calendar*' -mtime +30 -exec rm -rf {} \;

script abspeichern, die “calid”s in dem array an die eigenen gegebenheiten anpassen, ausfuehrbar machen und einen cronjob anlegen. die “calid” findet man in den einstellungen des kalenders. einfach mit der rechten maustaste den link bei “herunterladen” kopieren.

20130628_occalendar

(stand: ownCloud 5.0.7)

backup des owncloud adressbuches per cron

hier ein kleines script, um vom owncloud adressbuch eines users ein backup zu erstellen. bei einer selbst gehosteten owncloud macht man normalerweise ein mysql backup und hat damit auch gleich das adressbuch gesichert. wenn man allerdings keinen shellzugriff hat, kann man sich mit diesem kleinen script behelfen, welches die exportfunktion von owncloud nutzt. gerade wenn man noch im “testbetrieb” ist und mit zig geraeten (mit durchaus unterschiedlichem verhalten) gleichzeitig auf das adressbuch zugreift, will man vielleicht auch mal ein solches backup haben – fuer den fall, dass doch etwas schief geht. gebraucht habe ich das bis jetzt noch nicht, aber wer weiss…

#!/bin/bash

OCUSER=meinusername
OCPASS=meinpasswort
OCHOST=https://owncloud.domain.tld
# die "bookid" am ende anpassen!
OCABOOKURL=$OCHOST'/index.php/apps/contacts/export.php?bookid=2'

# das "--no-check-certificate" ist unschoen
WGETPARAMS='--no-check-certificate --auth-no-challenge'
WGETAUTH='--http-user='$OCUSER' --http-password='$OCPASS
MYDATE=`date +%Y%m%d%H%M%S`
# in diesen ordner werden die backups abgelegt
OUTFOLDER=/home/ich/ocbackup
OUTFILE=$OUTFOLDER'/abook_'$OCUSER'_'$MYDATE'.vcf'

wget $WGETPARAMS $WGETAUTH -O $OUTFILE $OCABOOKURL
# packen und das original loeschen
gzip $OUTFILE

# backups aelter 30 tage loeschen
find $OUTFOLDER -maxdepth 1 -type d -name 'abook*' -mtime +30 -exec rm -rf {} \;

20130628_ocexportdie url bzw speziell die “bookid” muss man sich in seinem owncloud account raussuchen. dazu geht man im adressbuch in die einstellungen und kopiert sich die export url mit der rechten maustaste und passt das script an:

das “find” am ende loescht die backupdateien, die aelter als 30 tage sind. das script speichert man sich ab, macht es ausfuehrbar und fuehrt es so oft wie es beliebt per crojob aus.

(stand: ownCloud 5.0.7)

apache autschn?

das bedeutet bestimmt nix gutes…

Bildschirmfoto 2013-06-14 um 10.00.37

unbenannter arsch

oder besser unbenanntes arschgesicht? das programm iPhoto in osx hat eine eingebaute gesichtserkennung. wenn es ein gesicht noch nicht kennt, dann steht da “unbenannt”. hmmm…

20130613_arsch_unbenannt

ein grund gegen die vielen cloud dienste

fuer alle moeglichen anwendungszwecke gibt es irgendeien cloud dienst. irgendwann geht halt mal einer nicht. egal ob temporaer oder dauerhaft.

20130612_evernote

evernote nutze ich fuer diverse “unpersoenliche” sachen. nun wars das erste mal so weit, dass ich echt mal darauf zugreifen MUESSTE… und dann das. was waere nun, wenn die daten unwiederruflich weg waeren? seeehr aergerlich waere das. also doch wieder mal nach “selfhostet” alternativen suchen. was genauso komfortables wirds wahrscheinlich (noch) nicht geben.

catastrophic failure

mal was neues… (also fuer mich zumindest)

pic07958

zehn jahre wordpress

gestern hatte wordpress zehnjaehrigen geburtstag. ich selbst nutze diese “software” seit ziemlich genau sieben jahren und finde sie immernoch toll. natuerlich hat sie ihre macken und tuecken, aber fuer mich bleibt es “die blogsoftware”. alle ausfluege zu anderen systemen fand ich nicht prickelnd.

ein bischen geschichte zu wordpress kann man unter dem genannten link nachlesen.

also.. heyho.. und alles gute! muss einfach mal erwaehnt werden.

wordpress_10_years_anniversary_1

eyed3 und osx 10.8

mit dem update auf osx 10.8.x scheint auch eine neue python version mitgekommen zu sein. damit funktionierte mein ich-konvertiere-mir-meine-musik-in-128kbits-um-platz-auf-dem-handy-zu-sparen-und-fummels-die-tags-und-coverbilder-um-und-lege-das-in-einer-ordnerstruktur-ab-script nicht mehr.

python -V
Python 2.7.2

die loesung ist genauso einfach wie vorher das eyed3 zu installieren:

sudo easy_install eyed3

media upload verzeichnis aendern ab wordpress 3.5

ab wordpress 3.5 fehlt im backend die moeglichkeit, das upload verzeichnis zu aendern. diese funktion wurde entfernt, weil sie wenig genutzt, aber immer viel aerger eingebracht hat, wenn nutzer das im nachhinein aenderten.

wenn man das verzeichnis nun aendern will, muss man diese zeile in der wp-config.php einfuegen und natuerlich den eigenen gegebenheiten anpassen:

define( 'UPLOADS', 'wp-content/files' ); 

der default wert war frueher “wp-content/uploads”.

dns amplification (2)

den kram von gestern wollte ich noch ein wenig verfeinern. im logfile des bind konnte ich auf einen blick erkennen, dass diese beiden die groesste menge der (mittlerweile “sinnlosen”) abfragen darstellt:

[...] query: deniedstresser.com IN ANY +E
[...] query: . IN RRSIG +E

um nur genau diese per iptables raus zu filtern, muss man erstmal im netzwerkverkehr mithorchen, um sich dann die genauen strings rauszusuchen. das macht man am einfachsten mit dem tool tcpdump, welches anders als der name vermuten laesst auch udp und icmp mitschneiden kann 😉

tcpdump -i eth0 -s 0 -w /tmp/tcpdump.dump udp port 53

die damit erzeugte datei schaut man sich am besten mit wireshark an und sucht sich die entsprechenden teile der pakete raus:

20130521_iptables_string2

20130521_iptables_string1

die relevanten (im screenshot markierten) teile, nach denen ich filtern wollte, sind dann in hexadezimaler schreibweise diese:

# hex fuer "deniedstresser.com: type ANY, class IN"
0e 64 65 6e 69 65 64 73 74 72 65 73 73 65 72 03 63 6f 6d 00 00 ff 00 01 00
# hex fuer ": type RRSIG, class IN"
00 00 2E 00 01 00 00 29

die abfrage des typs ANY kann ich bedenkenlos komplett rausfiltern, da ich den abgefragten namen (deniedstresser.com) mit reingenommen habe. niemals hat dieser dns server genau diese abfrage zu beantworten.

iptables -I INPUT 1 -i eth0 -d xx.xx.xx.xx -p udp --dport 53 -m string --from 30 --algo bm --hex-string '|0e 64 65 6e 69 65 64 73 74 72 65 73 73 65 72 03 63 6f 6d 00 00 ff 00 01 00|' -j DROP

die abfrage nach der “recource record signature” der root zone darf ich nicht komplett rausfilter, da dem dns server vertrauete ipadressen sehr wohl genau diese abfrage machen koennen und duerfen. dafuer ist diese loesung mit iptables eigentlich eher ungeeignet. aber da ich weiss, dass die server mit den “vertrauten” ipadressen noch nichts mit DNSSEC am hut haben, nutze ich die regel erstens nur temporaer und zweitens sicherheitshalber nur wenn “geflutet” wird – sprich mehr als vier abfragen pro minuten von einer ipadresse kommt.

erst wieder die ip “taggen”:

iptables -I INPUT 2 -i eth0 -d xx.xx.xx.xx -p udp --dport 53 -m string --from 35 --algo bm --hex-string '|00 00 2E 00 01 00 00 29|' -m recent --name dnsrootrrsig --set

und die anfrage wegschmeissen, wenn der counter in 60 sekunden die vier erreicht hat, :

iptables -I INPUT 3 -i eth0 -d xx.xx.xx.xx -p udp --dport 53 -m string --from 35 --algo bm --hex-string '|00 00 2E 00 01 00 00 29|' -m recent --name dnsrootrrsig --rcheck --seconds 60 --hitcount 4 -j DROP

klar muessen die “angreifer” nur eine kleinigkeit an einer der abfragen aendern, um diese regeln zu umgehen. aber so schickt der dns server wenigstens nicht mal das “REFUSED” an den gefaelschten absender zurueck. ich hoffe ja, dass dieser “angriff” irgendwann vorueber ist, da der bind sowieso kein offener resolver mehr ist und somit fuer die angreifer uninteressant wird.