selbiges gilt f. den Individualverkehr: bringt deinen Cadaver an Orte, die es nicht bräuchte, wenn wir sie nicht hätten;
Das kann man noch weiter treiben lol
Die Welt bietet uns einen Lebensraum, den wir nicht bräuchten, wenn wir Sie nicht hätten.
3deep5me und so 
jetzt weißt welche Existenzberechtigung Steuerkanzleien haben: um Dinge zu erklären, die es nicht bräuchte, wenn wir sie nicht hätten¹;
soll heißen: die Komplexität des Steuersystems hat einen Grund;
¹ gilt auch f. die EDV: sie unterstützt bei Aufgaben, die es nicht bräuchte, wenn wir sie nicht hätten;
selbiges gilt f. den Individualverkehr: bringt deinen Cadaver an Orte, die es nicht bräuchte, wenn wir sie nicht hätten;
;
Die Welt bietet uns einen Lebensraum, den wir nicht bräuchten, wenn wir Sie nicht hätten.
... dann könnten wir aber nicht existieren ...
so krass wollt ich das jetzt nicht formulieren
QuoteDiese habe ich mit den zwei angegebenen Befeehlen (von GitHub) installiert und dann gestartet [...]
Die Befehle von GitHub:
Quote
Und dann wundern, wenn irgendwas nicht geht oder noch schlimmer, wenn der Server gehackt worden ist.
Das sind so Momente, wo mann einfach nur noch weinen gehen möchte.
Die Befehle von GitHub:
Und dann wundern, wenn irgendwas nicht geht oder noch schlimmer, wenn der Server gehackt worden ist.
Das sind so Momente, wo mann einfach nur noch weinen gehen möchte.
Ich habe auch lange gegen solche Installationsmethoden gekämpft. Aber wenn wir mal ehrlich sind, ist das auch nicht unsicher als irgendein externes Repos einzubinden und ein Paket daraus zu installieren. Denn auch dort können beliebige Befehle als Root während der Installation ausgeführt werden.
Ich mag das eher aus einem anderen Grund nicht, nämlich weil man das obige Verfahren nur schwer automatisieren kann. Da sind externe Repos + Pakete dann doch deutlich angenehmer. Aber in Hinblick auf Sicherheit spielt das aus meiner Sicht eigentlich keine Rolle. Externe Sachen bleiben externe Sachen. Egal ob man jetzt als Shell Skript ausführt oder als Paket installiert.
Paul mit dem Riesenunterschied, dass man eigentlich sagen müsste, dass jemand der direkt
curl ... | sh ausführt, das root-Mandat entzogen werden müsste;
ma schaut auch nach links und rechts bevor ma die Straße quert,
so ist es auch hier, dass ma vorher schaut was ma da eigentlich ausführt ...
Display MorePaul mit dem Riesenunterschied, dass man eigentlich sagen müsste, dass jemand der direkt
curl ... | sh ausführt, das root-Mandat entzogen werden müsste;
ma schaut auch nach links und rechts bevor ma die Straße quert,
so ist es auch hier, dass ma vorher schaut was ma da eigentlich ausführt ...
Ich sehe da nicht wirklich einen Unterschied, wenn ich stattdessen mit "sudo apt install <paket>" (falls <paket> aus einer vorher extern konfigurierten Quelle stammt) etwas installiere. Dort weiß ich auch nicht, was für Befehle alles in den Post Install Tasks ausgeführt werden. Da ist so ein Shell Skript sogar noch etwas transparenter.
Für mich ist eine externe Quelle eine externe Quelle. Der vertraue ich oder nicht. Da spielt es gar keine so große Rolle wie ich mir die Sachen ins System hole.
Edit: Ein Beispiel: https://github.com/MrMEEE/bumb…and-abbandoned/issues/123
Für mich ist eine externe Quelle eine externe Quelle.
nur bist beim oben erwähnten selber Schuld, wennst Dir was einziehst ...
(Du hattest Deine Chance es vorher zu sehen...)
Was ist eigentlich aktuell bei netcup mit Mail zugange? Ich dachte hier würde man alles durchlassen und niemals Mails rejecten...?
Ich sehe da nicht wirklich einen Unterschied, wenn ich stattdessen mit "sudo apt install <paket>" (falls <paket> aus einer vorher extern konfigurierten Quelle stammt) etwas installiere.
Es gibt einen riesigen Unterschied. Wenn du 'curl http://shorturl -> 301 -> http://github/a/b/branch/devel | bash' ausführst, dann hast du keine Ahnung mehr was du installiert hast. Das RPM kannst du archivieren und später noch reinschauen.
Jap, die vermehrten Meldungen zu den Mails in letzter Zeit beunruhigen mich auch ein wenig.
Für wichtige System- und Vertragsmails habe ich ohnehin einen externen Mailaccount. Überlege nun aber ernsthaft das Mailsetup der Domains zu mailbox.org rüberzuschaufeln - bisher schreckten mich jedoch die wenigen Aliase ab und eine eigene Mailkuh möchte ich schlicht nicht pflegen müssen, hab schon genug andere Baustellen. Naja, mal gucken...
Was ist eigentlich aktuell bei netcup mit Mail zugange? Ich dachte hier würde man alles durchlassen und niemals Mails rejecten...?
Gute Frage, ist noch nicht sehr lange her, da kamen hier regelmäßig klagen, dass Spam-Mail durchgelassen wird. Jetzt hat man wohl in die andere Richtung gesteuert und eventuell etwas übertrieben. Wobei ich auch noch keine der angeblichen Spam-Mails live gesehen habe, also alle Headerzeilen, Inhalt ..., die man gern als "kein Spam" klassifiziert haben möchte. Ich kann nachvollziehen, dass man sich teils darauf verlassen hat, dass kein Spam aussortiert wird und jetzt nicht so gerne seine Mail-basierten Abläufe überarbeiten will. Andere, vor allem Neukunden, sehen das aber grundlegend anders. Also was?
In letzter Zeit Reject Netcup extrem viele Mails, hatte auch das Problem bei Sogo gehapt.
Meine Berichte von meiner Fritte wurden als SPAM eingestuft und konnten nicht zugstellt werden (Fehler Bericht bekommen).
Dabei habe ich den SMTP Server von Sogo in meiner Fritte eingrichtet und die Mail an eine Alias interne Adresse zugstellt.
Andere Mails von der Fritte wurden weiterhin zugstellt und habe dann mal eine Testmail versendet, später den Bericht nochmals.
Seit ich das gemacht habe, ist der Fehler seit ca. 3 Tagen nun Weg, kann aber auch sein das Netcup was gemacht hat. 
Track1991 Das erinnert mich an Office365. Da liefen dann unsere internen Build-Mails drüber. Zum Testen hatten wir einen stündlichen Job mit Logfiles. Laut unserem SMTP war die Übergabe immer sauber. Dennoch sind immer wieder Emails im Nirvana verschwunden sind. Rejects gab es auch, aber nur ganz wenige.
DerRené : CatchAll. Das hat auch den Vorteil, dass du dir für jeden Anbieter live eine Adresse ausdenken kannst. Geleakte/verbrannte Adressen leitest du dann direkt in den Spam-Ordner oder lässt die rejecten. Im Nachhinein bieten die sehr viele intelligente Features an.
vmk
: CatchAll wäre eine Möglichkeit, da hast du Recht. Allerdings mache ich seit Jahren einen riesigen Bogen um CatchAll auf Grund des Ausmaßes an Spam mittlerweile (eher allgemein betrachtet, so sehr verbrannt sind meine Maildomains scheinbar (noch?) nicht) und ich scheue schlicht den Aufwand verbrannte Adressen dann händisch zu verwalten. Aber ich glaube ich lasse es wirklich mal auf einen Test ankommen, womöglich ist der Aufwand ja gar nicht so hoch. 
Womit dann in meinem Fall die Buchung des Webhostings komplett obsolet wird. Nutze es eigl nur für das bequeme Mailsetup und als Testumgebung (hierfür wiederum reicht auch ein kleiner VPS).
Ich bekomme auch nicht mehr Spam als ich vorher auf meinem eigenem Mailserver hatte, nämlich deutlich weniger als 1 pro Tag (update: die zu ca 50% im Spam landet). Bei meinen privaten Mailserver hatte ich über 100 Mails pro Tag rejected weil die definitiv Spam waren.
Meine Email-Adressen sind ca 20 Jahre alt und ich habe vor über 10 Jahren absichtlich Adressen wie spam@ / info@ / etc auf Webseiten für Crawler hinterlegt, in diverse Foren in Signaturen gepackt und immer fleissig bei Spam diese Adressen bei "unsubscribe" verteilt. Intern hatte ich die dann direkt als Spam markiert und dem Spamassassin/etc zum Lernen gegeben.
So, jetzt habe ich drei Rechner mit Ubuntu Server 20.04 LTS aufgesetzt, wollte mich nicht mehr gegen neue Konzepte wehren und einen offenen Horizont bewahren, und ärgere mich nach einer Editor-Orgie wieder über netplan. Was rauchen Entwickler eigentlich, die ein Indent-Brainfuck (YAML) mit mäßig dokumentierten Keywords von Admins abverlangen? Ich verstehe ja noch die Beweggründe, eine universelle Config für diverse Renderer anbieten zu wollen, aber das ist meines Erachtens eine Zumutung, die die Fehler von network-scripts anders neu interpretiert, ohne einen Mehrwert zu bieten.
Oder wie seht Ihr das?
Oder habt Ihr ein Howto nach der Art: How I stopped worrying and learned to love netplan?
So, jetzt habe ich drei Rechner mit Ubuntu Server 20.04 LTS aufgesetzt, wollte mich nicht mehr gegen neue Konzepte wehren und einen offenen Horizont bewahren, und ärgere mich nach einer Editor-Orgie wieder über netplan. Was rauchen Entwickler eigentlich, die ein Indent-Brainfuck (YAML) mit mäßig dokumentierten Keywords von Admins abverlangen? Ich verstehe ja noch die Beweggründe, eine universelle Config für diverse Renderer anbieten zu wollen, aber das ist meines Erachtens eine Zumutung, die die Fehler von network-scripts anders neu interpretiert, ohne einen Mehrwert zu bieten.
Oder wie seht Ihr das?
Oder habt Ihr ein Howto nach der Art: How I stopped worrying and learned to love netplan?
Ich mag YAML. Warum man das für Netzwerkconfigs nutzen sollte kann ich mir aber auch nicht erklären...
Vielleicht sollte ich auch nur noch einmal meinen Attitude tunen? Kommentare willkommen. Ich habe es immerhin geschafft, nach der Bonding-Einrichtungsorgie, VLANs und Bridges darauf ohne auch nur einen Tipp- oder Indent-Fehler auf Anhieb hinzubekommen. Trotzdem fand ich die alte Konfiguration via network-scripts übersichtlicher. Sogar die sysconfig unter CentOS erscheint mir immer noch aufgeräumter.
Hat sich was an der Bereitstellung der Server geändert? Habe gestern Abend einen weiteren Server bestellt und warte immer noch. Das ging doch mal innerhalb weniger Minuten, offenbar automatisiert. Jetzt habe ich das Gefühl das jemand manuell Hand anlegen muss...
