Beiträge von WolfgangV

    Ums dir nochmal bisschen auszudeutschen: Das sind Server entweder für irgendwelche Spieler wo's nicht wirklich auf Verfügbarkeit und Zuverlässigkeit ankommt oder eben für Script-Kiddies (nicht böse gemeint) wo's eben nicht so 100%ig drauf ankommt.
    Kein Snapshot bedeuted oft dass du bei bisschen aufwändigerem Serversetup verdammt schnell in die Röhre guckst wenn du plötzlich zum update bzw. upgrade gezwungen bist (Heartbleed, Shellshock, ...).... damit leben kann man sicher aber mit professionellem Arbeiten hat es nicht viel zu tun. Ist halt sehr von deinen eigenen Anforderungen abhängig.


    Achja, bezüglich der Apache vs NGINX Frage: Ich persönlich habe vor einiger Zeit auf nginx umgestellt und es nicht bereut. Man muss sich natürlich wieder bisschen einlesen aber ich glaub mittlerweile sind Tutorial alá "wie kriege ich Board/CMS/... x auf nginx zum laufen" auch leichter und häufiger zu finden als vor einiger Zeit.
    Eines der "Hauptprobleme" 'damals' war für mich z.B. dass ich vorher svn über ein Apache Modul auslieferte und für nginx gab es keines (keine Ahnung ob es mittlerweile eines gibt?!) - seitdem bin ich auf git umgestiegen und betreibe u.A. ein eigenes gitlab.
    Der oben genannte "Vergleichslink" ist schon recht gut, du kannst ja zum Test mal Apache benutzen und dann nginx - z.B. habe ich eine Seite von jemanden der mit Wordpress eine extrem Bildlastige Seite erstellt hat - sehr große Bildformate und das auch noch im Wechsel - alles gute zureden dass das für den Besucher der Seite eher hinderlich ist war da vergebens. Hier sticht z.B. nginx (mit den richtigen Einstellungen bezüglich static content) den Apache um Längen aus.... allerdings musst bei nginx dich eben selber kümmern was z.b. mit PHP passieren soll (ich nutzte dafür php-fpm). Vor allem aber kommt nginx auch sehr gut mit vielen, eher "kleinen" Zugriffen zurecht bei dennen der Apache durch sein Design eher schwächelt.


    Im Endeffekt muss es also jeder für sich wissen, möchte auch keinem seinen Glauben oder seine Überzeugungen beschmutzen... was Leistung angeht würde ich persönlich immer und immer wieder nginx dem apache klar vorziehen. Was Verbreitung (und damit eben verfügbare Module etc. angeht) da ist allerdings der Apache noch immer überlegen (und wird es sicher auch noch lange bleiben).


    So, viel Glück bei deiner Entscheidung!

    Ähhm, auch wenn ich jetzt der gefühlt 1000ste bin der das sagt: Mach den Server platt!


    Hier die Begründung:
    - es wurden dir unbekannte binaries auf dein System geladen und ausgeführt, welche Effekte diese hatten weißt du nicht
    Du kannst dein System von "innen" heraus nicht reparieren da du KEINER deiner dort vorhandenen Binaries trauen kannst, weiter ist ein Scan von außen mit 100%iger Tiefe von sehr aufwändig bis unmöglich zu bewerten....
    Nebenher bemerkt hat das Ding u.U. Sachen gelöscht die für den (sicheren) Betrieb deines Servers ganz gut wären... dein alter Crontab z.B. ist ja auch weg (crontab -r).... also wenn ich einen Virus/Worm vertreiben wollen würde, würde z.B. überlegen ob ich meinen Opfern nicht z.B. die Möglichkeit updates zu fahren nehmen würde... oder alle paar Tage / Wochen lässt man sich einen Log des Servers zustellen in dem vielleicht interessante Daten zu finden sind (nicht in deinem Interesse wie ich vermute) oder ..... die Möglichkeiten sind unbegrenzt.


    Lässt du den Server in gutem Glauben an "es war hoffentlich nicht mehr" weiterlaufen und wird dieser z.B. für Straftaten verwendet (häßliche Themen wie Kinderpornographie die verteilt wird etc.) dann bist du mindestens grob fahrlässig.... da du es spätestens nach diesen Foreneinträgen besser wissen MUSST.


    Von daher ganz klar: Daten sichern (zieh dir z.B. ein Image für eine virtuelle Maschine) und das Ding in den Äther gejagt.

    Der Support weiß am besten was er für dich tun kann.....


    Wenn es "nur" der Timeout ist könntest du schon "von hinten durch die Brust ins Auge" kommen indem du z.b. bei dir Lokal den Webserver nachbaust (ist ja nur'n Apache oder nginx....) und bei dir lokal installierst (hier hast du ja volle Kontrolle über die Timeouts) - mit dem "Trick" deine /etc/hosts entsprechend so umzubiegen dass es nach deiner richtigen Domäne aussieht..... die fertige Installation schiebst du per FTP Dateiweise auf den Webserver und portierst deine Datenbank auf den Server - alles ist gut. Das wäre mal so ein Gedanke...

    Ne, die Antwort 200 ist schon korrekt da die HTTP Anfrage (per GET) an das root verzeichnis (nicht der root des Servers sondern das root-Dir des Webservers) ging und dieses logischerweise vorhanden ist. 200 sagt ja nur "OK", ich liefere mal was zurück. 400 wäre ein Bad Request und das hieße der Request selbst wäre "nicht korrekt" - immer aus Sicht des Webservers. Und von dem aus ist ja alles gut... Das macht keine Aussage ob da was ausgeführt wurde oder nicht, es wäre jedoch eher untypisch da dies ja hieße dein Webserver führt direkt irgendwas in der Bash aus.... im Regelfall (selbst mit verwundbarem System) würde diese Anfrage einfach nichts machen und nur in speziellen Fällen eben auf Server treffen die tatsächlich für die Hauptseite CGI oder etwas in der Richtung am Laufen haben. Das ist derzeit eben so das "rumgestochere" nach verwundbaren Systemen, viele Script-Kiddies sind hier halt aus ihren Löchern gekrochen und fühlen sich jetzt bisschen cool....


    Prüfen kannst du im Endeffekt recht einfach ob da was losgelaufen sein kann, stell selber die Anfrage an deinen Webserver nur eben ohne Botdownload sondern z.B. einfach ein "touch /tmp/verdammich" statt dem wget. Findest du unter /tmp/ dann die "verdammich" file würd ich den Server wohl auch entweder plätten oder gründlichst durchforsten - im Regelfall verraten sich Bots etc. ja sowieso durch offene, lauschende oder sogar aktive Ports... also netstat anwerfen und Freude haben - aber hier nochmal: Die Chance das da "getroffen" wurde ist mehr als gering. Wenn dein System zum Zeitpunkt der Anfrage eh schon gefixed war dann hast du gleich zweimal keinen Grund zur Besorgnis (bzw. nicht mehr als man halt immer haben muss wenn man einen Webserver betreibt.... :D).


    Server abschalten deswegen? Also ich von meiner Warte aus: NEVER, das mit dem Raspberry verstehe ich nicht wirklich - hat i.d.R. auch eine bash und wenn du den gefixed hast wieso ist er dann besser als ein "richtiger" Server?!

    naja ist jetzt grad schwer nachzuvollziehen..... ich empehle dir mal ganz stark eine apt.sources entsprechend anzupassen:
    SourcesList - Debian Wiki


    im Endeffekt erstmal das rein und was in einen "alten" listen eben noch so rumschwirrt... weiß wie gesagt nicht wie es in debian so ist, ich hab z.B. auch /etc/apt/sources.list.d/ als Verzeichnis zur Verfügung in welches ich eben "spezielle" repos reinpakte.... wenn du auch sowas zur Verfügung hast würde ich es nutzen...

    Timeout ist wohl ziemlich eindeutig... wenn du "normalen" Webspace hast dann vielleicht mal ganz freundlich beim Support anfragen.... andere Möglichkeit wäre maximal das Installscript nehmen und in zwei Teile zerbröseln (was vermutlich sehr aufwändig werden kann)... oder nach dem ersten erfolglosen Lauf einfach ein zweites mal laufen lassen in der Hoffnung dass einige "installationsaufgaben" schon gemacht sind und somit nicht mehr soviel Arbeit machen. Mehr wird nicht drin sein...

    Bin jetzt nicht so firm mit Debian aber du hast verdammt viele squeeze sourcen in deiner liste für ein wheezy.....
    bzw. sehe ich nur

    Code
    Hit http://ftp.de.debian.org wheezy Release.gpg
    Hit http://ftp.de.debian.org wheezy Release



    für wheezy .... vermisse da sowas wie

    Code
    deb http://http.debian.net/debian wheezy main
    deb http://http.debian.net/debian wheezy-updates main
    deb http://security.debian.org/ wheezy/updates main


    .... das fällt mir so auf den ersten Blick auf.

    Davon abgesehen dass es langsam wirklich nicht mehr hier in das Thema gehört - was meinst du mit "was spricht eigentlich dagegen" - gegen sudo? Es spricht vieles für sudo, du kannst damit eben eine "Adminmacht" beschränken aber dennoch das System administrieren ohne den root auszupacken... aber wenn du sudo so gar nicht haben willst:

    Zitat

    passwd root

    (nicht dass hier gleich Schläge kommen aber wir sind doch alle erwachsen und sollten wissen was wir tun..)

    Also ich fahre meine Backups über StoreBackup ([url=http://www.pro-linux.de/artikel/2/1596/2,installation-und-erstes-backup.html]http://www.pro-linux.de/artike…on-und-erstes-backup.html[/url]) - bin damit sehr zufrieden da ich bei Änderungen immer nur die Deltas wegsichern muss, ist wunderbar scriptbar und ein push auf'n externen FTP mache ich ebenfalls per script per "ftp".... allerdings kein Cron sondern ich hab's mir als Daemon hardgecoded da dies für mich für diese spezielle Aufgabe solider schien...

    Also mich interessiert Design nicht wirklich (sorry aber so sind nun einmal die verschiedenen Präferenzen) - SSO wäre dennoch sehr, sehr empfehlenswert. Da ich den Aufwand, den es euch technisch verursacht bzw. die Kosten nicht kenne hier nur ein Vorschlag ins "Blaue" hinein was die Snapshots Exporte angeht: Pro 3 Monate einer "frei" wäre z.B. sehr nett, all zu oft wird dies vermutlich sowieso nicht genutzt und es wäre ein Entgegenkommen.... (ich nutze den Export eigentlich nie und dennoch fände ich es angenehmer z.B. eben einmal pro Quartal einen herunterzuladen...) - also so in der Richtung wenn seit letztem Snapshot Export mehr als 3 Monate vergangen sind wird kostenlos wieder einer freigegeben (also ohne aufsummieren der Exports!).
    Die Sonderangebote per RSS Feed ist sowieso schon super, ebenso finde ich die Seite gut übersichtlich - sowohl die Angebotsseite, als auch die Controlpanel etc. - jedoch wie schon Eingangs erwähnt wäre ein SSO schon angebracht - und damit verbunden auch dass eben alles über eine Hauptleiste erreichbar ist. Das Controlpanel passt eben einfach nicht zum Rest... (Design = mir egal, jedoch "gleich" sollte es sein :D).
    Noch ein Wort zum Controlpanel: Ich nutze es nahezu nicht da ich (fast) alles per ssh erledigen kann (von Snapshots mal abgesehen...) - somit besuche ich es auch (fast) nie, eine bessere Integration in den Rest der Seite wäre somit schon wünschenswert.


    Ansonsten hier nochmal mein Lob, ihr macht einen tollen Job und ich fühle mich bei euch sehr gut aufgehoben!

    Ich kann hier, wie auch schon twiddern empfohlen hat, imapsync empfehlen - direkt am Server laufen lassen und die Größe der Postfächer ist eher zweitrangig. Die Daten der Postfächer in einer plain text datei ablegen und schon ist es massenmigrationstauglich...

    Ist doch alles gut, Debian 6 Squeeze ist ja jetzt nicht "böse" oder untragbar - wenn du halt gewissen Schwierigkeiten beim Umgang mit deinem Server hast fährst du mit einer neueren Version halt tendenziell "besser". Ich habe auch ein 12.04 LTS Ubuntu laufen obwohl 14er LTS verfügbar ist - weil es einfach ziemlich viel Arbeit mach(t/en kann) zu upgraden... i.d.R. macht man da ja auch nicht Hauptberuflich *g*


    Viel Glück dann für den Dezember :D

    Also ich habe bislang keine sehr guten Erfahrungen mit der php mail() funktion gemacht. Es wird eigentlich recht oft empfohlen einen eigenen Mailer zu verwenden (im Endeffekt ist ja eine E-Mail nichts anderes als ein geöffneter Sockel über den Daten gehen...):
    PHPMailer/PHPMailer · GitHub - hier z.B. hast das ganz praktisch und einfach "verpackt".... Ich weiß nicht was ein "normaler" Webhosting Nutzer darf, von daher kann ich dir hier auch nicht mehr zu sagen.


    Achja, wenn du weitreichendere Hilfe brauchst solltest du vielleicht mal ein Stück Quellcode (idealerweise das mit dem "mail()" Part) sehen lassen...


    Gruß
    Wolfgang

    Hallo,


    benutzt du den Debian 6 Squeeze?
    Wenn ja, dann kannst du, wie schon von killerbees19 angedeutet, die LTS Pakete verwenden:


    in die /etc/apt/sources.list fügst du ein:

    Code
    #LTS security
    deb http://http.debian.net/debian/ squeeze-lts main contrib non-free
    deb-src http://http.debian.net/debian/ squeeze-lts main contrib non-free


    danach einfach ein "apt-get update && apt-get install bash" laufen lassen..... sollte helfen.
    Nebenher solltest dir aber überlegen ob du nicht langsam auf eine neuere Version willst, muss ja nicht jetzt so Hals über Kopf passieren aber sich mit dem Gedanken schonmal anfreunden :D