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.

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:

proto tcp
keepalive 1800 3600

1 2	proto tcp keepalive 1800 3600

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

ufw allow 1194/tcp

1	ufw allow 1194/tcp

oraz 1 na kliencie

proto tcp

proto tcp

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 ! 🙂

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:

msm_sdcc.1 może się różnić
dd if=/dev/zero of=/dev/block/platform/msm_sdcc.1/by-name/fota
dd if=/dev/zero of=/dev/block/platform/msm_sdcc.1/by-name/misc

msm_sdcc.1 może się różnić

dd if=/dev/zero of=/dev/block/platform/msm_sdcc.1/by-name/fota

dd if=/dev/zero of=/dev/block/platform/msm_sdcc.1/by-name/misc

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:

wget http://wllbg.org/latest-v2-package

1	wget http://wllbg.org/latest-v2-package

Rozpakowujemy paczkę w /opt/wallabag

tar zxvf latest-v2-package
mv wallabag/* /opt/wallabag

1 2	tar zxvf latest-v2-package mv wallabag/* /opt/wallabag

Skonfigurujmy vhost apacha:

<VirtualHost *:80>
    ServerName domain.tld
    ServerAlias www.domain.tld

    DocumentRoot /opt/wallabag/web
    <Directory /opt/wallabag/web>
        AllowOverride None
        Order Allow,Deny
        Allow from All

        <IfModule mod_rewrite.c>
            Options -MultiViews
            RewriteEngine On
            RewriteCond %{REQUEST_FILENAME} !-f
            RewriteRule ^(.*)$ app.php [QSA,L]
        </IfModule>
    </Directory>

    # optionally disable the RewriteEngine for the asset directories
    # which will allow apache to simply reply with a 404 when files are
    # not found instead of passing the request into the full symfony stack
    <Directory /opt/wallabag/web/bundles>
        <IfModule mod_rewrite.c>
            RewriteEngine Off
        </IfModule>
    </Directory>
    ErrorLog /var/log/apache2/wallabag_error.log
    CustomLog /var/log/apache2/wallabag_access.log combined
</VirtualHost>

ServerName domain.tld

ServerAlias www.domain.tld

DocumentRoot /opt/wallabag/web

AllowOverride None

Order Allow,Deny

Allow from All

Options -MultiViews

RewriteEngine On

RewriteCond %{REQUEST_FILENAME} !-f

RewriteRule ^(.*)$ app.php [QSA,L]

</IfModule>

</Directory>

# optionally disable the RewriteEngine for the asset directories

# which will allow apache to simply reply with a 404 when files are

# not found instead of passing the request into the full symfony stack

RewriteEngine Off

</IfModule>

</Directory>

ErrorLog /var/log/apache2/wallabag_error.log

CustomLog /var/log/apache2/wallabag_access.log combined

</VirtualHost>

Z głownego katalogu /opt/wallabag

php bin/console wallabag:install --env=prod

1	php bin/console wallabag:install --env=prod

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

php bin/console server:run --env=prod` for using wallabag: http://localhost:8000

1	php bin/console server:run --env=prod` for using wallabag: http://localhost:8000

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/

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

wget http://baikal-server.com/get/baikal-regular-0.2.7.tgz

1	wget http://baikal-server.com/get/baikal-regular-0.2.7.tgz

Następnie rozpakowujemy

tar zxvf baikal-regular-0.2.7.tgz

1	tar zxvf baikal-regular-0.2.7.tgz

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

mv baikal-regular /var/www/dav.example.com

1	mv baikal-regular /var/www/dav.example.com

Utworzmy plik vhost dla Apache

# vim /etc/apache2/sites-available/dav.example.com.conf 
<VirtualHost *:80>
    DocumentRoot /var/www/dav.example.com/html
    ServerName dav.example.com

    RewriteEngine On
    RewriteRule /.well-known/carddav /card.php [R,L]
    RewriteRule /.well-known/caldav /cal.php [R,L]

    <Directory "/var/www/dav.example.com/html">
        Options None
        Options +FollowSymlinks
        AllowOverride All
    </Directory>
</VirtualHost>

# vim /etc/apache2/sites-available/dav.example.com.conf

DocumentRoot /var/www/dav.example.com/html

ServerName dav.example.com

RewriteEngine On

RewriteRule /.well-known/carddav /card.php [R,L]

RewriteRule /.well-known/caldav /cal.php [R,L]

Options None

Options +FollowSymlinks

AllowOverride All

</Directory>

</VirtualHost>

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

# php5_fastcgi + ssl baikal config file
<Directory /var/www/dav.example.com>
        AllowOverride None
        Require all denied
</Directory>

<VirtualHost *:80>
        ServerName dav.example.com
        Redirect permanent / https://dav.example.com/
</VirtualHost>

<IfModule mod_ssl.c>
        <VirtualHost ip_address:443>
                ServerAdmin webmaster@example.com
                ServerName dav.example.com:443
                DocumentRoot /var/www/dav.example.com/html/
                ErrorLog /var/www/dav.example.com/logs/error.log
                CustomLog /var/www/dav.example.com/logs/access.log combined

                RewriteEngine On
                RewriteRule /.well-known/carddav /dav.php [R,L]
                RewriteRule /.well-known/caldav /dav.php [R,L]

                SSLEngine on
                SSLCertificateFile      /etc/letsencrypt/live/dav.example.com/fullchain.pem
                SSLCertificateKeyFile /etc/letsencrypt/live/dav.example.com/privkey.pem

                <Directory "/var/www/dav.example.com/html">
                        Options None
                        Options +FollowSymlinks
                        AllowOverride All
                </Directory>

                <FilesMatch "\.(cgi|shtml|phtml|php)$">
                                SSLOptions +StdEnvVars
                </FilesMatch>
                <Directory /usr/lib/cgi-bin>
                                SSLOptions +StdEnvVars
                </Directory>

                BrowserMatch "MSIE [2-6]" \
                                nokeepalive ssl-unclean-shutdown \
                                downgrade-1.0 force-response-1.0
                # MSIE 7 and newer should be able to use keepalive
                BrowserMatch "MSIE [17-9]" ssl-unclean-shutdown

                <IfModule mod_fastcgi.c>
                        AddType application/x-httpd-fastphp5 .php
                        Action application/x-httpd-fastphp5 /php5-fcgi
                        Alias /php5-fcgi /usr/lib/cgi-bin/php5-fcgi_dav.example.com
                        FastCgiExternalServer /usr/lib/cgi-bin/php5-fcgi_dav.example.com -socket /var/run/php5-fpm_dav.example.com.sock -pass-header Authorization
                 </IfModule>
        </VirtualHost>
</IfModule>

# vim: syntax=apache ts=4 sw=4 sts=4 sr noet

# php5_fastcgi + ssl baikal config file

AllowOverride None

Require all denied

</Directory>

ServerName dav.example.com

Redirect permanent / https://dav.example.com/

</VirtualHost>

ServerAdmin webmaster@example.com

ServerName dav.example.com:443

DocumentRoot /var/www/dav.example.com/html/

ErrorLog /var/www/dav.example.com/logs/error.log

CustomLog /var/www/dav.example.com/logs/access.log combined

RewriteEngine On

RewriteRule /.well-known/carddav /dav.php [R,L]

RewriteRule /.well-known/caldav /dav.php [R,L]

SSLEngine on

SSLCertificateFile /etc/letsencrypt/live/dav.example.com/fullchain.pem

SSLCertificateKeyFile /etc/letsencrypt/live/dav.example.com/privkey.pem

Options None

Options +FollowSymlinks

AllowOverride All

</Directory>

SSLOptions +StdEnvVars

</FilesMatch>

SSLOptions +StdEnvVars

</Directory>

BrowserMatch "MSIE [2-6]" \

nokeepalive ssl-unclean-shutdown \

downgrade-1.0 force-response-1.0

# MSIE 7 and newer should be able to use keepalive

BrowserMatch "MSIE [17-9]" ssl-unclean-shutdown

AddType application/x-httpd-fastphp5 .php

Action application/x-httpd-fastphp5 /php5-fcgi

Alias /php5-fcgi /usr/lib/cgi-bin/php5-fcgi_dav.example.com

FastCgiExternalServer /usr/lib/cgi-bin/php5-fcgi_dav.example.com -socket /var/run/php5-fpm_dav.example.com.sock -pass-header Authorization

</IfModule>

</VirtualHost>

</IfModule>

# vim: syntax=apache ts=4 sw=4 sts=4 sr noet

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

a2enmod rewrite
a2ensite dav.example.com
service apache2 restart

a2enmod rewrite

a2ensite dav.example.com

service apache2 restart

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

chown www-data:www-data -R /var/www/dav.example.com

1	chown www-data:www-data -R /var/www/dav.example.com

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

touch /var/www/dav.example.com/Specific/ENABLE_INSTALL

1	touch /var/www/dav.example.com/Specific/ENABLE_INSTALL

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

http://dav.example.com
#lub
https://dav.example.com

http://dav.example.com

#lub

https://dav.example.com

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

wget https://github.com/fruux/Baikal/releases/download/0.4.2/baikal-0.4.2.zip

1	wget https://github.com/fruux/Baikal/releases/download/0.4.2/baikal-0.4.2.zip

Rozpakowujemy archiwum

unzip baikal-0.4.2.zip

1	unzip baikal-0.4.2.zip

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:

Upgrading Baïkal from version 0.2.7 to version 0.4.2

1	Upgrading Baïkal from version 0.2.7 to version 0.4.2

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:

_caldavs._tcp.example.com. IN SRV 0 5 443 dav.example.com.
_carddavs._tcp.example.com. IN SRV 0 5 443 dav.example.com.

1 2	_caldavs._tcp.example.com. IN SRV 0 5 443 dav.example.com. _carddavs._tcp.example.com. IN SRV 0 5 443 dav.example.com.

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

Przykładowe konfiguracje:

Thunderbird:

#CalDav
https://dav.example.com/dav.php/calendars/__user__/default

1 2	#CalDav https://dav.example.com/dav.php/calendars/__user__/default

Thunderbird + Cardbook

Add address book > Remote

Type: CardDav 
URL: https://dav.example.com/dav.php/addressbooks/__user__/default/

Username: user
Password: password

Validate > Next

Type: CardDav

URL: https://dav.example.com/dav.php/addressbooks/__user__/default/

Username: user

Password: password

Validate > Next

Android + DavDroid:

Pre-emptive authentication: Off

1	Pre-emptive authentication: Off

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:

openssl s_client -connect mail.server.address:993
a login <USER> <PASSWORD>
a IDLE

openssl s_client -connect mail.server.address:993

a login <USER> <PASSWORD>

a IDLE

Powinniśmy uzyskać taki rezultat:

+ idling
* OK Still here

1 2	+ idling * OK Still here

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

Zmienimy to zachowanie poprzez edycję pliku:

vim /etc/dovecot/conf.d/20-imap.conf
imap_idle_notify_interval= 29 mins

1 2	vim /etc/dovecot/conf.d/20-imap.conf imap_idle_notify_interval= 29 mins

systemctl restart dovecot.service

Zrobione!

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:

adb pull /data/data/com.google.android.apps.authenticator2/databases/databases

1	adb pull /data/data/com.google.android.apps.authenticator2/databases/databases

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

sqlite3 ./databases

select * from accounts;

sqlite3 ./databases

select * from accounts;

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:

adb push databases /data/data/com.google.android.apps.authenticator2/databases/databases
adb shell
#tutaj musimy dokładnie znać usera i grupę
chown user:group /data/data/com.google.android.apps.authenticator2/databases/databases

adb push databases /data/data/com.google.android.apps.authenticator2/databases/databases

adb shell

#tutaj musimy dokładnie znać usera i grupę

chown user:group /data/data/com.google.android.apps.authenticator2/databases/databases

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

/data/data/com.google.android.apps.authenticator2/databases/databases

1	/data/data/com.google.android.apps.authenticator2/databases/databases

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ć)

P	W	Ś	C	P	S	N
« Gru
				1	2	3
4	5	6	7	8	9	10
11	12	13	14	15	16	17
18	19	20	21	22	23	24
25	26	27	28