auf /dev/sdb1 wechseln?

[spotti]

Hab grad zum ersten mal eine zusätzliche Festplatte unter openSuSE eingebunden und als ext3 (wie die andere Platte auch) formatiert.
die Platte wird auf unter fdisk -l entsprechend aufgeführt.

Jetzt frage ich mich die ganze Zeit, wie ich denn Dateien zwischen den beiden Platten hin und herkopieren kann.
Habe mal vorhin cp /etc/networks /dev/sdb1 probiert und bekam keine Fehlermeldung.
Aber wie wechsel ich denn jetzt auf die neue Festplatte? cd /dev/sdb1 funktioniert nämlich nicht: No such file or directory

[EKKi]

Mahlzeit spotti,

Jetzt frage ich mich die ganze Zeit, wie ich denn Dateien zwischen den beiden Platten hin und herkopieren kann.

Eventuell (falls nicht schon geschehen) musst Du erst ein neues Dateisystem auf der Platte erzeugen (vulgo: formatieren). Anschließend solltest Du die Platte mittels "mount" dort in die bestehende Verzeichnisstruktur einhängen, wo es Dir am besten passt (z.B. "/mnt/platte"). Danach kannst Du dieses Verzeichnis ("/mnt/platte") ganz normal nutzen.

MfG,
EKKi

[Der Martin]

Hallo,

Hab grad zum ersten mal eine zusätzliche Festplatte unter openSuSE eingebunden und als ext3 (wie die andere Platte auch) formatiert.
die Platte wird auf unter fdisk -l entsprechend aufgeführt.

das ist schon mal gut.

Jetzt frage ich mich die ganze Zeit, wie ich denn Dateien zwischen den beiden Platten hin und herkopieren kann.
Habe mal vorhin cp /etc/networks /dev/sdb1 probiert und bekam keine Fehlermeldung.

Oh. Das ist seltsam; das hätte nach meinem Verständnis so nicht funktionieren können.

Aber wie wechsel ich denn jetzt auf die neue Festplatte? cd /dev/sdb1 funktioniert nämlich nicht: No such file or directory

Bevor du "normal" auf die Platte zugreifen kannst, musst du sie noch ins Filesystem einhängen, man spricht hier von "mounten".

Ich kenne SUSE nicht, bestimmt gibt's da ein GUI-Tool zum Mounten von Datenträgern.
In einem richtigen Linux würde das etwa so funktionieren:

1. Melde dich auf der Konsole als root an.
2. Erstelle ein Verzeichnis, das zukünftig die neue Platte repräsentieren soll, beispielsweise /disk2 (Name und Ort kannst du natürlich variieren).
3. öffne die Datei /etc/fstab im Editor und ergänze eine Zeile für das neue Filesystem. Am besten orientierst du dich an einer der vorhandenen Zeilen, die die Filesysteme auf sda einbinden. Ich würde die Zeile, die sda1, sda2 oder sda3 auf / mountet, kopieren und dann den Mountpoint auf /disk2 und die Partitionsbezeichnung auf /dev/sdb1 ändern.
4. Speichern, fast fertig.

Das neue Filesystem wird nun beim nächsten Booten eingebunden; wenn du es sofort haben willst, kannst du es mit mount /disk2 haben - das sollte nach den oben beschriebenen Schritten gehen, weil die Information über diesen Mountpoint in /etc/fstab nun vorhanden ist.
Nun musst du die Berechtigungen für /disk2 noch anpassen, damit nicht nur root darauf zugreifen kann.

Viel Spaß,
 Martin

[Dennis_B]

Hey Martin,

1. Melde dich auf der Konsole als root an.
2. Erstelle ein Verzeichnis, das zukünftig die neue Platte repräsentieren soll, beispielsweise /disk2 (Name und Ort kannst du natürlich variieren).
3. öffne die Datei /etc/fstab im Editor und ergänze eine Zeile für das neue Filesystem. Am besten orientierst du dich an einer der vorhandenen Zeilen, die die Filesysteme auf sda einbinden. Ich würde die Zeile, die sda1, sda2 oder sda3 auf / mountet, kopieren und dann den Mountpoint auf /disk2 und die Partitionsbezeichnung auf /dev/sdb1 ändern.
4. Speichern, fast fertig.

muss dieser eintrag immer zwingend erfolgend?
Ich habe erst ein ganz ganz wenig Erfahrung mit den Mounten, dass einzigste was ich bis Dato jemals gemountet habe war ein USB-Stick mittels:
mount /dev/sda1 /USBPEN

Das hat geklappt soweit. Nur leider war am nächsten Tag weder der Inhalt des USB-Sticks wie zu erwarten in /USBPEN noch in dev/sda1 zu finden... :(
Irgendwie lief das wohl was scheif... hast du evtl. eine Idee?
Was mich auch ziemlich verwunderte war der Name des USB-Sticks "sda1", heißen so nicht normalerweise die Partitionen von Festplatten?

Danke dir :)

[Der Martin]

Hallo Dennis,

3. öffne die Datei /etc/fstab im Editor und ergänze eine Zeile ...
   muss dieser eintrag immer zwingend erfolgend?

nein, das nicht. Aber ...

Ich habe erst ein ganz ganz wenig Erfahrung mit den Mounten, dass einzigste was ich bis Dato jemals gemountet habe war ein USB-Stick mittels:
mount /dev/sda1 /USBPEN
Das hat geklappt soweit. Nur leider war am nächsten Tag weder der Inhalt des USB-Sticks wie zu erwarten in /USBPEN noch in dev/sda1 zu finden... :(

Genau das. Natürlich kannst du ein Filesystem mal schnell "von Hand" mounten. Aber das gilt dann eben nicht dauerhaft.

Was mich auch ziemlich verwunderte war der Name des USB-Sticks "sda1", heißen so nicht normalerweise die Partitionen von Festplatten?

Kommt drauf an. Traditionell werden Festplatten mit hd** bezeichnet. Das ist bei IDE-Platten auch heute noch so. Alles andere (SCSI, SATAN, USB-Massenspeicher, ...) werden mit sd** enumeriert.
Wenn du also ein System mit einer IDE-Platte hast, passt das schon - der USB-Stick ist dann das erste Nicht-IDE-Laufwerk und wird zu sda, die erste (und vermutlich einzige) Partition darauf sda1.
Bei einem System mit SATAN-Festplatten ist sda üblicherweise die erste (interne) Festplatte.

Ciao,
 Martin

[Jens Holzkämper]

Tach,

Kommt drauf an. Traditionell werden Festplatten mit hd** bezeichnet. Das ist bei IDE-Platten auch heute noch so. Alles andere (SCSI, SATAN, USB-Massenspeicher, ...) werden mit sd** enumeriert.

nah dran: IDE-Geräte (z.B. auch CD-ROMs) werden traditionell mit hd* durchnummeriert, und zwar mit festem Schema hdd ist also immer der Slave am zweiten Kanal, auch wenn der erste Kanal nicht genutzt wird. IDE-CD-Brenner werden häufiger auch nach sd* umgemappt, weil sie über ein adneres Subsystem angesprochen werden.

mfg
Woodfighter

[Alexander (HH)]

Moin Moin!

Kommt drauf an. Traditionell werden Festplatten mit hd** bezeichnet. Das ist bei IDE-Platten auch heute noch so. Alles andere (SCSI, SATAN, USB-Massenspeicher, ...) werden mit sd** enumeriert.

nah dran: IDE-Geräte (z.B. auch CD-ROMs) werden traditionell mit hd* durchnummeriert, und zwar mit festem Schema hdd ist also immer der Slave am zweiten Kanal, auch wenn der erste Kanal nicht genutzt wird. IDE-CD-Brenner werden häufiger auch nach sd* umgemappt, weil sie über ein adneres Subsystem angesprochen werden.

Noch dichter dran, aber immer noch nicht getroffen.

Mit libata bzw. CONFIG_ATA_SFF (ATA SFF support) werden auch die alten IDE-Geräte (und SATA-Geräte im Kompatibilitätsmodus) wie SATA-Geräte und SCSI-Geräte behandelt: Alle Platten werden sequenziell ab sda aufgezählt, alle CD/DVD-Laufwerke ab sr0 durchnumeriert. Rückschlüsse auf den Anschluß aus dem Gerätenamen allein sind nicht mehr möglich.

Das ist besonders angenehm, wenn man viele IDE-Platten jeweils als Master an vielen IDE-Controllern betreibt, weil es damit keine Lücken mehr zwischen den Device-Namen gibt.

Alexander

[Der Martin]

Hi,

Mit libata bzw. CONFIG_ATA_SFF (ATA SFF support) werden auch die alten IDE-Geräte (und SATA-Geräte im Kompatibilitätsmodus) wie SATA-Geräte und SCSI-Geräte behandelt: Alle Platten werden sequenziell ab sda aufgezählt, alle CD/DVD-Laufwerke ab sr0 durchnumeriert. Rückschlüsse auf den Anschluß aus dem Gerätenamen allein sind nicht mehr möglich.

jetzt wird's interessant!
Wie kann ich eigentlich diese Zuordnungen steuern? Kann ich überhaupt?
Ich habe hier einen PC mit interner Festplatte (sda) und internem Card-Reader am USB (sdb..sde). Sobald ich eine externe Festplatte anschließe, wird die zu sdf. Lasse ich sie aber angeschlosse, und boote dann den Rechner neu, ist sie plötzlich sdb und der Cardreader wird als sdc..sdf enumeriert. Das ist natürlich doof. Kann man dafür sorgen, dass die Zuordnungen wenigstens immer gleich sind?

Das ist besonders angenehm, wenn man viele IDE-Platten jeweils als Master an vielen IDE-Controllern betreibt, weil es damit keine Lücken mehr zwischen den Device-Namen gibt.

Kann ich nachvollziehen.

Ciao,
 Martin

[Jens Holzkämper]

Tach,

Wie kann ich eigentlich diese Zuordnungen steuern? Kann ich überhaupt?
Ich habe hier einen PC mit interner Festplatte (sda) und internem Card-Reader am USB (sdb..sde). Sobald ich eine externe Festplatte anschließe, wird die zu sdf. Lasse ich sie aber angeschlosse, und boote dann den Rechner neu, ist sie plötzlich sdb und der Cardreader wird als sdc..sdf enumeriert. Das ist natürlich doof. Kann man dafür sorgen, dass die Zuordnungen wenigstens immer gleich sind?

mit udev sollte das gehen: http://ubuntuforums.org/showthread.php?t=168221

mfg
Woodfighter

[Alexander (HH)]

Moin Moin!

jetzt wird's interessant!
Wie kann ich eigentlich diese Zuordnungen steuern?

Bei den alten IDE-Controllern ist die Reihenfolge analog der alten hd[a-z]-Numerierung, nur eben lückenlos. Der erste gefundene Controller (der auf den klassischen ISA-Adressen) steht ganz vorne, dann kommen die nächsten Controller in Fund-Reihenfolge (vermutlich nach PCI-Bus-Scan-Reihenfolge).

Bei SATA dürfte das genauso sein. Bei gemischten Systemen (hab ich hier nicht) entscheidet wohl nur die Reihenfolge, in der die Controller gefunden werden.

Der Linux-Kernel macht (wenigstens auf SMP-Systemen) einige Erkennungen parallel, die Reihenfolge der unterschiedlichen Controller-Typen scheint da gelegentlich etwas zufällig zu sein.

Kann ich überhaupt?

udev müßte das können.

Ich habe hier einen PC mit interner Festplatte (sda) und internem Card-Reader am USB (sdb..sde). Sobald ich eine externe Festplatte anschließe, wird die zu sdf.

Natürlich, weil a bis e schon vergeben sind.

Lasse ich sie aber angeschlosse, und boote dann den Rechner neu, ist sie plötzlich sdb und der Cardreader wird als sdc..sdf enumeriert.

Klar, die Platte wird eher erkannt als der Cardreader. SATA oder USB? SATA müßte schneller sein als USB, denn bei USB trödelt Linux absichtlich etwas, um lahmarschige Geräte zu finden.

Bei USB könntest Du versuchen, einen anderen Port zu benutzen, der später abgefragt wird als der vom Cardreader.

Das ist natürlich doof.

Ja, aber kein großes Problem. Mounte die Partitionen nicht nach dem Device-Namen, sondern nach dem Label des Dateisystems oder nach dessen UUID:

mount LABEL=foobarbaz /mnt/tmp
mount UUD=whatever /mnt/tmp

Kann man dafür sorgen, dass die Zuordnungen wenigstens immer gleich sind?

Wenn, dann über udev.

Alexander

[Der Martin]

Hi,

Kann ich überhaupt?
udev müßte das können.

das deckt sich mit der Auskunft von Jens, und ich hab auch ansatzweise mal ein wenig darüber gelesen. Noch nicht genug, um das Konzept zu verstehen, aber das kommt sicher noch.

Ich habe hier einen PC mit interner Festplatte (sda) und internem Card-Reader am USB (sdb..sde). Sobald ich eine externe Festplatte anschließe, wird die zu sdf.
Natürlich, weil a bis e schon vergeben sind.

Ja, das war mir auch klar. ;-)

Lasse ich sie aber angeschlosse, und boote dann den Rechner neu, ist sie plötzlich sdb und der Cardreader wird als sdc..sdf enumeriert.
Klar, die Platte wird eher erkannt als der Cardreader. SATA oder USB?

USB. Sowohl die externe Platte als auch der Cardreader.

Bei USB könntest Du versuchen, einen anderen Port zu benutzen, der später abgefragt wird als der vom Cardreader.

Klingt plausibel - andererseits unbefriedigend, weil ja nach der allgemein üblichen Lesart "alle USB-Ports gleichwertig sind".

Ja, aber kein großes Problem. Mounte die Partitionen nicht nach dem Device-Namen, sondern nach dem Label des Dateisystems oder nach dessen UUID:
mount LABEL=foobarbaz /mnt/tmp
mount UUD=whatever /mnt/tmp

Nach dem Label ist eine gute Idee - die UUIDs sind mir zu suspekt, als dass ich sie nutzen möchte. Die habe ich schon in /etc/fstab wieder durch die klassischen Device-Namen ersetzt, weil mir deren Konzept insgesamt doch logischer und sinnvoller erscheint.

Ciao,
 Martin

[Alexander (HH)]

Moin Moin!

Bei USB könntest Du versuchen, einen anderen Port zu benutzen, der später abgefragt wird als der vom Cardreader.

Klingt plausibel - andererseits unbefriedigend, weil ja nach der allgemein üblichen Lesart "alle USB-Ports gleichwertig sind".

Ja schon, aber mit irgendeinem muß man ja anfangen, wenn man nach bereits angeschlossenen Geräten sucht. Ich weiß nicht so genau, wie das im Detail implementiert ist. Es kann natürlich auch sein, dass die Antwortgeschwindigkeit entscheidet. Dann hilft umstöpseln gar nichts.

Ja, aber kein großes Problem. Mounte die Partitionen nicht nach dem Device-Namen, sondern nach dem Label des Dateisystems oder nach dessen UUID:
mount LABEL=foobarbaz /mnt/tmp
mount UUD=whatever /mnt/tmp

Nach dem Label ist eine gute Idee - die UUIDs sind mir zu suspekt, als dass ich sie nutzen möchte.

UUIDs sind auch nur Labels, mit dem feinen Unterschied, dass sie automatisch generiert sind und es recht unwahrscheinlich ist, dass zwei Partitionen die selbe UUID haben -- außer nach einer Image-Kopie.

Die habe ich schon in /etc/fstab wieder durch die klassischen Device-Namen ersetzt, weil mir deren Konzept insgesamt doch logischer und sinnvoller erscheint.

Ein anderer Weg sind RAID-Devices. Für nur eine Platte ist das natürlich Quatsch, aber auf meinem Server spreche ich die System- und Datenpartitionen nur über RAID-Devices an. Root ist ein RAID-1 auf zwei antiken IDE-Platten (2x 6,4 GB), mit dem Device-Namen /dev/md0. Daten sind ein RAID-5 aus vier alten IDE-Platten (4x 400 GB), mit dem Device-Namen /dev/md1. Auf den beiden Root-Platten liegen außerdem Swap-Partitionen, die per Label gemountet werden. Alle RAID-Partitionen haben den Typ 0xFD, d.h. Linux RAID Autodetect. Linux sucht sich die Partitionen beim Booten selbst zusammen und nimmt den Device-Namen, den sie beim letzten Mount hatten, wieder. Dabei ist es völlig egal, ob ich über /dev/hdX oder /dev/sdX arbeite. Im Moment nimmt mein Server /dev/sdX. Die externe USB-Platte mit der Backup-Partition wird wie die Swap-Partitionen über Label gemountet.

Kleines Detail am Rande: Ich hätte gewettet, dass die beiden kleinen Root-/Swap-Platten, die am internen IDE-Controller hängen, /dev/sda und /dev/sdb heißen. Irrtum! /dev/sda bis /dev/sdd sind die vier großen Platten an den beiden zusätzlichen IDE-Controllern, die beiden kleinen Platten heißen /dev/sde und /dev/sdf. Es ist also nicht einmal so, dass BIOS 0x80 = /dev/sda gilt. Früher(TM) hießen die kleinen Platten /dev/hda und /dev/hdc, die großen Platten hießen /dev/hde, /dev/hdg, /dev/hdi und /dev/hdk. Die Backup-Platte heißt heute /dev/sdg, früher /dev/sda. Dank RAID und Labels ist das aber mittlerweile völlig egal.

Alexander

[Jens Holzkämper]

Tach,

Noch dichter dran, aber immer noch nicht getroffen.

thx

mfg
Woodfighter

[Brillo Agent Nr. 1]

Hi,

Bevor du "normal" auf die Platte zugreifen kannst, musst du sie noch ins Filesystem einhängen, man spricht hier von "mounten".

Ich kenne SUSE nicht, bestimmt gibt's da ein GUI-Tool zum Mounten von Datenträgern.
In einem richtigen Linux würde das etwa so funktionieren:

was meinst du mit *richtigem Linux*? SUSE ist *richtiges* Linux, und zum Mounten braucht man auch dort kein GUI-TOOL sondern die Shell sollte ausreichen.
Für meine Verständnisse war Ubuntu immer kein richtiges Linux, aber das ist ebenso Quatsch.

Brillo

[Der Martin]

Hallo,

Ich kenne SUSE nicht, bestimmt gibt's da ein GUI-Tool zum Mounten von Datenträgern.
In einem richtigen Linux würde das etwa so funktionieren:
was meinst du mit *richtigem Linux*? SUSE ist *richtiges* Linux

naja, ich habe SUSE ein paarmal bei Kollegen und Bekannten erlebt, und für mich wirkt es wie ein untotes, unkontrolliert wucherndes Windows auf einem Linux-Kernel. Das liegt einerseits am KDE, andererseits wohl an der typischen Klientel - die meisten Nutzer starrten mich fassungslos an und stammelten irgendwas im Sinne von "Was ist denn das, ich dachte, DOS gäb's nicht mehr", wenn ich irgendwo in den Tiefen irgendwelcher Menüs doch noch eine Konsole gefunden hatte.

und zum Mounten braucht man auch dort kein GUI-TOOL sondern die Shell sollte ausreichen.

"Brauchen" ist auch nicht das, was ich meinte - aber der (aus meiner Sicht) typische SUSE-Nutzer bevorzugt GUI-Methoden.

Für meine Verständnisse war Ubuntu immer kein richtiges Linux, aber das ist ebenso Quatsch.

Ja, so richtig ist das für mich auch nicht; es ist doch sehr GUI-lastig. Es ist IMO ein ideales Umsteiger-System für jemanden, der Windows gewöhnt ist und nicht auf all den bunten Firlefanz verzichten möchte.

Ciao,
 Martin

[brillo agent nr.1]

Hi,

naja, ich habe SUSE ein paarmal bei Kollegen und Bekannten erlebt, und für mich wirkt es wie ein untotes, unkontrolliert wucherndes Windows auf einem Linux-Kernel. Das liegt einerseits am KDE, andererseits wohl an der typischen Klientel - die meisten Nutzer starrten mich fassungslos an und stammelten irgendwas im Sinne von "Was ist denn das, ich dachte, DOS gäb's nicht mehr", wenn ich irgendwo in den Tiefen irgendwelcher Menüs doch noch eine Konsole gefunden hatte.

DAS muss aber schon ne Weile her sein... :) OpenSuse11.2 bringt standardmäßig ne Menge Programme mit, das mag sein. Man kann aber bei der Installation schon "Minimales System" wählen, dann wird nur das nötigste installiert. Mit der Konsole kann ich nicht nachvollziehen. Unter Programme->System stehen 5 Konsolen leicht auffindbar zur Verfügung...

KDE wirkt etwas starr, aber mir ist es lieber als Gnome.  Und die typische Suse-Klientel kenne ich nicht. Allerdings KANN es sein, dass früher die meisten Umsteiger von Windows auf Linux Suse genommen haben. Es war/ist leicht verfügbar (beiligende CDs/DVDs in Computerheften) und wurde relativ stark beworben.

und zum Mounten braucht man auch dort kein GUI-TOOL sondern die Shell sollte ausreichen.

"Brauchen" ist auch nicht das, was ich meinte - aber der (aus meiner Sicht) typische SUSE-Nutzer bevorzugt GUI-Methoden.

Also ich bin u.a. SUSE-Nutzer und bevorzuge die Methoden, die mir am besten erscheinen. Das können GUI-Tools sein oder eben mal schnell die Shell.

Für meine Verständnisse war Ubuntu immer kein richtiges Linux, aber das ist ebenso Quatsch.

Ja, so richtig ist das für mich auch nicht; es ist doch sehr GUI-lastig. Es ist IMO ein ideales Umsteiger-System für jemanden, der Windows gewöhnt ist und nicht auf all den bunten Firlefanz verzichten möchte.

Hmm, GUI-lastig sind die ja mittlerweile alle irgendwie.. Fedora12 z.B. kann man schon sehr gut nutzen, auch wenn man Linux-Noob ist. Allerdings MUSS man das ja nicht. Bei Ubuntu stört mich solche Sachen, wiez.b., dass man sich (wohl aus Sicherheitsgründen) nicht als root anmelden kann. Oder geht das mittlerweile?

Gruß
Brillo

[Alexander (HH)]

Moin Moin!

Bei Ubuntu stört mich solche Sachen, wiez.b., dass man sich (wohl aus Sicherheitsgründen) nicht als root anmelden kann. Oder geht das mittlerweile?

Kannst Du auf MacOS X auch nicht, und es ist auch nicht nötig. Wenn du Root-Rechte brauchst, nimm sudo. Wenn es eine Root-Shell sein soll, sudo -i. Pack die Accounts, die sich root-Rechte verschaffen können sollen, in die Gruppe wheel, und schalte den entsprechenden Eintrag in /etc/sudoers frei.

Bei OS X und wohl auch Ubuntu passiert das schon während des Setups, wenn Du die wichtigsten User anlegst.

Es gibt absolut keinen Grund, dauerhaft als root zu arbeiten, zumal das in aller Regel eine extrem blöde Idee ist. root hat einfach viel zu viele Rechte.

Alexander

[brillo agent nr.1]

Hi,

Kannst Du auf MacOS X auch nicht, und es ist auch nicht nötig. Wenn du Root-Rechte brauchst, nimm sudo. Wenn es eine Root-Shell sein soll, sudo -i. Pack die Accounts, die sich root-Rechte verschaffen können sollen, in die Gruppe wheel, und schalte den entsprechenden Eintrag in /etc/sudoers frei.

guter Tip, ist vielleicht keine schlechte Idee. Schlechte Angewohnheit von mir, mich manchmal als root einzuloggen.

Bei OS X und wohl auch Ubuntu passiert das schon während des Setups, wenn Du die wichtigsten User anlegst.

ah ok, das wusste ich nicht. Und jeder sudoer kann weitere sudoer anlegen bzw. User zu Sudoern machen?

Es gibt absolut keinen Grund, dauerhaft als root zu arbeiten, zumal das in aller Regel eine extrem blöde Idee ist. root hat einfach viel zu viele Rechte.

da gebe ich dir ausnahmslos Recht.

Brillo

[Jens Holzkämper]

Tach,

Pack die Accounts, die sich root-Rechte verschaffen können sollen, in die Gruppe wheel, und schalte den entsprechenden Eintrag in /etc/sudoers frei.
ah ok, das wusste ich nicht. Und jeder sudoer kann weitere sudoer anlegen bzw. User zu Sudoern machen?

das hängt von der Konfiguration ab, im Falle der Gruppe wheel ja, jeder Nutzer darin hat in der üblichen Konfiguration volle root-Rechte bzw. kann sie sich beschaffen. Man kann sudo allerdings auch stark einschränken und damit nur noch Befehle in exakt definierten Grenzen zulassen.

mfg
Woodfighter

[Alexander (HH)]

Moin Moin!

Und jeder sudoer kann weitere sudoer anlegen bzw. User zu Sudoern machen?

das hängt von der Konfiguration ab, im Falle der Gruppe wheel ja, jeder Nutzer darin hat in der üblichen Konfiguration volle root-Rechte bzw. kann sie sich beschaffen. Man kann sudo allerdings auch stark einschränken und damit nur noch Befehle in exakt definierten Grenzen zulassen.

Genau das ist einer der Gründe, warum man sudo benutzen soll und nicht su oder ein root-Login. Bei mir darf z.B. jeder User und sogar ohne jede Passwort-Abfrage das Script runfetchmail aufrufen, dass über daemontools fetchmail anstubst, um neue Mails abzurufen.

Ein zweiter Grund ist, dass man kein geteiltes root-Passwort braucht. Jeder Benutzer verschafft sich mit seinem EIGENEN Passwort die notwendigen Rechte.

Und natürlich schreibt sudo ein Log. Richtig konfiguriert ist es mit sudo möglich, dass Leute gewisse Programme mit root-Rechten starten, ohne dass sie ihre Spuren verwischen können. Der Weg über die wheel-Gruppe ist natürlich gefährlicher, weil User in dieser Gruppe nach sudo -i effektiv root sind und natürlich auch das Log beseitigen können.

Für das Szenario, dass ein Computer nur von einer Person benutzt wird, oder dass nur eine Hand voll vertrauenswürdiger Leute den Rechner administrieren und der Rest der User eben nicht, ist der Weg über wheel am schnellsten eingerichtet und stört am wenigsten. Kommandos, die root-Rechte benötigen, stellt man ein sudo voran und alles ist gut. Und für längere Wartungsarbeiten nutzt man eben sudo -i. Ein deutlich anderer Prompt (Environment-Variable PS1) ist da sehr nützlich als Warnung, dass man zu viele Rechte hat.

In paranoiden Umgebungen ist wheel eher nicht zu empfehlen, dann muß sehr stark eingeschränkt sein, welche Software überhaupt über sudo gestartet werden kann. Wer per sudo den Midnight Commander, joe oder emacs aufrufen kann, hat auch automatisch eine Root-Shell. Selbst mit tee kann man sich ganz leicht eine Root-Shell verschaffen, wenn man es per sudo ausführen darf. Ist halt ein Schritt mehr als über den mc.

Alexander

[Jens Holzkämper]

Tach,

Ein zweiter Grund ist, dass man kein geteiltes root-Passwort braucht. Jeder Benutzer verschafft sich mit seinem EIGENEN Passwort die notwendigen Rechte.

ein geteiltes Paßwort ist nicht nötig, mehrere User mit ID 0 sind kein Problem: http://en.wikipedia.org/wiki/Toor.

mfg
Woodfighter

[Der Martin]

Hallo,

Ein zweiter Grund ist, dass man kein geteiltes root-Passwort braucht.

was will man auch mit einem halben, einem Drittel- oder Viertelpasswort? Warum teilen, warum lässt man es nicht lieber komplett? ;-)
Mir ist klar, was du meinst, aber mich stört immer wieder die Übersetzung "teilen" für den englischen Begriff "to share". Besser wäre "gemeinsam nutzen". "Teilen" ist für mich immer gleichbedeutend mit Zerstückeln oder Dividieren.

So long,
 Martin

[Alexander (HH)]

Moin Moin!

Ein zweiter Grund ist, dass man kein geteiltes root-Passwort braucht.

was will man auch mit einem halben, einem Drittel- oder Viertelpasswort? Warum teilen, warum lässt man es nicht lieber komplett? ;-)
Mir ist klar, was du meinst, aber mich stört immer wieder die Übersetzung "teilen" für den englischen Begriff "to share". Besser wäre "gemeinsam nutzen". "Teilen" ist für mich immer gleichbedeutend mit Zerstückeln oder Dividieren.

Klar, wenn wir beide uns ein Stück Kuchen teilen müßten, gäbe es sicherlich ein fürchterliches Gemetzel. ;-)

Aber ein Auto sollten wir uns problemlos teilen können, ohne nachher eine Tonne Stahl in zwei Stücken zum Schrottplatz bewegen zu müssen.

Alexander

[Der Martin]

Hi,

Mir ist klar, was du meinst, aber mich stört immer wieder die Übersetzung "teilen" für den englischen Begriff "to share". Besser wäre "gemeinsam nutzen". "Teilen" ist für mich immer gleichbedeutend mit Zerstückeln oder Dividieren.
Klar, wenn wir beide uns ein Stück Kuchen teilen müßten, gäbe es sicherlich ein fürchterliches Gemetzel. ;-)

och, nimm nur ... ich kümmer mich stattdessen um das Steak, das muss auch weg! :-)

Aber ein Auto sollten wir uns problemlos teilen können, ohne nachher eine Tonne Stahl in zwei Stücken zum Schrottplatz bewegen zu müssen.

Das ist aber nicht das, was ich unter "Teilen" verstehe (aber unter "Sharing").
Vielleicht könnten wir uns ein Büro teilen: Du benutzt eine Hälfte, ich die andere. Vielleicht auch eine Zeitung: Du kriegst den Sport- und Wirtschaftsteil, ich die lokalen und regionalen Nachrichten. Teilen heißt für mich immer, dass man nicht mehr das Ganze hat. Auch die Formulierung "ich teile diese Ansicht" finde ich sehr befremdlich.

Einen schönen heißen Tag noch,
 Martin

[dedlfix]

Hi!

Teilen heißt für mich immer, dass man nicht mehr das Ganze hat. Auch die Formulierung "ich teile diese Ansicht" finde ich sehr befremdlich.

Wie wär das dann bei "Geteiltes Leid ist halbes Leid" neu zu formulieren?

Redundanzschaffung durch Informationsweitergabe sorgt für ... ja was eigentlich, wie formuliert man 'Leid' mit einem informatorischen Begriff?

Oder impliziert "Weitergabe" wieder, dass ein bisheriger Besitzer etwas nicht mehr hat?

Redundanzschaffung durch Erstellung einer Informationskopie und deren Weitergabe sorgt für ...

Lo!

[at]

Hallo.

Wie wär das dann bei "Geteiltes Leid ist halbes Leid" neu zu formulieren?

Redundanzschaffung durch Informationsweitergabe sorgt für ... ja was eigentlich, wie formuliert man 'Leid' mit einem informatorischen Begriff?

"IE"?
MfG, at

[Der Martin]

Hallo,

Bei Ubuntu stört mich solche Sachen, wiez.b., dass man sich (wohl aus Sicherheitsgründen) nicht als root anmelden kann. Oder geht das mittlerweile?

ging das jemals nicht? Ich habe noch nie drüber nachgedacht, aber bei Ubuntu 9.04 (jaunty) und 10.04 (lucid) ist das problemlos möglich. Gut, am X11-Login nicht, aber mit su auf der Konsole ohne weiteres. Reicht ja auch.

Ciao,
 Martin

[Der Martin]

n'Abend,

für mich wirkt es wie ein untotes, unkontrolliert wucherndes Windows auf einem Linux-Kernel. Das liegt einerseits am KDE, andererseits wohl an der typischen Klientel - die meisten Nutzer starrten mich fassungslos an und stammelten irgendwas im Sinne von "Was ist denn das, ich dachte, DOS gäb's nicht mehr", wenn ich irgendwo in den Tiefen irgendwelcher Menüs doch noch eine Konsole gefunden hatte.
DAS muss aber schon ne Weile her sein... :)

naja, das letzte traumatsiche Erlebnis dieser Art ist schätzungsweise zwei Jahre her. War AFAIR ein SUSE 9-punkt-irgendwas, und einer von den Kollegen fand das ganz schick, hatte aber wenig Ahnung. Ich hatte damals auch nicht den großen Durchblick, aber zumindest überhaupt ein bisschen Verständnis für Linux. Immerhin hatte ich mit Ubuntu -damals gutsy- schon erste Erfahrungen gesammelt.

KDE wirkt etwas starr, aber mir ist es lieber als Gnome.

Ich habe vor einigen Wochen, als Ubuntu 10.04/lucid rauskam, mal die Kubuntu-Variante als Live-Version vom Stick ausprobiert. Ich fand das ätzend - ohne Handbuch oder menschliche Hilfestellung ist es doch praktisch nicht möglich, den Desktop überhaupt zu bedienen. Ich habe ein paar Minuten rumprobiert, aber nicht herausgefunden, wo ich an irgendwelche Menüs komme, wie ich überhaupt an irgendwas Bekanntes drankomme. Benutzerfreundlich, geschweige denn intuitiv, ist für mich etwas anderes.

und zum Mounten braucht man auch dort kein GUI-TOOL sondern die Shell sollte ausreichen.
"Brauchen" ist auch nicht das, was ich meinte - aber der (aus meiner Sicht) typische SUSE-Nutzer bevorzugt GUI-Methoden.
Also ich bin u.a. SUSE-Nutzer und bevorzuge die Methoden, die mir am besten erscheinen. Das können GUI-Tools sein oder eben mal schnell die Shell.

Für mich ist immer die Entscheidung: Entweder komfortabel oder GUI. ;-)

Ciao,
 Martin

[brillo agent nr.1]

Hi,

Ich habe vor einigen Wochen, als Ubuntu 10.04/lucid rauskam, mal die Kubuntu-Variante als Live-Version vom Stick ausprobiert. Ich fand das ätzend - ohne Handbuch oder menschliche Hilfestellung ist es doch praktisch nicht möglich, den Desktop überhaupt zu bedienen. Ich habe ein paar Minuten rumprobiert, aber nicht herausgefunden, wo ich an irgendwelche Menüs komme, wie ich überhaupt an irgendwas Bekanntes drankomme. Benutzerfreundlich, geschweige denn intuitiv, ist für mich etwas anderes.

Kubuntu kenne ich nicht. Müsste ich mal testen. Wie gesagt, KDE kommt etwas klotzig daher, aber ist Gewöhnungssache. So ganz kann ich das zwar ehrlich gesagt nicht nachvollziehen, zumindest nicht bei OpenSuse11.1...

Für mich ist immer die Entscheidung: Entweder komfortabel oder GUI. ;-)

Wohl wahr, wohl wahr. Im Bett mit Laptop auf dem Schoß ist eine GUI zweifelsohne die bessere Wahl, wie ich feststellen musste. Schreiben fällt da schon schwer. Programmieren (eventuell noch mit Handbuch daneben) ist dann schon eher Akrobatik.

Brillo

[Alexander (HH)]

Moin Moin!

Auf zum Glaubenskrieg! ;-)

Ich hab SuSE aus Zeiten einstelliger Versionsnummer als eine sehr unangenehme Distribution in Erinnerung. Installation ging ja noch, aber sobald man auf die "einzig wahre Art und Weise" (TM) etwas umkonfigurieren möchte, nämlich in dem man die entsprechende Konfigurationsdatei editiert, haut einem das dämliche SuSE-Konfigurationstool auf die Finger und überschreibt(!) die Konfigurationsdateien mit dem, was irgendwo in seiner Registry-artigen Konfigurationsmüllhalde steht. Natürlich nicht sofort, sondern erst beim nächsten Runlevel-Wechsel, Reboot oder Start des SuSE-Tools (YaST hieß das wohl). Natürlich ohne Rückfrage. Irgendwo in der Doku stand dann sinngemäß: Wenn du an den Konfigurationsdateien herumschrauben willst, kannst Du jeden Support vergessen und solltest tunlichst die Finger von YaST lassen. Das liest man aber erst, nachdem die Konfiguration zwei oder drei mal demoliert wurde. Weiteres Problem: Zu tode gepatchte Kernel, voller Distributions-spezifischer Patches, Backports und ähnlichem Müll.

Redhat/Fedora habe ich ähnlich in Erinnerung, aber seit ewigen Zeiten nicht mehr angefaßt.

Debian habe ich in sehr frühen Zeiten mal gesehen und wurde durch das damals noch absolut grausame Installationstool reichlich abgeschreckt. Im Laufe der Zeit ist meine Anerkennung für Debian gewachsen, nicht zuletzt durch Knoppix, aber ich konnte mich noch nie dazu durchringen, Debian ernsthaft zu nutzen. -stable ist antik, mit ewig weiter gepatchten Applikationen, -unstable muß ich nicht haben, und -testing schon mal gar nicht. Davon abgesehen drehen einige Debian-Leute in Sachen Lizenzen echt am Rad. Perl-Doku hat keine explizite Lizenz-Angabe? Wird also mal stumpf nicht installiert. Na bravo!

Zwischendurch bin ich über die Slackware gestolpert und nach einigen Installationsanläufen dabei geblieben. Es gibt kein allwissendes Tool, das überall hereinpfuscht, es gibt keine Million Pakete, keine ewig kaputte Paket-Manager-DB, und so lange etwas legal weiter verbreitet werden kann, darf es ins Paket. Auch wenn nicht jede Datei mit Copyright-Vermerken vollgepflastert ist. Fehlt etwas, compiliert man es eben selbst. Und Abhängigkeiten löst man auch mit dem Kopf. Zugegeben, die Lernkurve ist steiler, aber dafür macht ein gelegentlicher Wechsel auf *BSD, Solaris oder ähnliches keine Probleme. Allein das init-System nervt mich jedes Jahr mehr, SysV-Kompatibilität auf ein BSD-Init gefrickelt. Früher oder später schmeiße ich das komplett raus und ersetze das durch die ohnehin schon laufenden daemontools und ein Mini-Init.

Gentoo -- alles maßgeschneidert compiliert. Nur: Wozu? Die paar Prozentpunkte mehr Geschwindigkeit merkt man nicht, und Plattenplatz ist billig. Das von BSD abgekupferte Ports-System ist eine nette Idee, aber es braucht jede Menge Wartung. Kennt das Ports-System eine neue Version noch nicht, muß man genauso compilieren wie bei der Slackware. Dann doch lieber gleich die Slackware.

Knoppix -- geniale Live-CD, eines meiner Standard-Werkzeuge. Aber nicht als dauerhafter Desktop oder gar Server. Für kleinere Jobs tut's auch die Setup-CD/DVD der Slackware.

Andere Debian-Derivate: Naja, Debian eben, mit etwas anderen Farben und einigen kleineren Änderungen, vielleicht auch etwas entspannteren Lizenz-Wächtern.

Linux from Scratch & Co -- irgendwann mal, wenn ich ein Spezial-Linux brauche ...

Alexander

[Alexander (HH)]

Moin Moin!

Habe mal vorhin cp /etc/networks /dev/sdb1 probiert und bekam keine Fehlermeldung.

Oh. Das ist seltsam; das hätte nach meinem Verständnis so nicht funktionieren können.

Doch doch, das funktioniert, nur nicht so wie erwartet. /dev/sdb1 beginnt jetzt mit dem Inhalt von /etc/networks. Das dort evtl. vorhandene Dateisystem ist jetzt mindestens angeknackst, bei FAT und einer ausreichend großen /etc/networks ist es vielleicht komplett geschrottet.

Hast Du erwartet, dass cp sich weitert, in ein Device zu schreiben? Oder das cp erst das Ziel löscht? Das ist mitnichten so, wie Du mit einer Floppy, einem Loop-Device oder notfalls dem Verstehen einer Fehlermeldung sehen kannst.

echo "hohoho" > hohoho.txt

cp hohoho.txt /dev/full
cp: writing `/dev/full': No space left on device

Copy auf /dev/full schlägt fehl, weil das full-Device chronisch überfüllt ist.

Ein kleines Loop-File, weil die Linux-Kiste gerade ein paar Räume weiter weg steht. 5120 Bytes, alles Nullen.

dd if=/dev/zero of=loopfile bs=512 count=10
10+0 records in
10+0 records out
5120 bytes (5.1 kB) copied, 0.000133719 s, 38.3 MB/s

losetup /dev/loop0 loopfile

Ein Block-Device /dev/loop0 aus dem Loop-File machen.

cp hohoho.txt /dev/loop0

Reinkopieren, keine Fehlermeldung

dd if=loopfile bs=1 count=7
Hohoho
7+0 records in
7+0 records out
7 bytes (7 B) copied, 0.000706611 s, 9.9 kB/s

Und wieder erfolgreich rauskopieren.

losetup -d /dev/loop0

Block-Device wieder loswerden.

Nächstes Spiel. Wir simulieren eine alte 720K-Floppy, ebenfalls per Loop-File.

dd if=/dev/zero of=loopfile bs=512 count=1440
1440+0 records in
1440+0 records out
737280 bytes (737 kB) copied, 0.01017 s, 72.5 MB/s

Einmal genullt.

mkdosfs -v loopfile
mkdosfs 2.11 (12 Mar 2005)
loopfile has 2 heads and 9 sectors per track,
logical sector size is 512,
using 0xf9 media descriptor, with 1440 sectors;
file system has 2 12-bit FATs and 2 sectors per cluster.
FAT size is 3 sectors, and provides 713 clusters.
Root directory contains 112 slots.
Volume ID is 4c323c5c, no volume label.

Nun ist da ein wunderhübsches, leeres FAT-Dateisystem drauf.

file - < loopfile
/dev/stdin: DOS floppy 720k, x86 hard disk boot sector

File bestätigt das.

losetup /dev/loop0 loopfile

Block-Device bauen.

cp /etc/passwd /dev/loop0

Kaputtkopieren.

file - < loopfile
/dev/stdin: data

Ooooops, Dateisystem geschrottet.

losetup -d /dev/loop0

Schnell wieder weg damit.

Alexander

[spotti]

also habe ich mit cp das ext3 geschrottet??? Merkwürdig. Ich hab doch nur versucht logisch vorzugehen um mir nicht anhören zu müssen ich hätte nichts probiert.
Mein Problem ist, dass mount -t ext3 /dev/sdb1 /mnt/daten keinerlei Fehlermeldung abgibt. Es ist alles so, wie wenn es funktioniert blos, dass in mnt kein Link auftaucht.

[Alexander (HH)]

Moin Moin!

also habe ich mit cp das ext3 geschrottet???

Ja, vielleicht. e2fsck -f /dev/sdb1 wird es Dir verraten.

ext2/ext3 ist aber deutlich anders strukturiert als FAT, und so weit ich mich erinnere, ist am Anfang des Filesystems noch etwas "Luft", z.B. um dort einen Bootloader wie Grub oder LILO unterzubringen.

Außerdem sind kritische Strukturen (Superblock) bei ext2/ext3 mehrfach auf der Platte verteilt, so dass der Dateisystem-Treiber bei einem Fehler einfach auf einen anderen Superblock wechseln kann.

Merkwürdig. Ich hab doch nur versucht logisch vorzugehen um mir nicht anhören zu müssen ich hätte nichts probiert.

Naja, logisch finde ich das nur sehr bedingt. Ein Blick in die Doku wäre vielleicht hilfreich gewesen.

Mein Problem ist, dass mount -t ext3 /dev/sdb1 /mnt/daten keinerlei Fehlermeldung abgibt.

Nö, weil der Kernel das Dateisystem vermutlich fehlerfrei mounten kann. Vielleicht steht im Kernel-Log ein Hinweis auf einen defekten Superblock am Anfang des Dateisystems. Probier mal dmesg | less direkt nach dem mount-Kommando.

Es ist alles so, wie wenn es funktioniert blos, dass in mnt kein Link auftaucht.

Warum soll da ein Link auftauchen? Und was für einer?

/mnt/daten ist ein Verzeichnis. Mountest Du dort ein Dateisystem, z.B. /dev/sdb1, sind alle bisherigen Inhalte von /mnt/daten (das typischerweise leer ist) nicht mehr erreichbar, stattdessen findest Du dort alle Inhalte des frisch gemounteten Dateisystems, mit der obersten Verzeichnisebene des frisch gemounteten Dateisystems direkt unter /mnt/daten.

Nimm spaßeshalber mal eine Floppy, auf der ein paar nicht zwingend benötigte Dateien drauf sind. mount -t vfat /dev/fd0 /mnt/floppy, dann ls /mnt/floppy, und Du siehst die Daten, die auf der Floppy sind. umount /mnt/floppy und noch einmal ls /mnt/floppy und Du siehst wieder nichts. Noch einmal mount -t vfat /dev/fd0 /mnt/floppy und die Dateien sind wieder da. Dann cp /etc/networks /mnt/floppy/networks.txt, umount /mnt/floppy, warten bis das Laufwerk ruhig ist. Steck die Floppy in einen anderen Rechner oder starte den Rechner mit dem kommerziellen Betriebssystem aus Redmond neu, und bewundere die neue Datei auf der Floppy. Und dann zurück zum Linux, Floppy reinstecken, KEIN mount, sondern stumpf cp /etc/networks /dev/fd0. Warten bis das Laufwerk ruhig ist, Floppy in eine Windows-Kiste stecken und feststellen, dass Windows mit dem Inhalt der Floppy nichts mehr anfangen kann, die Floppy formatieren will. Dateisystem geschrottet.

Wie gesagt, FAT ist sehr anfällig für überschriebene oder defekte Datenblöcke. Mit ausreichend vielen Daten kannst Du auf diese Art aber auch ein ext2/ext3-Dateisystem komplett demolieren.

Übrigens sind normalerweise alle Block-Devices nur für root und die Gruppe disk schreibbar, der Rest der Welt darf sie nicht einmal lesen. Und das, wie Du gerade siehst, aus gutem Grund. Der Grund, warum der Rest der Welt die Block-Devices nicht einmal lesen darf, ist auch ganz einfach. Es ist überhaupt kein Problem, im "User Space" ein Programm zu haben, das ein Dateisystem lesen kann. Und natürlich ist es auch überhaupt kein Problem, in diesem Programm die normalerweise wirksamen Datei- und Verzeichnisattribute komplett zu ignorieren. Schon kann jeder User jede Datei lesen, inklusive /etc/shadow und privaten Dateien anderer User.

Wenn ein Dateisystem aber ganz normal per mount eingehängt wird, gelten die Datei- und Verzeichnisattribute ganz normal, und niemand kann Dinge sehen, die er nicht sehen darf.

Alexander