Anfängerfragen - Linux Neuling? Hier ist der richtige Platz für deine Fragen (2)

[ClisClis]

Moinmoin..
Auch mal ne philosophische Frage..

Bin jetzt schon seit einer Weile mit Debian basierten Systemen unterwegs (also Privat jetzt, nichts wildes).
Ich komme damit eigentlich ziemlich gut klar (Bin kein Linux crack oder sowas, aber beherresche die gängigen Befehle, weiss in etwa was wo ist oder wie ich mir helfen kann).

Mein Desktop läuft mit Mint debian edition und dann stehen zwei "server". Einer ist vorallem im internen Netz für die Dateifreigabe zuständig, da läuft ein Debian 8 mit ein paar Anpassungen. Keine Probleme.

Der Zweite geht auch zum Internet. Da läuft Minecraft, subsonic, teamspeak, owncloud (mit apache natürlich) und noch ein paar andere kleinigkeiten. OS ist hier Crunchbang (basierend Debian Wheezy)

Das läuft auch alles super stabil.
Ich habe Debian gewählt, nachdem ich am Anfang zig Distributionen durch hatte und irgendwie nie etwas klappen wollte ausser bei Debian. Da gingen schon mal geschätzt 20% von dem was ich wollte. Man muss ja klein anfangen.


Was mich aber aufregt: Die alten Pakete. Apache ist irgendwie 2.2, PHP bei 5.2 oder sowas..
Ich bin gerne jemand, der was neueres hat. Will aber auch nicht jede Version selber kompilieren.
apt-get update /upgradeund gut ist, so sollte es sein.

Gestern wollte ich z.B auf PHP7 wegen der Performance allein. Zumal 5.2 wirklich outdated ist.
Für Debian 8 scheint das schon zu gehen mit anderen Repos. Auf deb7 habe ich das aber echt nicht hingekriegt, auch wenn Anleitungen sagen es geht. Repos hinzugefügt, aber Paket nicht gefunden.


Wenn man jetzt eine Distro mit dem Prinzip wie Arch einsetzt, da müsste ich doch immer gleich auf die neuesten Pakete kommen, oder?
Bin jemand der gerne alles aktuell hat. Ist ja kein enterprise environment..

 

[Cyrrel]

Hi, Ubuntu basiert auf Debian, ist von der Verwendung also schon mal recht ähnlich. Hat aber neuere Pakete in den repos. Wäre evtl. Auch tatsächlich eine Alternative.
Habe es inzwischen auf meinem vserver in Verwendung (aus deinen genannten Gründen) und das ist auch schon echt okay

 

[fax668]

Ja, mit Arch Linux bist du meistens sehr nah dran an den aktuellen Versionen. Du solltest dann aber mindestens einmal in der Woche ein Update machen, besser noch öfter, sonst wirst du von der Menge an neuen Versionen erschlagen.

 

[oooverclocker]

Wenn man jetzt eine Distro mit dem Prinzip wie Arch einsetzt, da müsste ich doch immer gleich auf die neuesten Pakete kommen, oder?

Ja - und genau darin liegt auch ein Problem. Die kleinste Änderung kann dazu führen, dass abhängige Pakete plötzlich nicht mehr funktionieren. Das bedeutet, dass im Extremfall der ganze Server funktionsunfähig wird. Debian Stable ist auf absolute Stabilität ausgelegt und beinhaltet deshalb auch steinalte Pakete, die ewig getestet wurden. Statt Ubuntu könnte man zum Beispiel auch Debian Testing nehmen, aber meiner Ansicht nach ist das Konzept von Debian stable noch immer für Server am besten geeignet - solange man nur Pakete aus den Repos benutzt!
Für den Desktop kann man Debian dafür eigentlich aus mehreren Gründen in die Tonne kloppen. Da reicht schon ein Drittanbieterpaket aus dem Internet und man darf so viele libs manuell nachladen, dass man es auch lassen kann... Oder ein anderes Beispiel: In Eclipse hat man auf Debian eigentlich immer nur ein veraltetes JDK aus den Repos. Dafür muss man zum Beispiel in Ubuntu/Arch vielleicht auch mal damit leben, dass das eine oder andere Programm/exotischer Treiber plötzlich einen Bug hat, der vorher nicht da war und erst in der nächsten Version wieder verschwindet.

 

[ClisClis]

Ja, schon klar.
Nur wird zum beispiel die PHP version, die man unter Debian per default hat, von Owncloud nicht mehr unterstützt/als unsicher abgestempelt.
Neuere Versionen von Owncloud lassen sich aufgrund veralteter PHP und Apache Version nicht mehr installieren.

Auch nicht gut..

- - - Updated - - -

Hi, Ubuntu basiert auf Debian, ist von der Verwendung also schon mal recht ähnlich. Hat aber neuere Pakete in den repos. Wäre evtl. Auch tatsächlich eine Alternative.
Habe es inzwischen auf meinem vserver in Verwendung (aus deinen genannten Gründen) und das ist auch schon echt okay

Irgendwie wollte mir ubuntu nicht so recht gefallen. Aber hat schon auch die vorteile, ja

Ja, mit Arch Linux bist du meistens sehr nah dran an den aktuellen Versionen. Du solltest dann aber mindestens einmal in der Woche ein Update machen, besser noch öfter, sonst wirst du von der Menge an neuen Versionen erschlagen.

Server admins werden hier sicher die Hände verwerfen, aber ich habe meinen owncloud server einfach mit nem update befehl via cron automatisch aktualisiert.

Klar, das kann dazu führen, dass mal was nicht mehr läuft, dafür ist man eben aktueller (und manchmal auch sicherer [oder auch wieder nicht]).
Bei mir ist die verfügbarkeit nicht soo kritisch, deshalb läuft das auch zu haus. Aber es ist eben auch Hobbyprojekt und daher probiere ich gerne neues aus.

 

[fax668]

Mit snap-pac kannst du automatisch einen Snapshot sichern bevor Pakete aktualisiert werden: https://wiki.archlinux.org/index.php/Snapper#Wrapping_pacman_transactions_in_snapshots. Aber einen aktuellen Boot/Rescue Stick sollte man schon bereit halten, weil es auch passieren kann, dass nach einem Update die Maschine gar nicht mehr hochfährt.

 

[ClisClis]

Bei Arch so schlimm?
Hatte jetzt den server 2.5 Jahre so in Betrieb. Täglich geupdated, einmal musste ich ihn neu starten, weil die Netzwerkverbindung tot war..

 

[fax668]

Ich habe alle paar Monate Probleme mit den NVidia Treibern, LVM/mdraid hat es mir mal zerschossen und die systemd Umstellung war seinerzeit ziemlich holperig. Früher hatte ich auch eine Bezahlversion von VMware drauf laufen, das habe ich irgendwann dann in die Tonne getreten und durch VirtualBox ersetzt, weil's bei jedem Kernelupdate Ärger gab. Das kann man Arch Linux jetzt aber nicht wirklich vorwerfen, für so kernelnahe Software von extern ist das halt nicht die richtige Distribution. Generell finde ich aber schon, dass Arch Linux eher etwas ist für Leute, die sich lieber mit dem Betriebssystem als mit der Anwendung desselben beschäftigen. Deshalb bin ich nach fünfzehn Jahren wieder bei meinen Anfängen angekommen, nämlich Debian.

 

[oooverclocker]

Ja, schon klar.
Nur wird zum beispiel die PHP version, die man unter Debian per default hat, von Owncloud nicht mehr unterstützt/als unsicher abgestempelt.
Neuere Versionen von Owncloud lassen sich aufgrund veralteter PHP und Apache Version nicht mehr installieren.

Auch nicht gut..

Wenn das Konzept Debian so funktioniert, wie es gedacht ist, hast Du zwar auf dem Papier alte Versionen, aber mit rausgepatchten Sicherheitslöchern. Aber das, was Du beschreibst, ist eben das Manko. Genau in so einem Fall muss man zwangsläufig eine Stufe in der Stabilität zurückschrauben - ich würde das in etwa so sehen:
[Stabilität] Debian Stable - Debian Testing - Ubuntu - Arch [Aktualität]
Demnach würde ich persönlich erst Debian Testing in einem solchen Fall präferieren.

 

[Fischje]

haha. ich kenn Linux bisher überwiegend von meinen serversystemen her. dort mit Debian erste Erfahrungen begonnen, später kam ubuntu dazu.

jetzt habe ich mir doch überlegt ubuntu als zweitsystem auf meinem spielerechner eine Chance zu geben. dazu wollte ich xubuntu direkt nehmen, wegen den tollen xfce Desktops die ich oft gesehen habe. andere uibuntu-Derivate könntne mir aber auch gefallen.

versucht zu installieren, bei der Installation schon einen fehler bekommen, das was nicht gefunden wurde. ich probiere heute abend nochmal und poste dann auch die Meldung. aber einfach ist irgendwie doch was anderes....

 

[ClisClis]

Deshalb geniesst Linux im Desktop environment ja auch immer noch ein Nieschedasein...

Du findest zu jedem Vorhaben tutorials (ich ja auch zu meinem PHP7 update). Kannst alles genau so copy&pasten.
Aber am Ende gehts dann doch nicht..

 

[oooverclocker]

dazu wollte ich xubuntu direkt nehmen, wegen den tollen xfce Desktops die ich oft gesehen habe. [...] versucht zu installieren, bei der Installation schon einen fehler bekommen, das was nicht gefunden wurde. [...] aber einfach ist irgendwie doch was anderes....

Also zu den Startmedien von Kubuntu, Xubuntu, Edubuntu etc. kann ich leider nicht viel sagen. Zur Installation benutze ich entweder ein originales Ubuntu Minimal- ISO oder die normale Version mit 1,4GB. Und tatsächlich hing es in der Vergangenheit auch bei Ubuntu manchmal an der Installation - allerdings geht mittlerweile alles flüssig, vielleicht haben die anderen Images da noch etwas nachzuholen.
Hat man Ubuntu mal installiert, kann man ziemlich beliebig die Desktops installieren:

sudo apt-get update
sudo apt-get install ubuntu-desktop ubuntu-gnome-desktop xubuntu-desktop lubuntu-desktop kubuntu-desktop cinnamon ubuntu-mate-desktop

Natürlich bietet sich das Minimal- ISO besonders an, wenn man den Desktop dann erst später auswählt, damit sich nichts in die Quere kommt.

https://wiki.ubuntuusers.de/GNOME_Installation/
https://wiki.ubuntuusers.de/Xfce_Installation/
https://wiki.ubuntuusers.de/LXDE_Installation/
https://wiki.ubuntuusers.de/KDE_Installation/
https://wiki.ubuntuusers.de/Cinnamon/
https://wiki.ubuntuusers.de/MATE/

Edit: Man sollte jetzt den Codeblock oben bitte nicht so verstehen, dass man wirklich alles auf einen Schlag installiert, sondern nur einzeln Desktops auswählen, die man testen möchte.

Edit2: Habe das gerade getestet. kubuntu-desktop scheint komplett inkompatibel mit dem Rest zu sein -> Schwarzer Bildschirm und Error bei der Installation. Beim ubuntu-desktop startet zwar Unity, aber es hat krasse Darstellungsfehler, wenn die anderen Desktops installiert sind. Alle anderen Desktops funktionieren mit leichten Einschränkungen zusammen. Also höchstens zum Testen empfehlenswert

 

[jdl]

Klar, das kann dazu führen, dass mal was nicht mehr läuft, dafür ist man eben aktueller (und manchmal auch sicherer [oder auch wieder nicht]).
Bei mir ist die verfügbarkeit nicht soo kritisch, deshalb läuft das auch zu haus. Aber es ist eben auch Hobbyprojekt und daher probiere ich gerne neues aus.

Arch Linux ist aus Administrator Sicht ein Alptraum, weil man eben keinerlei Sicherheit hat wie die Abhängigkeiten geändert werden. Gerade wenn man kommerzielle Software einsetzen muß oder will geht das gar nicht. Daher entweder für eine Firma Ubuntu LTS, RHEL oder SLES. Da man die Wartungskosten privat nicht zahlen kann, sollte man daher auf Ubuntu oder einen RHEL Clone ausweichen. Persönlich habe ich Erfahrung in der Betreuung einer Scientific Linux Installation. Das CERN ist 2015 von Scientific Linux zu CentOS gewechselt. Ich würde es daher mit einem der beiden Distributionen probieren, auf Basis von RHEL 7.

- - - Updated - - -

versucht zu installieren, bei der Installation schon einen fehler bekommen, das was nicht gefunden wurde. ich probiere heute abend nochmal und poste dann auch die Meldung. aber einfach ist irgendwie doch was anderes....

Ich würde es zuerst mit der Standard Version von Ubuntu probieren. xfce läßt sich da problemlos nachinstallieren.

 

[flxmmr]

Edit2: Habe das gerade getestet. kubuntu-desktop scheint komplett inkompatibel mit dem Rest zu sein -> Schwarzer Bildschirm und Error bei der Installation. Beim ubuntu-desktop startet zwar Unity, aber es hat krasse Darstellungsfehler, wenn die anderen Desktops installiert sind. Alle anderen Desktops funktionieren mit leichten Einschränkungen zusammen. Also höchstens zum Testen empfehlenswert
Anhang anzeigen 361884

Und da frag' ich mich dann irgendwann schon, was die bei Ubuntu so toll machen, in den Zeiten in denen ich noch auf Debian alle Desktops getestet hatte, gab es nie Probleme (gut, da gab's auch noch kein System/Login/Poetterichd)

 

[ClisClis]

Arch Linux ist aus Administrator Sicht ein Alptraum, weil man eben keinerlei Sicherheit hat wie die Abhängigkeiten geändert werden. Gerade wenn man kommerzielle Software einsetzen muß oder will geht das gar nicht. Daher entweder für eine Firma Ubuntu LTS, RHEL oder SLES. Da man die Wartungskosten privat nicht zahlen kann, sollte man daher auf Ubuntu oder einen RHEL Clone ausweichen. Persönlich habe ich Erfahrung in der Betreuung einer Scientific Linux Installation. Das CERN ist 2015 von Scientific Linux zu CentOS gewechselt. Ich würde es daher mit einem der beiden Distributionen probieren, auf Basis von RHEL 7.

Naja, ich möchte halt einfach deutlich aktuellere Pakete. Die wurden ja auch irgenwann mal getestet und alles.
Debian ist hier halt mehr "Wenn es alle anderen getestet haben für 2 Jahre, dann nehmen wir das auch in unsere Quellen auf".

Aber so wie ich deinen Post lese, wäre man mit fast allen anderen Distros aktueller, oder?

 

[flxmmr]

ich weiß ja nicht, welche Software eine PHP-Version von Dezember 2015 braucht, ab Stretch ist PHP7 dabei, dass das ganze auf den oldstable-Release backgeportet wird, halte ich schon für eine übertriebene Erwartung. Im allgemeinen ist Desktop-Software mit den Backports eigentlich doch recht aktuell, Spezialsoftware (hier z.B. gromacs, vmd) muss man sowieso extra installieren und für Server-Software kann man Docker nehmen...

 

[ClisClis]

Klar ist wheezy nicht mehr die aktuelle version.
Dass man es irgendwie zum laufen bringt darf man schon erwarten. Wird wohl auch gehen, wenn man das selber macht.

Aber afaik ist es auch mit 8 nicht dabei.

Und mir geht es auch nicht darum, dass ich erwarte dass es geht, sondern dass ich es möchte und dass es umständlich ist, wenn man es selber machen muss. Es geht darum dass es "schöner" wäre, wenn das einfacher ginge. Komfort.

Und ne, PHP7 ist nicht pflicht für die neueste Owncloud version, soll jedoch für viele Anwendungen grosse Performanceverbesserungen bringen. Im Falle von Owncloud aber auch Probleme mit SabreDav.

Pflicht ist hingegen eine neuere PHP version als diese von Debian 7 momentan angeboten wird, da die "aktuelle Version" die Debian in den Paketen hat als "unsicher" angesehen wird. So habe ich das verstanden.

Selbes gilt für apache

 

[fax668]

Pflicht ist hingegen eine neuere PHP version als diese von Debian 7 momentan angeboten wird, da die "aktuelle Version" die Debian in den Paketen hat als "unsicher" angesehen wird.

Debian portiert sicherheitsrelevante Patches in die alte Version des Pakets. Ein direkter Vergleich der Versionsnummern funktioniert bei Debian so nicht.

Warum redest du eigentlich von Debian 7 (oldstable)? Wem Sicherheit wichtig ist, ist schon längst bei Debian 8 (stable). Das hat natürlich auch wesentlich aktuellere Pakete (PHP 5.6.20 + security patches, also eine Major Release hinter PHP 7).

 

[oooverclocker]

Und da frag' ich mich dann irgendwann schon, was die bei Ubuntu so toll machen, in den Zeiten in denen ich noch auf Debian alle Desktops getestet hatte, gab es nie Probleme

Wenn Du die Ubuntu- Pakete aus über zwei Jahren zusammensammelst und dann erst veröffentlichst (=Debian stable), hier und da noch kleine Patches einfügst, würde das sicherlich auch funktionieren. Nur will ich mal sehen, wie Du mit den teilweise fünf Jahre alten Paketen auf dem Desktop zurechtfinden willst. Kompromisse muss man immer eingehen und dann funktionieren eben so extrem eingreifende Dinge nicht unbedingt auf Anhieb - sind ja dann auch nicht optimal aufeinander abgestimmt.

 

[flxmmr]

@cliclis: dann nimm doch docker; wheezy ist halt oldstable, das LTS-Team portet wohl die schlimmsten Bug-Fixes auch auf alte Versionen, aber verlassen kann man sich da nicht, daher macht man dann halt ein apt-get update && apt-get upgrade und gut ist es – missionskritisch scheint das System nicht zu sein, denn der Umstieg auf PHP7 macht sicher mehr Probleme. Wenn du nicht wirklich viele mit PHP entwickelst (und selbst dann) sehe ich keinen Grund, warum man PHP7 im Heim-Umfeld braucht (mag ja sein, dass Owncloud damit schneller ist, aber das ist simples SMB auch ).

@overclocker: die Dinge wären nicht so extrem eingreifend, wenn die jeweiligen *-desktop-Pakete nicht sämtliche ihre eigenen Display-Manager-Themes als dependencies hätten, die sich dann auch konfliktfrei installieren lassen, leider aber so gar nicht konfliktfrei betreiben lassen. Ein bisschen hängt das wohl auch mit den ganz logind/userd's zusammen, denn ich könnte mir gut vorstellen, dass selbst einige Package-Maintainer nicht mehr blicken, wie man das so konfiguriert, dass es a) funktioniert und sich b) nicht in die quere kommt (wenn man sieht, wie jeder Desktop seinen eigenen Bootsplash reinzieht, glaube ich allerdings, dass das auch gar nicht gewollt ist).
Ich habe hier wunderbar einen Ubuntu 16.04-Rechner mit Gnome, KDE und Unity – da darf man aber nicht die *-desktop-Packages installieren, sondern muss sich mühsam bspw. aus kde5apps und plasma-apps die Sachen zusammensuchen, die entweder genug dependencies mitbringen, um einen desktop zu bekommen oder b) einzeln unabhängig nötig sind. Bei debian war das beim letzten mal noch durch ein kde-desktop-package geregelt, das aber im Gegensatz zu den dämlichen *-desktop-packages nur die Programme ohne Globalkonfiguration für lightdm/systemd mitbringt (und man hat halt dann, wenn man vom Minimalsystem startet den default-lightdm – so what...); warum es keine *-desktop-config packages gibt, die sich gegenseitig ausschließen und die Konfiguration dann zur Subdistro passend gestalten weiß ich leider nicht...

[und ja, unter dem gut abgestimmten Ubuntu gab das immer noch Probleme, weil ich dann zwischenzeitlich mal irgendein *-desktop reinstalliert hatte und dann bei jedem Login das "Systemfehler-Fenster" kam - die Deinstallation des betreffenden Paketes hat das dann auch behoben...]

 

[jdl]

Aber so wie ich deinen Post lese, wäre man mit fast allen anderen Distros aktueller, oder?

RHEL ist unter Umständen deutlich älter, aber Patches gibt es trotzdem. Es ist einfach ein grauenhaft ständig Software an sich ändernde APIs anpassen zu müssen, es vernichtet Lebenszeit ohne jede Nutzwert. Daher ist RHEL auch im kommerziellen Umfeld so erfolgreich. Alleine das Testen von Software dauert länger, als bei den ganzen Rolling Release Distributionen die Zeitdauer beträgt, bis eine neue Version ausgerollt wird.

 

[snoopyx]

Kurz mal eine Zwischenfrage nachdem ich ein release-upgrade meine N54L auf 14.04 LTS durchgefuehrt habe, wird mir beim updaten immer folgende Fehlermeldung ausgespuckt:

Spoiler

$ sudo apt-get update && sudo apt-get upgrade
[sudo] password for user:
Unknown parameter encountered: "symlinks"
Ignoring unknown parameter "symlinks"

Ich weiss was symlinks sind, aber weswegen werden die als unknown parameter erkannt?

Das update der Pakete laeuft danach aber normal durch.

 

[fax668]

Klingt nach einer Konfigurationsdatei mit einem unbekannten Parameter. Was spuckt "fgrep -R symlinks /etc/apt" aus?

 

[snoopyx]

Gar nichts!??

 

[fax668]

Mach mal update und upgrade getrennt. Bei welchem der beiden kommt die Fehlermeldung?

 

[snoopyx]

Ich glaube sobald ich irgendeinen Befehl sudo voranstelle tritt der Fehler mit unknown parameter auf, zB beim mounten und unmounten.

tapatalked!

 

[fax668]

Ach so. Was spuckt denn "sudo fgrep -R symlinks /etc/ssh" aus?

 

[snoopyx]

Ach so. Was spuckt denn "sudo fgrep -R symlinks /etc/ssh" aus?

Ich glaube daraus wirste auch nicht schlauer

Spoiler

$ sudo fgrep -R symlinks /etc/ssh
[sudo] password for user:
Unknown parameter encountered: "symlinks"
Ignoring unknown parameter "symlinks"

 

[fax668]

Einen hab ich noch:

sudo fgrep -R symlinks /etc/sudo*

 

[snoopyx]

Einen hab ich noch:

sudo fgrep -R symlinks /etc/sudo*

Trommelwirbel...
und wieder nichts:

$ sudo fgrep -R symlinks /etc/sudo*
[sudo] password for user:
Unknown parameter encountered: "symlinks"
Ignoring unknown parameter "symlinks"

Es scheint ja kein Problem zu sein. Der miniserver laueft normal. Wollte nur mal wissen weswegen er sich beschwert.