Da Stiftung Warentest aktuell die erneuten Tests für E-Mail Server heraus gibt, habe ich mir mal die Mühe gemacht, die Transport Verschlüsselung auf unseren E-Mail Servern herauszufiltern um diese nach Ihrer ciphers zu untersuchen. Spannend war, dass mittlerweile alle eingehenden Verbindungen eine Recht hohe Sicherheit aufwiesen. Microsofts hotmail.com outlook.com so wie Mail.de waren die einzigsten, die noch ein CBS Mode verwenden. Alle anderen sind schon auf den neuen GCM Mode umgestiegen. Bei web.de, mail.de und mailbox.org haben anscheinend unersichtliche Server Infrastruktur die mit unterschiedlichen ciphers E-Mails Ausliefern.
google.com
ECDHE-RSA-AES128-GCM-SHA256
yahoodns.net
ECDHE-RSA-AES128-GCM-SHA256
t-online.de
ECDHE-RSA-AES256-GCM-SHA384
gmx.net und gmx.de
DHE-RSA-AES256-GCM-SHA384
web.de
DHE-RSA-AES256-GCM-SHA384
ECDHE-RSA-AES256-GCM-SHA384
hotmail.com
ECDHE-RSA-AES256-SHA384
outlook.com
ECDHE-RSA-AES256-SHA384
freenet.de
DHE-RSA-AES256-GCM-SHA384
icloud.com
ECDHE-RSA-AES128-GCM-SHA256
mail.de
DHE-RSA-AES256-GCM-SHA384
DHE-RSA-AES256-SHA256
ECDHE-RSA-AES256-GCM-SHA384
mailbox.org
DHE-RSA-AES256-GCM-SHA384
ECDHE-RSA-AES256-GCM-SHA384
posteo.de
ECDHE-RSA-AES256-GCM-SHA384
Die Resultate habe ich unter 100.000 E-Mailserver-Verbindungen der letzten Woche herauszufiltern. Sortiert sind die aufrufe nach Anzahl der Verbindungen wobei die Anzahl der letzten 3 Anbieter < 1% liegt.
Veröffentlicht am: 01.10.2016 von: CHR | Tags: postfix, ssl | publiziert in: Security
Beim mounten eines NFS unter Ubuntu 16.04 mit folgenden Kommando bekam ich immer eine Fehlermeldung die leider sehr häufig vor kommt.
sudo mount.cifs -v //10.0.0.1/MEMORYCARD/ /mnt -o guest,sec=ntlm
mount.cifs kernel mount options: ip=10.0.0.1,unc=\\10.0.0.1\MEMORYCARD,sec=ntlm,user=,pass=********
mount error(13): Permission denied
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)
Durch das einfügen von User und Passwort war das mounten möglich:
sudo mount.cifs -v //10.0.0.1/MEMORYCARD/ /mnt -o sec=ntlm,user=guest,pass=
Veröffentlicht am: 04.09.2016 von: CHR | Tags: 16.04 | publiziert in: Ubuntu
Um VMs zwischen HDD und SSD zu migrieren wäre ein „lvmove“ äquivalent ganz praktisch. Dies kann es aber nicht geben, da der Pfad zum lv dann auch angepasst werden muss. Um meine Master Slave Setup dennoch Live migrieren zu können, habe ich ein neues gleich großes lv erstellt, die Platte ausgehangen und die neue wie folgt eingegangen.
Zunächst habe ich geprüft ob ich Master oder Slave bin (ro:Secondary)
grep -A1 '^11:' /proc/drbd
11: cs:Connected ro:Secondary/Primary ds:UpToDate/UpToDate C r-----
ns:1176552 nr:236 dw:1176788 dr:233640 al:194 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:f oos:0
Dann habe ich dem DRBD Verbund die Storage aus gehangen:
drbdadm detach drbdvm11
grep -A1 '^11:' /proc/drbd
11: cs:Connected ro:Secondary/Primary ds:Diskless/UpToDate C r-----
ns:1176552 nr:272 dw:1176824 dr:233640 al:194 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:f oos:0
Dies DRBD Config Datei editiert und bei der localen node das neue lv auf der neuen vg eingetragen.
vim /etc/drbd.d/drbdvm11.res
disk /dev/mapper/vg2-drbdvm11;
Danach muss das neue lv von DRBD initialisiert werden:
drbdadm create-md drbdvm11
initializing activity log
NOT initializing bitmap
Writing meta data...
New drbd meta data block successfully created.
success
Anschließend wird alles wieder gestartet und die Synchronisation begibt automatisch.
drbdadm attach drbdvm11
grep -A2 '^11:' /proc/drbd
11: cs:SyncTarget ro:Secondary/Primary ds:Inconsistent/UpToDate C r-----
ns:0 nr:184320 dw:184320 dr:0 al:194 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:f oos:7155452
[>...................] sync'ed: 9.4% (116080/127996)M
grep -A1 '^11:' /proc/drbd
11: cs:Connected ro:Secondary/Primary ds:UpToDate/UpToDate C r-----
ns:0 nr:7339804 dw:7339804 dr:0 al:194 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:f oos:0
Veröffentlicht am: 01.08.2016 von: CHR | Tags: 16.04, drbd, lvm2 | publiziert in: public, Ubuntu
In der Bayernallee war für den Samstag 09.08. eine geplanten Stromabschaltung zwischen 08:00 und 13:00 durch die Stawag angekündigt worden.
Leider hatten wir den CISCO Switch seit über 5 1/2 Jahren nicht neu gestartet, aber der reihe nach.
8:15 wurde der Strom abgeschaltet.
8:43 gingen die USVs der Ciso 4006 gingen zu neige.
10:13 Strom wurde wieder eingeschaltet.
12:56 Eintreffen meinerseits in der Bayernalle für eine erste Analyse:
- Cisco zeit den Status Fail an. Ein Neustart der Cisco so wie das Resetten
der Superviso war ohne Erfolg. Nach 3Sec Grünen Blinken fällt die Sup in den
Status Fail zurück.
- Suchen nach Cisco Konsolen Kable.
14:00 Abreise meinerseits mit neuer Terminfindung für den späten Abend.
14:00 – 23:45 Mehrere Koordinationsgespräche. Suche von privater Hardware.
23:50 Eintreffen mit einem Kollegen in der Bayernallee. Erneute Analyse mit Konsolenkable.
- Sup gab aber leider keinerlei Status
- CF Karte war Leer ohne Dateisystem
- Vorbeiteitung Notlösung, suche nach dem zweitem HP Switch und den SFP Adaptern.
- Einbau der 3com Karte in Chistoph Router
Begründung: Hier sind bereits alle Routing Funktionalitäten Installiert
und VLAN Feachers vorhanden.
03:00 Erfolgreicher Funktionstest und Verbindung zum Internet. Vorbereitung umbau der
Netzwerkinfrastruktur auf 100Mbit Switches.
04:00 Erster Netzwerk Test nicht erfolgreich, vermutlich eine Loop
gesteckt.
04:30 Zweiter Netzwektest Erfolgreich. Edorome Test erfolgreich. Fahrt
nach hause!
Nach dem Umstecken sah unsere Notlösung etwas chaotisch aus, die CISCO 4006 etwas leer, dafür waren die 144 Bewohner am nächsten morgen wieder sehr glücklich.
Veröffentlicht am: 13.07.2016 von: CHR | publiziert in: Bayernallee, CISCO
Immer wenn ich meinen Arbeitsplatz verlasse Sperre ich meinen Bildschirm. Vor eingestellt ist ALT + L
. Das geht aber einfacher. Unter Systemeinstellungen => Tastatur kann man im Reiter „Tastenkürzel“ die voreingestellten Einstellungen bearbeiten. Unter System => Bildschirm sperren habe ich hier die Pause Taste hinterlegt.
Damit ich aber weiß, wann ich in Pause gegangen bin habe ich mir ein kleine Script geschrieben:
bin/pause
#!/bin/bash
gnome-screensaver-command -l
logger "PAUSE"
Dieses sperrt den Bildschirm und schreibt eine Logzeile ins Syslog:
Jun 6 17:00:00 desktop user: PAUSE
Hierfür habe ich mir unter Systemeinstellungen => Tastatur kann man im Reiter „Tastenkürzel“ ein eigenes Tastenkombination definiert
Im auth.log
steht equivalten wann ich mich wieder eingeloggt habe:
Jun 6 18:00:00 desktop compiz: gkr-pam: unlocked login keyring
Veröffentlicht am: 06.06.2016 von: CHR | Tags: 16.04 | publiziert in: public, Ubuntu