Auth required on KDE

Leave a reply

Debian Wheezy, KDE und ab und zu funktioniert das Einspielen von Updates nicht oder das Mounten von Datenträgern. Manchmal hilft Reboot, manchmal nervt’s und manchmal schaut man warum. Also heute, eine NTFS-Partition auf einer eingebauten Platte, die nicht in /etc/fstab steht, über Dolphin einbinden. Normalerweise wird da nach dem Passwort gefragt und dann macht er das. Heute nicht, stattdessen:

An error occurred while accessing ‘DATEN’, the system responded: An unspecified error has occurred.: Authentication is required

Rumsuchen im Netz ist da nicht ganz leicht, aber folgendes ließ sich rausfinden. Es gibt ein Programm namens udisks mit dem man die selbe Fehlermeldung provozieren kann und das auch ansonsten interessante Dinge ausgibt. Und es gibt ein Programm pkexec welches Teil von polkit ist und wenn man es so aufruft, kann man testen, ob da alles stümmt:

pkexec --disable-internal-agent /bin/true

Stimmte hier nicht, aber das brachte mich dahin, dass anscheinend ein Programm names polkit-kde-authentication-agent-1 laufen muss. Das lief hier nicht. Ob das abgestürzt war, oder nicht gestartet wurde, und warum, hab ich nicht mehr rausgefunden, aber das Ding einfach nochmal starten, behob mein Problem:

/usr/lib/kde4/libexec/polkit-kde-authentication-agent-1

Sachdienliche Hinweise nehme ich gern entgegen.

JavaMail and TLS: Turn on the security switch!

1 Reply

While talking to Ge0rg about latest issues in Java TLS we stumbled upon the question whether the JavaMail API would have similar problems.

Naturally one would expect that Java’s SSL implementation is secure. However, this is not the case: Special care needs to be taken regarding Man-In-The-Middle attacks: While a certificate may turn out to be valid, you cannot be sure that it has the right origin!

The problem is known for a while and library maintainers are taking steps to avoid it. However, for compatibility reasons those features may need to be turned on.

For JavaMail version 1.5.2 the SSLNOTES.TXT says specifically:

— Server Identity

Check RFC 2595 specifies addition checks that must be performed on the server’s certificate to ensure that the server you connected to is the server you intended to connect to. This reduces the risk of “man in the middle” attacks. For compatibility with earlier releases of JavaMail, these additional checks are disabled by default. We strongly recommend that you enable these checks when using SSL. To enable these checks, set the “mail..ssl.checkserveridentity” property to “true”.

Here is the thing that most examples forget: You need to switch that feature on!

final Authenticator auth = ... // somewhere in your application
final Properties p = new Properties();

// add your JavaMail configuration here

// this is implied by the protocol "imaps"
p.put("mail.imap.starttls.enable", "true");

// not only check the certificate, but also make sure that we are
// connected to the right server.
p.put("mail.imap.ssl.checkserveridentity", "true");

try {
	Session session = Session.getDefaultInstance(p, auth);
	Store store = session.getStore();
	store.connect();

	// do something with the store
} catch (MessagingException e) {
	// do something meaningful(!) with the exception
}

// close the store when you are done

To use SSL at all, you need to turn it on, either by specifying “imaps” in the property mail.store.protocol or by setting mail.imap.starttls.enable to “true”. Replace imap respectively for other protocol suites (e.g. smtp).

Update 2014-08-05: Inserted the Link to Georg’s blog post about latest issues in Java TLS.

HowTo: gitolite auf Debian Wheezy

2 Replies

Das Netz ist natürlich voll von HowTos zum Thema gitolite, in diesem hier nutze ich aber nicht die bleeding edge Version von upstream sondern das Debian-Paket. Eine gewisse Hilfe für’s Verständnis und bei der Installation war die Dokumentation für gitolite 2.x, denn in Wheezy ist Version 2.3 verpackt.

Installation

Geht los mit Installation des Pakets gitolite. Wenn der bei der Installation dpkg nichts konfiguriert haben will, dann gibt man danach nochmal ein:

dpkg-reconfigure gitolite

Dort wird dann ein SSH public key abgefragt für den Admin-Nutzer. In meinem Fall hab ich hier für die Testinstallation auf dem selben Rechner den folgenden Pfad angegeben, ansonsten kopiert man seinen public key ins Eingabefeld:

/home/adahl/.ssh/id_rsa.pub

Damit liegt jetzt hier unterhalb von /var/lib/gitolite1 folgendes:

% ls -la /var/lib/gitolite
insgesamt 28
drwxr-xr-x  5 gitolite gitolite 4096 Jun 17 13:51 ./
drwxr-xr-x 58 root     root     4096 Jun 17 13:47 ../
drwx------  8 gitolite gitolite 4096 Jun 17 13:47 .gitolite/
-rw-r--r--  1 gitolite gitolite 4217 Jun 17 13:47 .gitolite.rc
-rw-------  1 gitolite gitolite    0 Jun 17 13:47 projects.list
drwx------  4 gitolite gitolite 4096 Jun 17 13:47 repositories/
drwx------  2 gitolite gitolite 4096 Jun 17 13:47 .ssh/

Da mein public key bereits hinterlegt ist, kann ich direkt zum nächsten Schritt übergehen und das Admin-Repo clonen, welches bei der Installation angelegt wurde:

git clone gitolite@localhost:gitolite-admin

Wie man sieht, hatte ich den dedizierten Nutzer gitolite genannt, für Produktionsumgebung ist vielleicht git eine bessere Wahl.

Ganz wichtig: beim Ändern der Config muss man stets drauf achten, dass man sich nicht selbst aussperrt. Für das Repository gitolite-admin muss man Schreibrechte für irgendeinen Key behalten, auf den man auch Zugriff hat und der unterhalb von keydir im Repo liegt, sonst hat man keine Möglichkeit mehr ohne große Schmerzen diese Rechte wiederzuerlangen.

Konfiguration

Als nächstes habe ich die Datei /var/lib/gitolite/.gitolite.rc angepasst. Berücksichtigt sind hier bereits, dass ich sowohl git-daemon als auch gitweb einsetzen und die Repos auf einen anderen Rechner spiegeln will. D.h. ich habe folgende Einträge geändert:

$REPO_UMASK = 0027;
$GL_GITCONFIG_KEYS = "gitolite.mirror.*";
$REPO_BASE="/srv/repos/git";

Der letzten Zeile ist erhöhte Beachtung zu schenken. Die bereits angelegten Repositories gitolite-admin und testing aus /var/lib/gitolite/repositories müssen nämlich in den geänderten Pfad verschoben werden.2 Damit der Zugriff über gitweb funktioniert, habe ich den Nutzer www-data der Gruppe git hinzugefügt und die Rechte des Repository-Verzeichnisses gelockert:3

sudo addgroup www-data git
sudo chmod g+rx /var/lib/gitolite/repositories

Die eigentliche Konfiguration erfolgt dann wie bei gitolite üblich über das admin-Repository nachdem man es geklont hat:

git clone gitolite@myfancyserver:gitolite-admin

Wie man das im Einzelnen macht, kann man in der Doku zu gitolite v2 nachlesen. Das ist nicht Debian-spezifisch.

gitweb mit lighttpd

Für einen schnellen Überblick mit dem Webbrowser ist das Paket gitweb installiert. Als Webserver kann vermutlich irgendein Webserver dienen. Für lighttpd habe ich eine Datei /etc/lighttpd/conf-available/80-gitweb.conf angelegt und mit den für diesen Browser üblichen Mechanismen aktiviert. Der Inhalt sieht so aus:4

# -*- depends: cgi -*-
server.modules += ("mod_setenv")
setenv.add-environment = ("GITWEB_CONFIG" => "/etc/gitweb.conf")
alias.url += ( "/gitweb" => "/usr/share/gitweb" )

$HTTP["url"] =~ "^/gitweb/" {
        server.indexfiles = ("gitweb.cgi")
        cgi.assign = ( ".cgi" => "" )
}

Es ist außerdem das Modul 10-cgi.conf zu aktivieren:

sudo lighty-enable-mod cgi
sudo lighty-enable-mod gitweb

In der /etc/gitweb.conf sind auch noch Anpassungen zu tätigen. Hier meine geänderten Zeilen:

$projectroot = "/var/lib/gitolite/repositories";
$projects_list = "/var/lib/gitolite/projects.list";
@diff_opts = ('--find_renames', '--minimal');

Urspünglich war jetzt hier noch eine Beschreibung zum Mirroring, ich verschiebe das auf später und tu es in einen separaten Artikel … O:-)

  1. auch den Pfad kann man beim dpkg-reconfigure angeben. [↩]
  2. Dieser Schritt kann natürlich entfallen, wenn man die Repositories im Standard-Pfad belässt. [↩]
  3. Die Rechte der bei der Installation angelegten Repositories sind allerdings immernoch so restriktiv, dass sie nicht über gitweb angezeigt werden können. Bei <code>gitolite-admin</code> will man das sowieso nicht und statt <code>testing</code> legt man sich vielleicht ein weiteres Testrepository an, um zu sehen, ob das mit den Rechten beim neu anlegen richtig klappt. [↩]
  4. Siehe auch gitweb im ArchWiki. [↩]

Port based VLAN mit Netgear GS108Tv2

Leave a reply

Wir bauen im Netz39 gerade das Netzwerk ein bisschen um und wollen dabei auch mehrere logisch getrennte Netze einrichten. Die Routerhardware hat genau zwei Netzwerkkarten und kann nicht mehr bekommen, aber der Switch kann VLAN. D.h. was ich prinzipiell gern aufbauen möchte, ist etwa folgendes:

vlan

VLAN auf dem Router konfigurieren ist mit fli4l kein Problem, aber der Switch in meinem Testsetup1 hat mich grübeln lassen. So ging es dann. Erstmal die VLANs unter VLAN Configuration anlegen, hier mit den IDs 11 und 22:

netgear_vlan_1

Dann kommt sozusagen die Einrichtung des ausgehenden Verkehrs unter VLAN Membership. Hier wollen wir den Netzwerkverkehr aus den VLANs 11 und 22 beide auf dem Port zum Router haben und dort sollen die Tags drin bleiben, damit der Router das auch wieder aufdröseln kann. Deswegen wird Port 2 am Switch für beide VLANs mit T markiert, damit der Verkehr auf dem Port getaggt wird.2 Bisschen umständlich ist es, dass man jedes VLAN einzeln auswählen und dann unten noch die Liste mit den Ports aufklappen und alles einzeln bestätigen muss.3 Für den Netzwerkverkehr zu unseren dummen Geräten, die kein VLAN können oder davon nichts wissen sollen, lassen wir den Switch die Tags entfernen, markieren also die Ports 6 bis 8 mit U wie untag, was aber dennoch heißt, dass der Verkehr aus diesen VLANs über diese Ports rausgeht. Das sieht dann hier so aus:

netgear_vlan_2

… und …

netgear_vlan_3

Jetzt müssen wir uns noch um den eingehenden Verkehr kümmern, also das was ohne VLAN-Tag in den Switch gelangt. Dazu geht man auf Port PVID Configuration und kann dort dann einem Port genau ein VLAN zuordnen:

netgear_vlan_4

Ich hoffe, ich hab das alles richtig verstanden und keinen Quatscht jetzt hier erzählt. Es scheint aber zu funktionieren.

Update: Wenn man sich die PVID-Konfiguration nochmal ansieht, so wird Traffic auf den Ports 1 bis 5, der kein Tag hat, der VLAN-ID 1 zugewiesen. Da per default auf allen Ports U aka untag für die ID gesetzt ist, verlässt also ungetagter Verkehr von allen Ports den Switch auf allen Ports wieder. Was man jetzt vermutlich will: auf den Ports 6 bis 8 das U bei VLAN-ID noch rausnehmen, damit da wirklich nur Traffic des jeweiligen VLANs ankommt, und nicht noch der andere Traffic auch noch.

  1. welches leider nicht der Switch ist, der später auch Verwendung finden wird. [↩]
  2. Das was wir hier mit Port 2 gemacht haben, also Tags von verschiedenen VLANs in den Paketen belassen, wird an einigen Stellen im Netz als VLAN-trunk bezeichnet. [↩]
  3. Wegen so dämlichem UI gibt es solche HowTos … [↩]

Debian GNU/kFreeBSD in Xen HVM DomU mit Verschlüsselung und ZFS

1 Reply

Ich will Backup und ich will ZFS, da brauch ich glaube ich in beiden Fällen nicht drauf eingehen warum. Auf dem Server läuft ein Debian Wheezy (amd64) und mit Xen werden diverse virtuelle Maschinen ausgeführt. Für’s Backup sind vier Platten vorgesehen und da soll ZFS drauf und die Daten sollen verschlüsselt werden.

Wie ich jetzt darauf gekommen bin das ganze mit Debian GNU/kFreeBSD zu realisieren, sei mal nicht in Frage gestellt, ist jetzt so und es gibt eine VM, die mittels Hardware-Virtualisierung der CPU installiert wurde, hatte ich ja hier schon erwähnt wie. Probleme mit der I/O-Performance hab ich dank der passenden Mailingliste auch beheben können.

Bevor wir jetzt ZFS installieren, soll noch Crypto drunter. Das könnte man auch anders schichten, aber so rum scheint empfohlen zu sein. Ebenfalls empfohlen ist es Crypto nicht auf die nackte Platte zu tun (auch wenn das ginge) sondern die Platten noch zu partitionieren. Bei BSD scheint da mittlerweile GPT der Standard zu sein und das passende Tool bei FreeBSD wäre gpart. Beim Debian GNU/kFreeBSD haben wir aber Debian Userland und da gibt’s dieses Tool nicht. Partitioniere ich also mit gdisk, dachte ich mir, aber das ist dann auch wieder nicht so einfach, weil gdisk sich beschwert, dass /dev/da0 ein character device sei. Ist es auch, scheint bei BSD so zu sein, bedeutet aber, dass ich die Platten nicht in der VM partitionieren kann, sondern das bereits im Wirt tun muss. Mit gdisk war das kein Problem und als Partitionstyp hab ich mal FreeBSD ZFS benutzt aka 0xA504.

Nächster Schritt: Verschlüsselung. Da benutzt man bei FreeBSD das Tool geli und das ist dann wieder Kernel Space genug, dass es auch verfügbar ist. Befehle hier:

% sudo geli init -s 4096 -l 256 /dev/da0p1
Enter new passphrase:
Reenter new passphrase: 

Metadata backup can be found in /var/backups/da0p1.eli and
can be restored with the following command:

        # geli restore /var/backups/da0p1.eli /dev/da0p1

Und dann:

% sudo geli attach /dev/da0p1
Enter passphrase:

Beim Initialisieren kann man auch noch Keydateien angeben und alle möglichen Optionen setzen. Details dazu hat das FreeBSD-Handbuch. Analog wird mit den anderen Platten verfahren und es stehen einem dann die aufgeschlossenen Devices zur Verfügung, für die erste verschlüsselte Partition der ersten Platte hier /dev/da0p1.eli welches dann gleich einem zpool hinzugefügt wird.

Den zpool namens tank erzeugte ich dann so:

sudo zpool create tank raidz2 da0p1.eli da1p1.eli da2p1.eli da3p1.eli

Das entspricht de facto einem RAID-6 und ist auch bereits unter /storage gemountet. Für den nächsten Systemstart fehlt also nur noch ein Skript, was mir die Crypto-Devices aufmacht. Bei Debian GNU/kFreeBSD kann man da mal in /etc/default/geom schauen. Das darauf liegende ZFS wird dann automatisch gefunden und eingebunden.

Alles weitere ist dann Anwendung von ZFS, das wäre thematisch aber was für einen anderen Artikel. ;-)

ksplash’d

Leave a reply

Auf dem neuen Rechner im Büro ist (natürlich) Debian installiert, mit KDE, so wie auf allen meinen Rechnern. Flotte Kiste und ich hab mir nichts weiter dabei gedacht, dass nach dem Einloggen kein Splash Screen erschien, schnell halt die Mühle. Durch einen Zufall bin ich aber heute nochmal bei den Einstellungen der Splash-Screens gelandet und stellte fest, dass »Default« zwar funktionierte, das von mir bevorzugte »joy« des aktuellen Debian-Release Wheezy jedoch nicht. Warum? Gar nicht so leicht rauszufinden, aber was aufgerufen wird, ist wohl sowas wie das hier:

adahl@ada ~ % ksplashx joy --test     
libpng error: Read Error
Failed to load: background.png

Huch, was ist da denn das Problem? Mein Monitor läuft in keiner der Auflösungen, wo im Paket desktop-base Bilder mitgeliefert werden, also mal mit strace geschaut, was er da öffnen will:

open("/home/adahl/.kde/cache-ada/ksplashx/joy-1680x1050-background.png", O_RDONLY) = 5

Hmm, da hat wohl wer umgerechnet und abgelegt, und …

 
adahl@ada ~ % ls -l ~/.kde/cache-ada/ksplashx/
insgesamt 2028
-rw-r--r-- 1 adahl adahl 2076229 Jun  1  2012 Default-1680x1050-background.png
-rw-r--r-- 1 adahl adahl       0 Aug 23  2012 joy-1680x1050-background.png

Na sowas?! Also kurzerhand die leere Datei gelöscht und schon geht das! :-)

Link

Wunderbarer Beitrag von Lena:

“Non-coders” in Open Source projects or: On aliens – Confessions of a “non-coder” (1).

Gut geschrieben und amüsant illustriert. Eine Freude zu lesen, auch für Coder. ;-)

(via Twitter)

Wireshark als normaler Nutzer ausführen

Leave a reply

Mit jedem neuen Rechner und damit jeder neuen Installation kommen jedesmal die gleichen Probleme auf einen zu. Aktuell hab ich hier im Büro eine neue Maschine mit Debian Wheezy und ich will Wireshark als normaler Nutzer ausführen. Laut /usr/share/doc/wireshark/README.Debian muss dumpcap installiert sein und richtig eingerichtet und man muss selbst der Gruppe wireshark angehören. Das genannte Tool ist Teil des Pakets wireshark-common und das lässt sich wie folgt umkonfigurieren:

sudo dpkg-reconfigure wireshark-common

Es öffnet sich ein Menü, man stellt das gewünschte ein. Nutzer zur passenden Gruppe hinzufügen mit Debian-Mitteln sieht dann so aus:

sudo addgroup adahl wireshark

Ausloggen und neu wieder einloggen, damit die Gruppenberechtigungen wirksam werden und dann tut das.

Problemchen mit approx beheben

Leave a reply

In Zeiten vieler Rechner und dennoch langsamer Internetverbindungen1 kann ein Paketproxy ein wahrer Segen sein. Updates und Pakete für Debian und auf Debian basierenden Betriebssystem werden dann im lokalen Netz zwischengespeichert und es muss nicht jeder einzelne Rechner immer alles von einem Debian-Spiegel aus dem Netz holen. Ich setze dazu approx ein. D.h. ich betreibe keinen eigenen Mirror, sondern halte nur die nötigen Pakete lokal nochmal vor. Ein spezialisierter Proxy wie approx, der über die Struktur des Paketservers bescheid weiß, kann hier meiner Meinung nach bessere Dienste leisten, als ein generischer Proxy.

Während die Idee an sich gut ist, gibt es im Detail ein paar Problemchen. Sowohl approx vermurkst sich manchmal seine Daten als auch clientseitig das apt auf dem Rechner. Auf beiden Seiten kann man das wieder bereinigen und ich zeige kurz wie.

approx

Ein häufiges Problem, das ich bei approx festgestellt habe, sind 0 Byte große Dateien. Sind solche unter /var/cache/approx solche vorhanden, kommt es auf Clientseite zu allerlei komischen Fehlern, heute hatte ich da beispielsweise HTTP 404 für Dateien, die auf dem Mirror vorhanden sind. Auf dem Server, wo approx läuft, habe ich dann zwei Sachen ausgeführt:

sudo find -L /var/cache/approx -empty -exec rm -rf {} +
sudo approx-gc

apt

Die Probleme hier entstehen vermutlich ähnlich wie serverseitig durch unterbrochene Updatevorgänge, nutzer- oder netzwerkseitig, egal, es ist halt was kaputt. Es gibt natürlich aptitude clean und dergleichen und manchmal scheint das aber nicht zu helfen. Zuletzt behalf ich mir dann damit:

sudo rm -rf /var/lib/apt/lists
sudo mkdir -p /var/lib/apt/lists/partial

So sind Updates jetzt wieder möglich. Ich weiß zwar nicht, was genau und warum das ab und zu kracht, aber so kann man’s wenigstens in einen funktionierenden Zustand zurücksetzen.

  1. Breitbandausbau am Arsch! [↩]

Git unter Windows

3 Replies

Ganz ehrlich, ich hab die Schnauze voll von Windows. Es begann damit, dass ich mehrere Tage gebraucht habe, um Qt 4.8.x selbst zu kompilieren, weil die pre-built Binaries mit einem alten MinGW mit GCC 4.4.x gebaut wurden, dieses aber nicht mit Qt mitgeliefert wird. MinGW selbst stellt aber keine älteren Releases bereit und wegen ABI-Änderungen bei GCC lässt sich Qt (GCC 4.4) nicht mit aktuellem MinGW (GCC 4.8) zusammen nutzen. Das allein schon war frustrierend genug, aber es tauchen dann ja noch so Schwierigkeiten auf, wie dass der Snakeoil Virenscanner selbst kompilierte Software hart löscht. Jetzt habe ich endlich ein Qt und dann beschwert sich CMake noch lange vor dem Build der Anwendung, dass es ein “sh” im PATH gefunden hat. Git für Windows bringt das mit, wozu auch immer. Dachte ich, schauste mal, ob das unbedingt nötig ist, aber die Git-GUIs für Windows brauchen das und auch sonst ist das mit den GUIs für Git unter Windows höchst schmerzhaft. Eine Liste gibt es zwar, aber das ist alles unbrauchbar:

GitHub for Windows
Verbirgt große Teile der Komplexität von Git, ist damit für gewisse Workflows unbrauchbar und arbeitet, oh Wunder, nur mit GitHub.
Git Extensions
Ist nicht plattformunabhängig und installiert mir Dinge mit, die ich schon habe.
git-cola
Braucht erstmal noch Python und PyQt und letzteres wiederum bringt im Binary-Installer gleich wieder ein ganzes Qt mit. Was hatte ich noch gleich selbst kompiliert?
GitEye
Ist ein komplettes Eclipse, für Git, also riesengroß, nur für ein Versionsverwaltungssystem. Irre.
SmartGit
Nicht frei.
SourceTree
Braucht mindestens Windows 7.

Dann wäre da noch TortoiseGit, aber das ist nur ein Fork von dem für Subversion super geeigneten TortoiseSVN und dementsprechend ungeeignet für einen Git-Workflow. Git ist halt kein zentralisiertes Versionsverwaltungssystem wie CVS, wie soll ich dafür dann das selbe Interface gebrauchen können?

Bei Mercurial hat man wenigstens ein schönes plattformunabhängiges GUI in Qt geschrieben. Das heißt zwar auch TortoiseHg, hat aber von der Bedienung her kaum was mit den zuvor genannten gemein und spült mir auch keine zusätzliche kaputte Shell auf meinen Rechner.

Hölle, ist das alles broken. Ich will mein Linux zurück. :-/

Ach so ja, das Problem mit CMake lässt sich übrigens lösen, indem man das CMake-GUI mit einem sauberen PATH startet, bspw. mit einer Batch-Datei cmake-gui.bat:

cd "C:\Programme\CMake 2.8"
PATH=C:\MinGW\bin;C:\Qt\Qt4.8.5-x86\bin
"C:\Programme\CMake 2.8\bin\cmake-gui.exe"