Erstellt man eine VM unter ESX-Server, wird standardmässig eine AMD-Netzwerkkarte emuliert. Ändert man den Eintrag in der .VMX-Datei auf eine Intel E1000 mit

gibt es für das Gastsystem eine neue Netzwerkkarte. Bei Ubuntu ist dann erstmal eth0 weg und nix neues da. Die neue Karte lässt sich per schnell als eth1 einbinden. Wenn man aber lieber wieder eth0 ansprechen würde, hilft es, den alten Eintrag für eth0 in der Datei zu entfernen, und den neuen einfach auf eth0 umzuschreiben. Dann einmal die VM neu gestartet und fertig.

Memo an mich :)

Wo ich gerade auf meine neue Workstation umziehe, gehört natürlich Putty zum ersten was installiert wird. Da ich ungern alle Putty-Einstellungen manuell übertragen wollte, und es ja bekanntlich keine ini-Datei o.ä. gibt, hab ich mal kurz die Registry durchwühlt...

Und eigentlich ist es ganz einfach... Man sucht sich den Zweig

und export diesen in ein .reg File. Das wird auf dem anderen Computer eingetragen und fertig :)

Wer es noch nicht mitbekommen hat...
Sämtliche Debian Versionen seit 2006 haben ein Sicherheitsproblem mit OpenSSL. Die generierten Schlüssel sind nicht so zufällig wie sie sein sollten... Von daher sind die Schlüssel vorhersagbar (bzw. exisiteren bereits Wörterbücher mit den möglichen Keys) und somit ist die verschlüsselte Datenübertragung äußerst unsicher und schnell knackbar geworden.

Ich möchte der Einfachheit halber auf einen Artikel bei Heise verweisen, der die Problematik und die Erkennung von Problemen gut erklärt.

Da möchte man mal eine Festplatte verkaufen. Was hierbei in jedem Fall im Vordergrund stehen sollte ist die Beseitigung der bislang darauf befindlichen Daten.

Um hier eine möglichst hohe Sicherheit zu gewährleisten reicht einfaches formatieren nicht aus. Die Daten müssen physikalisch überschrieben werden. Und das am besten mehrfach.

Als eine gute Lösung zu diesem Thema erweist sich das Linux-Programm shred. Es überschreibt Dateien, Partitionen oder ganze Festplatten mit Zufallsdaten. Man nehme sich also eine Linux Live-CD (Knoppix und Ubuntu haben sich hier als sehr zuverlässige Lösungen erwiesen) und boote zum Desktop.

Man öffne also ein Terminal-Fenster entweder direkt als root oder man mache unter ubuntu

Dann erstmal zusehen, dass die Platte auch mit ner ordentlichen Geschwindigkeit angesprochen wird

Die /dev/hda natürlich durch die Platte ersetzen die es betrifft!

Dann wird gelöscht...

Hierbei steht -n 2 für 2 Durchgänge, -f für force (sprich bei bedarf dateirechte ändern), -z für einen zusätzlichen Schreibvorgang mit nur nullen, um die übrigen Löschvorgänge zu vertuschen und zu guter letzt -v für eine Ausgabe des Fortschritts.

Bei einer 80er Platte hat es mit einem AthlonXP 2600+ ca 1,5 Std. gedauert. Beachtenswert ist, dass eine parallel gelöschte SATA Platte ca. 50% schneller war als eine IDE gleicher Baureihe.

und da isse wieder...

Nach nur knapp 10 Tagen kam die Box vom Service zurück. Jetzt mit neuem Board in Rev. 1.2! Nach Einbau meiner alten Platten lief die Box sofort wieder wie gewohnt. Alle Daten vorhanden, Systemconfig i.O. - alles Prima.

Beim Einschalten wurde die Verbindung mit dem Gigabit-Switch sofort erfolgreich und stabil hergestellt. Der Spindown will natürlich immer noch nicht - das ist eine Sache der Firmware... Hoffen wir da auf ein schnelles update.

Auf jeden Fall ein toller Service bei RaidSonic

Damit man auch eine sichere FTP-Verbindung anbieten kann, bietet sich eine TLS-Verschlüsselung an.

Bei Proftpd richtet man diese wie folgt ein:

• Verzeichnis für SSL-Cert erstellen:
  mkdir /etc/proftpd/ssl
• Das Zertifikat erstellen:
  openssl req -new -x509 -days 3650 -nodes -out /etc/proftpd/ssl/proftpd.cert.pem -keyout /etc/proftpd/ssl/proftpd.key.pem
• In der proftpd.conf den IfModule mod_tls.c Block wie folgt anpassen:
  
  1  <IfModule mod_tls.c>
  2  TLSEngine on
  3  TLSLog /var/log/proftpd/tls.log
  4  TLSProtocol SSLv23
  5  TLSOptions NoCertRequest
  6  TLSRSACertificateFile /etc/proftpd/ssl/proftpd.cert.pem
  7  TLSRSACertificateKeyFile /etc/proftpd/ssl/proftpd.key.pem
  8  TLSVerifyClient off
  9  TLSRequired on
  10  </IfModule>
  
• Proftpd neu starten:
  /etc/init.d/proftpd restart

Fertig. Nun kann man sich mit FTP+TLS zum Server verbinden.
Um alten Clients noch die Möglichkeit einer Verbindung ohne TLS zu ermöglichen, kann man den Punkt TLSRequired auf "off" setzen.

Um "mal eben" etwas auf den Webserver zu schieben, oder einem Kunden komfortabel den upload von Bilderkes in seine Galerie zu ermöglichen, kann man seinem Apachen WebDAV beibringen.

Hier eine Kurzfassung wie man es auf die simple Tour einrichtet:

• Modul dav_fs aktiviren (dav wird wegen Abhängigkeit direkt mit aktiviert)
  a2enmod dav_fs
• Ein Verzeichnis für WebDAV anlegen
  mkdir /var/webdav
• Selbiges für den Apachen beschreibbar machen
  chown www-data:www-data /var/webdav
• Im VirtualHost das Verzeichnis eintragen und Passwortschützen
  
  1  Alias /webdav "/var/webdav/"
  2  <Directory "/var/webdav/">
  3   DAV on
  4   Options +Indexes
  5   AllowOverride AuthConfig
  6   AuthType Basic
  7   AuthName "WebDAV Verzeichnis"
  8   AuthUserFile /var/webdav-users
  9   Require valid-user
  10  </Directory>
  
• Die Password-Datei und einen User anlegen
  htpasswd -c /var/webdav-users webdaver
• Um Lesezugriffe oder sonstige Ausnahmen zu confen gibts innerhalb des Directory-Eintrags folgende Möglichkeit:
  1  <LimitExcept GET>
  2   Require valid-user
  3  </LimitExcept>
  
• Unterverzeichnisse können separat über eine .htaccess-Datei nur bestimmten Usern zugänglich gemacht werden
  1  Require user user1 user2
  

Und fertig.
Bitte beachten: Bei dieser Methode wird das Passwort im Klartext durchs Internet übertragen. Wenn man sich für diese Art der Authentifizierung entscheidet, sollte der Virtualhost eine SSL-Verschlüsselung eingerichtet haben!!!

Da ich das immer wieder nachschlage - hier mal die Kurzfassung:

• CSR erstellen:
  openssl req -new > www.domain.de.csr
• Passphrase entfernen:
  openssl rsa -in privkey.pem -out www.domain.de.key
• Cert ausstellen:
  openssl x509 -in www.domain.de.csr -out www.domain.de.crt -req -signkey www.domain.de.key -days 3650
• Listen 443 in die ports.conf
• Virtual Host anlegen:
  1  <VirtualHost 111.222.333.444:443>
  2   ServerName ssl.domain.de
  3   SSLEngine on
  4   SSLCertificateKeyFile /etc/apache2/conf/ssl/www.domain.de.key
  5   SSLCertificateFile /etc/apache2/conf/ssl/www.domain.de.crt
  6  </VirtualHost>
  
• Mod_SSL aktivieren:
  a2enmod ssl
• Apache neu starten:
  /etc/init.d/apache2 restart

fertig :)

Das ganze funktioniert mit Pfadanpassungen übrigens auch auf Windows-Systemen.

Anmerkung:
Um kostenfrei ein Zertifikat zu bekommen, aber doch wenigstens etwas Sicherheit zu vermitteln, kann man sich kostenlos bei CAcert.org Registrieren und Zertifikate ausstellen.

Meines Wissens arbeitet CAcert gerade daran, eine anerkannte Authorität zu werden :)