Titel geändert: Wie installiere ich Programme in der Konsole mit Rootrechten

Da Alero den Titel seines Beitrages geändert hat, wurde hier der Titel auf Wunsch von Berichtigung auch geändert.
Am Beitrag selbst wurde nichts verändert.

Aleros Beitrag: Wie werde ich Root in einer Konsole ....

Dies ist nun eine kurze Erklärung, wie man mit zypper in einer Konsole als Root Pakete installiert.
(Sauerland)

Alero hat letztlich nur geschrieben, wie man in einer Console root wird.

Ein zypper in meinprogramm ist auch etwas irreführend.

Programme werden in Repositiories als Pakete angeboten.
Diese Pakete sind letztlich nur komprimierte Archive, die ein Rezept für die Installation des Programmes meinprogramm enthalten, alle dafür benötigten Dateien und evtl. Scripte, die vor und nach der Installation auszuführen sind. Manchmal sind noch Lokalisierungen dabei, oft auch Libs.
Diese Pakete haben traditionell die Endung .rpm (RedhatPackageManager )

In der obigen Form holt sich zypper das Paket aus einem Repo, wenn es denn in einem Repo, das in der Konfiguration von zypper aufgelistet ist, gefunden werden kann.

Man kann sich aber auch ein solches RPM Paketchen herunterladen und mit
zypper in /Pfad/zu/dem/programm.rpm installieren.

Es gibt diverse Arten von ausführbaren Programmen. Das kann ein Perl oder Pythonscript sein, ein Shellscript, ein Java- Jar (JavaARchive) oder ein binäres Programm.
(Es gibt noch viel mehr solche Interpretersprachen.)

Ein binäres Programm ist selbst lauffähig ohne auf irgendwelche Interpreter angewiesen zu sein. Solche binären Programme sind bereits fertig für die eigene Rechnerarchitektur compiliert.
Meist aus C oder C++ Quellcode, neuerdings auch Go oder Rust.
Diese Programme gibt es dann auch als .srpm ( ein SourceRPM). Statt eines fertig kompilierten Programmes enthalten die also die Quellen, die dann natürlich auf dem Installationssystem compiliert werden müssen.
Auch solche Pakete kann man sich mit zypper aus einem Repo installieren, oder aus einem heruntergeladen .srpm mit entsprechender Pfadangabe.
zypper si oder zypper source-install
(Viele zypper Befehle gibt es in Kurzform und in Langform in == install . Einfach zypper<leerzeichen><tab><tab> tippen )

Will man sich sein System häufiger durch heruntergeladene Pakete, die in Repos nicht angeboten werden, versauen,
so empfiehlt es sich, sich irgendwo ein Verzeichnis anzulegen und alle RPMs dorthin herunterzuladen.

Dann fügt man bei zypper Repository Verwaltung ein eigenes Repo hinzu und wählt den Repotyp Datei/Verzeichnis und gibt eben dieses Downloadverzeichnis dabei an.
Ab hier kann man dann einfach ohne Pfad seine RPMs installieren.
Und falls man neuere Versionen ebenfalls dorthin heruntergeladen hat, auch updaten.

Hat man genug von einem Programm, einfach mit
zypper rm programmname löschen.

Das ist wohl eher Geschmackssache.
Ich selbst installiere sogar komplett andere Sprachen nach, damit ich eben Auswahl habe.
Hat schon manchen verblüfft, wenn mein Rechner plötzlich alles Griechisch darstellte und sogar die Tastatur dazu sauber funktionierte.
(Falls man nicht auf die Tasten gucken muss, um fehlerfrei zu tippen).
Bei den heutigen Kapazitäten ist mir das schnuppe, ob 10 oder 100 Sprachen drauf sind.

Weil es Unterschied macht, ob ich ein Paket installiere, das aus einem Repo stammt?
Oder ein lokal vorliegendes RMP?
Bei der Installation via Repo muss ich keinen Dateinamen (meinprogram.rpm) angeben, sondern einen Paketnamen.
Und ein Paketname kann ziemlich stark von einem Programmnamen abweichen.
Denk mal an Python Programme.
Bei der Installation eines lokalen RPMs muss ich einen Pfadnamen angeben. Nicht einen Paketnamen.

Erkennst du langsam die Tatsachen und die Feinheiten?
Merkst du langsam, dass die Ergänzung sehr wohl nötig ist?

Wenn es dir genügt, dass zypper oft erklärt wurde, und es dazu eine Manpage gibt, dann ist das schön für dich.
Warum schreibst du dann hier?
Alero ging es darum Anfängern die Installation von Programmen in der Konsole zu erklären.
Das hat er nicht getan. Über das su kam er kaum hinaus.
Zumindest diese zwei völlig unterschiedliche Methoden hätte er wohl wenigstens klären sollen.

Ich halte -da ich quasi altgedienter openSUSE User bin- den Gebrauch von sudo bei openSUSE (und den meisten anderen rp,-Distris auch) für falsch.
sudo (SubstituteUserAndDO) setzt eine saubere Konfiguration EINZELNER Befehle samt ihren Optionen und Argumenten in der Datei sudoers voraus.
Er dient dazu gedacht Nichtrootusern für eben genau definierte Befehle, die mehr Rechte brauchen, ausführen zu lassen, ohne dass sie das Rootspasswort kennen müssten.
Sehr begrenzte und genau definierte Rootrechte.

su [someUser] (SubstituteUser) tut etwas anderes: Es ersetzt den GESAMTEN Prozesskontext.
In einer Shell wird damit eine weitere Shell gestartet, die aber KOMPLETT unter einem anderen User läuft. So als hätte man sich als dieser User angemeldet.
(Gebe ich keinen someUser an, so ist root der Default)
Und das Auswirkungen. Einige wichtige Variablen werden bei su root geändert, bei sudo nicht.

Sauerland machte mich neulich darauf aufmerksam, dass wohl seit Leap wenigstens die PATH Variable mit sudo auch geändert wird.
Ich persönlich halte das für eine schlechte Angleichung an das schlechte Ubuntuvorbild.
However. Man mag das auch für eine Erleichterung halten. Für Leute, die oberflächlich im Netz lesen und dann blind nachtippen, pardon abkopieren.

Vielleicht magst du ja künftig wenigstens meine Beiträge genauer lesen.

Wenn der auszuführende Befehl in der sudoers korrekt definiert ist, nein.
Man kann aber auch nach dem Spasswort prompten lassen.

Es wird sogar zwischen rootpw targetpw und runaspw

Lies einfach mal man 5 sudoers

Eine so pauschale Antwort ist nicht möglich.
Dazu kann man damit viel zu viel Sicherheitsszenarien abdecken und es halt deshalb auch so verschieden konfigurieren.
Letztlich ist es ein PAM Plugin, das sogar via LDAP gesteuert werden kann.
(Und wenn es in realiter eingesetzt wird, werden alle Useraccounts aller Rechner eh via LDAP verwaltet und oft sitzt davor sogar Kerberos; womit wir aber endgültig in einer anderen Liga wären)
Die meisten verwenden es - durch die üble Ubuntuverwendung- eh nur als ein su -c Ersatz.
Gibt man su -c irgendeinCommand --irgendwelche-Optionen irgendwelcheArgs an, so hat man die korrekte Entsprechung zu dem üblen sudo Gebrauch.
Das Kommando wird ausgeführt und man landet wieder im Originalkontext, also meist ordinärer User.

Ich weiß nicht, was du so alles bemerkst, oder nicht bemerkst.
Magst nicht doch einfach meine Posts -wie schon empfohlen- genauer lesen?
Würde uns beiden doch einiges ersparen, oder?