FireFox Sync Server

Thursday, November 30. 2017

After years of Chromium as my default browser I've moved to give FF a new go after the release of v57 aka Quantum. Mozilla is still more trustworthy than Google and hey, I prefered Netscape over Mosaic once. Part of the shift was trying out FireFox sync. Since I have not much trust in the cloud unless it is my own server this meant installing Firefox Syncserver on my debian server.

I more or less followed the howto from sathya.de/blog/how-tos/setup-your-own-firefox-1-5-sync-server-on-debian-with-apache2-and-mysql/ , there are links to the mozilla docu included on his site. The basic steps are easy to take, with dns.he.net and letsencrypt with dehydrated setup of a new subdomain with a valid SSL-certificate has gone down to a matter of minutes.

Git clone the server, create a db and db-user, config the virtualhost in the web servers configuration, edit the default syncserver.ini, restart the webserver and then tell the clients in about:config which syncserver to use. Pretty basic, but it still has some potential for confusion and took me two runs to get it running.

the supplied syncserver.ini has an entry   public_url = http://localhost:5000/   which appears to suggest that ports should be defined in the server config, client config. But this is not so, in a production environment with https and a web server non ports are given.

I saw 404 errors in the error_log which stemmed from an error with the client config, I had erased the token/ - ppart of the uri. And I experienced a multitude of 500 server errors with traces in the error_log pointing at a line between Public_url = ... and allow_new_users = ...
The first complained the given secret exceeded the maximum length, while it had been created like the comments advise. Later I saw errors from parsing the sqluri. Many visual checks did not find a problem.

What helped me was a set of voodoo measures including: manually retyping the sqluri line  and  inserting a 'dummy = stupid' line supposed to catch any non-visible carried syntactical elements. Other possible sources of problems here include permissions issues and missing execution flag on the wsgi file.

And then, suddenly, it worked.

 

ipv6 bei hetzner

Tuesday, December 30. 2014

 schon schräg. IPv6 humpelt immer noch.

Neuen root server bei hetzner bestellt (EX40 im RZ 21), Debian-77-wheezy-64-minimal drauf. Erste Aktion die neuen IPs auf dns.he.net eingetragen, host erkennt sie sofort, also als naechstes ein ssh auf den neuen Vogel. Dauert, und dauert, und .. Ok, ssh -4 neuerVogel.domain.tld: zap ist er da.

Gleich ein ping6 heise.de und 

PING heise.de(redirector.heise.de) 56 data bytes
From Debian-77-wheezy-64-minimal icmp_seq=1 Destination unreachable: Address unreachable
From Debian-77-wheezy-64-minimal icmp_seq=2 Destination unreachable: Address unreachable
From Debian-77-wheezy-64-minimal icmp_seq=3 Destination unreachable: Address unreachable
^C
--- heise.de ping statistics ---
6 packets transmitted, 0 received, +3 errors, 100% packet loss, time 5030ms
 
Na fein, Tante Google findet mir serverfault.com/questions/477471/ipv6-only-works-after-pinging-the-default-gateway mit einer Problembeschreibung, die ich voll nachvollziehen kann. Nur die dort beschriebene Lösung bleibt hier wirkungslos.
Zahllose google/test/reboot - Zyklen später bleibt als Ergebnis meiner Recherche:
- verblüffend wenige Fundstellen. IPv6 scheint wirklich kaum jemanden zu interessieren.
- der einzige auf meinem Rechner funktionierende Weg ist, den im obigen Link beschriebenen Workaround
  ping6 -I eth0 -c3  fe80::1
mit etwas sleep davor und danach in /etc/rc.local zu packen. slep 1 war zu wenig, sleep 10 tuts scheinbar.
 
Das ist doch kaum zu glauben, dass das Hetzner/debian - Image IPv6 nicht auf Anhieb klaglos hinbekommt sondern ich eine solche Krücke einsetzen muss! 
Vor gefühlt 10+ Jahren habe ich mir IPv6-Tunnel von sixxs und später he.net auf Hetzner-Server gelegt und die waren schneller benutzbar konfiguriert als das 'native' heute ...
 
 

ssh mit chroot für ausgewählte Benutzer

Saturday, December 27. 2014

 Es gibt da eine aufmunternd kurze und im ersten test auch prompt funktionierende Anleitung, wie man für bestimmte user den ssh - Zugang in einen chroot jail lenken kann.

allanfeid.com/content/creating-chroot-jail-ssh-access

Einen Mangel sehe ich derzeit:

cd ~
#: cd: /var/jail/home/test-ssh: No such file or directory
 
Lösung: Das Problem war hier, dass für den user test_ssh als home-verzeichnis eben der absolute Pfad eingetragen war. auf /home/tet_ssh verkürzt klappt es wie erwartet.
 
Dass nächste Problem war, dass nach dem Kopieren von .bashrc und .bash_profile der Prompt  PS1="[\u@\h:\l \W]\\$ "  zu dieser Ausgabe führte:
[I have no name!@server:tty ~]$
Den Grund, weshalb \u nicht aufgelöst wird, habe ich nicht gefunden, aber den Workaround, stattdessen $USER einzutragen.
 
mc liess sich aufrufen, fand aber seine default - Skin nicht und verstand die Pfeiltasten der Tastur nicht. Ich musste im jail /usr/hare/mc und /usr/share/terminfo ergänzen. 
 
Damit auch scp gelingt, musste ausser /usr/bin/scp und den libs, die l2chroot kopiert, noch /lib64/libnss_files.so.2 kopiert werden, und ein symlink von /bin/bash auf /bin/sh war auch nötig. 
 
Ich habe anschliessend www.little-idiot.de/ChrootEntkommen.pdf nachzuvollziehen versucht, aber weder mit direktem scp noch verpackt in ein tar ist es mir gelungen, eine Datei mit root als owner in den jail zu kopieren. 
 
 
 
(Page 1 of 1, totaling 3 entries)