Archiv ‘Linux’

Sonntag, 3. November 2013

(Aus dem Archiv) Find files greater than x Bytes

Der vorliegende Artikel habe ich ursprünglich irgendwann einmal ab 2002 auf meinem damaligen Linux-Entwicklungsserver im Web publiziert. Da ich das bloggen erst 2005 entdeckt habe, waren die Tipps in einer grossen HTML-Seite untergebracht. Anlässlich einer Aufräumaktion auf dem Server habe ich mich entschieden, die „Perlen“ über meine heutige Kommunikationsplattform ins Web zu posaunen. Seitdem ich die Artikel verfasst habe, sind viele Tage ins Land gegangen — ob der Artikel noch Gültigkeit hat, entscheidet der geneigte Leser selber.

In my special case, I used the following command to separate thumbnails (expected smaller than 10KB) and closeups (expected to be greater than 10KB) in a web-dump.

find . -type f -name "*.jpg" -size +10240c -exec mv '{}' ~/newdir/ ';'

Tags: , ,
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 3. November 2013

(Aus dem Archiv) Remove file types except those which contain ‚foobar‘

Der vorliegende Artikel habe ich ursprünglich irgendwann einmal ab 2002 auf meinem damaligen Linux-Entwicklungsserver im Web publiziert. Da ich das bloggen erst 2005 entdeckt habe, waren die Tipps in einer grossen HTML-Seite untergebracht. Anlässlich einer Aufräumaktion auf dem Server habe ich mich entschieden, die „Perlen“ über meine heutige Kommunikationsplattform ins Web zu posaunen. Seitdem ich die Artikel verfasst habe, sind viele Tage ins Land gegangen — ob der Artikel noch Gültigkeit hat, entscheidet der geneigte Leser selber.

My linux servers hosts my complete electronic Music Library, sharing it using daapd. All downloads come with a mess of additional files like covers, cue-sheets, nfo-files etc. Usually, I’m too lazy to get rid of’em directly after the download. As time passed by, everything got messed up with every new album I’ve leeched. Instead of going through every directory – and there are many of them – I used another fine find-command to remove anything not an mp3-file within my MP3-Folder:

find . -type f \! -name "*.mp3" -exec rm '{}' ';'

Tags: , ,
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen

Freitag, 25. Oktober 2013

Graustufenbilder mit ImageMagick in Schwarz-Weiss-Bilder umwandeln

Kürzlich hat Stephanie ihre Cumulus-Karte verlegt. Damit sie weiterhin bei jedem Einkauf eifrig Punkte sammeln kann, habe ich ihr meinen Barcode als Bild eingescannt und wollte diesen ausdrucken, um ihn auf die Rückseite der Supercard (Frevel!) aufzukleben.

Damit der Barcode-Leser der Kasse den Scan auch möglichst einwandfrei lesen kann, wollte ich den Scan aber von Farbe resp. Graustufen in ein monochromes Bild umwandeln. Mittels ImageMagicks convert geht das ganz simpel:

$ convert "Cumulus Barcode.png" -colorspace gray -auto-level -threshold 50% "Cumulus Barcode bw.png"

Indem man mit den Prozentwerten bei -threshold spielt, kann man den Schwellenwert hinunter oder heraufsetzen, basierend auf dem ein Pixel als schwarz oder weiss markiert wird. Ein Wert von 75% resultiert in mehr schwarzen Pixeln, ein Wert von 25% in mehr weissen Pixeln.

Tags: , , , , , , ,
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen

Dienstag, 8. Oktober 2013

Unter Linux eine aktive screen-Session übernehmen

Ab und zu kommt es vor, dass sich mein alter Mac mini in den Ruhemodus versetzt, während ich noch per SSH mit einer screen-Session verbunden bin. Mit folgendem Befehl kann ich die Session nach einem neuen Login mit SSH übernehmen:

$ screen -d -r

-d bedeutet „detach“, -r bedeutet „resume“.

Tags: ,
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen

Mittwoch, 18. September 2013

Den Raspberry Pi mit rsync über SSH auf die Synology DiskStation sichern

Als Gedankenstütze nachfolgend einige Lösungen für Probleme, die sich mir in den Weg stellten:

Mac OS X

$ ssh-keygen -t rsa -b 2048 -f id_rsa_dashboard_vault

Die Aufforderung, ein Passwort für den Private Key zu generieren, bestätigt man mit ENTER — der Private Key wird so nicht zusätzlich mit einem Passwort geschützt, weil dies den automatisierten Login von Raspberry Pi auf die DiskStation verhindern würde.

Der Befehl erstellt zwei Dateien:

  • id_rsa_dashboard_vault
  • id_rsa_dashboard_vault.pub

Synology DiskStation

Als erstes richtet man sich über die Web-Oberfläche einen normalen Benutzer dashboard ein, in dessen Home-Verzeichnis die Backup-Daten geschrieben werden.

Hierzu müssen dem Benutzer Schreibrechte auf /homes gegeben werden. Ansonsten sieht man sich beim Starten des Backup-Scripts (s. unten) mit folgender Fehlermeldung gegenüber:

ERROR: module is read only

Quelle: Rsync over ssh: “ERROR: module is read only” suddenly appeared

Wichtig ist weiter, dass der SSH-Zugang über die Web-Oberfläche aktiviert wurde.

/etc/passwd

Dem neu erstellten Benutzer müssen wir nun eine gültige Login-Shell zuweisen:

...
dashboard:x:1029:100::/var/services/homes/dashboard:/bin/ash

Erfasst man hier ein nicht existierendes Login-Shell, kriegt man beim Debugging des publickey SSH-Logins folgende komische Infos ans Gesicht geworfen:

...
Authentication succeeded
...
Permission denied
...

Um sicher zu gehen, dass die Login-Shell richtig konfiguriert ist, macht man als auf der DiskStation eingeloggter User root folgendes:

# su dashboard

Wechselt man in ein neues Shell, ist /etc/passwd korrekt konfiguriert.

/var/services/homes/dashboard/.ssh/authorized_keys

In dieser Datei legen wir den Public Key ab (id_rsa_dashboard_vault.pub).

/etc/ssh/sshd_config

Wahrscheinlich müsste man hier gar nichts anpassen, beim Debugging habe ich es dann doch getan (wohl unnötigerweise):

$ cat sshd_config | grep -v "^#" | sort
AllowTcpForwarding no
AuthorizedKeysFile	.ssh/authorized_keys
ChallengeResponseAuthentication no
ChrootDirectory none
HostKey /etc/ssh/ssh_host_dsa_key
HostKey /etc/ssh/ssh_host_ecdsa_key
HostKey /etc/ssh/ssh_host_rsa_key
LogLevel INFO
Match User root
    AllowTcpForwarding yes
Protocol 2
PubkeyAuthentication yes
Subsystem       sftp    internal-sftp -f DAEMON -u 000
SyslogFacility AUTH
UseDNS no
UsePAM yes

Raspberry Pi

/root/.ssh/config

Host vault
   Hostname 10.0.44.44
   User dashboard
   IdentityFile ~/.ssh/id_rsa_dashboard_vault

In der Datei ~/.ssh/id_rsa_dashboard_vault legt man den Private Key ab.

Login überprüfen

Dies sollte nun ohne Eingabe eines Passwortes möglich sein:

$ ssh vault

Bei einer Fehlermeldung helfen die Optionen -v, -vv und -vvv weiter:

$ ssh -v vault

/usr/local/bin/backup.sh

Folgendes Script sichert / (root) des Raspberry Pis auf den Host vault in den Pfad /volume1/homes/dashboard/backups/. Auf dem Raspberry Pi nicht mehr vorhandene Dateien werden auf der DiskStation gelöscht.

#!/bin/sh

RSYNC=`which rsync`

if [ ! -e "$RSYNC" ]
then
	echo "rsync binary not found: '$RSYNC'"
	exit 1
fi

TODAY=`date +"%F_%T"`
SNAPSHOTFILE="/var/log/rsync/$TODAY.snapshot.txt"
#touch "$SNAPSHOTFILE"
echo "$TODAY" > "$SNAPSHOTFILE"

if [ ! -f "$SNAPSHOTFILE" ]
then
	echo "Could not create snapshotfile '$SNAPSHOTFILE'"
else
	echo "Snapshotfile created at:"
	ls -l "$SNAPSHOTFILE"
fi

LOGFILE="/var/log/rsync/$TODAY.log.txt"
EXCLUDEFILE="/usr/local/bin/backup-exclude.txt"

SOURCE="/"
DEST="vault:/volume1/homes/dashboard/backups/"

echo "Running rsync ..."
$RSYNC -avz --log-file="$LOGFILE" --exclude-from="$EXCLUDEFILE" --delete -e ssh "$SOURCE" "$DEST" 
echo "Backup complete."

exit 0

/usr/local/bin/backup-exclude.txt

proc/*
sys/*
dev/*
tmp/*
run/*
mnt/*

Quelle: Can a Raspberry Pi be used to create a backup of itself?

/etc/crontab

...
4 0 * * *	root	/usr/local/bin/backup.sh

Hiermit wird das Backup-Script täglich um 4 Uhr morgens ausgeführt.

Links

Tags: , , , ,
Labels: Linux

1 Kommentar | neuen Kommentar verfassen

Freitag, 16. August 2013

MySQL-Passwörter nicht in cron-Job Kommandozeilen hinterlegen

Seit längerem habe ich mich gestört, dass in den von cron versendeten E-Mails mit dem Status des Datenbank Backup-Scripts der Benutzername und das Passwort des verwendeten Datenbankbenutzers im Klartext stehen.

Dank einer Frage auf Superuser.com konnte ich diese „Unschönheit“ beheben.

Im Home-Verzeichnis meines Hosting-Benutzers habe ich eine Datei namens .my.cnf angelegt. Deren Inhalt:

[client]
user=username
password=password

username und password müssen selbstverständlich mit gültigen Zugangsdaten ersetzt werden.

Ganz wichtig: Die Datei ist mittels folgendem Befehl nur für den Owner lesbar zu machen:

$ chmod 600 ~/.my.cnf

Anschliessend habe ich mein Backup-Script umgebaut. Dort steht nun neu:

...
OPTS=""
OPTS="$OPTS --defaults-file=/home/sitename/.my.cnf"

echo ""
echo "Running $MYSQLDUMP $OPTS $DATABASE > $DUMPFILE"

$MYSQLDUMP $OPTS $DATABASE > $DUMPFILE

Der Vorteil dieser Lösung: Selbst wenn der Sysadmin des Servers mittels ps ax alle auf dem Web-Server laufenden Prozesse (und so je nach Zeitpunkt auch meinen cron-Job) angezeigt erhält, steht auch dort nichts von einem Passwort oder gar Benutzernamen.

Tags: , , , , ,
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen

Donnerstag, 15. August 2013

libapache2-svn unter Apache 2.4 zum Laufen bringen

Da führt man zu Monatsbeginn auf dem heimischen Linux-Server vor lauter Blödheit ein

# apt-get dist-upgrade

durch und sieht sich plötzlich mit Apache 2.4 konfrontiert.

Nachdem man die Zugriffsprobleme mit IP- und Host-basierten Regeln in allen .htaccess-Dateien behoben hat, realisiert man erst, dass der Web-Server nicht starten will, weil das DAV-Modul „svn“ nicht mehr gefunden wird:

Unknown DAV provider: svn

Was zum Geier?

Die Ursache des Problems ist rasch gefunden: Das Paket libapache2-svn hat eine Abhängigkeit vom Paket apache2.2-common, doch mit Apache 2.4 hat letzteres Paket seine Daseinsberechtigung verloren und ist folglich nicht mehr auf dem System vorhanden. Zu allem Unglück hinzu unterstützt Subversion in der Debian-Version 1.6.17dfsg-4+deb7u3 Apache 2.4 gar nicht.

Nach längerem Herumsuchen im Internet komme ich zum Schluss, dass wirklich nichts an der auf Stackoverflow herumgebotenen Lösung vorbeiführt: Ich muss Subversion doch tatsächlich in der derzeit aktuellen Version 1.7.9 (Debian: 1.7.9-1+nmu3) aus der Quelle kompilieren und danach auf dem System installieren. Diese Version kennt und unterstützt Apache 2.4.

Nachfolgend eine rudimentäre Anleitung, welche sich an den Stackoverflow-Artikel anlehnt.

Anleitung

Zuerst benötigen wir folgende Pakete, um Subversion gegen das aktuell installierte Apache 2.4 kompilieren zu können:

# apt-get install apache2-dev
# apt-get build-dep subversion

Bei mir war anschliessend noch manuell die Installation von folgendem Paket nötig:

# apt-get install libserf1 libserf-dev

Jetzt geht es an das Herunterladen des Subversion-Quellcodes:

$ cd /tmp
$ apt-get source --compile subversion
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables... 
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
... (Ctrl+C)

Richtig gelesen: Während das Teil vor sich hinkompilieren will, bricht man die Durchführung mittels Ctrl+C ab. Denn zuerst sind noch einige kleinere Anpassungen an den Kompilierungseinstellungen nötig, damit man am Ende nicht nur mit Subversion, sondern auch mit einem Paket libapache2-svn dasteht.

In /tmp/subversion-1.7.9/debian/rules ändert man dazu folgenden Wert:

ENABLE_APACHE        := yes

Und in /tmp/subversion-1.7.9/debian/control fügt man zuunterst folgenden Text ein:

...

Package: libapache2-svn
Section: httpd
Architecture: any
Depends: ${shlibs:Depends}, ${misc:Depends}
Suggests: db5.1-util
Description: Subversion server modules for Apache
 This package provides the mod_dav_svn and mod_authz_svn modules for
 the Apache 2.2 web server.  These modules provide Subversion's WebDAV
 server backend, to serve repositories over the http and https
 protocols.  See the 'subversion' package for more information.

Schlussendlich startet man die Kompiliererei erneut, verzichtet dieses Mal aber mit dem Attribut DEB_BUILD_CONFIG, dass nach der Kompilierung stundenlang Tests durchgeführt werden, diese scheitern und man nach dem Warten auf Godot ohne .deb-Pakete dasteht (via DEB_BUILD_OPTIONS=nocheck):

$ cd /tmp/subversion-1.7.9/
$ DEB_BUILD_OPTIONS=nocheck dpkg-buildpackage -b -uc

Anschliessend installiert man die folgenden drei Pakete:

# dpkg -i /tmp/libsvn1_1.7.9-1+nmu3_i386.deb
# dpkg -i /tmp/libapache2-svn_1.7.9-1+nmu3_i386.deb
# dpkg -i /tmp/subversion_1.7.9-1+nmu3_i386.deb

Schlussendlich muss man in Apache unter /etc/apache2/mods-enabled noch die folgenden Module aus /etc/apache2/mods-available symlinken, wenn sie nicht schon dort sind:

  • authz_svn.load
  • dav_svn.conf
  • dav_svn.load

Dann noch das obligate …

# /etc/init.d/apache2 restart

… und gut is!

Tags: , , , , , , , ,
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen

Donnerstag, 25. Juli 2013

Debian-Installation mit zwei Netzwerkkarten ausfallsicher(er) machen

Auf Grund eines defekten Kabelmodem-Netzteils und einem wackeligen Switch-Netzteil war mein Debian-Server im Elternheim kürzlich für mehr als 3 Tage offline. Für einen IT-Auditoren, welcher tagtäglich mit Load Balancing, Geo-Redundanz und Failovers in Kontakt kommt, eine untolerierbare lange Zeit!

Hintergrund: Als meine linke Hand mittels Telefonsupport das tote Kabelmodem analysierte, hatte er wohl aus Unachtsamkeit das Netzteil des Gigabit-Switches aus der Fassung gerissen (zu seiner Entschuldigung: Irgendetwas ist am Switch-Netzteil defekt, es sitzt nicht mehr fest in der Steckerleiste). Obwohl am nächsten Tag dank des Austauschs des Kabelmodem-Netzteils der Router und ein Teil des Netzwerks wieder online, blieb der Switch offline (ich war beim Austausch des Netzteils nicht vor Ort, konnte deshalb keine Diagnose machen — ansonsten hätte ich den dunklen Switch innert Minuten als Fehlerquelle isoliert).

Was tun? Einerseits habe ich mir auf Ricardo einen iKVM-Switch (Avocent SwitchView IP 1010 Remote Access Device) ersteigert, welchen ich in den nächsten Wochen mit dem Server verbinden werde. Das Netzwerkkabel wird direkt an den Router eingestöpselt, um Fehler in der restlichen Netzwerktopologie auszuschliessen.

Andererseits habe ich mich entschieden, den Server über zwei Netzwerkkarten an das Netzwerk anzubinden. Da ich mir vor langer Zeit eine performante Intel Gigabit-Netzwerkkarte geleistet habe, war mit dem Onboard-NIC meines Asus P5QPL-VM EPU bereits eine zweite Netzwerkschnittstelle vorhanden, die aktiviert werden wollte.

Natürlich ging es aber nicht darum, den Server mittels dieser zweiten NIC an den Router zu verbinden und dieser NIC eine zweite IP-Adresse zu geben — der Server sollte beim Ausfall der einen NIC logisch immer noch unter derselben IP-Adresse ansprechbar sein — physisch halt aber über die Onboard-NIC.

Bonding musste her!

Im Netz gibt es viele (alte und neuere) Anleitungen dazu, aber folgendermassen habe ich den Plunder nach langem Pröbeln zum Laufen gebracht:

bonding-Modul

In der Datei /etc/modules lädt man das bonding-Modul beim Start des Betriebssystems:

bonding
fuse
...

Die Konfiguration des Moduls — ich bin immer noch nicht sicher, ob es das wirklich braucht — legt man in /etc/modprobe.d/bonding ab:

alias bond0 bonding
options bonding mode=1 miimon=100

Erläuterungen:

  • alias bond0 bonding bond0 entspricht bonding — für was man dies genau benötigt, entzieht sich meiner Kenntnis
  • mode=1 Das Bonding-Modul kennt 6 verschiedene Modi. Modus 1 ist der active-backup-Modus: Es gibt eine aktive Netzwerkkarte und eine, die als Backup bereit steht und die Aufgabe der ersten Netzwerkkarte übernehmen kann.
  • miimon=100 Überwache die aktive Netzwerkkarte alle 100 Millisekunden auf einen Verlust des Links (bspw. Kabel ausgezogen, Switch ohne Strom).

Debian-Packages

Ob man diese Packages effektiv braucht, kann ich nicht sagen — installiert habe ich sie aber auf anraten von Anleitungen im Netz:

# apt-get install ifplugd ifenslave-2.6

/etc/network/interfaces

Vorbemerkung: Am Besten macht man sich zuallererst eine Kopie der aktuellen /etc/network/interfaces — bei meinen Tests musste ich zig Reboots durchführen und teilweise wieder die alte Interface-Konfiguration laden, um Dinge aus dem Netz herunterzuladen.

Meine finale, sauber funktionierende /etc/network/interfaces sieht folgendermassen aus:

auto lo
iface lo inet loopback

auto bond0
iface bond0 inet static
	address 192.168.100.101
	netmask 255.255.255.0
	network 192.168.100.0
	broadcast 192.168.100.255
	gateway 192.168.100.1
	bond-mode active-backup
	bond-miimon 500
	bond-slaves none

auto eth1
iface eth1 inet manual
	bond-master bond0
	bond-primary eth1 eth2

auto eth2
iface eth2 inet manual
	bond-master bond0
	bond-primary eth1 eth2

Wie man klar erkennen kann, werden hier die bonding-Parameter nach /etc/modprobe.d/bonding erneut gesetzt, und dies teilweise sogar mit anderen Werten. Einige Notizen:

  • Die Netzwerkkarten heissen bei mir leider Gottes aus mir unerfindlichen Gründen eth1 (Intel-Steckkarte) und eth2 (Onboard). In anderen Systemen werden die Karten wohl eher eth0 und eth1 heissen.
  • auto bond0 Nach Reboots war bond0 nicht aktiv und musste von mir immer zuerst mittels ifup bond0 geladen werden. Irgendwann einmal realisierte ich, dass ich Linux mittels auto bond0 sagen musste, das virtuelle Gerät automatisch zu starten.
  • Unklar ist, ob es eine Rolle spielt, wo die Konfiguration von bond0 innerhalb von /etc/network/interfaces steht. Ich habe es schlussendlich an den Anfang der Datei gesetzt, nach dem Loopback-Interface.
  • bond-mode active-backup ist dasselbe wie bond-mode 1
  • bond-miimon 500 Die Überprüfung des Netzwerkkabels alle 500 Millisekunden finde ich vernünftig
  • bond-slaves none Tönt komisch (nach meiner Lesart sind eth1 und eth2 die Slaves) — aber es klappt
  • bond-master bond0 Damit wird ein physisches Interface dem virtuellen Interface zugeteilt
  • bond-primary eth1 eth2 Damit gebe ich an, welche der beiden Netzwerkkarten verwendet wird, wenn beide einen funktionierenden Uplink haben. Natürlich habe ich mich für die performantere Intel-Karte entschieden und nicht die Onboard-NIC.

Status

Den Status des Bondings erfährt man über das proc-Dateisystem unter /proc/net/bonding/bond0:

Ethernet Channel Bonding Driver: v3.7.1 (April 27, 2011)

Bonding Mode: fault-tolerance (active-backup)
Primary Slave: eth1 (primary_reselect always)
Currently Active Slave: eth1
MII Status: up
MII Polling Interval (ms): 500
Up Delay (ms): 0
Down Delay (ms): 0

Slave Interface: eth2
MII Status: up
Speed: 1000 Mbps
Duplex: full
Link Failure Count: 0
Permanent HW addr: 00:00:00:00:00:00
Slave queue ID: 0

Slave Interface: eth1
MII Status: up
Speed: 1000 Mbps
Duplex: full
Link Failure Count: 0
Permanent HW addr: 00:00:00:00:00:00
Slave queue ID: 0

Via: Debian-Installation mit zwei Netzwerkkarten ausfallsicher(er) machen

Links

Tags: , , , , ,
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 7. Juli 2013

Debian-Installation auf eine SSD-Festplatte migrieren

Auf Grund eines längeren Ausfalls meines Servers (Gründe: Netzteil des Cablemodems ist gestorben, Switch auf Grund eines Wackelkontaktes des Netzteils ohne Strom) war ich heute im Elternhaus. Aus gegebenem Anlass habe ich mich entschieden, die Debian-Installation von einer Samsung HD161GJ (160GB) auf eine hier unbenutzt herumliegende 128GB SSD–Festplatte (Crucial M4-CT128M4SSD2) zu migrieren.

Nachfolgend eine Schritt-für-Schritt-Anleitung, wie dieses Vorhaben in möglichst kurzer Zeit bewerkstelligt werden kann.

Grob (für Profis)

  1. Zweite Festplatte an Server anschliessen (SATA oder via USB-Adapter)
  2. SSD-Festplatte partitionieren (bei mir: /boot, Swap und / (root))
  3. SSD-Partitionen formatieren (mkfs.ext4, mkswap)
  4. Partitionen mounten
  5. Mittels rsync alle Nutzdaten von den System-Partitionen auf die SSD-Partionen verschieben
  6. Die UUIDs in /etc/fstab der SSD-Festplatte anpassen
  7. grub-install auf die SSD-Festplatte
  8. Herunterfahren
  9. Ehemalige System-Platte vom System trennen
  10. Neu starten
  11. BIOS anpassen
  12. grub rescue überreden, von der SSD-Festplatte zu starten, obwohl die UUIDs nicht mehr stimmen
  13. update-grub ausführen

Detailliert (für Anfänger/Erfahrene)

Partitionierung

Nachdem die Festplatte erfolgreich an den SATA-Bus angeschlossen worden ist, sollte sie sowohl unter /var/log/messages als auch mittels fdisk -l aufgelistet werden. Den von dort übernommenen Device-Namen (in meinem Fall: /dev/sdd) verwendet man, um das Partitionierungstool fdisk zu starten:

# fdisk /dev/sdd

Ich habe mir zuerst eine primäre Partition für /boot erstellt (p, 1024MB) und die Partition bootbar gemacht (a). Anschliessend habe ich eine erweiterte Partition erstellt, in welcher ich einerseits eine Swap-Partition erstellt habe (Typ 82, 1024MB — so gross wie der verfügbare RAM-Speicher) als auch die root-Partition.

Ganz wichtig ist, alle Änderungen am Schluss mittels w auch effektiv auf die SSD zu schreiben.

Formatierung

Die Formatierung ist schnell erledigt. Mittels mkfs.ext4 formatiert man die /boot-Partition:

# mkfs.ext4 /dev/sdd1

… als auch die / (root)-Partition:

# mkfs.ext4 /dev/sdd6

Mittels mkswap formatiert man die Swap-Partition:

# mkswap /dev/sdd5

Mounten

Solange man die /etc/fstab-Einträge noch nicht umgebogen hat, müssen /boot und / (root) manuell gemountet werden:

# mount /dev/sdd1 /mnt/neu/boot
# mount /dev/sdd6 /mnt/neu/root

Der Filesystem-Typ wird automatisch erkannt.

Filesystem klonen

Die beiden Partitionen klont man folgendermassen:

# cd /
# rsync -av --one-file-system . /mnt/neu/root
# cd /boot
# rsync -av --one-file-system . /mnt/neu/boot

fstab

Die fstab-Datei muss auf der neuen / (root)-Partition angepasst werden. Die Festplatten sollte man heutzutage mit den UUIDs ansprechen. Die UUIDs findet man mit dem Befehl blkid heraus:

...
/dev/sdd1: UUID="3993c6e2-de5c-4227-9cae-637bbfc820b7" TYPE="ext4" 
/dev/sdd5: UUID="79c00de9-06a7-41e5-a470-641b5f68b909" TYPE="swap" 
/dev/sdd6: UUID="9672eb79-b6da-4192-a507-45de2662af2d" TYPE="ext4"
...

Die Partitionen definiert man basierend darauf folgendermassen in /etc/fstab:

...
#/etc/fstab: static file system information.
#
# 												
UUID=3993c6e2-de5c-4227-9cae-637bbfc820b7	/boot		ext4	discard,noatime,errors=remount-ro	0	2
UUID=79c00de9-06a7-41e5-a470-641b5f68b909	none		swap	sw					0	0
UUID=9672eb79-b6da-4192-a507-45de2662af2d       /               ext4    discard,noatime,errors=remount-ro       0       1
...

Gemäss SSD-Fetischisten sind die Optionen discard,noatime unendlich wichtig, um die Lebensdauer der SSD-Festplatte von 19 auf 19.1 Jahre zu erhöhen … Randbemerkung: Die SSD-Optimierer erscheinen mir ähnlich suspekt wie die Idioten, welche bei jedem Mac-Problem erst einmal raten, Repair Permissions durchzuführen (Richtigstellung: Seriously, ‘Repair Permissions’ Is Voodoo).

grub installieren

Mittels folgendem Befehl wird der grub Bootloader in den MBR der neuen Festplatte geschrieben:

# grub-install /dev/sdd

ACHTUNG: Viele Web-Seiten raten in diesem Schritt, den Computer von einer Linux Live-CD zu starten, mittels chroot das Root des Systems auf die SSD-Festplatte umzubiegen sowie sys, proc und dev neu zu mounten. Wer den hier notierten Anweisungen folgt, kann sich diesen umständlichen Schritt sparen.

BIOS

In meinem Fall war im BIOS hardkodiert, dass die 160 GB-Platte von Samsung die zu bootende Festplatte war. Da diese nun fehlte, blieb das System ohne Fehlermeldung hängen. Im BIOS musste ich deshalb die SSD-Festplatte neu als Boot-Festplatte aufnehmen.

grub rescue

Da ich grub-install ausgeführt hatte, als Linux noch von der Samsung-Festplatte als Systemplatte lief, wurden die UUIDs der Partitionen dieser Festplatten in den grub-MBR der SSD-Festplatte geschrieben.

Als das BIOS den Bootloader von der SSD-Platte startete, erschien folgende Fehlermeldung auf dem Schirm:

No such Device: ad4103fa-d940-47ca-8506-301d8071d467

Mittels des Befehls ls wurden mir alle erkannten Festplatten und Partitionen angezeigt. Nachdem ich die System-Festplatte in der grub-Nomenklatur ausgemacht hatte, konnte ich grub mitteilen, wie es zu starten hatte:

set prefix=(hd0,msdos0)/grub
set root=(hd0,msdos5)
insmod normal
normal

Mit diesen Angaben fand grub die Partitionen mit den benötigten Boot-Informationen und Debian startete sauber — und dank SSD blitzschnell.

grub

Da das System nun von SSD-Festplatte lief, konnte ich grub-install erneut ausführen. Dieses Mal übernahm grub die UUIDs der SSD-Partitionen, was ich mir mit update-grub bestätigen liess. Der letzte Befehl schrieb die grub-Konfiguration im Klartext in die Datei /boot/grub/grub.cfg.

Links

Tags: , , , , , ,
Labels: Linux

1 Kommentar | neuen Kommentar verfassen

Sonntag, 9. Juni 2013

Mit postfix über cyons SMTP E-Mails versenden

Wer wie ich zu Hause einen Linux-Server betreibt, benötigt manchmal auch die Möglichkeit, E-Mails zu versenden.

Mit folgenden Einstellungen versende ich mit Linux E-Mails über meinen schweizerischen Qualitätshoster cyon:

/etc/postfix/main.cf

...
relayhost = [server00.cyon.ch]
smtp_use_tls = yes
smtp_sasl_auth_enable = yes
smtp_sasl_mechanism_filter = login
smtp_sasl_password_maps = hash:/etc/postfix/sasl/outgoing
smtp_sasl_security_options = noanonymous

Damit der Versand aber effektiv klappt, muss ich wie im Attribut smtp_sasl_password_maps angegeben noch die Zugangsdaten eines cyon-Mail-Kontos hinterlegen:

/etc/postfix/sasl/outgoing

[server00.cyon.ch] user@domain.tld:password

Bevor postfix zum ersten Mal gestartet wird, muss diese Datei gehasht werden:

# postmap /etc/postfix/sasl/outgoing

Damit wird eine neue Datei unter /etc/postfix/sasl/outgoing.db angelegt, welche von postfix beim nächsten Start eingelesen wird.

Test

Zu Testzwecken versende ich nun per Kommandozeile eine E-Mail:

$ echo "Bla" | mail -s "Test" user@domain.tld

WICHTIG: Es empfiehlt sich, im cyon-Control Panel eine dediziertes E-Mail-Konto anzulegen, welches nur dem E-Mail-Versand dient. Sollte der Server gehackt werden, kann sich der Angreifer so nicht im privaten E-Mail-Verkehr herumtummeln.

Die beiden Dateien /etc/postfix/sasl/outgoing und /etc/postfix/sasl/outgoing.db sollten zudem nur für den Besitzer lesbar gemacht werden:

# chmod 600 /etc/postfix/sasl/outgoing /etc/postfix/sasl/outgoing.db

Tags: , , , ,
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen