Drush installation Probleme kein ‚name‘ - Attribut.

Um dir hier weiter zu helfen, bräuchten wir schon ein paar mehr Infos zu deinem Server/ System auf dem du drush installieren kannst.
Wie versuchst du denn drush zu installieren/ welche Version?
Teilweise kann es sein, dass du hier nicht alle notwendigen Rechte besitzt - so wäre eine Installation nicht möglich.

Drush an sich sollte sich problemlos installieren lassen - auch wenn der Build failed. Dies ist nur eine Info des Build-Systems von github.

Hier lohnt dann auch ein Blick in die Issues auf github:
https://github.com/drush-ops/drush/issues?utf8=%E2%9C%93&q=is%3Aissue+is...

SteffenR

Also ist halt ein Webhosting Paket ohne SSH Zugang ich muss alles halt per Hand installiern.
Ich habe halt die https://github.com/drush-ops/drush/archive/master.zip per Drupal versucht zu installiern.
PHP 5.6.6
Datenbank 5.5.41-0+wheezy1

Kläre uns doch mal auf, wie du ein Kommandozeilentool wie Drush benutzen willst, wenn dein Hosting Produkt dir keinen Shell Zugriff erlaubt?

Ok ich dachte das funktioniert nur mit php und sql.
Dann muss ich mal schauen ob ich noch ssh bekomme.
Ich vermute aber mal das ich es in Plesk nicht beommen kann.

Gibt es außer Drush eine möglichkeit den Drupal core zu updaten ohne immer alle Daten per Hand (FTP ) zu tauschen ?

(Noch)Nicht "out of the box". Bei entsprechenden Rechten auf dem Server kann man sich selber ein Script schreiben, aber da ist drush einfacher.

Ok
Das wundert mich das man da nicht mal was anbietet weil nicht jeder hat root Rechte oder ssh.
Ich habe gerade mal geschaut Webhosting mit ssh ist im Vergleich zu Webhosting ohne ssh richtig teuer.

Root-Rechte auf dem Server sind noch ein Sache für sich, aber ein sinnvolles und sicheres Hosting baut elementar auf separate Unix-Benutzer auf, am besten unterschiedliche zum Ausführen des Webservers und zum Verwalten der PHP-Dateien auch mit Hinblick auf Sicherheitstlücken in der Webanwendung.
Auch Drush ist primär ein PHP-Anwendung, die aber in der Regel über SSH aufgerufen wird. Es geht zum Teil sogar über das Modul "Shell", das wie Hacking-Angriffe nur dann Drush ermöglicht, die Webanwendung zu manipulieren, wenn der Server zumindest nach meinen Maßstäben nicht sicher konfiguriert ist. Das trifft leider auf sehr viele Hosting-Anbieter zu. In diesem Sinne bin ich auch komplett gegen die Modul/Theme-Upload-Funktion in Drupal 7, die ich meistens als erstes deaktiviere. Jeder Versuch, Drupal noch mehr Möglichkeiten zu geben, sich selbst zu manipulieren macht meiner Meinung nach das System weniger sicher. Das, was manche hier als Mangel eines Features sehen, sehr ich dann eher als Sicherheitslücke, an deren Entwicklung ich mich nicht beteilige (ohne dafür bezahlt zu werden). Somit würde ich mich eher wundern, wenn ernsthafte Entwickler, hier ein Broser-basiertes Werkzeug entwickeln würden. Für die massenhafte, schlechte Ausstattung von Webspace kann ja schließlich die Drupal-Community nichts.

Um Drush sinnvoll einzusetzen benötigt man auch noch Zugriff zu den Befehlen "mysql" und "mysqldump", die wiederum große Vorteil gegenüber PHP-Anwendungen im Browser haben wie z.B. PHPmyadmin. Wenn so etwas im Betrieb ist, muss man sich auch um deren Sicherheit kümmern.
Im Fall von Datenbank-Zugriff habe ich mal ein kleines Script geschrieben, daß das Einspielen von Datenbank-Dumps, die per FTP kommen, ohne SSH und PHPmyadmin verbessert, aber das war auch mehr ein Test und betraf nur ein bestimmter Hoster und ein konkretes Kunden-Projekt.
SSH und Mysql-Befehle in der Commandline gibt es zusammen mit einer sinnvollen, sicheren Server-Konfiguration (zwei System-Benutzer) als managed Hosting derzeit erst ab ca. 20 Euro im Monat, soweit mir bekannt bei Hosteurope. Wenn jemand da andere Angebote kennt, wäre ich daran auch interessiert.
Da ich mit SSH und Drush mit Datenbankzugriff erheblich effizienter arbeiten kann und ich meinen Kunden schnell vorrechnen kann, was es Ihnen kosten würde, wenn ich mich mit FTP und solchen Bremsen herumärgern müsste, rechnet sich bei diesen allerdings schnell der Aufpreis im Hosting.

Wenn man eines vom "Drupalgeddon" letzten Herbst lernen sollte, dann daß man die Sicherheit von Drupal-Systemen auch bezüglich Server-Konfiguration (d.h. Hosterwahl) und die Geschwindigkeit beim Einspielen von Patches enorm wichtig sein kann (bei Drupalgeddon unter 3 Stunden um wirklich sicher zu sein).

So mein Anbieter hat mir jetzt SSH Zugriff freigeschaltet.
Es fehlen aber noch Abhängigkeiten. Ich muss noch schauen was man alles benötigt.
Ich zahle im Moment 8,76 hosting + 2,89 de domain pro Jahr.
Wobei es bei meinem Anbieter noch andere Pakete gibt mit 50 oder 25 Kunden pro CPU-Core.

Hosting-Pakete, d.h. in dann oft Kunden-Daten bemühen sich die Hoster von einander abzuschirmen. Diese geschieht mit unterschiedlichen Methoden und die Sicherheitsebene kann ich auch nicht so gut beurteilen. Ansonsten betrifft die Konfiguration mit mehreren Kunden dann vor allem auch Performanz usw.
Das Sicherheitskonzept, das man selten in Managed Hosting-Paketen umsetzen kann, nutzt zwei System-Benutzer pro Host (in der Regel Hosting-Paket). Der eine führt den Webserver aus, der Drupal PHP-Dateien z.B. über "fcgi" oder moderner "fpm". Der zweite Benutzer ist der "Besitzer" dieser PHP-Dateien (Zugriff über SSH und meinetwegen auch FTP oder wenigstens FTPS). Verbunden sind die beiden System-Benutzer über eine gemeinsame Gruppe. Damit kann dann dann der Besitzer, dem Webserver und damit Drupal Schreibrechte in bestimmten Ordner (tmp, files, cache usw) gewähren, die Drupal auch speziell schützt mit ".htaccess"-Dateien, die in diesen Verzeichnissen kein PHP-Schreibrecht erlauben. Siehe auch: Securing file permissions and ownership.
Es mag auch noch andere Möglichkeiten geben, wie man eine Webanwendung dafür bewahrt, sich selbst zu verändern. Aber die einzigen anderen Ansätze, die ich kenne, erfordern eher komplexere Zugriffs-Möglichkeiten auf einen Server als einfachere.
Für dieses Sicherheits-Konzept benötigt man nicht notwendigerweise SSH und Drush. Aber ich befürchte, daß bei vielen Hostern, die damit werben, daß man bei Ihnen super CMS und andere Webanwendungen installieren kann, entweder gleichgültig sind gegenüber diesem Problem oder einfach zu wenig Verstehen von den Funktionsweisen einer modernen Webanwendung (was auch gefährlich ist).
Eine Sicherheitslücke wie das Drupalgeddon im letzten Oktober kann auch in Contrib-Modulen auftauchen (ich habe selbst schon so eine gefunden und behoben) und im Grunde auch viele CMS betreffen. Durch die oben beschriebene Sicherheitsstrategie kann man immerhin weitgehend verhindern, daß ein erfolgreicher Angreifer weiteren Schadcode nachinstallieren kann, um z.B. eine Spam-Schleuder in dem Hosting-Paket zu installieren.