bisher wars naemlich echt ein kampf und krampf…

aber warum “heroku”? die meisten pod betreiber duerften wohl eigene server betreiben. aber schonmal ein schritt nach vorne…

 

…wieder, damits irgendwo geschrieben steht. wer weiss, fuer was man das nochmal gebrauchen kann.

beim letzten mal hats ja schon nicht so recht klappen wollen. (fuer mich ist es) jedesmal wieder ein krampf. einfach nicht meine welt… naja…

beim update kam es bei diesem schritt…

DB="mysql" bundle install --without development,test

…zu dieser fehlermeldung:

Using markerb (1.0.0) from https://github.com/plataformatec/markerb.git (at master) 
ArgumentError: invalid byte sequence in US-ASCII
An error occured while installing markerb (1.0.0), and Bundler cannot continue.
Make sure that `gem install markerb -v '1.0.0'` succeeds before bundling.

oh.. ja.. die locales waren nicht richtig eingestellt. mal schnell nachholen und auf en_US.UTF-8 einstellen:

dpkg-reconfigure locales

dann kam es zu diesem fehler:

Installing rubygems-1.8.17 for ruby-1.9.3-p125@diaspora ...
Error running 'GEM_PATH="/home/diaspora/.rvm/gems/ruby-1.9.3-p125@diaspora:/home/diaspora/.rvm/gems/ruby-1.9.3-p125@global:/home/diaspora/.rvm/gems/ruby-1.9.3-p125@global" GEM_HOME="/home/diaspora/.rvm/gems/ruby-1.9.3-p125@diaspora" "/home/diaspora/.rvm/rubies/ruby-1.9.3-p125/bin/ruby" "/home/diaspora/.rvm/src/rubygems-1.8.17/setup.rb"', please read /home/diaspora/.rvm/log/ruby-1.9.3-p125@diaspora/rubygems.install.log
Installation of rubygems did not complete successfully.

was einfach deher ruehrte, dass in diesem pfad nichts installiert war…

/home/diaspora/.rvm/rubies/ruby-1.9.3-p125/bin/

warum auch immer… also einmal neu installieren.

rvm reinstall ruby-1.9.3-p125

ahja.. deswegen ists nicht installiert.. weil autoreconf fehlt:

rvm requires autoreconf to install the selected ruby interpreter however autoreconf was not found in the PATH.

also autoreconf installieren:

apt-get install dh-autoreconf

und dann klappts auch mit dem…

rvm reinstall ruby-1.9.3-p125

und das update wie bereits hier beschrieben laeuft durch… yeah ;-)

su - diaspora
git pull origin master
DB="mysql" bundle install --without development,test
RAILS_ENV="production" DB="mysql" bundle exec rake db:migrate
bundle exec rake assets:precompile

UPDATE: oh.. und diesmal war ich richtig schnell und bin ohne fremde hilfe ausgekommen ;-)

PingdomAlert UP:
https://pod.sd.vc (pod.sd.vc) is 
UP again at 03.07.2012. 09:39:36, after 45m of downtime.

 

seit dem letzten update des diaspora pods hat die kiste keine emails mehr verschickt. ein netter mann aus russland hat mich darauf hingewiesen, weil er die email zum passwort zuruecksetzen nicht bekommen hat. einfach ins blaue rein heute nochmal ein update gemacht.. und siehe da… es funktioniert ;-)

das bekam ich dann per mail:

Thank You, it works..and also thank you for making communicating in internet more independent and free..

*hach*… aber gerne doch.

 

vorhin in diaspora gelesen:

Use #diaspora for #personal #notes

Create an aspect (let’s say “Personal Notes” ) and don’t add any contacts to it. With that only your posts will show up there…

When creating a post give them a specific tag (like #personal_note or somethong more specific like #pn_2beX7 to make sure nobody else uses it…) and share it only with your previously created aspect “Personal Notes”

Voilá: when choosing your tag you see those posts dedicated for you

nuja… eine alternative zu anderen notizen? smartphone? pastebin? papier? sms? email? diverse online organizer? gehirn? blog? whatever? aber allemal besser, als facebook dafuer zu nutzen ;-)

 

nur mal so gepostet, damit ichs irgendwo niedergeschrieben habe.. fuer die meisten leser eher unbrauchbar ;-)

nach ein paar tagen war wiedermal ein update des diaspora pods faellig. da laeuft ja kein update wie das andere. und ich stehe mit ruby und java nicht wirklich in einem guten verhaeltnis. naja..

normalerweise ging das update so (in meinem fall…):

erstmal die laufende pod instanz killen, dann

cd /home/diaspora/diaspora
git pull origin master
DB="mysql" bundle install --without development,test
RAILS_ENV="production" DB="mysql" bundle exec rake db:migrate
RAILS_ENV=production DB="mysql" bundle exec jammit
chown diaspora.diaspora /home/diaspora/diaspora/ -R

und die pod instanz wieder starten.

diesmal brachte das

DB="mysql" bundle install --without development,test

folgenden fehler:

Bundler could not find compatible versions for gem "bundler":
  In Gemfile:
    bundler (~> 1.1.0) ruby
 
  Current Bundler version:
    bundler (1.0.21)
 
This Gemfile requires a different version of Bundler.
Perhaps you need to update Bundler by running `gem install bundler`?

also erstmal

gem install bundler

… ausgefuehrt. dann eins weiter in der “normalen” update liste

RAILS_ENV=production DB="mysql" bundle exec jammit

brachte diesen fehler:

/var/lib/gems/1.8/gems/bundler-1.1.3/lib/bundler/rubygems_integration.rb:147:in `gem': jammit is not part of the bundle. Add it to Gemfile. (Gem::LoadError)
	from /var/lib/gems/1.8/bin/jammit:20

also jammit ins gemfile eingetragen.
danach ein:

bundle install

…ausgefuehrt und nach einem wiederholten

RAILS_ENV=production DB="mysql" bundle exec jammit

kam dann das:

/var/lib/gems/1.8/gems/execjs-1.3.0/lib/execjs/runtimes.rb:50:in `autodetect': Could not find a JavaScript runtime. See https://github.com/sstephenson/execjs for a list of available runtimes. (ExecJS::RuntimeUnavailable)
	from /var/lib/gems/1.8/gems/execjs-1.3.0/lib/execjs.rb:5
	from /var/lib/gems/1.8/gems/uglifier-1.2.4/lib/uglifier.rb:3:in `require'
	from /var/lib/gems/1.8/gems/uglifier-1.2.4/lib/uglifier.rb:3
	from /var/lib/gems/1.8/gems/jammit-0.6.5/lib/jammit/dependencies.rb:22:in `require'
	from /var/lib/gems/1.8/gems/jammit-0.6.5/lib/jammit/dependencies.rb:22
	from /var/lib/gems/1.8/gems/jammit-0.6.5/lib/jammit.rb:221:in `require'
	from /var/lib/gems/1.8/gems/jammit-0.6.5/lib/jammit.rb:221
	from /var/lib/gems/1.8/gems/jammit-0.6.5/bin/../lib/jammit/command_line.rb:2:in `require'
	from /var/lib/gems/1.8/gems/jammit-0.6.5/bin/../lib/jammit/command_line.rb:2
	from /var/lib/gems/1.8/gems/jammit-0.6.5/bin/jammit:3:in `require'
	from /var/lib/gems/1.8/gems/jammit-0.6.5/bin/jammit:3
	from /var/lib/gems/1.8/bin/jammit:21:in `load'
	from /var/lib/gems/1.8/bin/jammit:21

das verlangte

gem install execjs

ausgefuehrt.. brachte mich aber kein stueck weiter. auf eine empfehlung hin dann node.js installiert. leider gabs kein debian 6.0 package, also musste ich zur manuellen installation greifen. die hab ich hier gefunden.

git clone https://github.com/joyent/node.git
cd node
# 'git tag' shows all available versions: select the latest stable.
git checkout v0.7.7
./configure --openssl-libpath=/usr/lib/ssl
make
make test
sudo make install

und der naechste versuch…

RAILS_ENV=production DB="mysql" bundle exec jammit

brachte dieses ergebnis:

Could not find the asset configuration file "/home/diaspora/diaspora/config/assets.yml"

auf rat von denshub im diaspora irc channel ein

bundle exec rake assets:precompile

ausgefuehrt, was auch wieder nen fehler spuckte:

rake aborted!
/var/lib/gems/1.8/gems/heroku_san-2.1.1/lib/tasks.rb:112: syntax error, unexpected ':', expecting kEND
          puts stage.push_config RACK_ENV: stage.name

er meinte dann, dass ich doch lieber ne neuere rube version verwenden sollte. gibt mittlerweile auch ein howto fuer squeeze.

es ist taktisch unklug, die ruby version dem system package manager zu ueberlassen, weshalb man doch besser rvm benutzen sollte. die wesentliche installation von rvm und ruby 1.9.2 ist laut dieser anleitung:

bash <(curl -s https://raw.github.com/wayneeseguin/rvm/master/binscripts/rvm-installer) stable
echo "[[ -s '$rvm_path/scripts/rvm' ]] && . '$rvm_path/scripts/rvm' # Load RVM function" >> ~/.bashrc
source ~/.bashrc
rvm install ruby-1.9.2-p290
rvm use ruby-1.9.2-p290@global

danach kommt beim wechseln in das diaspora verzeichnis diese meldung:

==============================================================================
= NOTICE                                                                     =
==============================================================================
= RVM has encountered a new or modified .rvmrc file in the current directory =
= This is a shell script and therefore may contain any shell commands.       =
=                                                                            =
= Examine the contents of this file carefully to be sure the contents are    =
= safe before trusting it! ( Choose v[iew] below to view the contents )      =
==============================================================================
Do you wish to trust this .rvmrc file? (/home/diaspora/diaspora/.rvmrc)
y[es], n[o], v[iew], c[ancel]> y

welche mit ja zu bestaetigen ist. dann noch ein freundliches:

bundle install

mein naechstes update wird verrmutlich so aussehen:

su - diaspora
git pull origin master
DB="mysql" bundle install --without development,test
RAILS_ENV="production" DB="mysql" bundle exec rake db:migrate
bundle exec rake assets:precompile

und diese geschichte ging noch gefuehlte stunden lang weiter. nach dem starten hatte ich nur noch 500er fehler. die shell, in der ich den server gestartet hatte, war noch mit der alten ruby version verheiratet. die netten leute im diapsora irc channel haben mich aber noch ein bischen supportet. logfiles wurden ueber pastebin ausgetauscht usw… ohne die jungs waere ich hoffnungslos aufgeschmissen gewesen. danke nochmal an DenSchub und MrZYX fuer die kompetente hilfe.

letztendlich wars noch ein fehler im source, der behoben wurde, als wir noch an der fehlersuche waren. ein freundliches git pull mit allem was dazugehoert brachte dann abhilfe.

kurze gedankenstuetze, damit ich mich irgendwann noch dran erinnern kann:

assets=javascript, bilder & css
jammit=js&css kompilieren (wir benutzen ne meta sprache für css: sass) und komprimieren
rails 3.1: asset pipeline: neuer weg um den gesamten kram zu handlen
dadrin: neuer weg zum zusammenstöpseln und komprimieren von dem ganzen kram
diasporas upgrade auf rails 3.1: die bildchen sind in der neuen verzeichnisstruktur verloren gegangen
aber halt im quellcode noch benutzt worden
das war der fehler den du gesehn hast (eh, mir fehlen die bilder)

ja, diaspora ist noch alpha. aber fuer jemanden, der sich zwar mit linux auskennt, aber mit ruby, java und dem ganzen kram nichts am hut hat, ist es echt nicht einfach, solch einen pod in diesem entwicklungsstadium zu betreiben. ich werde erstmal die mailingliste abonnieren, damit ich gravierende aenderungen vielleicht vorher mitbekomme. vorausgesetzt, ich finde ueberhaupt die zeit dazu, mich intensiver damit zu beschaeftigen. man hat ja noch genuegend andere mailinglisten etc. zu lesen.

 

wha.. kurz vorm ins bett gehen wollte ich “noch schnell” den diaspora pod mal wieder updaten. geht ja schnell… und dann geht nix mehr. der firefox sagt:

Die aufgerufene Website leitet die Anfrage so um, dass sie nie beendet werden kann.

da haben die mal wieder was geaendert und ich habs nicht mitbekommen, weil ich zu faul bin, die release notes zu lesen. ich unterstelle jetzt einfach mal, dass das da drin gestanden haette. die installationsanleitung hat im abschnitte Configuring SSL zumindest ein update bekommen. ein kurzer besuch im deutschen diaspora irc channel brachte mich auf die richtige faehrte, dass die reverse proxy configuration angepasst werden muss. fuer den nginx lautet die entsprechende zeile:

proxy_set_header X-Forwarded-Proto https;

und fuer den apache2:

RequestHeader set X_FORWARDED_PROTO 'https'

 

gerade toent es hinter mir:

“bist ja doch wieder auf facebook und nicht auf desperados… äh.. nee… diaspora, oder?”

 

grad auf einer d* mailingliste gelesen:

[..] But my conception is little bit different. I think, a real decentralized social network doesn’t need pods. My idea is a network from personal wordpress blogs which can communicate through diaspora protocol as minimal (1 person) pods. This is something real decentralized thing. You have not trust any pod provider, cause you really own all of your data in your personal wordpress instance. [..]

yes. genau den gedanken hatte ich auch schon. ok, das mit dem vertrauen in einen provider hat man auch bei ner simplen wordpress installation. die geschichte koennte man noch paaren mit xmpp statt http. das wiederspraeche zwar der “einfachheit”, so dass es jeder auf einem shared hosting ding installieren kann, aber wuerde der “realtime communication” eher dienen als alles ueber irgendwelche webserver abzuwickeln. das “message queue’ing” bei xmpp duerfte einfacher (und fertig und standardisiert) sein und ausserdem braucht man xmpp ja sowieso zum chatten. facebook, google, gmx usw machen es vor.

da drueber schlaf ich jetzt mal.

 

so… der meinige diaspora pod (btw ist die abkuerzung fuer diaspora ist “d*”) kriegt gerade sein erstes backup verpasst. man weiss ja nie. ausserdem ist er nun bei podupti.me gelistet. die schlechte antwortzeit kommt daher, dass der genutzte monitoring anbieter seine serverchen wohl in kanada stehen hat.

und! achtung… *trommelwirbel* ..naja.. nicht ganz so spektakulaer: es sind schon sieben user auf dem pod ;-)

im irc channel auf freenode hab ich mich mal umgeschaut, auf der mailingliste bei google groups bin ich angemeldet, diverse blogs und wikis durchstoebert, viele neue sachen auf meine “spaetervorbeisurf-liste” gelegt wie z.b. friendica.com oder das wiki auf github, wo jemand mal protokoll details niedergeschrieben hat (1,2).

ein haufen neues zeug. megabytes an input fuers hirn. ich brauche vielleicht jemanden, der sich mit mir zusammen ein bischen um den pod kuemmert. schliesslich muss der kram momentan eigentlich taeglich aktualisiert werden.

ums mit volkers worten zu sagen: “man brauch ja noch projekte”.

 

hmm.. auf podupti.me sind inzwischen 74 diaspora server gelistet. interessant ist die geographische verteilung:

in einigen laendern gibts wohl mehr leute, die es fuer notwendig halten, eine alternative zu kommerzialisierten social networks zu schaffen.