Dlaczego przechodzę z Baikal na Radicale (CalDav i CardDav)

Saber/Dav jest głównym komponentem projektu Baikal, aktualnie poszukiwana jest osoba, która zostanie opiekunem projektu (cała historia po angielsku)

Jakiś czas temu przeniosłem moje zasoby z Kalendarza Googla na rzecz otwarto źródłowych, hostowanych przezemnie rozwiązań.

Nigdy nie dostrzegłem problemów związanych z dostępnością – może moje potrzeby były wystarczająco małe 🙂

W żadnym stopniu nie obwieszczam, że Baikal umarł – jeżeli interesuje Ciebie Baikal może przeczytać poprzednie posty o nim (installacja, aktualizacja)

Jeżeli chodzi o mnie, jedyny problem jaki miałem z Baikal-em była bardo problematyczna konfiguracja dzielenia się kalendarzami. Jest to możliwe ale bardzo problematyczne i nazwijmy sobie to po imieniu „brzydkie”. Oczywiście zapowiedziano opcję współdzielenia kalendarzy, która miała być dodana po wielkim przepisywaniu kodu do php7.0+silex, ale zabrakło ludzi, opiekuna, czasu… Na szczęście w między czasie znalazłem Radicale, nie posiada on współdzielenia, które można przeklikać przez stronę www, ale posiada bardzo WIELKĄ zaletą, którą są współdzielone strefy (sharing zones), uprawnienia użytkowników (user rights) dzięki czemu jedną prostą komendą byłem w stanie współdzielić jeden kalendarz między wieloma użytkownikami.

Żadne z rozwiązań (Baikal czy też Radicale) nie wpierało narzędzi migracyjnych. Jednak nic nie stało na przeszkodzi by zapisać stary kalendarz lokalnie i zaimportować go w nowym kalendarzu.

Facebooktwittergoogle_plusreddit

Bezpieczne połączenie do sieci (Android + OpenVPN)

Być może korzystacie z darmowego internetu w kawiarenkach, restauracjach czy na lotniskach.

Może wasz operator GSM sprzedając pakiety internetu śledzi co robicie, oczywiście na potrzeby celów marketingowych (Kiwam do Was T-Mobile, ach te czasy kiedy T-Mobile wstrzykiwało swoje reklamy w Twittera etc…)

Zagrożeń płynących z dostępu do internetu w miejscach publicznych jest tak dużo lub więcej niż zalet.

Co robić? Jak żyć?

A co gdybym powiedział, że można dalej korzystać z mało bezpiecznych puntów dostępu, bez bycia śledzonym przez operatora…

Tym rozwiązaniem, właśnie jest korzystanie z VPN

 

Nie potrzebujemy mieć zROOTowanego telefonu by cieszyć się vpn-em.

„OpenVPN for Android” do działania naszego bezpiecznego połączenia wymagany jest serwer VPN obcy (wykupiona usługa) lub Nasz (sprawdź jak uruchomić własny serwer OpenVPN)

 

Zaawansowane opcje wspierające baterie:

Wiadomo nie od dzisiaj, że VPN lubi zjadać baterię, dlaczego ? Ponieważ co 30 sekund ponownie łączy się do serwera by sprawdzić czy połączenie nie zostało zerwane w czasie kiedy nie wysyłamy/odbieramy żadnych danych. Oczywiście tylko wtedy kiedy mamy go włączonego – chociaż domyślnie powinniśmy mieć go łączonego cały czas 😉 Jak temu zapobiec ?

Zmieńmy 2 opcje na serwerze /etc/openvpn/server.conf:

Otwórzmy port na serwerze, żeby dało się do niego połączyć:

oraz 1 na kliencie

Pamiętajmy o zresetowani usługi na serwerze, a następnie połączenia na komórce.

 

Uwaga: należy pamiętać, że protokół TCP nie był tworzony z myślą o połączeniach VPN, na bardzo niestabilnym internecie można odczuć problemy, za to zużycie baterii w porównaniu do UDP spadnie diametralnie ! 🙂

Facebooktwittergoogle_plusreddit

Zapętlony tryb recovery po wgrywaniu oprogramowania

Zdarzyć się może, że po wgrywaniu oprogramowania (nie oficjalnego) do komórki każdorazowy restart powoduje wejście w tryb recovery nie ważne co byśmy robili.

Lekarstwem jest prosta komenda:

 

Facebooktwittergoogle_plusreddit

Wallabag v2 – Czyli alternatywa Pocket (getPocket/ReadItLater)

Od dłuższego czasu jestem użytkownikiem getPocket – wynikało to kiedyś z dużej kompatybilności z portelem IFTTT (if this then that), który automatyzował wiele rzeczy (robi to do teraz).

Z serwisu do automatyki przestałem korzystać tak namiętnie już jakiś czas, a pocket służył do synchronizacji url-i między urządzeniami. Obecnie podobną funkcjonalność oferuje Firefox i inne wiodące przeglądarki – ale czemu nie władać własnymi danymi ?! Okazuje się, że wallabag to nasza open sourcowa alternatywa.

 

Pobieramy paczkę z wszystkimi bibliotekami:

Rozpakowujemy paczkę w /opt/wallabag

Skonfigurujmy vhost apacha:

Z głownego katalogu /opt/wallabag

W celu przetestowania możemy uruchomić wallabag za pomocą wbudowanego serwera www

Oczywiście uruchomimy go na porcie 8000 na lokalnym hoście, więc tylko z lokalnego hosta zobaczymy czy działa – w celach bezpieczeństwa.

 

Wersja 2.0.0 premierę miała 03.04.2016 roku – na chwilę obecną aplikacja na androida nie wspiera v2, mimo to system działa świetnie!

 

Edit 07/04/2016:

  • firefox plugin – https://addons.mozilla.org/firefox/addon/wallabag-v2/
Facebooktwittergoogle_plusreddit

Baikal – własny kalendarz z listą ToDo (CalDav) oraz książka adresowa (CardDav)

Własny serwer usługi CalDav oraz CardDav może w bardzo łatwy sposób pomóc stworzyć nam platformę synchronizacji kalendarzy i kontaktów pomiędzy urządzeniami takimi jak smartphone oraz usługami typu webmail.

Pobierzmy najnowszą wersję baikal ze strony: http://baikal-server.com/  i rozpakujemy do katalogu np. /var/www/dav.example.com

Następnie rozpakowujemy

Przenosimy pliki do katalogu /var/www/dav.example.com

Utworzmy plik vhost dla Apache

lub bardziej zaawansowany plik z SSL (razem z Let’sEncrypt) + php5_fastcgi zgodny z:

Uruchommy teraz potrzebne moduły apache oraz zresetujmy go by uruchomić vhost:

Nadajny uprawnienia dla katalogu (w zależności jaki użytkownik uruchamia apache np. www-data):

Utwórzmy plik, który udostępni nam panel konfiguracyjny:

W zależności czy skonfigurowaliśmy vhost dla Apacha z lub bez SSL wchodzimy na stronę

Ustawmy wszystkie opcje według upodobań, w następnym kroku będziemy wybierać czy baza będzie znajdować sie w pliku sqlite, czy w mysql/mariadb.

 

I oto w ten sposób uruchomiliśmy platformę carddav, caldav dla własnych potrzeb.

 

Aktualizacja:

Osobiście zalecam aktualizację do nowszej wersji, która zanajduje sie na github-ie projektu.

Dla przykładu, na chwilę obecną najnowszą wersją jest 0.4.2

Zalecane jest utworzenie kopii zapasowej bazy danych, z której korzysta baikal.

Pobieramy baikal do katalogu z zainstalowanym naszym baikal-em w wersji 0.2.7

Rozpakowujemy archiwum

Ustawiamy odpowiedniego właściciela plików i przenosimy je bez katalogu ‚Specific

Wejdźmy na panel administracyjny dav.example.com, a ukaże się nam napis np:

Po zalogowaniu nastąpi proces aktualizacji bazy i wszystko powinno zakończyć sie powodzeniem.

 

Różnicą między wersją 0.2.x a 0.4.x jest zmiana URL card.php i cal.php został zastąpiony dav.php, o ile stare linki będą działać bez większego problemu, o tyle będą one wygaszone z kolejnymi aktualizacjami, więc lepiej od razu używać dav.php w URL.

Dopełnieniem konfiguracji jest ustawienie odpowiednich rekordów DNS:

Dzięki nim programy obsługujące format Dav odnajdą serwer usługi.

 

Przykładowe konfiguracje:

Thunderbird:

 

Thunderbird + Cardbook

Add address book > Remote

 

Android + DavDroid:

 

Facebooktwittergoogle_plusreddit

Dovecot – Poprawienie IDLE timeout dla Androidów

Jeżeli korzystasz z własnego serwera poczty, w tym imap, a maile sprawdzasz na urządzeniach z androidem, możesz zaobserwować (chociaż niekoniecznie) spadem w długości życia urządzenia na jednym ładowaniu. Objawia się to krótszym czasem działania oraz przedewszystkim tym, że aplikacja do emaila np. k-9 jest jedną z pierwszych aplikacji, która widnieje na liście aplikacji zużywających najwięcej baterii.

Nie jest wykluczone, że problem nie leży po stronie samej aplikacji, a winien jest źle skonfigurowany serwer poczty. Domyślnie DoveCot czas bezczynności połaczenia IMAP ma ustawiony na wartość 2 minut, znaczy to, że co 2 minuty klient pocztowy odpytuje serwer poczty, czy nie pojawiły się nowe wiadomości. Oczywiste jest, że czym mniejszy interwał czasu tym większe zużycie baterii.

Możemy sprawdzić nasz serwer pod tym kontem korzystając z komendy:

Powinniśmy uzyskać taki rezultat:

Interwał pomiędzy poszczególnymi „OK still here” to czas bezczynności. Domyślnie to 2 minuty.

Zmienimy to zachowanie poprzez edycję pliku:

systemctl restart dovecot.service

Zrobione!

Facebooktwittergoogle_plusreddit

Google Authenticator – ręczna archiwizacja i odtwarzanie kopi zapasowej

Jeżeli posiadamy uprawnienie ROOT możemy ręcznie wykonać kopię zapasową pliku odpowiadającego za przetrzymywanie ‚seed-ów’ dla haseł.

Archiwizacja: Należy w komórce ustawić ROOT dla ADB, a następnie:

Zawartość pliku można podejrzeć klientem sqlite:

Powyższe wynności można wykonać także w przeglądarce plików, która obsługuję dostęp z uprawnieniami ROOT-a

Odtworzenie kopii:Należy w komórce ustawić ROOT dla ADB, a następnie:

Powyższą czynność można przeprowadzić filemanagerem i skopiować databases do:

Oraz co ważne ustawić uprawnienia na plik dla com.google.android.apps.authenticator2 w innym wypadku nie uruchomimy aplikacji (będzie się sama zamykać)

Facebooktwittergoogle_plusreddit