“Link Bubble” für Android – Zeitersparnis beim Surfen

Link Bubble, eine neue Android App von Chris Lacy, sorgt für eine radikale Änderung in der Nutzung meines Smartphones und verhilft mir zu einer enormen Zeitersparnis. Wie genau funktioniert das Ganze?

Öffnet ihr Beispielsweise einen Link aus einer E-Mail, Facebook oder Twitter so wird nicht gleich der Browser/Chrome geöffnet, sondern ein Chathead ähnlicher Bubble. Dieser Bubble rotiert so lange, bis die Seite geladen ist. Die App kann dann so eingestellt werden, dass die Seite automatisch in einem PopUp geöffnet wird oder eben manuell durch klicken auf den Bubble.
Ist die Seite dann geöffnet, so könnt ihr den “Link Bubble” an den Bildschirmrand ziehen und damit gewisse Aktionen Verknüpfen. Per Default wird die Seite beim Ziehen nach links oben in Pocket (ReadItLater) gespeichert, rechts oben kommt die bekannte Share/Teilen Funktion zum Einsatz. Schließen könnt ihr das Browser Popup durch klicken auf den Zurück Button oder indem Ihr den Link Bubble nach unten zieht.

Zu kompliziert erklärt? Deshalb hier ein Video:

Auch wirtschaftlich macht der Entwickler alles richtig, denn in der kostenlosen Version kann man nur mit einem Bubble gleichzeitig arbeiten. Gönnt man sich die Pro Version (3,59€) so surft man mit mehreren Bubbles gleichzeitig und somit viel effizienter.

Noch ein paar Screenshots:

Link Bubble Pro
Download @
Google Play
Developer: Chris Lacy
Price: 3,59 €

Related Posts:

TimeMachine sinnvoll eingesetzt mit TimeMachineScheduler

Einer der Hauptgründe für mich mittlerweile auf einen Apple Mac (Jehova!) zu setzen ist der Backup Mechanismus TimeMachine. Damit habe ich beispielsweise kurz nach dem Erwerb meines MacBooks dieses wieder durch ein Anderes (mit größerer SSD) einfach und schnell ersetzt.
TimeMachine kümmert sich somit um regelmäßige Backups auf mein NAS via WLAN. Allerdings macht es dies für meinen Geschmack viel zu regelmäßig.

Deshalb habe ich den TimeMachineScheduler von Stefan Klieme installiert. Dieser deaktiviert die “normalen” Zeitabstände von TimeMachine und bietet dem User die Möglichkeit, das Backup Intervall manuell einzustellen (1h -12h). Zudem kann man einen Blackout Zeitraum definieren, in dem gar keine Backups stattfinden. Weiterhin hat man die Möglichkeit, WLAN/LAN Verbindungen zu konfigurieren, über die überhaupt gebackupt werden kann.

Die folgenden zwei Screenshots zeigen die möglichen Konfigurationsoptionen.

Screenshot 2014-01-28 23.38.51

Screenshot 2014-01-28 23.39.01

OS X Mavericks benötigt die Beta Version von TimeMachineScheduler (Version 4.0b8).

Feature Liste von TimeMachineScheduler:

  • Set the interval from 1 to 12 hours.
  • Run the backup manually or automatically also at startup, login or when the daemon has been loaded.
  • Display the status of the daemon, of the backup volume and if the backup is currently running.
  • Automount, an option to mount and unmount the backup volume automatically (see known problems).
  • Option to hide the backup volume (to take effect a Finder relaunch is required).
  • Option to restrict backups to a defined network connection (WiFi/Ethernet) and over WiFi to a certain SSID.
  • Option to skip the backup within a specified time range.

Die von OS X erstellten lokalen Backups habe ich deaktiviert, denn hierfür möchte ich nicht den “teuren” SSD Platz verschwenden. Das geht ganz einfach im Terminal mit

sudo tmutil disablelocal

(sudo ohne Passwort geht nicht, euer Account benötigt hierfür ein PW)

Related Posts:

  • No Related Posts

Einmal um die Welt – ohne Flugzeug

Früher träumten die Menschen vom Fliegen,
heute träumen wir vom Nicht-Fliegen.

Gwen (20) und Patrick (29) sind zwei Deutsche aus Freiburg, die sich mit dem Rucksack samt Zelt auf eine Reise um die Welt aufgemacht haben.
Ihr Motto:

Es ist eine Reise um die Welt, eine weite Reise. Sie führt uns durch viele Länder und auch über die Meere. Nur Fliegen, Fliegen werden wir nie. Immer wollen wir die Erde berühren. 5€ am Tag für jeden, das muss reichen….2 oder 3 Jahre lang.

Hört sich erstmal ziemlich wahnsinnig an, aber das Ganze funktioniert sehr viel besser als geplant. Es funktioniert sogar so gut, dass sie die erste Etappe von Freiburg bis Moskau komplett erleben, ohne einen einzigen Euro auszugeben. Von Freiburg aus sind sie über Ljubljana, Belgrad, Bukarest, Kiew, Moskau, Kazan und Zentralasien bis nach Aqtau (Kasachstan) komplett getrampt, bevor es dann per Schiff nach Baku weiterging.
Einen längeren Aufenthalt haben Sie sich dann erst in Georgiens Hauptstadt Tiflis (Tiblisi) gegönnt. Von dort ging es weiter in den nahen Osten. Kurz vor dem Iran haben sie dann sogar kurz geheiratet, damit die Einreise überhaupt ohne Probleme möglich ist.

Hier die grobe Route im Überblick:

Genug der Worte. Die beiden haben vor, nach ihrer Rückkehr irgendwann 2015 einen Film zu veröffentlichen. Als kleinen Leckerbissen gibt es alle paar Wochen/Monate einen 4-6 Minuten Ausschnitt aus ihrem aktuellen Abenteuer. Damit ihr das Ganze einfach anschauen könnt habe ich ein Vimeo Album erstellt, welches ich im Laufe der Reise immer aktualisieren werde. Bisher gibt es 8 Geschichten, die bisher viel zu wenig likes & shares haben – also teilt die Videos oder gerne auch diesen Beitrag.

Natürlich könnt ihr die beiden auch auf Ihrer Webseite verfolgen: weitumdiewelt.de
Zusätzlich erstellen Sie kurze Videoportraits von Personen unterschiedlichster Kulturen, welche ihr hier findet.

Liebe Gwen, lieber Patrick – Hut aber vor eurer Abenteuerlust und weiterhin viel Spaß und tolle Eindrücke!

Related Posts:

recurring downtimes in Icinga

Recurring Downtimes or repeating notifications during non-work hours is a quite popular topic. For example when your doing a backup of your productive database, the server load could increase up to 10-20 times of the normal value. In this case it seems unwise to increase the threshold for the check in general.
What you could do instead is to work with a recurring downtime in icinga (experimental?!).

How does this work?
Basically you just need a configuration file for your downtimes and a cronjob to schedule them on a regular basis.

Script Installation from Icinga Sources
Download Icinga Sources from here and cxtract the source to a temp directory.
Copy sched_down.pl & sched_conv.pl from icinga-$version/contrib/downtimes/ to your icinga working directory and give them a hug with chmod +x:

cp /usr/src/icinga-1.10.2/contrib/downtimes/sched*.pl /etc/icinga/bin/
chmod +x /etc/icinga/bin/sched_*.bin

Install dependency Perl module “Date::Calc” either via

yum install perl-Date-Calc

or

apt-get install libdate-calc-perl

Configure Downtime via file
Create new config file (e.g. downtimes.cfg) in your icinga directory

vi /etc/icinga/downtimes.cfg

Example for a fixed service downtime of “System Load” in /etc/icinga/downtimes.cfg:

define downtime {
    host_name           myhostname
    service_description System Load
    author              Downtime Cronjob
    comment             SAP Backup
    downtime_period     monday - sunday 22:30-23:30
    register            1
    fixed               1
}

This would configure a fixed Downtime for the service check “System Load” on the host “myhostname” between monday and sunday from 22:30 to 23:30.
Flexible downtimes are also possible:

define downtime {
    host_name           myhostname
    service_description System Load
    author              Downtime Cronjob
    comment             SAP Backup
    downtime_period     monday - sunday 21:00-23:30
    register            1
    duration            30
    fixed               0
}

This is an example for a flexible Downtime for the service check “System Load” on the host “myhostname” between monday and sunday from 21:00 to 23:30 and a duration of 30 minutes.
All configuration parameters are described in the icinga documentation for recurring downtimes.

Script test and cronjob activation
You should now test your configuration (debug in sched_down.pl is activated per default):

/etc/icinga/bin/sched_down.pl -c /etc/icinga/icinga.cfg -s /etc/icinga/objects/downtime.cfg
1: status_file=/var/spool/icinga/status.dat
  1: object_cache_file=/var/spool/icinga/objects.cache
  1: command_file=/var/spool/icinga/cmd/icinga.cmd
  1: planning myhostname;System Load;SAP Backup: monday - sunday 21:45-22:15
  1: possibly on: Thu Dec 12 21:45:00 2013 to Thu Dec 12 22:15:00 2013 for 0 mins
0: CMD:SCHEDULE_SVC_DOWNTIME;myhostname;System Load;1386881100;1386882900;1;0;0;Downtime Cronjob;SAP Backup
  1: --- Debug enabled so NO commands will be sent to /var/spool/icinga/cmd/icinga.cmd! ---
CMD: [1386847800] SCHEDULE_SVC_DOWNTIME;myhostname;System Load;1386881100;1386882900;1;0;0;Downtime Cronjob;SAP Backup
Already scheduled: 0, Definitions: 1, newly planned: 0 | Existing=0 defined=1 new=0

Now everything looks fine, we can activate the downtime:

 /etc/icinga/bin/sched_down.pl -c /etc/icinga/icinga.cfg -s /etc/icinga/objects/downtime.cfg -d0
0: CMD:SCHEDULE_SVC_DOWNTIME;myhostname;System Load;1386881100;1386882900;1;0;0;Downtime Cronjob;SAP Backup
CMD: [1386847980] SCHEDULE_SVC_DOWNTIME;myhostname;System Load;1386881100;1386882900;1;0;0;Downtime Cronjob;SAP Backup
Already scheduled: 0, Definitions: 1, newly planned: 1 | Existing=0 defined=1 new=1

Few seconds later, the scheduled downtime should be visible in your icinga frontend on the Downtime Overview or directly on the host/service-check.

Now we just need to activate a cronjob to trigger the downtimes on a regular basis:

 vi /etc/cron.d/icinga_downtime
0 * * * * icinga /etc/icinga/bin/sched_down.pl -c /etc/icinga/icinga.cfg -s /etc/icinga/objects/downtime.cfg -d0

Related Posts:

Outdoor Action in der Area47

area47 logo

Anfang Juli waren wir in der Area47 im Ötztal in Österreich. Wir kletterten im mit 27 Meter Höhe höchsten Hochseilgarten der Welt und fuhren mit den Rafts die tosende Ötztaler Ache hinunter. Zwischendurch verbrachten wir etwas Zeit in der Water Area.

Ein einmaliges Erlebnis, bei dem folgendes Video entstand:

Vielen Dank nochmal Jungs!

Related Posts:

logo_eoft_1314_black

European Outdoor Filmtour 2013 – Filme und Termine

Der Teaser Trailer für die diesjährige European Outdoor Filmtour wurde schon vor 2 Wochen veröffentlicht, falls ihr ihn noch nicht gesehen habt, dann schaut mal hier:

Die bisher bekannten Filme im kurzen Überblick:
Wide Boyz
Die zwei Briten Tom Randall und Pete Whittaker sind die neuen Helden des Offwidth-Climbing. So nennt man Kletterer,die sich nur an Rissen nach oben bewegen. Nachdem die beiden fleissig im Keller geübt hatten, sind sie die ersten, die den Century Crack gemeistert haben.

Preview auf Vimeo:

The Road from Karakol
Der Alpinist Kyle Dempster ist alleine in den Gebirgen und Tälern von Kirgisistan unterwegs. Insgesamt legte er dabei mehr als 1200km in 2 Monaten zurück. Was er dabei erlebte ist pures Abenteuer:

North of the Sun
Die beiden norwegischen Surfer Inge Wegge und Jørn Nyseth Ranum verbringen 9 Monate am Polarkreis. Sie hausen dabei in einer selbst gebauten Hütte an einer geheimen Bucht um die perfekte Welle zu finden…dabei finden sie am Strand neben vielen nützlichen Dingen auch jede Menge Müll.

Supervention
Die EOFT zeigt eine spezielle Kurzfassung des aktuellsten Freeride (Ski und Snowboard) Streifens. Darsteller Terje Håkonsen, James Heim, Aksel Lund Svindal, Tom Wallisch uvm…:

The Beginning
Das Deap-Canyoning-Team aus der schönen Schweiz zeigt, was beim Canyoning alles möglich ist. So hat man das auch noch nicht gesehen.

Cascada
Cascada zeigt uns extreme Kajak Stunts im magischen Dschungel von Mexiko. Darsteller: Erik Boomer, Tyler Bradt, Galen Volckhausen, Tim Kemple, Anson Fogel, Blake Hendrix & Skip Armstrong. Tyler Bradt war bereits im vorletzten Jahr der EOFT zu sehen.

Sound of the Void
Sébastien de Sainte Marie fährt zwar erst seit 4 Jahren Ski, treibt es dabei aber schon sehr viel weiter als 99,99 % aller Skifahrer. Er ist Extrem-Steilwandfahrer möchte die Nordwand des Gspaltenhorns mit 55% Steigung in den Berner Alpen bezwingen.
Das ist dann auch der einzige Film, bei dem es bisher kaum Material zu finden gibt. Allerdings bloggt Sébastien selbst, ihr könnt euch den Beitrag zum Gspaltenhorn hier anschauen.

Fazit
Wie ihr seht, kann man mit ein wenig Recherche einige der Filme schon jetzt sehen. Natürlich ist das auf der großen Kinoleinwand nochmal ein ganz anderes Gefühl.
Leider ist die EOFT bei uns seit einigen Jahren in der Harmonie Heilbronn unterwegs, was natürlich Bild und Ton technisch keineswegs mit einem Kino zu vergleichen ist.
Wenn das komplette Programm fertig ist, findet ihr es hier.

Termine im wilden Süden:
10.11.2013 17:00 Uhr, 20:30 Pforzheim – Kulturhaus Osterfeld
17.11.2013 13:00, 17:00, 20:30 Uhr: Karlsruhe Konzerthaus
18.11.2013 20:00 Uhr: Karlsruhe Konzerthaus
22.11.2013 20:00 Uhr: Stuttgart Liederhalle – Hegelsaal
23.11.2013 13:00, 17:00, 20:30 Uhr: Stuttgart Liederhalle – Hegelsaal
25.11.2013 20:00 Uhr Heilbronn: Harmonie
15.12.2013 17:00, 20:30 Uhr: Heidelberg – Stadthalle – Großer Saal
16.12.2013 20:00 UHR Ludwigsburg: Forum am Schlosspark – Theatersaal
Weitere Termine findet ihr hier.

Die Tickets kann man endlich online kaufen. In Heilbronn kosten die dieses Jahr 14€ pro Person.

Related Posts:

GlusterFS in multi home environments

GlusterFS is an open source, distributed file system capable of scaling to several petabytes (actually, 72 brontobytes!) and handling thousands of clients.
from gluster.org

The environment

At diginights, we are using GlusterFS as high available Storage for all images. Currently we store more than 2,5 million images on around 700GB storage.
For performance reasons we only use it to store images and larger files, no php code.

If you want to use GlusterFS and are running a multi-home environment, for example multiple VLANs for your storage and client machines, then you have to fight a strange GlusterFS host is not a friend scenario:

In this example we use the following VLANs:

  • VLAN1 172.20.1.0/24 (our main storage LAN)
  • VLAN2 172.30.1.0/24 (The network our clients are residing)
  • Our 4 GlusterFS nodes use 172.20.1.10-172.20.1.13 in VLAN1 and 172.30.1.10-172.30.1.13 in VLAN2

We can easily trust the hosts from one node with “gluster peer probe gluster02″ (for the other storage hostnames respectively)
After adding all 3 nodes via “gluster peer probe” we end up with our Gluster cluster:

[root@gluster01 ~]# gluster peer status
Number of Peers: 3

Hostname: gluster02
Uuid: 25f9aece-4403-39ef-8ac3-15159c46a5ec
State: Peer in Cluster (Connected)

Hostname: gluster03
Uuid: 1d52f829-ab19-5378-9142-3acfa1c31f9c
State: Peer in Cluster (Connected)

Hostname: gluster04
Uuid: fc21c2ac-bee2-1caf-fc5a-19ae127a4094
State: Peer in Cluster (Connected)

If we then try to probe on VLAN2 everything looks fine, the nodes are already trusted:

[root@gluster01]# gluster peer probe 172.30.1.10
Probe on localhost not needed

[root@tux333-101 repl-volume]# gluster peer probe 172.30.1.11
Probe on host 172.30.1.11 port 24007 already in peer list

The problem
Finally we try to create a volume on VLAN2 (so that this is easily accessible from our clients in VLAN2)

[root@gluster01]# gluster volume create VLAN2-volume replica 2 transport tcp 172.30.1.10:/export/gluster01 172.30.1.11:/export/gluster01 172.30.1.12:/export/gluster01 172.30.1.13:/export/gluster01

Host 172.30.1.11 not a friend

So we can’t create a volume with the VLAN2 IPs. Ok, we know that GlusterFS is listening on all interfaces, so lets just create the volume on VLAN1 and try to mount it over VLAN2.

[root@gluster01]# gluster volume create VLAN2-volume replica 2 transport tcp 172.20.1.10:/export/gluster01 172.20.1.11:/export/gluster01 172.20.1.12:/export/gluster01 172.20.1.13:/export/gluster01
volume create: VLAN2-volme: success: please start the volume to access data

If we then try to mount the volume on our client in VLAN2 via the glusterfs native client the following happens:
mount -t glusterfs 172.30.1.10:/VLAN2-volume /data/gluste20.20.rfs
mount failed

If we take a look at the logfile (/var/log/glusterfs)

[2013-06-21 15:21:35.848058] I [glusterfsd.c:1776:main] 0-/usr/sbin/glusterfs: Started running /usr/sbin/glusterfs version 3.3.0.8 (/usr/sbin/glusterfs --volfile-id=/VLAN2-volume --volfile-server=172.30.1.10 /data/glusterfs)
[2013-06-21 15:21:35.864669] I [io-cache.c:1549:check_cache_size_ok] 0-VLAN2-volume-quick-read: Max cache size is 4018585600
[2013-06-21 15:21:35.864790] I [io-cache.c:1549:check_cache_size_ok] 0-VLAN2-volume-io-cache: Max cache size is 4018585600
[2013-06-21 15:21:35.870783] I [client.c:2150:notify] 0-VLAN2-volume-client-0: parent translators are ready, attempting connect on transport
[2013-06-21 15:21:35.875525] I [client.c:2150:notify] 0-VLAN2-volume-client-1: parent translators are ready, attempting connect on transport
[2013-06-21 15:21:35.879950] I [client.c:2150:notify] 0-VLAN2-volume-client-2: parent translators are ready, attempting connect on transport
[2013-06-21 15:21:35.884440] I [client.c:2150:notify] 0-VLAN2-volume-client-3: parent translators are ready, attempting connect on transport
Given volfile:
+------------------------------------------------------------------------------+
1: volume VLAN2-volume-client-0
2: type protocol/client
3: option remote-host 172.20.1.10
4: option remote-subvolume /export/gluster01
5: option transport-type tcp
6: end-volume
7:
8: volume VLAN2-volume-client-1
9: type protocol/client
10: option remote-host 172.20.1.11
11: option remote-subvolume /export/gluster01
12: option transport-type tcp
13: end-volume
14:
15: volume VLAN2-volume-client-2
16: type protocol/client
17: option remote-host 172.20.1.12
18: option remote-subvolume /export/gluster01
19: option transport-type tcp
20: end-volume
21:
22: volume VLAN2-volume-client-3
23: type protocol/client
24: option remote-host 172.20.1.13
25: option remote-subvolume /export/gluster01
26: option transport-type tcp
27: end-volume
28:
29: volume VLAN2-volume-dht
30: type cluster/distribute
31: subvolumes VLAN2-volume-client-0 VLAN2-volume-client-1 VLAN2-volume-client-2 VLAN2-volume-client-3
32: end-volume
33:
34: volume VLAN2-volume-write-behind
35: type performance/write-behind
36: subvolumes VLAN2-volume-dht
37: end-volume
38:
39: volume VLAN2-volume-read-ahead
40: type performance/read-ahead
41: subvolumes VLAN2-volume-write-behind
42: end-volume
43:
44: volume VLAN2-volume-io-cache
45: type performance/io-cache
46: subvolumes VLAN2-volume-read-ahead
47: end-volume
48:
49: volume VLAN2-volume-quick-read
50: type performance/quick-read
51: subvolumes VLAN2-volume-io-cache
52: end-volume
53:
54: volume VLAN2-volume-md-cache
55: type performance/md-cache
56: subvolumes VLAN2-volume-quick-read
57: end-volume
58:
59: volume VLAN2-volume
60: type debug/io-stats
61: option latency-measurement off
62: option count-fop-hits off
63: subvolumes VLAN2-volume-md-cache
64: end-volume
+------------------------------------------------------------------------------+
[2013-06-21 08:39:38.879122] E [socket.c:1715:socket_connect_finish] 0-VLAN2-volume-client-0: connection to failed (Connection timed out)
[2013-06-21 08:39:38.879554] E [socket.c:1715:socket_connect_finish] 0-VLAN2-volume-client-1: connection to failed (Connection timed out)
[2013-06-21 08:39:38.884021] E [socket.c:1715:socket_connect_finish] 0-VLAN2-volume-client-2: connection to failed (Connection timed out)
[2013-06-21 08:39:38.888013] E [socket.c:1715:socket_connect_finish] 0-VLAN2-volume-client-3: connection to failed (Connection timed out)
[2013-06-21 08:39:38.895640] I [fuse-bridge.c:4233:fuse_graph_setup] 0-fuse: switched to graph 0
[2013-06-21 08:39:38.897890] I [fuse-bridge.c:3416:fuse_init] 0-glusterfs-fuse: FUSE inited with protocol versions: glusterfs 7.13 kernel 7.13
[2013-06-21 08:39:38.904437] W [fuse-bridge.c:525:fuse_attr_cbk] 0-glusterfs-fuse: 2: LOOKUP() / => -1 (No such file or directory)
[2013-06-21 08:39:38.912992] I [fuse-bridge.c:4133:fuse_thread_proc] 0-fuse: unmounting /data/glusterfs
[2013-06-21 08:39:38.913453] W [glusterfsd.c:924:cleanup_and_exit] (-->/lib64/libc.so.6(clone+0x6d) [0x7f8c3999190d] (-->/lib64/libpthread.so.0(+0x7851) [0x7f8c39fdd851] (-->/usr/sbin/glusterfs(glusterfs_sigwaiter+0xdd) [0x405cad]))) 0-: received signum (15), shutting down
[2013-06-21 08:39:38.913493] I [fuse-bridge.c:4722:fini] 0-fuse: Unmounting '/data/glusterfs'.

It seems that altough we try to mount the volume through VLAN2, glusterfs is transferring the volume file with values from VLAN1. Then it is clear, that the mount failes because the clients in VLAN2 can not access the server via VLAN1.

This odd behaviour is a known bug and already documented somehow in bugs: Bug 831699 Bug 908641 Bug 764850

The solution

One solution (which isn’t an option in our case) is: Mount the volume via nfs:
[root@tux392 glusterfs]# mount -t nfs 172.30.1.10:/VLAN2-volume /data/glusterfs
[root@tux392 glusterfs]# df -h | grep glust
40G 129M 40G 1% /data/glusterfs

The other solution needs some DNS botching, cause Everything is a Freaking DNS problem in the end.
You could fix this by editing your /etc/hosts files on the servers and clients, or by adjusting your DNS entries.
We continue with editing the hosts files to make the solution clear.

/etc/hosts on the storage nodes:
172.20.1.10 gluster01 storage01.myfqdn.com
172.20.1.11 gluster02 storage02.myfqdn.com
172.20.1.12 gluster03 storage03.myfqdn.com
172.20.1.13 gluster04 storage04.myfqdn.com

/etc/hosts on the client nodes in VLAN2
172.30.1.10 gluster01 client01.myfqdn.com
172.30.1.11 gluster02 client02.myfqdn.com
172.30.1.12 gluster03 client03.myfqdn.com
172.30.1.13 gluster04 client04.myfqdn.com

All we have to do now is to recreate the cluster (delete previously created VLAN2-volume, peer detach the nodes first) with the hostname gluster01/02/03/04, create the volume with the same names as specified in /etc/hosts and finally mount the volume with the glusterfs native client and the specified client hostname.

Hope this helps somebody else until it gets fixed.

Related Posts: