Schlagwörter-Archiv: linux

ownCloud – jetzt schon!

Veröffentlicht am von — Keine Kommentare ↓

Vergangenen Herbst hatte ich ja schon mal den Einsatz von ownCloud als BYOS Dropbox-Ersatz getestet und kurz darüber berichtet. Damals kam ich zu dem Schluss, dass auf Client-Seite noch zu viele Kinderkrankheiten bestehen.

Da mittlerweile nun sogar schon Produktivinstanzen mit mehr als 35.000 Nutzern gefahren werden (TU Berlin, Quelle: Heise Online), habe ich einen neuen Versuch unternommen.

Verwendet habe ich auf Server-Seite ownCloud 5.0.6, auf meiner Workstation den owncloud-client 1.2.5-1, basierend auf ocsync-0.70.7-1, beides aus dem AUR.

Auf dem Server lief alles genau so reibungslos wie bei meinem letzten Test, keine Fehler in den Apache-Logs. Einzig bei der Installation wird trotz manuell geändertem Pfad für das Data-Folder noch erzwungen, dass der Standardpfad existiert – stört aber nicht weiter. Ich bin übrigens ziemlich paranoid bzw. restriktiv beim Setzen der Ordner-Rechte und -Besitzer, man wird den Schönheitsfehler (wenn es denn einer ist) bei einer Standardinstallation wahrscheinlich nicht mal bemerken.

Der Client scheint seine Probleme soweit ich bisher beurteilen kann losgeworden zu sein:

  • keine Unmengen Debugging-Output mehr
  • QT-Eingabefelder im Setup-Dialog verlieren ihren Inhalt nicht mehr
  • selbst signierte SSL-Zertifikate können nach Bestätigung eines entsprechenden Dialogs dauerhaft akzeptiert werden
  • keine unverständlichen Konflikte mehr

Dementsprechend wächst auch das Access-Log des Servers nicht mehr so schnell.

Soweit also ein für den Produktiveinsatz geeigneter Zustand, ich werde weiter testen und über etwaige Erfahrungen berichten.

fail2ban: punish retries

Veröffentlicht am von — Keine Kommentare ↓

One problem of fail2ban setups is that many bots seem to have adapted to the ban behavior: they detect being banned, start probing periodically and simply continue their attack after having been unbanned.

A simple solution is to choose a high value for banTime (or infinite), but that has the disadvantage of permanently banning regular users who just forgot their password, which unnecessarily generates support requests.

A different solution without this downside is a second-level approach: why not monitor /var/log/fail2ban.log for banned hosts and permanently ban them after some number of continued attacks?

Of course we do this with fail2ban, here’s the configuration:

# /etc/fail2ban/filter.d/fail2ban.conf
 
[Definition]
 
failregex   = fail2ban.actions: WARNING \[.*\] Ban <HOST>
ignoreregex = fail2ban.actions: WARNING \[fail2ban\] Ban <HOST>
# /etc/fail2ban/action.d/permaban.conf
 
[Definition]
actionstart = 
actionstop = 
actioncheck = 
 
actionban   = iptables -I banned 1 -s <ip> -j DROP
actionunban = /bin/true
 
 
[Init]

(Important here is to choose a different iptables chain than the one used for regular (i.e. temporary) bans!)

# /etc/fail2ban/jail.conf
 
(...)
 
[fail2ban]
enabled  = true
findtime = 86400
filter   = fail2ban
action   = permaban
           mail[logpath=/var/log/fail2ban.log]
logpath  = /var/log/fail2ban.log
maxretry = 2

Still testing it, but looks promising :)

Set Locale for Auto-Login through LightDM

Veröffentlicht am von — Keine Kommentare ↓

I don’t remember whether this is a known bug or a design flaw, but you currently end up with the default system locale when using LightDM with automatic login under Arch.

My fix until today was to extend my window manager, awesome, with the Lua-POSIX modules and set the desired locale in my rc.lua like this:

-- fix locale
pox = require("posix")
pox.setenv("LC_ALL", "de_DE.UTF-8")
pox.setenv("LANG", "de_DE.UTF-8")

When I switched to i3 yesterday, I ended up with this old hassle again. Searching the net, I stumbled upon this article, which made me set up ~/.pam_environment for my locale:

LC_ALL=de_DE.UTF-8
LANG=de_DE.UTF-8

Guess what, works like a charm :)

Login Manager Startup Delay

Veröffentlicht am von — Keine Kommentare ↓

(This post could also be titled An Ode to strace)

Recently had some weird problems with the login manager lxdm, which I switched over to because it was said to avoid the awesome keyboard layout bug.
The problem with lxdm (and slim) was that when started, it showed only a black screen and blocked for about a minute.

I had absolutely no clue what was going on until I started lxdm with strace. The output showed that the last thing lxdm was doing before blocking is trying to connect a TCP socket over IPv6 to ‘::1′, which is the IPv6 loopback address:

(...)
socket(PF_INET6, SOCK_STREAM|SOCK_CLOEXEC, IPPROTO_TCP) = 7
setsockopt(7, SOL_TCP, TCP_NODELAY, [1], 4) = 0
setsockopt(7, SOL_SOCKET, SO_KEEPALIVE, [1], 4) = 0
connect(7, {sa_family=AF_INET6, sin6_port=htons(6000), inet_pton(AF_INET6, "::1", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, 28) = ? ERESTARTSYS (To be restarted if SA_RESTART is set)

Checking my ip6tables I found out that I had forgotten to allow all loopback traffic in the INPUT chain, and as the default policy is set to DROP, the connection attempts were not rejected but dropped, therefore causing the delay (connect() timeout).

Adding the appropriate rules fixed the issue – man, this was weird :)

aerotools-ng

Veröffentlicht am von — Keine Kommentare ↓

Wie bereits angekündigt hatte ich vor einiger Zeit die ersten Hürden vor Aquaero5-Support für aerotools genommen.

Nun bin ich endlich dazu gekommen, den derzeitigen Stand der Dinge für jedermann zugänglich zu machen – in Form des neuen Projekts aerotools-ng.

Code und Readme gibts auf GitHub: https://github.com/lynix/aerotools-ng

xfce4-notifyd über dbus ansprechen

Veröffentlicht am von — Keine Kommentare ↓

Kürzlich bin ich von der awesome-eigenen Notificaion-Implementierung naughty auf xfce4-notifyd gewechselt – hauptsächlich wegen des (einfacheren) Themings.

Leider enden bei mir aus noch ungeklärten Gründen notify-send-Aufrufe sehr oft in Traps:

Nov 15 13:37:15 thor kernel: traps: notify-send[1857] trap int3 ip:7f92f516fa27 sp:7fff35a3a870 error:0

Also habe ich nach einem Weg gesucht, den xfce4-notifyd direkt per dbus anzusprechen.
Hierfür müsste eigentlich ein dbus-send-Aufruf à la

dbus-send --session --dest=org.freedesktop.Notifications \
    --type=method_call /org/freedesktop/Notifications \
    org.freedesktop.Notifications.Notify \
    string:'application' uint32:0 \
    string: string:'headline' \
    string:'message body' \
    array:string: dict:string: int32:3000

genügen, allerdings passt da irgendwas mit der Signatur der aufzurufenden Methode nicht und nicht mal dbus-explorer kann sie aufrufen.

Als Workaround, bis ich die Ursache gefunden habe, nutze ich diesen kleinen Fetzen Python, den ich aus einem Forum entnommen (und angepasst) habe:

#!/usr/bin/env python2
 
import dbus
import sys
 
item = ('org.freedesktop.Notifications')
path = ('/org/freedesktop/Notifications')
interface = ('org.freedesktop.Notifications')
 
if len(sys.argv) > 3:
	icon = sys.argv[3]
else:
	icon = 'dialog-information'
 
array = ''
hint = ''
time = 10000
app_name = ('')
title = (sys.argv[1])
body = (sys.argv[2])
 
bus = dbus.SessionBus()
notif = bus.get_object(item, path)
notify = dbus.Interface(notif, interface)
notify.Notify(app_name, 0, icon, title, body, array, hint, time)

(Keine Beschwerden bitte, das sind die ersten Zeilen Python, die ich je angefasst habe ;) )

ownCloud – noch nicht

Veröffentlicht am von — 2 Kommentare ↓

Angeregt durch einen Artikel in der C’T habe ich die vergangenen drei Tage selbst mal versucht, eine ownCloud-Instanz als BYOS-Ersatz für Dropbox zu verwenden.

Serverseitig bin ich rückblickend recht zufrieden, die Software macht einen deutlich stabileren Eindruck als bei meinem letzten Versuch vor ein paar Monaten und ich konnte keine Unregelmäßigkeiten in den Webserver-Logs erkennen.
Clientseitig herrscht jedoch noch große Baustelle: abgesehen von diversen kleineren Bugs in der Qt-GUI des offiziellen Clients (mirall auf csync) traten beim Ändern von Dateien immer wieder unverständliche Konflikte auf. Außerdem scheint der Client permanent Dateieigenschaften vom Server zu pollen, was bereits nach einigen Stunden ein mehrere MB großes Apache-Logfile generiert – unschön – und das ohne jede Dateiänderung.

Deswegen kommt für mich ownCloud derzeit (noch) nicht als Dropbox-Ersatz in Frage. Sollte es alternative Clients oder größeren Fortschritt beim offiziellen Client geben werde ich erneut testen.

Niedriger Ethernet-Durchsatz auf P8P67 und kernel3

Veröffentlicht am von — Keine Kommentare ↓

Wer ein ASUS-Board der Reihe P8P67 (Pro/Evo/Deluxe) und damit oft einen maximalen Ethernet-Durchsatz von ~6 kB/s netto hat sollte mal ins Kernel-Log schauen:

Jan  6 11:14:56 localhost kernel: Pid: 0, comm: swapper Tainted: P         C  3.1.7-1-ck #1
Jan  6 11:14:56 localhost kernel: Call Trace:
Jan  6 11:14:56 localhost kernel: <IRQ>  [<ffffffff810bbcf6>] __report_bad_irq+0x36/0xe0
Jan  6 11:14:56 localhost kernel: [<ffffffff810bbfac>] note_interrupt+0x15c/0x210
Jan  6 11:14:56 localhost kernel: [<ffffffff810b9e89>] handle_irq_event_percpu+0xc9/0x2a0
Jan  6 11:14:56 localhost kernel: [<ffffffff810ba0a8>] handle_irq_event+0x48/0x70
Jan  6 11:14:56 localhost kernel: [<ffffffff810bc8da>] handle_fasteoi_irq+0x5a/0xe0
Jan  6 11:14:56 localhost kernel: [<ffffffff81016992>] handle_irq+0x22/0x40
Jan  6 11:14:56 localhost kernel: [<ffffffff814095da>] do_IRQ+0x5a/0xe0
Jan  6 11:14:56 localhost kernel: [<ffffffff8140622e>] common_interrupt+0x6e/0x6e
Jan  6 11:14:56 localhost kernel: <EOI>  [<ffffffff81275f3b>] ? intel_idle+0xcb/0x120
Jan  6 11:14:56 localhost kernel: [<ffffffff81275f1d>] ? intel_idle+0xad/0x120
Jan  6 11:14:56 localhost kernel: [<ffffffff81319916>] cpuidle_idle_call+0xc6/0x350
Jan  6 11:14:56 localhost kernel: [<ffffffff81013229>] cpu_idle+0xc9/0x120
Jan  6 11:14:56 localhost kernel: [<ffffffff813e2d62>] rest_init+0x96/0xa4
Jan  6 11:14:56 localhost kernel: [<ffffffff8194ec15>] start_kernel+0x3bf/0x3cc
Jan  6 11:14:56 localhost kernel: [<ffffffff8194e347>] x86_64_start_reservations+0x132/0x136
Jan  6 11:14:56 localhost kernel: [<ffffffff8194e140>] ? early_idt_handlers+0x140/0x140
Jan  6 11:14:56 localhost kernel: [<ffffffff8194e44d>] x86_64_start_kernel+0x102/0x111

Tauchen diese Zeilen auf, so ist das Board von einem Problem mit ACPI und der verwendeten BIOS-Version betroffen. Workaround: die andere Ethernet-Karte benutzen ;)

Wie der Timestamp sagt ist das Problem recht alt, tauchte bei mir mit kernel-3.5.4-1 wieder auf.

Aquaero5 Payload geknackt

Veröffentlicht am von — Keine Kommentare ↓

An alle Nutzer meiner aerotools: der erste Schritt in Richtung Support für das aquaero5 ist getan, ich konnte heute die ersten Bytes des Payloads entschlüsseln zuordnen!

Damit lassen sich schon mal die Temperatursensoren auslesen:

[alex@thor aerotools-ng]$ ./main /dev/hidraw2
temp0: 29.97°C
temp1: 27.27°C
temp2: 33.96°C
temp3: not connected
temp4: not connected
temp5: not connected
temp6: not connected
temp7: not connected

Hatte nach Lektüre unzähliger Specs, Dokus und Codesamples zu USB, libhid & Co. schon fast aufgegeben, dabei war des Rätsels Lösung direkt vor meiner Nase :)

Details folgen, sobald es der Prüfungsstress zulässt.

munin-node mit systemd

Veröffentlicht am von — Keine Kommentare ↓

Für den Betrieb von munin-node unter systemd sind die folgende Service-Unit und ein Eintrag in /etc/tmpfiles.d nötig:

/etc/systemd/system/munin-node.service:

[Unit]
Description=Munin Node Service
After=syslog.target network.target
 
[Service]
Type=forking
PIDFile=/var/run/munin/munin-node.pid
ExecStart=/usr/sbin/munin-node
 
[Install]
WantedBy=multi-user.target

/etc/tmpfiles.d/munin-node.conf:

D /var/run/munin 0755 munin munin -