Archiv der Kategorie: HowTo

Amazon Fire Stick: Screensaver timeout

There are two timeouts for your fire stick:

  • Time until the screensaver starts
  • Time until the screen goes dark

The first one can be set in the preferences menu, the second only via adb. Enable debugging support on you device and connect via adb.

adb connect IP_ADDRESS
connected to IP_ADDRESS:5555
adb shell

Change the timeout:

shell@montoya:/ $ settings put system screensaver_timeout 30000
shell@montoya:/ $ settings put system screen_off_timeout 214760000
shell@montoya:/ $ settings get system screen_off_timeout
214760000

Owncloud: Es gab Probleme mit dem Code – Integritätsprüfung.

Owncloud hat wohl eine Integrationsprüfung für seine Dateien hinzugefügt (mit Version 9.0?). Da ich die util.php aufgrund von abweichenden Zugriffsrechten per Hand anpassen muss, erhalte ich in der Browseransicht die Fehlermeldung. Es funktioniert alles, aber der gelbe Balken stört.

Die Integritätsprüfung lässt sich durch einen Eintrag in der owncloud/config/config.php einfach abschalten.

'integrity.check.disabled' => true,

Anschließend auf der owncloud/index.php/settings/admin#security-warning die erneute Prüfung aktivieren.

Fieser workaround, aber tut was er soll.

Manual owncloud upgrade – full procedure

I always struggle with the steps involved to update a manual owncloud installation. I always need to check how to solve a specific permissions problem with the data directory on an external usb drive connected to the raspberry pi. So here it is.

Log in to the pi and download the latest version. Unpack it.

pi@pi ~ $ wget https://download.owncloud.org/community/owncloud-9.0.2.zip
pi@pi ~ $ unzip owncloud-9.0.2.zip

Backup the database.

pi@pi ~ $ mysqldump -u root owncloud -p > \ /media/usb/backup/owncloud/2016_05_13_owncloud/owncloud.sql

Become root, stop the webserver and change to the webserver directory and backup the owncloud files.

pi@pi ~ $ sudo bash
root@pi:/home/pi# service nginx stop
Stopping nginx: nginx.
root@pi:/home/pi# cd /var/www/
root@pi:/var/www# rsync -avrh owncloud \ /media/usb/backup/owncloud/2016_05_13_owncloud

Move the owncloud directory and copy the new files. Restore your config.php.

root@pi:/var/www# mv owncloud/ owncloud2
root@pi:/var/www# mv /home/pi/owncloud .
root@pi:/var/www# cp owncloud2/config/config.php owncloud/config/config.php

Fix the directory and file permissions. I put these commands in a small script and run it before the next step.

sudo find /var/www/owncloud -type d -exec chmod 750 {} \;
sudo find /var/www/owncloud -type f -exec chmod 640 {} \;
sudo chown -R www-data:www-data /var/www/owncloud/

Restart the webserver, change to the owncloud directory and start the upgrade procedure.

root@pi:/var/www# service nginx start
Starting nginx: nginx.
root@pi:/var/www# cd owncloud
root@pi:/var/www/owncloud# sudo -u www-data php occ upgrade
ownCloud or one of the apps require upgrade – only a limited number of commands are available
You may use your browser or the occ upgrade command to do the upgrade
Data directory (/media/usb/owncloud) is readable by other users
Please change the permissions to 0770 so that the directory cannot be listed by other users.
An unhandled exception has been thrown:
exception ‚Exception‘ with message ‚Environment not properly prepared.‘ in /var/www/owncloud/lib/private/console/application.php:120
Stack trace:
#0 /var/www/owncloud/console.php(83): OC\Console\Application->loadCommands(Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
#1 /var/www/owncloud/occ(11): require_once(‚/var/www/ownclo…‘)

Update 27.09.2016: The file has moved to owncloud/lib/private/legacy/util.php in owncloud version 9.1.x.

I have my data directory on an external usb drive which is mounted writeable for everyone. Owncloud doesn’t like that. You need to edit the permission check in the file owncloud/lib/private/util.php and change it from

if (substr($perms, -1) != ‚0‘) {
chmod($dataDirectory, 0770);
if (substr($perms, 2, 1) != ‚0‘) {

to

if (substr($perms, -1) != ‚7‘) {
chmod($dataDirectory, 0777);
if (substr($perms, 2, 1) != ‚7‘) {

If your permissions are different, you need to adjust the lines accordingly.

Here is my fstab:

root@pi:/var/www/owncloud# cat /etc/fstab | grep ‚/media/usb‘
UUID=1D3F163D4EEC069E /media/usb ntfs-3g defaults,auto,uid=pi,gid=www-data,umask=000,users,rm 0 0

Change the lines and restart the upgrade process.

root@pi:/var/www/owncloud# sudo -u www-data php occ upgrade
ownCloud or one of the apps require upgrade – only a limited number of commands are available
You may use your browser or the occ upgrade command to do the upgrade
Set log level to debug
Turned on maintenance mode
Checking whether the database schema can be updated (this can take a long time depending on the database size)
Checked database schema update
Checking updates of apps
Checking whether the database schema for <files_trashbin> can be updated (this can take a long time depending on the database size)
Checked database schema update for apps
Updating database schema
Updated database
Disabled 3rd-party app: files_opds
Disabled 3rd-party app: updater
Updating <files_texteditor> …
Updated <files_texteditor> to 2.1
Updating <gallery> …
Updated <gallery> to 14.5.0
Updating <files> …
Updated <files> to 1.4.4
Updating <files_trashbin> …
Updated <files_trashbin> to 0.8.0
Updating <files_versions> …
Updated <files_versions> to 1.2.0
Update 3rd-party app: files_opds
Starting code integrity check…
Finished code integrity check
Update successful
Turned off maintenance mode
Reset log level

Cleanup.

root@pi:/var/www/owncloud# rm -r /var/www/owncloud2
root@pi:/var/www/owncloud# rm /home/pi/owncloud-9.0.2.zip

Sources:
https://doc.owncloud.org/server/8.2/admin_manual/maintenance/manual_upgrade.html
https://forum.owncloud.org/viewtopic.php?t=25043

Drucker/CUPS in Samba auf dem Raspberry deaktivieren

Hat man keinen Drucker in Samba konfiguriert, wird das syslog oft mit Meldungen wie diesen zugespammt:

May 3 07:14:50 pi smbd[4609]: [2016/05/03 07:14:50.925006, 0] printing/print_cups.c:110(cups_connect)
May 3 07:14:50 pi smbd[4609]: Unable to connect to CUPS server localhost:631 – Verbindungsaufbau abgelehnt
May 3 07:14:50 pi smbd[22697]: [2016/05/03 07:14:50.928320, 0] printing/print_cups.c:487(cups_async_callback)
May 3 07:14:50 pi smbd[22697]: failed to retrieve printer list: NT_STATUS_UNSUCCESSFUL

Mit ein paar Einträgen in der /etc/samba/smb.conf kann man dieses Verhalten abstellen.

[global]

load printers = no
printing = bsd
printcap name = /dev/null
disable spoolss = yes

Install a full syslog-ng in pfsense

Some quick notes.

# Remove old syslog-ng package
pkg_info | grep syslog-ng
pkg_delete syslog-ng-1.6.12_1

# Installing new version
setenv PACKAGESITE
http://files.pfsense.org/packages/amd64/8/All/
ftp://ftp4.freebsd.org/pub/FreeBSD/ports/i386/packages-stable/Latest/
pkg_add -r syslog-ng

# Make sure there is a /usr/local/etc/syslog-ng.conf

# Autostart syslog-ng, edit /etc/rc.conf.local
syslog_ng_enable=“YES“

# Disable default syslog, /etc/rc.conf.local
syslogd_enable=“NO“

# Kill syslogd, start syslog-ng
kill `cat /var/run/syslog.pid`
/usr/local/etc/rc.d/syslog-ng start

 

Sources:
http://forum.pfsense.org/index.php?topic=3976.0
http://forum.pfsense.org/index.php/topic,7793.0.html
http://www.mail-archive.com/discussion@pfsense.com/msg02764.html
FreeBSD based version info: http://doc.pfsense.org/index.php/PfSense_and_FreeBSD_Versions

SSH-Tunnel mit Firefox nutzen

Kurz notiert:

Ich hatte etwas Probleme bei der Verwendung eines aktuellen Firefox mit einem dynamischen SSH Tunnel. Konnte ich in der Vergangenheit etwa mit dem Befehl

ssh -fNCD 4444 remotesshserver

einen SOCKS Proxy auf Port 4444 aufmachen und Firefox einfach auf diesen umlenken, funktioniert dies wohl aktuell(?) nicht mehr. Richte ich den Proxy in den Einstellungen des Browsers ein (localhost, Port 4444, alle Protokolle, SOCKSv5 etc), kann anschließend keine Verbindung aufgebaut werden. Die selben Daten, konfiguriert in FoxyProxy funktionieren allerdings problemlos.

Hilfreich bei der Fehlersuche:

ssh -N -vvv -D 4444 remotesshserver
curl –socks5 127.0.0.1:4444 http://icanhazip.com

QNAP NAS: Volle Festplatte und keine Reaktion mehr

Da ist mir wohl ein Script etwas Amok gelaufen und hat die Festplatten vom Qnap volllaufen lassen. Merkwürdigerweise kann man dann mit so einem Qnap nicht mehr wirklich viel anfangen. Verbindung über das Webinterface oder SSH funktionieren zwar noch, versucht man allerdings Dateien zu löschen, hängt sich das System auf. Die wohl einzige Lösung ist etwas unschön, aber funktioniert.

  • Qnap ausschalten (Stecker ziehen, da shutdown Befehle ignoriert werden)
  • Alle Festplatten ausbauen
  • Qnap einschalten
  • Kurzen und langen Piepton abwarten (kann ca. eine Minute dauern)
  • Alle Festplatten wieder rein
  • Per SSH mit dem NAS verbinden. Benutzer: admin, Passwort: admin. (Das NAS besorgt sich per DHCP eine andere als die konfigurierte IP. Entweder im Log des DHCP-Servers nachschauen oder den QNAP QFinder verwenden)
  • Per SSH: storage_boot_init 2
  • cd /share/MD0_DATA
  • Mit rm einige Dateien löschen
  • reboot

Nach dem Neustart ist das NAS wieder über die konfigurierte IP erreichbar.

Raspberry Pi: Owncloud setup revisited

The Raspberry and owncloud ran for a few months now and I really enjoyed my own personal cloud. But I was really annoyed by the poor performance. One possible solution was to switch the sd card, which I did. I replaced the Transcend 16GB SDHC card with a 4GB one. Performance is much better now. Since setting up the system is a pretty simple and fast process, I didn’t bother about cloning the card etc. I reinstalled raspbian and followed my own guide on how to setup nginx and php and oriented on my other tutorial on how to install owncloud 6 beta. Of course I needed to change some links etc.

Some more things (I) changed:

  1. owncloud added security for trusted domains
  2. moved owncloud storage to an external usb drive
  3. changed the nginx webserver configuration: restrict to https only and …
  4. accessing php-fpm through network socket

 

1. If you access the webinterface of your owncloud instance using different ips, names etc., you need to add them to the „trusted_domains“ parameter.

pi@raspberrypi ~ $ sudo vi /var/www/owncloud/config/config.php

‚trusted_domains‘ =>
array (
0 => ‚192.168.12.34′,
1 => ‚your.dyndns.org‚,
),

2. Connect the usb drive and use lsblk and blkid to find the needed UUID.

pi@raspberrypi ~ $ lsblk && blkid
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 2,7T 0 disk
└─sda1 8:1 0 2,7T 0 part /media/usb
mmcblk0 179:0 0 3,7G 0 disk
├─mmcblk0p1 179:1 0 56M 0 part /boot
└─mmcblk0p2 179:2 0 3,7G 0 part /
/dev/mmcblk0p1: SEC_TYPE=“msdos“ LABEL=“boot“ UUID=“7D5C-A285″ TYPE=“vfat“
/dev/mmcblk0p2: UUID=“5d18be51-3217-4679-9c72-a54e0fc53d6b“ TYPE=“ext4″
/dev/sda1: LABEL=“Backup3TB“ UUID=“1D3F163D4EEC069E“ TYPE=“ntfs“

Create the mountpoint /media/usb and edit /etc/fstab to mount the drive on startup.

pi@raspberrypi ~ $ sudo mkdir /media/usb

pi@raspberrypi ~ $ sudo vi /etc/fstab
proc /proc proc defaults 0 0
/dev/mmcblk0p1 /boot vfat defaults 0 2
/dev/mmcblk0p2 / ext4 defaults,noatime 0 1
UUID=1D3F163D4EEC069E /media/usb ntfs-3g defaults,auto, uid=pi,gid=wwwdata,umask=007,users 0 0

While setting up your owncloud, you can now define /media/usb as your data storage. Not sure if there is a way to change this on a already running owncloud setup.

 

3. Change the nginx configuration (/etc/nginx/sites-availabe/default) according to the owncloud 6 documentation

upstream php-handler {
server 127.0.0.1:9000;
}

server {
listen 80;
return 301 https://your.dyndns.org$request_uri; # enforce https
}

# HTTPS server
#
server {
listen 443 ssl;
server_name your.dyndns.org localhost;

root /var/www;

autoindex off;
index index.php index.html index.htm;

ssl on;
ssl_certificate /etc/nginx/conf.d/ssl/server.crt;
ssl_certificate_key /etc/nginx/conf.d/ssl/server.key;

client_max_body_size 10G; # set max upload size
fastcgi_buffers 64 4K;

rewrite ^/caldav(.*)$ /remote.php/caldav$1 redirect;
rewrite ^/carddav(.*)$ /remote.php/carddav$1 redirect;
rewrite ^/webdav(.*)$ /remote.php/webdav$1 redirect;

index index.php;
error_page 403 /core/templates/403.php;
error_page 404 /core/templates/404.php;

location = /robots.txt {
allow all;
log_not_found off;
access_log off;
}

location ~ ^/(data|config|\.ht|db_structure\.xml|README) {
deny all;
}

location / {
# The following 2 rules are only needed with webfinger
rewrite ^/.well-known/host-meta /public.php?service=host-meta last;
rewrite ^/.well-known/host-meta.json /public.php?service=host-meta-json last;

rewrite ^/.well-known/carddav /remote.php/carddav/ redirect;
rewrite ^/.well-known/caldav /remote.php/caldav/ redirect;

rewrite ^(/core/doc/[^\/]+/)$ $1/index.html;

try_files $uri $uri/ index.php;
}

location ~ ^(.+?\.php)(/.*)?$ {
try_files $1 =404;

include fastcgi_params;
fastcgi_param SCRIPT_FILENAME $document_root$1;
fastcgi_param PATH_INFO $2;
fastcgi_param HTTPS on;
fastcgi_pass php-handler;
}

# Optional: set long EXPIRES header on static assets
location ~* ^.+\.(jpg|jpeg|gif|bmp|ico|png|css|js|swf)$ {
expires 30d;
# Optional: Don’t log access to assets
access_log off;
}
}

4. Modify the php5-fpm config to listen on a netsocket.

 pi@raspberrypi ~ $ sudo vi /etc/php5/fpm/pool.d/www.conf

;listen = /var/run/php5-fpm.sock
listen = 127.0.0.1:9000

Restart the services.

pi@raspberrypi ~ $ sudo service php5-fpm restart
pi@raspberrypi ~ $ sudo service nginx restart

 

 

 

 

Unterordner in WordPress ausschließen – .htaccess

Sämtliche Ordner einer Domain mit installierten WordPress, werden normalerweise mittels RewriteRules von WordPress verwaltet. Möchte man einen bestimmten Unterordner davon auschließen, muss die .htaccess Datei entsprechend angepasst werden. In diesem Beispiel ist WordPress direkt im DocumentRoot unter www.carrier-lost.org installiert. Soll z.B. ein Unterordner www.carrier-lost.org/static/ ausgeschlossen werden, sähe der entsprechende Abschnitt in der .htaccess so aus:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ – [L]
RewriteCond %{REQUEST_URI} !^/(static|static/.*)$
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

Chrome: libudev.so.0: cannot open shared object file

Nach dem Update von Ubuntu 12.04.2 LTS auf 14.04 LTS startete Google Chrome nicht mehr. Der Aufruf über die Konsole offenbarte die Fehlermeldung

/usr/bin/google-chrome: error while loading shared libraries: libudev.so.0: cannot open shared object file: No such file or directory

Auf einem 64Bit-System lässt sich das Problem mit einem einfachen Kommando lösen:

sudo ln -s /lib/x86_64-linux-gnu/libudev.so.1.3.5 /usr/lib/libudev.so.0