Tag: software

er hat sich wieder gemeldet…

Da neulich die Frage nach einem funktionierenden Background-Stretcher aufgetaucht war: Gerade habe ich mal MooTools MooSizer erfolgreich in ein CONTAO 2.11.2 installiert. Ist zwar ein ganz klein wenig fummelig, aber wenigstens spart man sich JQuery, was für die Erweiterung bgstretcher erforderlich wäre 🙂 Netterweise gibts ein gutes Tutorial über die Konfiguration von MooSizer:

http://de.contaowiki.org/Fullsize_Background_mit_MooTools_MooSizer

cheers, spirou

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.

so.. da ich weder google fuer meinen kalender benutzen, noch einen exchange server (weiter) betreiben oder sonst irgendwelche “fremden” online dienste nutzen moechte, werde ich nun mal mein glueck mit owncloud versuchen. owncloud kann einen kalender via caldav zur verfuegung stellen und bietet auch eine weboberflaeche dafuer an. das iphone, ipad und auch die osx eigene iCal.app koennen mit caldav umgehen. also ran an die buletten und erstmal sehen, wie ich meine ganzen termine aus dem exchange da rueber bekomme. zufaellig hatte ich auf meinem alten mac noch das office paket mit entourage installiert. wenn das drauf ist, bietet die iCal.app eine funktion “Aus Entourage importieren..” an.

da mein kalender im exchange schon etwas laenger in betrieb ist, habe ich stolze 6475 eintraege zu ex- bzw. importieren. lustigerweise war das teil damit fast zwei tage (!!!) mit 100% cpu last beschaeftigt. keine ahnung, was das soll. zuerst dachte ich, dass der vorgang abgeschmiert waere, aber irgendwann hab ich festgestellt, dass sich der fortschrittsbalken doch noch bewegt.

wenn man das getan hat, hat iCal.app erstmal einen neuen, lokalen Kalender namens “Entourage” angelegt und alle termine dort rein importiert. diese muessen dann erst noch in eine datei exportiert werden:

(klick auf “Kalender” –> rechte maustaste auf “Entourage” –> exportieren)

warum muss ich erst importieren und dann exportieren? natuerlich, damit ich das wieder importieren kann! 😉

erst beim “normalen” import hat man naemlich die moeglichkeit, den kalender auszuwaehlen, in den importiert werden soll.

dann die vorhin exportierte datei auswaehlen:

und in den kalender importieren, in den man es haben will. in dem fall ist das der “default” kalender meiner owncloud instanz.

that’s it. sechseinhalb tausend kalendereintraege. mal sehen, wie performant die geschichte ist. das iphone hat ein moment gebraucht, bis es den kalender initial hatte. vor allem will ich mal drauf achten, was da fuer ein traffic entsteht und wie schnell die synchronisierung i.d.r. dauert. vielleicht ist es an der zeit, mal die passenden rfc’s zu schmoekern…

seit einiger zeit.. (ich weiss nicht genau wann, aber jetzt habe ich osx 10.7.3 drauf) habe probleme, wenn ich mich ueber ssh mit bestimmten alten linux kisten verbinde und dort z.b. “top” aufrufen moechte. folgende fehlermeldung bekomme ich dann zu gesicht:

'xterm-256color': unknown terminal type

eine ergooglete loesung waere in die datei ~/.profile (die es standardmaessig auf dem mac erstmal nicht gibt) diese zwei zeilen einzutragen.

TERM="xterm"
export TERM

wenn man das nicht auf dem mac machen will, kann man das alternativ auch auf dem zielsystem machen, welches die fehlermeldung gespuckt hat.

die ditte moeglichkeit ist: in den einstellungen der terminal.app unter erweitert die terminal emulation angeben:

bei allen drei varianten muss man die shell bzw das terminal neu starten, damit das wirksam wird.

ich ging schon immer an die decke, wenn 1st level supporter & co immer so sachen von sich gaben wie “wir haben probleme mit dem “outlook server”, wenn sie eigentlich exchange meinen. und dann muss ich auch noch bei google (also eine seite von google selbst) sowas lesen:

also quasi andersrum… exchange ist nun ein “email programm”?

hmm… mein ubuntu sagt mir, dass ich von dem 1,8 TB grossen netzlaufwerk noch 2,0 TB verfuegbare habe. das geht naemlich auch nur, weil -205 GB belegt sind… wtf?

apple hat in osx nicht mal eine moeglichkeit eingebaut, irgendwo einen haken setzen zu koennen, damit die versteckten dateien und ordner im finder angezeigt werden koennen. (die, die mit einem punkt beginnen)
im terminal kann man sich diese natuerlich anzeigen lassen… das ist aber nicht jedermanns sache, da man dort nicht rumklicken kann.
eine loesung ist dieser befehl, den man einfach in einem terminal ausfuehrt:

defaults write com.apple.finder AppleShowAllFiles TRUE && killall Finder

und um das wieder rueckgaengig zu machen:

defaults write com.apple.finder AppleShowAllFiles FALSE && killall Finder

so.. nachdem der erste versuch nicht ganz so erfolgreich war, hab ich mich zwischendurch mal wieder mit owncloud beschaeftigt und mal die neue version 3 installiert. um irgendwann mal unabhaengig von einem exchange account zu werden, habe ich erstmal probiert, den bei owncloud integrierten carddav server zu nutzen.

das einrichten am iphone geht wie folgt…

einen neuen account unter “einstellungen” –> “mail, kontakte, kalender” -> “account hinzufuegen”

dann “carddav-account hinzufuegen”

server, benutzer und passwort angeben. ich hab erst den fehler gemacht, den server mit vorangestelltem (https://servername/apps/contacts/carddav.php) einzutragen, was dann zu dieser fehlermeldung fuehrt:

also einfach nur “servername/apps/contacts/carddav.php” dort eintragen.

bei den einstellungen muss man dann (sofern man vom standardport abweicht) in die erweiterten einstellungen..

..und ssl auf port 443 einrichten (sofern man https nutzt. fuer http dann port 80, bzw den port, den man auch wirklich nutzt)

that’s it. nun muss ich nur mal schauen, wie ich die kontakte vom exchange exportiert und in owncloud importiert bekomme.
wenn man nun im iphone mehrere accounts mit kontaktdaten hat, muss man natuerlich beim nutzen des adressbuchs aufpassen, in welches adressbuch man neue kontakte einpflegt.

da immer wieder viele leute aufgrund der paar posts ueber whatsapp auf meinem blog landen, hier nochmal ein bischen background wissen vom shakal:

http://shakal.blog.de/2011/03/22/whatsapp-risiken-10872342/

und auch mal was positives… theoretisch… vielleicht… auf den ersten blick:

http://shakal.blog.de/2012/03/13/whatsapp-datenbanken-mehr-einsehbar-13170316/