Ich habe ein Update auf Xorg 1.15.0 gemacht und danach funktionierte meine Einstellung der Caps_Lock- als zusätzliche Control-Taste nicht mehr. Ich musste die ~/.Xmodmap anpass um meine gewohnte Konfiguration wiederherzustellen:
keycode 66 = Control_L
clear lock
add Control = Control_L
Wieder einmal ist ein Jahr vergangen... Neue Fingerprints:
imap:
MD5: 78:E8:22:A9:AA:5C:83:74:FE:85:70:76:89:51:09:C8
SHA1: 63:DC:51:31:8D:80:52:7A:F0:0E:B5:26:FD:CD:F3:74:00:1B:B5:46
Not Before: Jan 16 20:18:55 2014 GMT
Not After : Jan 16 20:18:55 2015 GMT
smtp:
MD5: AA:24:96:3E:05:5B:AD:56:E2:6E:CE:44:8D:89:AD:06
SHA1: 41:ED:EE:25:7D:7F:29:22:2F:26:36:C0:35:39:08:84:68:DC:14:27
Not Before: Jan 16 20:20:02 2014 GMT
Not After : Jan 16 20:20:02 2015 GMT
Endlich habe ich es mal geschafft mich ein paar Stunden hinzusetzen und das CSS für https://chrigl.de/ anzupassen. Die nicht-Edit-Variante der Seite läuft auf meinem Galaxy S3 ganz gut. Beim Edit-Bereich muss man ein paar kleine Abstriche machen. z.B. sind manche Felder minimal zu lang. Doch da ich der einzige Editor bin, kann ich gut darüber hinweg sehen.
Zuerst habe ich das CSS mit dem Firefox lokal auf dem Notebook mit media queries auf verschiede Größen getrimmt. Im Anschluss daran testete ich die Seite direkt im Firefox auf dem Galaxy S3. Wie zu erwarten sah ich ein anderes Ergebnis als auf dem Desktop-Firefox.
Da es aber doch die eine oder andere Seite im Netz gibt, die sich auch auf mobilen Geräten vernünftig anzeigen lassen, habe ich nach einer Debugging-Möglichkeit für den Firefox auf Android gesucht... und bin fündig geworden. Zu meiner Überraschung sogar mit Firefox-Bordmitteln (Remote debugging Firefox for Android und Firefox Remote Debugging ).
Zuerst galt es die Development-Option meines Cyanogenmod 10.2 zu aktivieren. Völlig intuitiv geht dies über Einstellungen => Über das Telefon. Dort gibt es ein Feld Build-Nummer. Wie man leicht errät, ist nach siebenmaligem drücken auf Build-Nummerdie Development-Option verfügbar. Erreichbar ist sie nun über Einstellungen => Developer options. Dort muss USB Debuggingaktiviert werden. Zusätzlich habe ich Firefox als Select debug appausgewählt.
Nach dem setzen des forwards konnte ich mit dem Devtools des Desktop-Firefoxes auf den Firefox auf Andriod verbinden und das DOM etc. ändern. Also alles wie lokal gewohnt. Es ist sogar möglich per Klick auf dem Telefon ein Element zu selektieren. Funktioniert sehr schön alles! Mit diesem Modus habe ich die letzten Kleinigkeiten ausgemerzt. Im echten Leben würde ich wohl früher mal auf dem Smartphone testen.
Für Interessierete steht der Quellcode auf Launchpad zur Verfügung.
In der vergangenen Woche konnte ich ein Test-Setup mit OpenStack Havana (für CentOS) von Grund auf einrichten. Wir haben uns erst einmal auf die Verwaltung der virtuellen Maschinene mittels KVM/libvirt konzentriert und weitere Komponenten wie Quantum erst einmal außen vor gelassen. Zusätzlich haben wir zur Verwaltung des Block Storage cinder aufgsetzt.
In der ersten Installation haben wir bewusst auf Hilfen wie DevStack verzichtet. Wir wollten auch etwas unter die Haube schauen. Ich finde es bemerkenswert, dass die Installation quasi nur aus Copy and Paste aus der OpenStack Dokumentation besteht.
Nachdem der Identity-Service keystone aufgesetzt, der Image-Service glance , der Block Storage cinder , das Dashboard horizon und die Compute-Nodes nova in relativen Standardkonfigurationen eingerichtet waren, haben wir uns an unsere Testfälle gesetzt. Zur Einrichtung der Compute-Nodes ist noch zu sagen, dass alle Zugriff auf die MySQL-Datenbank der Master-Node benötigen.
Das Anlegen und Verwalten der Images geht über die wirklich guten command line tools leicht von der Hand. Daraus Images zu starten ist ebenfalls einfach. Wenn man erst einmal vernünftige Images erstellt hat. Zu vergleichszwecken haben wir Gentoo-Images erzeugt, die so nah an unseren aktuellen VMs liegen wie möglich. Beim Erstellen der Images ist darauf zu achten, einen dhcp-client zu liefern und sich beim hochfahren eine dynamische IP zu holen. Um die Verwaltung kümmert sich OpenStack. Aus Images schreibbare Volumes zu erzeugen gelingt ähnlich einfach wie das Bereitstellen von Images.
Bis hier her hat alles exakt nach Dokumentation funktioniert. Hier noch einmal ein großes Lob für.
Wir spielten ein bisschen mit hoch und runter der VMs rum und waren ein bisschen vom JavaScript-VNC-Interface angetan. Das erste Problem auf das wir gestoßen sind, war die nicht funktionierende Migration. Doch auch hier gab war die Lösung durch Exceptions im Log einfach zu finden. Die Benutzer nova jeder Compute-Node müssen ohne Passwort (ssh-keys) auf die anderen Compute-Nodes zugreifen dürfen. Dies ist vor allem für das Kopieren der Daten nötig. Leider kann man bei der Migration einer VM keine Ziel-Node angeben. Die Auswahl obliegt OpenStack. Es gibt aber die (von uns ungetestete) Möglichkeit mittels Filter in die Auswahl der Ziel-Node einzugreifen. Ich verstehe hier ja durchaus den Sinn. Den Endanwender soll die zugrunde liegende Hardware nicht interessieren. Doch zurück zur Migration. Diese Erfolgt im Falle von laufenden Images immer einhergehend mit einem Neustart der VM. Die in libvirt unterstützte Live-Migration wird von OpenStack (noch) nicht unterstützt. Verwendet man an Stelle von Images aber Volumes, ist mit ein wenig Konfigurationsarbeit auch eine Live-Migration möglich. Wenn in beiden Migrationsfällen die Migration auf die Ziel-Node fehlschlägt, wird der nächste probiert.
OpenStack Havana fühlt sich erstaunlich fertig an und arbeitet an den meisten Stellen wie ich es erwartet habe. Kommt es mal zu Fehlern, lassen sich diese in den Logs finden. Wie das aber leider bei Exceptions im Log so oft der Fall ist, ist häufig nicht klar was genau passiert ist. Oft fehlen daher Quell- und Ziel-Node, was das Debugging erschwert. Schön finde ich die Möglichkeit an bestimmten Stellen eigenen Code einhängen zu können. Siehe Filter oder Driver.
Was mir persönlich ganz gut Gefällt ist die Art und Weise wie OpenStack arbeitet. Es dient als Verwaltungs-Layer und verwendet unter der Haube viele Komponenten die es schon lange gibt und die dementsprechend reif sind. z.B. dnsmasq als dhcp-Server, iSCSI mittels tgt für den Block Storage, u.a. libvirt als Hypervisor. Wenn man im OpenStack mal eine Instanz verloren hat, bedeutet das so keineswegs, dass man nicht mehr dran kommt.
Besonders positiv möchte ich die command line tools erwähnen. Sie kommen alle mit bash_completion daher und bedienen sich intuitiv.
http://vim.wikia.com/wiki/Modeline_magic
For example in python executables that does not ends with .py. I know, do never ever do this. Rollout packages using entry_point console_script. But however.
# vim: set filetype=python tabstop=4 softtabstop=4 shiftwidth=4 textwidth=120 smarttab expandtab:
Do not forget to use "set modeline" in your ~/.vimrc.
But only if you are aware of https://bugs.gentoo.org/show_bug.cgi?id=14088 and https://bugs.gentoo.org/show_bug.cgi?id=73715
Since paster is not compatible with python 3, I need an alternative.
I want to create a python package with a nested namespace. The package name and the first namespace should be the same all the time. For example my.monitoring. The next namespace should be flexible, to generate my.monitoring.solr, or my.monitoring.mysql. Some boilerplate code should be created and at least one script should be generated on installation of the new packages. The script generation is done by entry_points console_script in setup.py
entry_points="""
# -*- Entry points: -*-
[console_scripts]
solr_stats = my.monitoring.solr.script:solr_main
""",
mr.bob perfectly does everything I need. Check it out!
Both server running ejabberd 2.1.x
Sync the config files.
# rsync -avP oldhost:/etc/ejabberd/ /etc/ejabberd/
Maybe also copy ssl-certs and allow ejabberd to access the pem file.
On the old server. ejabberd must be still running.
# ejabberdctl backup /tmp/ejabberd-oldhost.backup
On the new server. ejabberd must be already running.
# ejabberdctl restore /tmp/ejabberd-oldhost.backup
This is just a kind of stub. But however ;)
>>> import paramiko.agent
>>> a = paramiko.agent.Agent()
>>> k = a.get_keys()[0]
>>> d = k.sign_ssh_data(None, 'Hello World')
### Transfer d
>>> from paramiko import Message
>>> from paramiko.rsakey import RSAKey
>>> with open('id_rsa.pub') as f:
... keytype, b64key, _ = f.next().strip().split(None, 2)
...
>>> import base64
>>> pkey = RSAKey(data=base64.b64decode(b64key))
>>> msg=Message(d)
>>> pkey.verify_ssh_sig('Hello World', msg)
True
>>> pkey.verify_ssh_sig('Hellö World', msg)
False
ssh-agent should run.
I integrated pylint into Jenkins to get a better code quality overview. Most of the integrations is quite easy and straightforward.
Jenkins -> Manage Jenkins -> Manage Plugins, or just /pluginManager
$ pylint --generate-rcfile > pylint.cfg
$ ... customize pylint.cfg
$ git add pylint.cfg
$ git commit -a -m "added pylint"
$ git push
Jenkins -> MyJob -> Configure
Add build step -> Execute shell
if [ ! -d venv ] ; then
virtualenv --python=python2.7 venv
fi
source venv/bin/activate
export PYTHONPATH="$PWD:$PYTHONPATH"
pip install pylint
cd repo
### Need this because some strange control sequences when using default TERM=xterm
export TERM="linux"
## || exit 0 because pylint only exits with 0 if everything is correct
pylint --rcfile=pylint.cfg $(find . -maxdepth 1 -name "*.py" -print) MYMODULE/ > pylint.log || exit 0
Jenkins -> MyJob -> Configure
Add post-build Action -> Report Violations
Filled the field pylint with the pattern **/pylint.log
So the next build also performed the pylint run, and generated the report with graphs.
... with the list of source files.
Unfortunately, on click onto the filename, I got an empty page, where I expected the source view, including detected warnings and errors.
I quick search on the jenkins server showed the xml results of the pylint run. The xml was valid, and seemed to be correct. So the reneration of the report should not be the problem.
A web search just gave me some defects, similar to my problem, but the tickets all are still open. So I digged around in the Violations cofiguration in MyJob. Just by "educated guess", I filled the field "Source Path Pattern" with **/
et voila, the the results for each file were available after the next build.
Maybe just because I did not update that often in the last weeks, I ran into this error:
# pacman -Suy
:: Synchronizing package databases...
core is up to date
extra is up to date
community is up to date
multilib is up to date
error: failed to prepare transaction (could not satisfy dependencies)
:: Starting full system upgrade...
:: poppler-qt: requires poppler=0.22.5
First updating poppler-qt, or to be more exact poppler-qt4, and poppler-glib solved the problem.
# pacman -S poppler-qt
resolving dependencies...
looking for inter-conflicts...
:: poppler-qt4 and poppler-qt are in conflict. Remove poppler-qt? [y/N] y
error: failed to prepare transaction (could not satisfy dependencies)
:: poppler-glib: requires poppler=0.22.5
# pacman -S poppler-qt poppler-glib
resolving dependencies...
looking for inter-conflicts...
:: poppler-qt4 and poppler-qt are in conflict. Remove poppler-qt? [y/N] y
Packages (4): poppler-0.24.0-1 poppler-qt-0.22.5-1 [removal]
poppler-glib-0.24.0-1 poppler-qt4-0.24.0-1
Total Download Size: 1.18 MiB
Total Installed Size: 5.90 MiB
Net Upgrade Size: 0.08 MiB
:: Proceed with installation? [Y/n]
:: Retrieving packages ...
poppler-0.24.0-1-x86_64 922.3 KiB 657K/s 00:01 [----------------------] 100%
poppler-qt4-0.24.0-... 130.0 KiB 395K/s 00:00 [----------------------] 100%
poppler-glib-0.24.0... 158.3 KiB 697K/s 00:00 [----------------------] 100%
(3/3) checking keys in keyring [----------------------] 100%
(3/3) checking package integrity [----------------------] 100%
(3/3) loading package files [----------------------] 100%
(3/3) checking for file conflicts [----------------------] 100%
(4/4) checking available disk space [----------------------] 100%
(1/1) removing poppler-qt [----------------------] 100%
(1/3) upgrading poppler [----------------------] 100%
(2/3) installing poppler-qt4 [----------------------] 100%
(3/3) upgrading poppler-glib [----------------------] 100%