[Help me] Einfaches Bashskript - Java8 oracle Installation

[AptGetConfused]

Guten Tag,

ich mache gerade meine ersten Schritte mit Shellskripts und habe mir vorgenommen ein Bash-Script zu erstellen, welches bei der Ausführung Java8 PPA hinzufügt und anschliessend Java8 Oracle installiert.
Dazu habe ich in verschiedenen unix/linux-Foren und auch hier in den Foren rechechiert, aber brauche wohl noch etwas zusätzliche Starthilfe.

Das Script habe ich ganz primitiv erstellt, nämlich so, wie ich Java8 Oracle im Terminal installieren würde.
Bei der Ausführung kommt jedoch immer die Fehlermeldung:

root@debscript:~# bash /root/Dokumente/Java8oracle_install.sh
/etc/apt/sources.list.d/java-8-debian.list: Datei oder Verzeichnis nicht gefunden

Die Datei java-8-debian.list wird zwar in der 2. Zeile erstellt und existiert im Verzeichnis /etc/apt/sources.list.d/, jedoch findet es bei Zeile 3 die Datei nicht.
Was für Alternativen könnt ihr mir da empfehlen? Oder würdet ihr das Skript generell ganz anders gestalten?


Hier das Bashscript

#!/bin/bash
touch /etc/apt/sources.list.d/Java-8-debian.list
ed /etc/apt/sources.list.d/java-8-debian.list >>EOF
/^$/
deb http://ppa.launchpad.net/webupd8team/java/ubuntu trusty main
/^$/
deb-src http://ppa.launchpad.net/webupd8team/java/ubuntu trusty main
wq
EOF
cd
apt-key adv --keyserver keyserver.ubuntu.com --recv-keys EEA14886
apt-get update
apt-get install oracle-java8-installer
apt-get install oracle-java8-set-default
reboot

Vorweg danke für alle konstruktiven Antworten

[RobertDebiannutzer]

touch /etc/apt/sources.list.d/Java-8-debian.list
ed /etc/apt/sources.list.d/java-8-debian.list >>EOF

Flüchtigkeitsfehler: Einmal "Java", einmal "java".

[DeletedUserReAsG]

Konstruktive Antwort … schwierig. Am ehesten noch: nein, es ist keine gute Idee, dir zu helfen, dir dein System automatisiert zu schrotten.

Aber wenn’s unbedingt sein muss: du hast einmal J groß, einmal klein geschrieben. Bitte sieh dann von „Hilfe, ich hab mir automatisiert mein System geschrottet!!k“-Threads ab. Dank im Voraus.

[RobertDebiannutzer]

s. dazu auch https://wiki.debian.org/DontBreakDebian (z.B. unter "FrankenDebian")

[AptGetConfused]

Konstruktive Antwort … schwierig. Am ehesten noch: nein, es ist keine gute Idee, dir zu helfen, dir dein System automatisiert zu schrotten.

Bitte sieh dann von „Hilfe, ich hab mir automatisiert mein System geschrottet!!k“-Threads ab. Dank im Voraus.

Ach, mach dir da nur mal keine Sorgen, habe mir einen virtuellen Debian9 Testserver erstellt, wenn ich es geschafft habe den zu schrotten, lösche ich ihn einfach und fange nochmal mit der nächsten vm an

Aber wenn’s unbedingt sein muss: du hast einmal J groß, einmal klein geschrieben.

Dankeschön, muss mich erstmal an das 8,5h-vor-dem-Bildschirm-sitzen gewöhnen, habe mit meiner Informatiker-Ausbildung erst begonnen, deine Augen haben wohl das grössere Durchhaltevermögen.

[AptGetConfused]

Die Datei wird immernoch nicht gefunden, ist auch logisch, da die Datei mit der Bezeichnung java-8-debian.list. erstellt wird, also mit einem . am Ende, aber das habe ich beim ed Befehl ja nicht angegeben:

ed /etc/apt/sources.list.d/java-8-debian.list >>EOF

https://www.bilder-upload.eu/bild-0c130 ... 5.png.html

Womit hat das zu tun?

[tobo]

Womit hat das zu tun?

Jetzt mal von Schreibweisen abgesehen - ed will eine Eingabe (<< Here document) für das Skript haben und nicht ausgeben (>>) und ed-syntaxtechnisch sollte man das vielleicht auch erstmal überprüfen!? Hast du denn deine Befehle überhaupt mal innerhalb von ed getestet?

Code: Alles auswählen

...
ed -s /etc/apt/sources.list.d/java-8-debian.list <<EOF
a
deb http://ppa.launchpad.net/webupd8team/java/ubuntu trusty main
deb-src http://ppa.launchpad.net/webupd8team/java/ubuntu trusty main
.
w
EOF
...

[owl102]

Ich verstehe nicht, wieso das mit touch + ed gemacht wird. Warum nicht so:

Code: Alles auswählen

cat > /etc/apt/sources.list.d/java-8-debian.list <<EOF
deb http://ppa.launchpad.net/webupd8team/java/ubuntu trusty main
deb-src http://ppa.launchpad.net/webupd8team/java/ubuntu trusty main
EOF

oder

Code: Alles auswählen

printf "%s\n" "deb http://ppa.launchpad.net/webupd8team/java/ubuntu trusty main" "deb-src http://ppa.launchpad.net/webupd8team/java/ubuntu trusty main" >/etc/apt/sources.list.d/java-8-debian.list

[heisenberg]

Das hier wäre auch noch hilfreich:

Code: Alles auswählen

export DEBIAN_FRONTEND=noninteractive	# Keine Fragen von Installationsscripten der Pakete!

apt-get install -y java-irgendwas  # Schalter -y für die Bestätigung der Installation an sich

[heisenberg]

Habe erst gar nicht gerafft, warum hier schon wieder gemeckert wird - bis ich das PPA gesehen habe.

Ich würde mal vermuten, dass die Zeiten, in denen man eine oracle-jre braucht sind doch eigentlich vorbei, oder? openjdk entwickelt sich doch mehr und mehr zum de-facto standard...

[willy4711]

Wenn man es denn unbedingt haben will:
Quelle: http://www.webupd8.org/2015/02/install- ... linux.html

Code: Alles auswählen

#!/bin/bash

echo "deb http://ppa.launchpad.net/webupd8team/java/ubuntu xenial main" | tee /home/willy/webupd8team-java.list
echo "deb-src http://ppa.launchpad.net/webupd8team/java/ubuntu xenial main" | tee -a /home/willy/webupd8team-java.list
pkexec tilix -x "cp /home/willy/webupd8team-java.list /etc/apt/sources.list.d"
pkexec tilix -x apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv-keys EEA14886
pkexec tilix -x apt-get update
pkexec tilix -x apt-get install oracle-java8-installer

Exit

Der Grund, warum ich die webupd8team-java.list erst im /home kreiere, ist der, dass ich es noch nicht geschafft habe,
nach dem Aufruf von tilix mit pkexec, mehrere Befehle hintereinander auszuführen.

Geht natürlich auch mit sudo oder sonst was, hab ich halt bloß nicht mehr.

Und ich hab kein Bock auf Passwörter

Getestet in einer VM

Ist als User auszuführen mit einer Policy oder halt für jedes andere Terminal:

Code: Alles auswählen

~$ cat /usr/share/polkit-1/actions/org.freedesktop.policykit.tilix.policy
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE policyconfig PUBLIC
 "-//freedesktop//DTD PolicyKit Policy Configuration 1.0//EN"
 "http://www.freedesktop.org/standards/PolicyKit/1/policyconfig.dtd">
<policyconfig>
    <action id="org.freedesktop.policykit.pkexec.tilix">
    <description>Run tilix program</description>
    <message>Authentication is required to run tilix</message>
    <icon_name>accessories-text-editor</icon_name>
    <defaults>
        <allow_any>auth_admin</allow_any>
        <allow_inactive>auth_admin</allow_inactive>
        <allow_active>yes</allow_active>
    </defaults>
    <annotate key="org.freedesktop.policykit.exec.path">/usr/bin/tilix</annotate>
    <annotate key="org.freedesktop.policykit.exec.allow_gui">true</annotate>
    </action>

Code: Alles auswählen

# update-alternatives --config java
Es gibt 3 Auswahlmöglichkeiten für die Alternative java (welche /usr/bin/java bereitstellen).

  Auswahl      Pfad                                         Priorität Status
------------------------------------------------------------
  0            /usr/lib/jvm/java-11-openjdk-amd64/bin/java   1111      automatischer Modus
  1            /usr/lib/jvm/java-10-openjdk-amd64/bin/java   1101      manueller Modus
  2            /usr/lib/jvm/java-11-openjdk-amd64/bin/java   1111      manueller Modus
* 3            /usr/lib/jvm/java-8-oracle/jre/bin/java       1081      manueller Modus

Drücken Sie die Eingabetaste, um die aktuelle Wahl[*] beizubehalten,

[DeletedUserReAsG]

OT, sorry:
… das bedeutet also, dass jeder, der irgendwie Userrechte auf deinem System erlangt, ohne weitere Umstände ein Rootterminal hochreißen kann?

[willy4711]

Jeder =ich (für ein Mehrbenutzer- System weniger geeignet)
und auch nur tilix
So mach ich seit über einem Jahr mein tägliches dist-upgrade.
Klick und gut, wenn's grad passt.
Die Option keep bei sudo oder auch in einer Policy finde ich auch nicht viel besser.
z.B

Code: Alles auswählen

auth_admin_keep

Da kann sich auch jeder für bestimmte Zeit einklinken.

[DeletedUserReAsG]

Wollt’s ja nur mal erfragt haben, ich nutze pkexec bislang nicht. Also jeder, der sich deinem System gegenüber als du ausgeben kann (mithin auch Schadscripte, die etwa über ’ne Lücke im Browser Code lokal ausführen können), kann also eine tilix-Instanz mit Rootrechten hochreißen und beliebige Befehle mitgeben?

Bei ’nem richtig für Updates konfigurierten sudo könnte der Angreifer (oder das Schadscript) dann ’ne Zeit lang ohne Rückfrage Updates fahren. Halte ich für weniger bedenklich, als ein Terminal mit beliebigen Befehlen starten zu können.

[willy4711]

Bei ’nem richtig für Updates konfigurierten sudo könnte der Angreifer (oder das Schadscript) dann ’ne Zeit lang ohne Rückfrage Updates fahren. Halte ich für weniger bedenklich, als ein Terminal mit beliebigen Befehlen starten zu können.

Wenn du in der obigen policy die Zeile

Code: Alles auswählen

<allow_active>yes</allow_active>

in

Code: Alles auswählen

<allow_active>auth_admin_keep</allow_active>

änderst, verhält es sich so , wie bei sudo ---> also ca. 5 MIn.

Dann wird das Root-PW einmal vor beginn der Ausführung abgefragt.

Siehe:
https://www.freedesktop.org/software/po ... kit.8.html

[DeletedUserReAsG]

Genausogut kannst du bei sudo unterbinden, dass die Rechte gehalten werden. Aber mir ging’s nicht um sudo vs. pkexec, sondern um ’ne möglicherweise unsichere Konfiguration, die du gepostet hast. Ich seh’ schon, ich werd’s selbst anschauen müssen, wenn ich auf meine Fragen ’ne konkrete Antwort will.

[willy4711]

sondern um ’ne möglicherweise unsichere Konfiguration, die du gepostet hast. Ich seh’ schon, ich werd’s selbst anschauen müssen, wenn ich auf meine Fragen ’ne konkrete Antwort will.

Habe aber extra darauf hingewiesen.
Und ja, wenn man eine Policy erstellt., sollte man sich sowieso vorher mal mit der Gebrauchsanweisung wenigstens halbwegs vertraut machen.
Ich rufe z.B. aus Thunar ebenfalls mit Root- Rechten Mousepad, Nano und Thunar selbst auf.
Da ist aber jedes mal das Root-PW ohne keep fällig also so:

Code: Alles auswählen

<allow_active>auth_admin</allow_active>

und:

Code: Alles auswählen

$ cat /etc/sudoers
cat: /etc/sudoers: Datei oder Verzeichnis nicht gefunden

[DeletedUserReAsG]

… dann muss der User also bei deinem Script viermal hintereinander das Root-PW eintippseln? Erscheint mir nicht sehr sinnvoll. Warum nicht ein Script schreiben, das den Job tut, und das dann einmal direkt als Root aufrufen (ob nun via sudo oder pkexec wäre dann auch nur Geschmackssache – du kannst sudo genauso confen, das Root-PW bei jedem Einsatz neu abzufragen und du kannst es ebenfalls so confen, dass nur exakt der eine Job damit ausgeführt werden kann)? Dann kann man sich auch den Umweg über das ~ des Users sparen.

Disclaimer: ich halt’s trotzdem weiterhin für ’ne bescheuerte Idee, sich a) auf diese Weise Fremdquellen ins System zu schreiben, die b) nicht mal für das betreffende System gedacht sind, und c) von ’ner nicht gerade vertrauenswürdigen Stelle stammen.

[willy4711]

dann muss der User also bei deinem Script viermal hintereinander das Root-PW eintippseln?

Nein - Wenn du in der Poilicy die Zeile so schreibst:

Code: Alles auswählen

<allow_active>auth_admin_keep</allow_active>

Muss er sie das Root- PW nur einmal am Anfang eingeben.

[DeletedUserReAsG]

… womit sich das Ganze im Kreis dreht. Einmal aufgerufen, kann also doch jeder Angreifer ein Terminal mit vollen Rootrechten ohne weitere Rückfrage starten. Es sei denn, man schreibt in die Regel, dass das nicht geht, dann aber muss der User viermal hintereinander das Passwort eingeben; es sei denn, man schreibt ›keep‹ in die Regel, dann kann jeder Angreifer anschließend ein Terminal mit vollen Rootrechten ohne Rückfrage starten, es sei denn […]. *sigh*

Edit:
Disclaimer: ich halt’s trotzdem weiterhin für ’ne bescheuerte Idee, sich a) auf diese Weise Fremdquellen ins System zu schreiben, die b) nicht mal für das betreffende System gedacht sind, und c) von ’ner nicht gerade vertrauenswürdigen Stelle stammen.

[willy4711]

dann kann jeder Angreifer anschließend ein Terminal mit vollen Rootrechten ohne Rückfrage starten, es sei denn […]. *sigh*

Er könnte nur tilix als Root starten. Für alles andere hat er keine Berechtigung, und wahrscheinlich würde man das auch sehen.

Im Gegensatz zu sudo wo die Berechtigung für eine bestimmte Zeit generell gilt (soweit mir bekannt).

Und gut- Ein Skript mit Root- Rechten aus dem Terminal ist die andre Lösung.

[DeletedUserReAsG]

… und tilix ist, der Beschreibung nach, ein Terminalemulator. Der startet üblicherweise ’ne Shell mit den Rechten des Aufrufers. In diesem Fall ’ne Rootshell. Darüber hinaus kann man beliebige auszuführende Befehle mitgeben, die dann mit UID 0 ausgeführt werden. Du erkennst, was ich meine?

Edit:

Im Gegensatz zu sudo wo die Berechtigung für eine bestimmte Zeit generell gilt (soweit mir bekannt).

Du kannst sudo genau so konfigurieren, wie’s eigentlich gedacht war: einem bestimmten User (nicht für jedem, der zufällig gerade eingeloggt ist) die Ausführung eines bestimmten Befehls (incl. genauer Optionen, man kann den exakten String festlegen) unter einer bestimmten UID (muss nicht Root sein) im Gegenzug für’s Passwort (das des Zielusers, oder das Eigene – nach Belieben) einmalig (oder ’ne bestimmte Zeit lang) zu ermöglichen.
Bei mir, zum Beispiel, kann der User, unter dem ich normalerweise arbeite, nur genau das System updaten, nachdem er’s Rootpasswort eingegeben hat. Mehr nicht. Keine Pakete deinstallieren, keine Quellen bearbeiten, … – nix, außer dem Update.
Zur Illustration:

Code: Alles auswählen

niemand@xeon /home/niemand % sudo ls                                                                                                                                             :(
[sudo] Passwort für niemand: 
Leider darf der Benutzer niemand »/usr/bin/ls« als root auf xeon nicht ausführen.

[willy4711]

Du erkennst, was ich meine?

Ja - aber ich glaube kaum, dass man ein zweites Terminal übersehen würde. der kann man Tilx auch "hidden" starten ?
und - habe es gerade mit meinem Update-Skript getestet:
Das keep funktioniert nur innerhalb des Skriptes. mit der Zeile

Code: Alles auswählen

<allow_active>auth_admin_keep</allow_active>

Ein zweites Mal aufgerufen (nach ca 30 Sekunden) , wird wieder Root-PW abgefragt.
Die Unsicherheit scheint also nur während der Ausführung eines Skriptes vorhanden.

Edit:
aus:https://wiki.debianforum.de/Sudo

Ein Problem der Debian-Sudo-Konfiguration ist, dass ein normaler Benutzer mit seinem Benutzerkennwort Rootberechtigungen erlangen kann und dass diese Anmeldung per Standardeinstellungen, 15 Minuten aktiv ist.

Mit sudo kann man also innerhalb dieses Zeitraums alles machen, es sei denn, man schreibt eine endlos lange /etc/sodoers, in der
alles geregelt ist. Für Mehrbenutzer System sicherlich sinnvoll.
Was mich aber dazu bringt mal zu testen, wie es sich verhält, wenn mein Update- Skript läuft und ich versuche via pkexec ein zweites tilix- Terminal zu öffnen. Aber dazu muss erstmal genug zum Updaten sein.

Aber insgesamt: ich halt’s trotzdem weiterhin für ’ne bescheuerte Idee, sich a) auf diese Weise Fremdquellen ins System zu schreiben, die b) nicht mal für das betreffende System gedacht sind, und c) von ’ner nicht gerade vertrauenswürdigen Stelle stammen.

Wohl war darum habe ich es ja auch in einer VM gemacht.

[DeletedUserReAsG]

Ja - aber ich glaube kaum das man ein zweites Terminal übersehen würde. der kann man Tilx auch "hidden" starten ?

Weiß ich nicht – nutze ich nicht. Steht sicher in dessen Manpage. Möglicherweise kann man’s auch aus sich selbst heraus minimieren, und bei entsprechend schneller Hardware ist die Ausführung sowieso nur als kurzes Flackern auf dem Bildschirm erkennbar.

Die Unsicherheit scheint also nur während der Ausführung eines Skriptes vorhanden.

Da wäre die Frage, wie du’s gestartet hast. Klick auf ’nen Starter? Oder aus der gleichen Shell heraus, aus der du’s zuvor auch gestartet hast?

Aber letztlich ist’s auch egal: ich halte den Weg, aus ’nem Script heraus viermal separat ’nen Terminalemulator als Root hochzureißen, nur um je einen Task zu erledigen, für nicht sinnvoll. Sudo hin, pkexec her. Sinnvoller wär’s, das Script selbst einmal mit den betreffenden Rechten und ohne überhaupt ’nen Terminalemulator samt Rootshell drumherum zu starten, wobei die Config, ob nun sudo oder pkexec oder wasauchimmer, eine Regel für genau dieses Script enthält, und das Script selbst nur für Root schreibbar, und idealerweise noch immutable ist.

Aber insgesamt: ich halt’s trotzdem weiterhin für ’ne bescheuerte Idee, sich a) auf diese Weise Fremdquellen ins System zu schreiben, die b) nicht mal für das betreffende System gedacht sind, und c) von ’ner nicht gerade vertrauenswürdigen Stelle stammen.

[willy4711]

Da wäre die Frage, wie du’s gestartet hast. Klick auf ’nen Starter? Oder aus der gleichen Shell heraus, aus der du’s zuvor auch gestartet hast?

Mein update-Skript, was genauso aufgebaut ist, starte ich natürlich mit einem Starter- sonst wär's ja nicht komfortabel .
Das obige Skript hatte ich aus der Shell gestartet. Soviel Arbeit hab ich da nun nicht rein gelegt.