owncloud | i live in my own little world, but it's ok... they know me here

reihenfolge der kalender in nextcloud bzw. der default kalender

eine alte owncloud installation habe ich “aus gruenden” endlich mal auf nextcloud aktualisiert. soweit war alles fein, aber in meinen sehr umfangreichen kalendern waren wohl ein paar syntaktische probleme enthalten. weil ich das bei der menge an eintraegen niemals einfach und schnell rausbekommen haette, waehlt ich eine holzhammer mehode. einmal exportieren, kalender loeschen, neu anlegen und wieder importieren.
bis dahin war der kalender mit dem namen “default” auch mein wirklicher default kalender und bei nutzung der webgui war dieser bei neu erstellten eintraegen auch vorausgewaehlt. nach meiner o.g. aktion war er es leider nicht mehr. jedes mal beim erstellen eines eintrages den passenden kalender auswaehlen war aber auch keine loesung. also gesucht und was gefunden. der beschrieben bug ist schon seit zwei jahren gemeldet… nur erledigt hats scheinbar noch niemand. da ich kein programmierer bin bin ich eher auf die workarounds angewiesen. diesen mag ich hier kurz beschreiben….

erstmal schauen, was da bei meinen kalendern so drin steht:

SELECT id, displayname, uri, calendarorder FROM oc_calendars WHERE principaluri LIKE '%MYUSERNAME;

da in dem feld “calendarorder” ueberall NULL drin steht, wirds erstmal gesetzt (auf wert “1”):

UPDATE oc_calendars SET calendarorder=1 WHERE principaluri LIKE '%MYUSERNAME%';

…um dann danach den richtigen kalender (“default” mit id 773) in der reihenfolge (calendarorder) eins hoeher (0 statt 1) zu setzen:

UPDATE oc_calendars SET calendarorder=0 WHERE principaluri LIKE '%MYUSERNAME%' AND id=773;

nach einem reload der webgui ist nun wieder alles paletti 🙂

linux mint und das owncloud tray icon

irgendwann – ich weiss nicht mehr wann und “nach was” – wurde mir auf meinem laptop das owncloud icon in der system tray nicht mehr angezeigt. nach viel googlen und merkwuerdigen und veralteten forenbeitraegen war die leosung dann doch viel einfacher als gedacht. auch wenn ich den grund fuer das verhalten (noch) nicht kenne und die loesung etwas komisch finde…. ach… will ich gerade auch garnicht wissen. so kriegt man es geloest:

(aktuell linux mint 18.1 cinnamon und owncloud client 2.3.3)

“system settings” -> “startup applications” ….schaut so aus:

dann die einstellungen fuer owncloud aendern und ein paar sekunden “startup delay” einbauen:

that’s it. nach einem neustart erscheint das tray icon dann wieder 🙂

owncloud integrity check: Certificate has been revoked

nach dem letzten owncloud update konnte ich die calendar app nicht mehr hinzufuegen. die meldung “Signature could not get checked. Please contact the app developer and check your admin screen” stand geschrieben.. ein blick ins admin panel beim integrity check ergab das:

Technical information
=====================
The following list covers which files have failed the integrity check. Please read
the previous linked documentation to learn more about the errors and how to fix
them.
 
Results
=======
- calendar
	- EXCEPTION
		- OC\IntegrityCheck\Exceptions\InvalidSignatureException
		- Certificate has been revoked.
Raw output
==========
Array
(
    [calendar] => Array
        (
            [EXCEPTION] => Array
                (
                    [class] => OC\IntegrityCheck\Exceptions\InvalidSignatureException
                    [message] => Certificate has been revoked.
                )
 
        )
 
)

bei github konnte man nachlesen, das irgendwer irgendjemandes zertifikat revoked hat. um die app doch zu installieren, kann man temporaer (!) diese zeile in die config.php einfuegen:

'integrity.check.disabled' => true

…damit klappts dann.

linux mint 17 und aktueller owncloud client?

igendwie meckert mein owncloud client immer rum, dass er nicht aktuell waere. scheinbar funktioniert das updaten mit den “normalen” repositories nicht so dolle. kurz meinen freund G. befragt, was gefunden, ausprobiert, funktioniert! damits nicht verloren geht, nochmal hier:

wget http://download.opensuse.org/repositories/isv:ownCloud:desktop/Ubuntu_14.04/Release.key
sudo apt-key add - < Release.key
sudo sh -c "echo 'deb http://download.opensuse.org/repositories/isv:/ownCloud:/desktop/Ubuntu_14.04/ /' >> /etc/apt/sources.list.d/owncloud-client.list"
sudo apt-get update
sudo apt-get install owncloud-client

linux mint 17.3 und aktueller owncloud client

im linux mint 17.3 repository findet sich momentan nur ein alter owncloud desktop client (1.5.0). wenn man versucht, sich damit an einer aktuellen owncloud installation anzumelden, bekommt man nur die fehlermeldung “Wrong Crendentials”.

um einen aktuellen owncloud client zu installieren muss man die datei /etc/apt/sources.list.d/owncloud-client.list (ggf. anlegen und) mit folgendem inhalt fuellen:

deb http://download.opensuse.org/repositories/isv:/ownCloud:/desktop/Ubuntu_14.04/ /

danach diese befehle ausfuehren:

sudo apt-get update
sudo apt-get install owncloud-client

wenn beim “apt-get update” ein fehler kommt bezueglich eines fehlenden keys mit der ID 977C43A8BA684223, dann kann man diesen wie folgt hinzufuegen:

gpg --keyserver pgpkeys.mit.edu --recv-key 977C43A8BA684223
gpg -a --export 977C43A8BA684223 | sudo apt-key add -

…danach nochmal die obenstehenden apt befehle ausfuehren

fehler nach owncloud update: “zend_mm_heap corrupted”

nachdem ich heute meine owncloud installation auf 7.0.4 aktualisiert habe, gabs erstmal nur noch “500 Internal Server Error” 🙁

im apache error.log fand ich folgenden eintrag:

zend_mm_heap corrupted

und nach ein wenig googlen habe ich abhilfe gefunden:

after much trial and error, I found that if I increase the output_buffering= value in the php.ini file, this error goes away

hmm… gesagt – getan… funktioniert. nun muss ich nur noch weiter suchen und den hintergrund verstehen 😉

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_ocexport die 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)