I recently ran into an issue where a docker container I started hung when generating som certificates/keys. After more than 1 hour it started successfully. As I found out, the system did not have enough entropy to generate the certificates/keys.

If you run in such a problem this is a good workarround to generate entropy:

while /bin/true; do dd if=/dev/urandom of=/tmp/100 bs=1024 count=100000; for i in {1..10}; do cp /tmp/100 /tmp/tmp_$i_$RANDOM; done; rm -f /tmp/tmp_* /tmp/100; done

Just run the above code in another session on the system where you want to start the docker container and after a very short time (much faster than before) the task needing entropy will succeed.

How to install Bugzilla 5.0 on CentOS 7

Wenn man unter Ubuntu Mate (getestet mit 15.10 64bit) die Erweiterung caja-share für den Dateimanager caja installiert

sudo apt-get install caja-share
killall caja
caja

hat man im Dateimanager die Option direkt über das Kontextmenü eines Ordners diesen freizugeben.

Danach (so habe ich angenommen) sollte man sofort auf die Freigabe zugreifen können – leider nicht.

Man muss den Benutzer der Zugriff auf die Freigabe haben soll auch noch als Samba User anlegen. Dies geschieht mit:

smbpasswd -a BENUTZERNAME

Leider sieht man hier wieder, dass einerseits für Endbenutzer eine einfache Möglichkeit geschaffen wurde, Freigaben über die grafische Oberfläche einzurichten, aber leider funktioniert das Ganze dann trotzdem nicht ohne Hintergrundwissen und zusätzliche Eingriffe.

Das sind meiner Meinung die kleinen Problemchen, die einen normalen Endanwender dann immer wieder ärgern und es dann zu der Aussage kommt: „Unter Windows geht das ganz einfach mit der Familienfreigabe…usw.usw.“

I recently bought a Dell XPS 13 (Modell 2015) Ultrabook and I run Arch Linux on it. One thing I missed from the beginning was the absence of a drive LED. When I saw, that the XPS 13 has a white LED to signal ShiftLock directly inside the ShiftLock-Key I had an idea. Hey, I run Linux and I have total control, so why not use this ShiftLock-LED as a HardDrive LED?

The following script (running as a service) provides the Drive LED functionality on the Dell XPS 13. (Thanks to P.I. Engineering, Manwe and Stefo for their ideas)

#!/bin/bash
# save this file as pcfreakled without extension
# and make it executable (chmod +x)

#check dependencies
command -v setxkbmap >/dev/null 2>&1 || { echo >&2 "Script requires setxkbmap but it is not installed.Aborting."; exit 1; }
command -v setleds   >/dev/null 2>&1 || { echo >&2 "Script requires setleds but it is not installed.Aborting."; exit 1; }

# console
CONSOLE=/dev/console

# disable caps lock key
# This can also be done within Gnome but here is also a good place
setxkbmap -option ctrl:nocaps  >/dev/null 2>&1

# Check interval seconds
CHECKINTERVAL=0.1

#indicator to use [caps, num, scroll]
INDICATOR=caps

getVmstat() {
#  cat /proc/vmstat|
   egrep "pgpgin|pgpgout" /proc/vmstat 
}
#turn led on
function led_on()
{
    setleds -L +${INDICATOR} < ${CONSOLE} >/dev/null 2>&1
}
#turn led off
function led_off()
{
    setleds -L -${INDICATOR} < ${CONSOLE} >/dev/null 2>&1
}
# initialise variables
NEW=$(getVmstat)
OLD=$(getVmstat)
## 
while [ 1 ] ; do
  sleep $CHECKINTERVAL # slowdown a bit
  # get status 
  NEW=$(getVmstat)
  #compare state
  if [ "$NEW" = "$OLD" ]; then  
    led_off ## no change, led off
  else
    led_on  ## change, led on
  fi
  OLD=$NEW  
done

If your Linux distribution already uses systemd, you can use the following file to implement the above script as a daemon (assuming you placed the script in /usr/lib/systemd/scripts/pcfreakled):

[Unit]
Description=PCFreaks Dell XPS13 DriveLED

[Service]
Type=simple
ExecStart=/usr/lib/systemd/scripts/pcfreakled

[Install]
WantedBy=multi-user.target

Es war einmal ein glücklicher Linux Anwender, der wollte eine vernünftige linux-kompatible Hardware kaufen und hörte davon, dass es das Ultrabook Dell XPS 13 "Developer Edition" gibt, welches ab Werk mit Linux ausgeliefert wird. Da er aber nicht das zum Verkauf angebotene Ubuntu 14.04 Linux benutzen wollte und an einen eventuellen späteren Verkauf des Notebooks dachte, kaufte er sich das Dell XPS 13 mit Windows 8.1. Zudem gab es am Kauftag im Online-Shop von Dell auch noch 10% Rabatt auf dieses Gerät und der Versand war kostenlos. Kurzum für 1069 Euro war der XPS 13 mit I5, HD Auflösung 8GByte RAM, 256GByte SSD ohne Touch erhältlich. Zusätzlich wurde dann noch ein zweites Netzteil und der Dell 4in1 Adapter (LAN, VGA, HDMI, USB) gekauft um die Sache abzurunden.

Einen Tag nachdem das Gerät geliefert war stellte der Anwender fest, dass die Tasten F9 und F10 keilförmig zueinander standen und vmtl. die Tastatur einen Schaden hat.

Erst mal kein Problem, Dell schickte einen Techniker vor Ort, der die Tastatur austauschte. Die Tasten waren nun in Ordnung. An der alten Tastatur war ganz klar erkennbar, dass das Tastaturblech bereits ab Werk verbogen war.

Am folgenden Abend bemerkte der Anwender bei der Nutzung des Touchpads jedoch, dass plötzlich die rechte Seite des Touchpad aus dem Gehäuse herausragte. Der Dell Techniker hatte beim Zusammenbauen des Gerätes irgendetwas verbockt.

Da der Anwender dachte, dass so ein Pech nicht normal ist und ein Gerät für ca. 1100 Euro solche Mängel nicht haben sollte, wollte er das Gerät umtauschen um ein neues Gerät zu erhalten. Leider musste er feststellen, dass das erst möglich ist, wenn mindestens 3x eine Reparatur am Gerät versucht wurde. Da man bei Onlinegeschäften jedoch innerhalb von 14 Tagen das Gerät zurücksenden kann, entschied sich der Anwender für diese Methode, verfasste aber gleichzeitig einen Brief (ja Brief, keine E-Mail) an die Dell-Beschwerdestelle, da er umgehend ein neues Laptop (diesmal sofort mit Ubuntu) bestellen wollte, jedoch der Rabatt von 10% nicht mehr auf der Homepage verfügbar war.
Die Beschwerdestelle hat mehr oder weniger prompt reagiert, nachdem Anrufe beim Support und auch Kontakt mit dem offiziellen Support Twitter Account von Dell nichts brachten. Der ausschlaggebende Satz in der Beschwerde des Anwenders war wohl:

Ich behalte mir das Recht vor, über diesen Sachverhalt zu bloggen, zu tweeten und je nach Ergebnis auch einen Bericht in einer namhaften Computerzeitschrift zu veröffentlichen.

Dell hat mir nach einigen Emails dann 70 Euro Rückerstattung gewährt um das Fehlen des 10% Rabatts ein wenig abzufedern. – Akzeptabel

Nun kam es aber noch besser. Die Ethernet-Schnittstelle des mitgekauften Dell 4in1 Adapters funktioniert zwar problemlos unter Linux, jedoch NICHT die enthaltene VGA- bzw. HDMI-Schnittstelle. Diese Ports in Kombination mit dem im Adapter verbauten Chip funktionieren derzeit unter Linux überhaupt nicht und werden vermutlich erst ab Q3 2015 experimentell unterstützt.

Zum Zeitpunkt des Kaufs wurde weder auf der deutschen Homepage von Dell noch bei Amazon (auch dort verkauft Dell diesen Adapter) darauf hingewiesen, dass dieser Adapter Microsoft Windows und entsprechende Treiber erfordert. Mittlerweile (wie von Geisterhand) zeigte die deutsche Homepage nach einer weiteren Beschwerde des Anwenders nun zwar die Betriebssystemvoraussetzung, jedoch auf englischsprachigen Dell Webseites und bei Amazon (unter Dell) wurde immer noch nicht angezeigt, dass bestimmte Betriebssystemvorausseztungen notwendig sind um den Adapter zu betreiben.

Nach mehreren E-Mails zeigte sich Dell auch hier einsichtig und bot an den Adapter (Rücksendung auf eigene Kosten) zurückzunehmen und das Geld zu erstatten.

Hier noch einige nette Punkte, die dem Anwender bei obiger Geschichte passiert sind:

– Erstkontakt mit Beschwerdestelle ist nur per Fax/Postbrief möglich
– man fliegt regelmäßig aus der Support-Hotline (vor allem wenn versucht wird weiter zu verbinden)
– nur mit genug Energie bekommt man sein Recht

Als positiv gibt es zu bemerken, dass das Ultrabook nun mit Arch Linux problemlos läuft (BIOS Update A04) und aktuelle Touchpad-Firmware (diese konnte man nur unter Windows installieren) vorausgesetzt.

Dell hat mittlerweile die Ubuntu-Version dieses Notebooks auf Eis gelegt (es traten zu viele Fehler auf), siehe dazu auch http://bartongeorge.net/2015/07/20/xps-13-developer-edition-on-pause/
Es war z.B. so, dass das Erstellen der Recovery-CDs während des Installationsvorgangs nicht möglich war (der Installer wurde komplett beendet), erst nach allen Ubuntu Updates war nach erneutem Aufruf der Recovery-Datenträger erstellbar

Negativ zu bemängeln ist natürlich, dass obwohl das Notebook sehr generische Komponenten aufweist, nur bedingt unter Linux alles out-of-the-box lief. Dank Arch-Linux und der Unterstützung der Community läuft nun aber alles sauber.

Als Ersatz für den Ethernet-Adapter wurde nun dieser gekauft: http://www.amazon.de/dp/B00ESVH4MO/ref=pe_386171_38075861_TE_item
Als Ersatz für HDMI/VGA wurde ein Adapter für den miniDisplayport gewählt: http://www.amazon.de/dp/B01147OIS2/ref=pe_386171_38075861_TE_item

Ich musste kürzlich meinen Linux-Home-Server neu booten. Ich stellte fest, dass es ein Problem mit exim4 gab.

/var/log/exim4/mainlog
2015-07-05 10:38:22 socket bind() to port 25 for address ::1 failed: Cannot assign requested address: waiting 30s before trying again (7 more tries)

/var/log/exim4/paniclog
2015-07-05 10:39:30 socket bind() to port 25 for address ::1 failed: Cannot assign requested address: daemon abandoned

Außerdem fehlt die Datei

/var/run/exim4/exim.pid

Das Problem war, dass exim4 sich zusatzlich zur IPv4-Adresse (127.0.0.1) auch auf die IPv6-localhost-Adresse binden wollte (::1) und damit Probleme hatte. Im Linux Umfeld hatte mit IPv6 schon oft Probleme und der Server läuft noch unter "Wheezy".

Abhilfe:
Wenn man wie ich IPv6 auf dem Server nicht benötigt, einfach in der Datei "/etc/exim4/update-exim4.conf.conf" die "dc_local_interfaces" Zeile anpassen und die "::1" entfernen.

vorher:

dc_local_interfaces=’127.0.0.1 ; ::1’

nachher:

dc_local_interfaces=’127.0.0.1 ; ’

Ggf. sollte man " /var/log/exim4/paniclog" noch löschen. Danach lässt sich der Daemon wieder ohne Fehler starten und schreibt auch sein PID-File.

VirtualBox zeigt beim Start einer VM immer kurz das VirtualBox Logo an. Es gibt die Möglichkeit, ein selbst erstelltes Logo anzuzeigen. Ich beschreibe hier in kurzen Schritten, wie man ein Logo mit GIMP erstellt und wie man es dann in eine existierende VM einbindet.

1. Erstellen des Logos (640×480 72dpi RGB)
   In GIMP (englisch): File –> New

    

   

2. Bild bearbeiten
3. Export des Bildes
   In GIMP (englisch):
   File –> Export –> <filename.bmp> –> Export
   Im darauf folgenden Dialog folgende Einstellungen durchführen:

    

   

   Das Bild legt man am besten im Ordner der virtuellen Maschine ab.

4. Einbinden des Logos in die VM
   Die Einbindung des Logos in eine VM erfolgt über die Kommandozeile. Wir benutzen dazu das Kommando „vboxmanage“. Es unterstützt folgende Optionen die für das Einbinden eines BIOS-Logos zuständig sind:

   [--bioslogofadein on|off]
[--bioslogofadeout on|off]
[--bioslogodisplaytime <msec>]
[--bioslogoimagepath <imagepath>]

   ! Wichtig ! Bei der Angabe des Logos muss der komplette Pfad angegeben werden, leider funktionieren hier keine relativen Pfade.
   
   Möchte man also einer virtuellen Maschine mit der Bezeichnung „Win8“ ein BIOS-Logo mit dem kompletten Pfad V:\VMs\windows8\bootlogo.bmp für 3 Sekunden (3000ms) beim Start der VM anzeigen lassen und noch einen schönen Ein- und Ausblendeeffekt erreichten muss man folgenden Befehl absetzen:

   vboxmanage modifyvm "Win8" --bioslogoimagepath "V:\VMs\windows8\bootlogo.bmp" --bioslogofadein on --bioslogofadeout on --bioslogodisplaytime 3000

5. Test
   Nun sollte beim nächsten Start der entsprechenden VM das von uns erstellte Logo angezeigt werden.

   

Schon seit einiger Zeit sind bei mir die Programme Firefox und Thunderbird extrem langsam geworden. Der Firefox-Browser war eigentlich nicht mehr zu gebrauchen und Thunderbird ging gerade noch so. Andere Browser z.B. Chrome liefen problemlos. Heute habe ich das Problem dann endlich lösen können.

Ich habe einen DSL-Anschluss der Deutschen Telekom und bereits sowohl eine IPv4 und IPv6 Adresse. Des weiteren gibt die FritzBox ebenfalls IPv4- und IPv6-Adressen aus. Irgendwie scheinen die Mozilla-Produkte da ein Problem mit der Namensauflösung und IPv6 zu haben.

Lange Rede kurzer Sinn, in beiden Programmen habe ich den Parameter „network.dns.disableIPv6“ auf „true“ gesetzt und schon waren beide Programme wieder so flott wie gewohnt. Hier noch kurz die Einstellungsschritte für das jeweilige Programm:

Firefox

In der Adresszeile about:config eingeben und den Button „Ich werde vorsichtig sein, versprochen!“ klicken. Dadurch bekommt man Zugriff auf den erweiterten Konfigurationseditor. In dessen Suchleiste einfach nach dem Text „ipv6“ suchen. Es sollte nun der Eintrag „network.dns.disableIPv6“ erscheinen. Diesen dann doppelklicken, sodass der Wert von „false“ auf „true“ umschaltet.

Thunderbird

Bearbeiten → Einstellungen → Erweiterte Konfiguration → Konfiguration bearbeiten
Ebenfalls den Button „Ich werde vorsichtig sein, versprochen!“ klicken und wie beim Firefox den Wert „network.dns.disableIPv6“ auf „true“ umsetzen.

Nach dieser Anpassung waren beide Mozilla-Produkte bei mir wieder so flott wie gewohnt. Möglicherweise könnte dieses Problem auch unter Windows auftreten!

After watching this episode of the „Linux Action Show“ I wanted to try Virtual Machine Manager on my Arch Linux Box. I used the very good Arch Wiki and got it installed without any problems, but when I wanted try to create a new virtual machine I always ran into this error:

summary=Error launching details: 'Terminal' object has no attribute 'set_visible_bell'
details=Error launching details: 'Terminal' object has no attribute 'set_visible_bell'

I found out, that after creating a virtual machine Virtual Machine Manager tries to launch a VTE Terminal to connect to the virtual machine. So it looked as if this VTE Terminal could not start. I did some google search and came along this bugzilla entry at Redhat, that pointed me into the right direction.

As you can see in the screenshot the last error is from the file

/usr/share/virt-manager/virtManager/serialcon.py

So I used the information from the bugzilla entry and installed extra/vte290 with the following command (Arch Linux):

sudo pacman -S vte290

Then I edited

/usr/share/virt-manager/virtManager/serialcon.py

and changed it a little bit:

BEFORE

from gi.repository import Vte

import libvirt

AFTER

#from gi.repository import Vte
import gi
gi.require_version('Vte', '2.90')
from gi.repository import Vte

import libvirt

After that change everything worked perfect.

Maybe there is another or better solution, but this works for me at the moment. If you found it useful, please leave me a comment!