Sehr ohne Context, ein paar Python Links, die ich in den letzten Tagen und Wochen interessant fand.
pypy3 mit python 3.2.5 rausgekommen. http://morepypy.blogspot.de/2014/06/pypy3-231-fulcrum.html
Hilfsbibliothek um python 2 & 3 im selben Code zu unterstützen: https://pypi.python.org/pypi/six
Würde Python 2.8 bei der Portiereung auf 3 helfen? https://regebro.wordpress.com/2014/06/03/would-a-python-2-8-help-you-port-to-python-3/
[UPDATE 23. Jun 2019]
I just realized... starting from OpenSSH 7.3, it is even easier by
using ProxyJump...
Host server1 10.0.1.1
Hostname 10.0.1.1
ProxyJump user1@jumphost1.example.org:22,user2@jumphost2.example.org:2222
... or using -J
ssh -J user1@jumphost1.example.org:22 10.0.1.1
[/UPDATE]
[UPDATE 06. May 2016]
Carlos Lopes Pereira pointed me to the article SSH Agent Forwarding Is a Bug by @neerolyte. I also think this is a valid point, so removed the agent forwarding flags.
[/UPDATE]
Sometimes it makes sense to use ssh jump hosts to reach hosts in a DMZ. To avoid connecting those jump host manually and starting another ssh-connection on the jump host, we are using ProxyCommand, defined in ssh_config.
Historically, we are using nc on the jump host, to forward the connection to the target host.
Host server1 10.0.1.1
Hostname 10.0.1.1
ProxyCommand ssh -q -x IP_OF_JUMP_HOST 'nc %h 22'
Unfortunately, this cause a large number of orphaned nc-processes on the jump host. It is possible to get rid of those leftovers by using nc -w 1 %h 22.
But why using nc? Why installing another piece of software on the ssh jump hosts? ssh is capable to do this on its own, using ssh -W %h:22.
-W host:port
Requests that standard input and output on the client be forwarded
to host on port over the secure channel. Implies -N, -T,
ExitOnForwardFailure and ClearAllForwardings and works with Protocol
version 2 only.
Changing the ssh_config:
Host server1 10.0.1.1
Hostname 10.0.1.1
ProxyCommand ssh -q -x IP_OF_JUMP_HOST -W %h:22
Hinweis:Desktopumgebungen bringen eventuell schon Einstellungen für natural scrolling mit.
$ xmodmap -e "pointer = 1 2 3 5 4 7 6 8 9 10 11 12"
## Oder
$ xinput list
⎡ Virtual core pointer id=2 [master pointer (3)]
⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)]
⎜ ↳ SynPS/2 Synaptics TouchPad id=11 [slave pointer (2)]
...
$ xinput set-button-map 11 1 2 3 5 4 7 6 8 9 10 11 12
xmodmap setzt die Einstellung für alle pointer, während er bei xinput explizit angegeben werden muss. xinput eignet sich daher für den Fall, dass sich Mäuse unterschiedlich verhalten sollen. Z.B. soll ein Scrollrad wie gehabt scrollen, ein TouchPad aber natural.
Die Einstellungen lassen sich zur Laufzeit wieder zurücksetzen in dem 5, 4 und 7,6 (horizontal) wieder zurück getauscht werden:
$ xmodmap -e "pointer = 1 2 3 4 5 6 7 8 9 10 11 12"
# bzw
$ xinput set-button-map 11 1 2 3 4 5 6 7 8 9 10 11 12
Zum globalen persistieren für alle input pointer eigenet sich die 1. Variante mit xmodmap am besten. Einfach eine ~/.Xmodmap mit folgendem Inhalt anlegen:
$ cat .Xmodmap
pointer = 1 2 3 5 4 7 6 8 9 10 11 12
Um die Einstellungen für jede Maus einzeln zu persistieren ist etwas mehr Hirnschmalz nötig. Z.B. https://github.com/cemmanouilidis/naturalscrolling .
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