Linux
Dem dem GRand Unified Bootloader (GRUB) auf den Grund gehen und das Booten eines Rechners verstehen sowie nach belieben ändern. Man kann sich jetzt durch etliche Konfigurationsdateien wälzen, oder einfach den grub-customizer verwenden:
sudo apt-get install grub-customizer
Bis ich das Tutorial fertig habe, gibt es vorerst diese Videos.
sudo ist eine Möglichkeit Rootrechte zu erlangen ohne sich als root einloggen zu müssen. Ich nutze es z. B. als Sicherheits-Feature und auf meinen Systemen hat root gar kein Passwort. Es ist also gar keinen Root-Account, auf den man sich einloggen könnte.
Um einem Benutzer diese Rechte zu übertragen geht man wie folgt vor:
usermod -aG sudo USERNAME
Dazu benötigt man natürlich Root-Rechte!
Benötigt man nun für ein Kommando rootrechte geht man wie folgt vor:
sudo BEFEHL
Benötigt man einmal einen richtigen Rootaccount, kann man mit diesen anschliessend mit:
sudo -i
auf root wechseln vorausgesetzt man befindet sich auf einen Account mit sudoers rechten. Einen echten Root-Account benötigt man ab diesen Zeitpunkt nicht mehr und man könnte das Rootpasswort aus der /etc/shadows entfernen bzw. mit einem Stern * ersetzen. Ab diesen Zeitpunkt ist es nicht mehr möglich sich als Benutzer root anzumelden.
Ich hatte zu dem Thema bereits 2018 einige Zeilen geschrieben.
[ QUELLE ]
Wenn Du Manjaro oder Arch verwendest, mit Stream Civilization bei Dir direkt nach dem Start abstürzt, versuche mal folgende Startoption in Steam:
LD_PRELOAD=/usr/lib32/libopenal.so.1 %command% 
Quelle: https://superuser.com/questions/…
Bearbeitet: 2024-11-02 10:25:07 Saturday
Der Tipp bezieht sich nicht auf eine ganz bestimmte Linux-Distribution obwohlich hier nur Manjaro erwähne.
Hier nur ganz kurz auf die Schnelle. Nach Neuinstallation eines Manjaro-Linux Systems konnte die Windowsfreigabe einer Fritzbox nicht mehr gemountet werden über die /etc/fstab. Zuerst habe ich schnell CIFS installiert mit sudo pacman -S cifs-utils.
Obwohl es die gleiche fstab aus einem Backup war, kam beim Versuch zu mounten folgende Fehlermeldung:
[work /]# mount -a mount error(112): Host is down Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)
Der ensprechende Eintrag in der /etc/stab sah wie folgt aus:
//fritz.box/FRITZ.NAS/Disk-Name-01 /media/fritzbox cifs credentials=/root/.smbcredentials 0 0
Das Passwort habe ich unter /root/.smbcredentials gespeichert, damit man es beim booten nicht eingeben muss. Die Fehlermeldung blieb und der Server war selbst verständlich nicht erreichbar.
Was war passiert? Ein Blick in man mount.cifs, wie die Fehlermeldung geraten hatte brauchte folgendes zum Vorschein (Auszug):
vers=arg SMB protocol version. Allowed values are: · 1.0 - The classic CIFS/SMBv1 protocol. · 2.0 - The SMBv2.002 protocol. This was initially introduced in Windows Vista Service Pack 1, and Windows Server 2008. Note that the initial release version of Windows Vista spoke a slightly different dialect (2.000) that is not supported. · 2.1 - The SMBv2.1 protocol that was introduced in Microsoft Windows 7 and Windows Server 2008R2. · 3.0 - The SMBv3.0 protocol that was introduced in Microsoft Windows 8 and Windows Server 2012. · 3.1.1 or 3.11 - The SMBv3.1.1 protocol that was introduced in Microsoft Windows Server 2016
Also habe ich die /etc/fstab schnell angepasst in:
//fritz.box/FRITZ.NAS/Disk-Name-01 /media/fritzbox cifs vers=1.0,credentials=/root/.smbcredentials 0 0
Problem gelöst! Keine Ahnung wieso es unter Debian 9 vorher problemlos lief. Vieleicht eine andere cifs-Version?
Ich wäre fast verzweifelt. Mit wget kann man bekanntlich ganze Internetprojekte rekursiv herunterladen. Mit einem einfachen wget -r -l2 [URL] kann man ein ganzes Projekt inklusive links bis zur zweiten Ebene herunterladen. Dies mache ich öfter wenn zB ein Tutorial auch offline verfügbar sein soll oder ich die Gefahr wittere das es eines tages einfach verschwinden könnte.
Nun hatte ich einmal so ein Tutorial [1] das sich nicht herunterladen lies. Die Ursache war mir völlig unbekannt und man wget brachte mich auch nicht wirklich weiter bis ich in einer Dokumentation [2] auf -e robots=off stieß.
Ich schaute in die robots.txt auf der besagten Seite und stellte fest das dort folgendes eingetragen war:
User-agent: * Disallow: /
Die robots.txt ist eigentlich an Suchmaschinen gerichtet um anzuweisen das eine Seite nicht indexiert wird. In diesem Fall ist das natürlich völliger Unfug den Anleitungen im Internet sind selbstverständlich zum gefunden und gelesen zu werden. Da wget aber die robots.txt beachtet fühlt er sich angesprochen und lädt die besagten Dateien nicht herunter.
Die obige Anweisung wird also erweitert: wget-e robots=off -r -l2 [URL] und wget wird die robots.txt ignorieren und wie gewünscht alles herrunterladen.
Nachtrag:
möchte man das wget dauerhaft die robot.txt ignoriert kann man diese Option auch in die Konfigurationsdatei von wget schreiben. diese befindet sich im im home (~/.wgetrc). Falls nicht muss sie noch erstellt werden.
Stand: 13/03/2018 -> log
Achtung, dieser Artikel ist an erfahrene Benutzer gerichtet. Nichtbefolgen oder eigenmächtiges Handeln kann zum Verlust des Systems und/ oder Daten führen!
Oft höre und lese ich die Frage „Soll ich als root oder lieber mit sudo administrationsarbeiten durchführen?“ Genauso oft höre ich „Bei Ubuntu habe ich gar kein root-Passwort!„. Ich möchte in diesem Beitrag ganz kurz auf diese beiden Fragen eingehen. Also, der Benutzer root wird grundsätzlich nur mit login-passwort benötigt wenn der eigentliche Systemverwalter gar keinen Benutzeraccount auf diesem Computer/ System hat oder benötigt. Dies trifft z.B auf einer Serverfarm zu, da wäre es Unsinn wenn der root sich extra einen Benutzer anlegen müsste um irgend welche Veränderungen vorzunehmen.
Ist der Computer eine Arbeitsstation, wie sie jeder zuhause hat, an der ganz normal gearbeitet wird und jemand im Haushalt auch die Administration übernimmt, ist der Benutzer root absolut unnötig. Dies bedeutet nicht das man ihn nicht benötigt, sondern das man für diesen kein Passwort benötigt. Wieso das so ist? Ganz einfach …
Diejenigen die sowieso einen Benutzeraccount auf diesem Rechner besitzen, können jederzeit (falls sie ein sudoers sind, dazu gleich mehr) mit sudo einen Befehl mit root-rechten ausführen. Benötigt man wirklich einmal eine echte root-login shell hilft der Befehl sudo -i
Dieser startet ohne weitere Parameter eine root-login-shell! In der Datei /etc/sudoers befinden sich alle Benutzer die sudo einsetzen dürfen. Bearbeiten darf man diese Datei nur mit dem dafür speziel vorgesehenen Tool visudo, nur dann ist gewährleistet das die Datei syntaktisch einwandfrei ist. Hat man den neuen sudo-Zugang getestet und ist dieser einwanfrei kann man getrost in der Datei /etc/shadow das Passwort des Benutzers root herrauslöschen. Die Zeile könnte dann so aussehen:
root::17068:0:99999:7:::
Die Passwörter in dieser Datei sind übrigends verschlüsselt und das Passwort würde sich hinter dem ersten Doppelpunkt befinden. Will man ein Passwort wieder herstellen und den root-Zugang wieder zulassen hilft ein sudo passwd root … zack ist alles wieder beim alten.
So, das sollte ersteinmal gekärt sein, root ist also absolut unnötig. Ist root auf diese weise deaktiviert gibt es noch einen positiven Nebeneffekt: Für root benötigt man zwei Passwörter, einmal für den eigentlichen Benutzer und ein zweites mal für sudo -i. Vor alleim bei rootservern für die Wartung aus der Ferne ist es Gold wert.
Kleiner Tipp zum Schluss: Bei solchen Arbeiten am System, bei dem man sich bei einem kleinen Tippfehler selbst aussperren kann, IMMER eine zweite Konsole öffnen mit z.B STRG-ALT-F2! Bei Fernwartung entsprechend ein zweites mal per ssh einloggen im Hintergrund. DANN ERST LOSLEGEN!
Änderungslog des Beitrags:
Zurück zum Hauptseite Linux
Version: 28/05/2017 - zur Überarbeitung markiert
BEITRAG VERALTET! Eventuell ist er noch brauchbar falls Du einen RasPi 1 mit dem alten Betriebsystem verwendest. Download der alten Raspbian Images ist HIER möglich zum aktuellen Zeitpunk.
Hier nur eine schnelle beiläufige Information zum Betriebssystem Raspbian für den Raspberry Pi. Es betrifft die Standarteinstellung für den SSH Zugriff.
Seit Release des Raspbian Images von 25.11.2016 ist der SSH-Server standardmäßig deaktiviert. Offensichtlich aus Sicherheitsgründen. Wenn man nun wie ich die Pi’s lediglich Headless betreibt, war ich schon verwundert wieso ich auf einem neu installieren Gerät keine SSH Verbindung herstellen kann.
Also wie aktiviert man nun wieder den SSH-Server auf dem Raspberry Pi? Ganz einfach: Die neu installierte SD-Karte nochmal flott an einem anderen Rechner mounten und in der Bootpartition eine leere Textdatei mit dem Namen ssh erstellen.
Das war es auch schon, wichtig ist lediglich das die Datei exakt so heißt. Nach dem nächsten Bootvorgang ist der SSH-Server wieder ganz normal zu erreichen.
Die Standart Zugangsdaten lauten:
Username: pi Passwort: raspbian
Das Passwort sollte und muss man nach dem ersten Login mit passwd ändern! Unter Umständen je nach Internetzugang und Einstellungen des Routers ist der Pi auch von außerhalb erreichbar.
Zur Grundkonfiguration sollte man sich sudo raspi-config genauer anschauen, als erstes sollte man dann die Speicherkarte expandieren.
Änderungslog:
