Switches ist die Update-Politik
echt jetzt? bei consumer-switches? was erwartest für einen zweistelligen eurobetrag?
Switches ist die Update-Politik
echt jetzt? bei consumer-switches? was erwartest für einen zweistelligen eurobetrag?
nagios
wenn dann icinga2. aber ist von der config her recht komplex. checkmk und zabbix stehen auf meiner shortlist.
mittels sieve-filter einfach alles "from *" rejecten:
ist das dann nicht klassischer backscatter? im webhosting wird man nicht während des smtp-dialogs rejecten können?
ProxyPass / http://***.***.***.***:3000/
dein wiki.js läuft aber schon auf der selben maschine, oder? dann kannst statt der IP localhost oder 127.0.0.1 angeben. denn wenn der proxy funktioniert willst Du eigentlich nicht mehr, dass wiki.js auf der öffentlichen IP am port 3000 lauscht sondern nur mehr eben am localhost.
Wenn ich auf einem der VPS nur Wiki.js laufen habe, kann ich mir doch den Reverse Proxy sparen,
nein. wiki.js bringt seinen webserver selbst mit.
einfach nur das Stammverzeichnis des Indianers auf den Wiki.js-Order ändern,
nein. apache kann mit den datein dort nichts anfangen. das ist dort weder html noch php.
damit das nicht falsch verstanden wird
sorry, da gibts nix falsch zu verstehen! alles andere ist murks!
wobei es in /var/www/wikijs ja auch in Ordnung gewesen wäre, richtig?
nein! programme haben in /var nichts verloren. inhalte ja. die hat dein wiki.js aber in der postgresql. und in /var/www gehören ausserdem nur inhalte die ein klassischer web-server ausliefern kann.
Mir macht eher noch das Rechte-Verhältnis bzw. die Rechte-Konfiguration Probleme. Nicht das Durchführen, sondern das verstehen.
zb alles in /opt/wikijs gehört nur dem user wikijs. der nodejs prozess läuft unter dem user wikijs. fertig.
Ich bin mir nicht ganz sicher, was du damit meinst...
wäre nur angedacht gewesen wenn Du nodejs nicht aus dem debian repo installierst. dafür gibts aber aktuell keine notwendigkeit.
Aktuell läuft Wiki.js unter IP:3000. Ist es ausreichend, wenn ich den Document Root von Apache2 einfach auf /home/bud/wikijs ändere,
falsch. Du brauchst einen proxy der von 80 bzw 443 auf localhost:3000 „übersetzt“. das kann man mit apache machen, eleganter aber mit nginx. diese proxy virtual hosts haben bei mir immer ein gemeinsames „leeres“ document root.
das installationsverzeichnis von wiki.js solltest Du nie freigeben, dort liegen ja programme und keine inhalte.
normal certbot installiere
den certbot musst Du über aliase im apache oder nginx einbinden.
huch, certbot dürfte einen eigenen server mitbringen, im gegensatz zu dehydrated welches ich immer einsetze.
Port 443 natürlich noch freigeben - kann ich den 80ger dann einfach schließen? Und den 3000 auch?
ich denke wenn Du ein valides zertifikat hast kannst den port 80 zu machen. ich lass den aber immer offen und mach im virtual host einen redirect auf https. den 3000 kannst dann auch zu machen, den braucht dann ja nur mehr der proxy übern localhost.
doch
oh, hast Du ein beispiel für mich bitte?
ip6tables -t nat -A PREROUTING -i enp35s0 -p $PROTOCOL --dport $HOST_PORT -j DNAT --to-destination [fc00::${VM_ID}]:${VM_PORT}
oh, IPv6 NAT auf eine ULA. welche vorteile hat das gegenüber einem forward auf eine public IP? ok, man braucht kein zusätzliches IPv6 netz oder das bestehende splitten. aber ausser topology hiding sonst noch was?
ziemlichen Bastelei werden, wennn man auf einem Server dann eine andere NodeJS Versionen installieren muss.
node.js hat sogar ein eigenes repo. das ist weit entfernt von bastelei. https://github.com/nodesource/…installation-instructions
PostgreSQL gibts fertig in den debian repos.
also kein grund für das ungetüm docker.
für Bud gibts dadurch ein paar lernziele
wo installiert man 3rd party software
wie erstellt man dafür einen eigenen user
wie bindet man ein 3rd party repo ein
wie legt man in postgresql einen user und eine datenbank an
wie erstellt man eine systemd unit
Aber auch /var wird dir keine Probleme bereiten, Du könntest sogar ein Verzeichnis /bud erstellen und es dort reinpacken.
auf manchen systemen gibt es partitionen. da ist im root eventuell nicht genug platz und /var hat vielleicht ein noexec flag.
oder das installationsscript besteht auf einem falschen pfad und mag aber keinen symlink, dann darf man plötzlich mit bind mounts herumhampeln.
am besten man machts gleich von anfang an richtig und gewöhnt es sich auch so an.
Gerade bei binaries ist es manchmal eher ein Ratespiel, ob die nun in /bin, /sbin, /usr/bin /usr/sbin oder sonstwo landen.
nein, das ist klar geregelt in der FHS und sogar in dem von Dir genannten link erklärt. mal abgesehen vom /usr-merge bzw machts der jetzt einfacher.
Was für einen Vorteil bringt mir die docker Installation? Ich habe docker noch nie verwendet, und mir wurde auch eher davon abgeraten... Zumindest vorerst.
sorry, mein edit war ironisch.
docker vermeidet halt jedwelchige abhängigkeiten und versteckt die komplexität der integration. so ähnlich wie wenn Du mit Deinem gesamten haus auf urlaub fahren würdest.
ich nehm halt nur meinen kaffeekocher mit, der muss dann halt in die dortige küche passen.
ich bevorzuge installationen am host und so viel über die systempacketverwaltung wie möglich. da bekommt man die security updates (der abhängigkeiten) nämlich frei haus. und, größter vorteil, man lernt dabei was.
ich installiere (wenn kein .deb vorliegt oder es kein repo gibt) generell nach /opt und lass den kram mit einem eigenen system user (uid < 1000 normalerweise, die entsprechende option von adduser macht das aber eh richtig) laufen.
Hat es irgendeinen Vor- oder Nachteil wenn ich Wiki.js in /home/user/wiki oder in /var/wiki installiere?
in /var hats gar nix verloren, vergleiche letzten absatz in https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch05.html
würde /home oder /opt empfehlen. dass man einen eigenen (system) user dafür verwendet ist obligatorisch.
edit: bist du deppat, manche software sollte man wirklich als docker installieren und nicht der legacy installationsanleitung folgen. https://docs.requarks.io/install/linux
edit2: und in der systemd unit erwähnen sie man möge einen eigen user verwenden, erklären das wie aber mit keinem wort. wieder mal typisch für entwickler die zu blöd sind ordentliche doku zu schreiben, packen ihre shyze dann halt einfach in docker. sorry für den rant.
Finde es trotzdem noch schade, so kann ich meine Server nie umfunktionieren bzw. umbenennen oder gar in eine andere Gruppe stecken, ohne alle Daten zu „verlieren“
doch. einfach die RRDs umbenennen.
die suchmaschinen-zauberwörter dazu lauten munin rename host
Der Sprung von 32GB auf 64GB ist natürlich groß
im netcup portfolio gibts zb nix dazwischen.
warum ich lieber einen Server mit genügend RAM wähle.
das sowieso. aber swap gibt einem eine zusätzliche sicherheitsstufe bevor der oom-killer zuschlägt. und wenn bei der dimensionierung 32 GB ausreichend sind warum soll ich dann nur weil ich kein swap mag den 64 GB server nehmen?
von Munin auf Check-mk wechsle
hier sollte man imho zwischen klassischen monitoring systemen wie nagios, icinga oder checkmk und metrics collection systemen wie munin, collectd, netdata oder prometheus unterscheiden.
RAM so richtig teuer
warum sollte ich mir einen 64 GB RS zulegen wenns auch ein 32 GB RS mit ein wenig swap zur sicherheit tut?
Willst Du einen Bugreport erstellen?
ja, aber erst ende der nächsten woche.
mindestens jedem kunden einmal