|
|
|
|
|
|
|
https://superuser.com/a/294034
-
OpenBSD "dist-upgrade":
> ssh
Last login: Mon Feb 17 11:48:00 2020 from
OpenBSD 6.5 (GENERIC) #9: Tue Jan 14 22:36:38 MST 2020
Welcome to OpenBSD: The proactively secure Unix-like operating system.
Please use the sendbug(1) utility to report bugs in the system.
Before reporting a bug, please try to reproduce it with the latest
version of the code. With bug reports, please try to ensure that
enough information to reproduce the problem is enclosed, and if a
known fix for it exists, include that as well.
headnode# sysupgrade
SHA256.sig 100% |*****************************************************************************************| 2141 00:00
Signature Verified
INSTALL.amd64 100% |****************************************************************************************| 43550 00:00
base66.tgz 100% |*****************************************************************************************| 236 MB 01:08
bsd 100% |*****************************************************************************************| 18250 KB 00:05
bsd.mp 100% |*****************************************************************************************| 18336 KB 00:05
bsd.rd 100% |*****************************************************************************************| 10058 KB 00:02
comp66.tgz 100% |*****************************************************************************************| 72109 KB 00:20
game66.tgz 100% |*****************************************************************************************| 2745 KB 00:00
man66.tgz 100% |*****************************************************************************************| 7418 KB 00:02
xbase66.tgz 100% |*****************************************************************************************| 22092 KB 00:06
xfont66.tgz 100% |*****************************************************************************************| 39342 KB 00:11
xserv66.tgz 100% |*****************************************************************************************| 15757 KB 00:04
xshare66.tgz 100% |*****************************************************************************************| 4482 KB 00:01
Verifying sets.
Fetching updated firmware.
Upgrading.
Connection closed by remote host.
...
...
> ssh
Last login: Mon Feb 17 11:52:26 2020 from
OpenBSD 6.6 (GENERIC) #353: Sat Oct 12 10:45:56 MDT 2019
Welcome to OpenBSD: The proactively secure Unix-like operating system.
Es tut einfach. Und dann nochmal syspatch für die aktuellen Patches seit Release.
|
|
[Dieser Beitrag wurde 3 mal editiert; zum letzten Mal von csde_rats am 17.02.2020 12:03]
|
|
|
|
|
|
|
|
|
|
ich hab seit ein paar Tagen opnsense als Router im Einsatz und das Ding hat bei meinen ersten Spielversuchen auch einen ziemlich robusten Eindruck gemacht. Upgrade von 17.x auf 20.1, einfach ein paar mal "klick klick, reboot, klick klick" und das aktuellste Release läuft. Das war ich bisher weder von Windows noch von Linux gewohnt.
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von hoschi
In einem KDE, also explizit nicht Multi-Seat?
Zwei Mauszeiger möchtest du aber nicht 
| |
Ich hätte gerne ein Pair Programming Setup, aber möchte niemandem meine Tastatur mit meinem Layout zumuten. 
|
|
|
|
|
|
|
|
|
|
|
Quick&dirty workaround in der .${SHELL}rc:
alias asdf='setxkbmap de adnw'
alias hiea='setxkbmap de neoqwertz'
asdf<ENTER> und das Layout ist geswitcht.
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von audax
| | Zitat von hoschi
In einem KDE, also explizit nicht Multi-Seat?
Zwei Mauszeiger möchtest du aber nicht
| |
Ich hätte gerne ein Pair Programming Setup, aber möchte niemandem meine Tastatur mit meinem Layout zumuten.
| |
Hmm *denk*
Ich habe keine Lösung, nur Workarounds:
- Unter GNOME habe ich den Layoutswitcher auf Supertaste + Leertaste, ihr könntet bei der "Übergabe" das immer drücken. Das wird bei GNOME auch schön visuell angezeigt. KDE hat sowas sicher auch.
- Wilde Idee: Ich habe keine Ahnung ob das funktioniert, zwei Rechner nebeneinander und der andere geht per VNC mit Remmina auf den anderen. In den Einstellung von Remmina kann man ein Keyboard Layout festlegen + Use Client Keyboard Mapping
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von hoschi am 17.02.2020 17:00]
|
|
|
|
|
|
|
|
|
-
Seit Jahren mal wieder einen qntm-Link gesehen und es ist a) etwas neues b) solid Gold
https://qntm.org/calendar
e: Und was frisches dazu
https://qntm.org/cd
In my proposed five-tier hierarchy of continuous delivery maturity, the name of each tier is simply the latest day in the working week on which you feel comfortable deploying.
Tier 1: "Friday": You are comfortable pushing to production on a Friday.
...
There are subtiers within "Friday": "first thing Friday", "Friday morning", "Friday afternoon", "2pm Friday", "4:30pm Friday", and so on, asymptotically approaching the weekend as the amount of expected fallout caused by a push shrinks from hours to minutes. The highest possible tier is "close of business, Friday".
There are secret unholy tiers "above" the "Friday" realm where for some reason you consider it acceptable to push to production on a Saturday or a Sunday. These tiers cannot be attained by improving your CD pipeline, nor should they be considered aspirational. Switch off, fool! Stop working on the weekend! You're creating a terrible precedent!
---
Wekan-Negativa:
- Damit Benachrichtigungsmails verschickt werden, muss man seine Mailaddresse bestätigen, selbst wenn man einen Einladungslink an selbige bekommen hat und sich damit angemeldet hat.
-- Entweder läuft der Link ab (was in der Mail nicht steht) oder das Verifizieren funktioniert aus $Gründen nicht (Ticket existiert, ist schon was älter)
-- Es gibt keine Möglichkeit als Nutzer diese Mail nochmal anzufordern
-- Es gibt keine Möglichkeit als Admin diese Mail nochmal zu verschicken
-- Es wird einem als Nutzer nicht angezeigt, dass man seine Mailaddresse noch verifizieren muss
-- Als Admin kann man nicht einfach sagen "Die Mail ist verifiziert, basta.", bzw. nur per händischem Rumfummeln in der Datenbank
- Generell können Admins nix
- Es gibt keinen Activityfeed insgesamt.
- Feeds (pro Board und Karte) gibt es in der Oberfläche, aber nicht als RSS.
- Man kann nicht einfach Nutzer anlegen.
(- Die deutsche Übersetzung scheint von Google Translate zu sein)
- Es benutzt Markdown, aber das ist teilweise kaputt. Der benutzte Markdown-Parser unterstützt offensichtlich Github-Style-Checklisten (- [ ] foo - [ ] bar), aber dargestellt wird das als - <input type='checkbox' checked='checked'> .
- Erwähnungen von Nutzern funktionieren nur im Happy-Path, man kann z.B. Leerzeichen im Namen haben, und das wird dann auch escaped (@foo => @"foo bar"), nur eben erwähnt es die Person dann halt nicht. Ups.
- Wenn man eine Karte öffnet, ist das kein Popup, sondern eine Spalte rechts von der aktuellen Liste. Das sieht ja ganz nett aus, wenn man maximal eine handvoll Listen hat und der Browser aufm 27" Bildschirm maximiert ist. Ist aber echt blöde UX in allen anderen Fällen.
- Es gibt eine Konfigurationsoption für den HTTP-Port, aber nicht für die Listen-Addresse. Die ist 0.0.0.0. Ergo Firewallregel nötig.
Die Backup/Restore-Story von ****DB macht auch einen echt soliden Eindruck. ***dump funktioniert nur für den "single machine single shard" Fall, wenn ich die Doku richtig lese. Für den Sharded-Fall ist die Antwort...? Get fucked m8 Hab alle Shards auf dem gleichen LVM und mach Snapshots? Kauft unseren Webscale-As-A-Service Managershizzle? Hä?
---
Offsite-Backups über ganz schmalen Uplink, wie?
=> Hatte ich mir vor einen Jahr drüber den Kopf zerbrochen, hatte keine guten Ideen. Borg Dedup funktioniert ganz gut, aber wesentliche Daten liegen auf einer VM und das hat die Deduplizierung aufgepustet wie eine Splittergranate, jedes Bit wird zu Megabytes. Wir müssen aber mit 5-10 s/MB auskommen.
Jetzt: Der eigentlich offensichtliche Ansatz, "die VM ist mir doch Wumpe, es geht um die Nutzdaten" -> Datenbank-Dump an Borg verfüttern? -> Ähnlicher Splittergranateneffekt. Besser: 1x Datenbank-Dump verfüttern, danach differenzielle Dumps an die gleiche Datei anhängen => der DB-Server gruppiert damit alle Änderungen für uns zusammen => wir müssen nur noch die Änderungen übertragen.
Dann gelentlich mal die Datei löschen und von neuem Anfangen. Könnte fast funktionieren. Das "von neuem Full-Dump/Backup" anfangen wird aber wieder aufblühen wie eine Granate und entsprechend ewig dauern, bis es übertragen ist. Natürlich immernoch viel effizienter als ohne Borg und Dedup, aber ersten Tests nach ~einige Gigabytes (bei ~1.5 hr/GB).
Realitätsabgleich: Backup auf eine einzelne 08/15 Festplatte liefert 400+ GB/hr. (Tendenziell weniger, wenn man Borg benutzt und die Daten tatsächlich übertragen muss. Merksatz: Borg ist gut im Arbeit vermeiden, aber nicht sonderlich schnell im Arbeiten.)
|
|
[Dieser Beitrag wurde 9 mal editiert; zum letzten Mal von csde_rats am 17.02.2020 21:47]
|
|
|
|
|
|
|
|
|
|
Wir sind Mittwoch. Wer noch?
|
|
|
|
|
|
|
|
|
|
|
WIE SCHNELL IST DIESES 100 GBIT/S VIRTIO NETZWERKINTERFACE EIGENTLICH WIRKLICH????
[ ID] Interval Transfer Bitrate
[ 5] 0.00-1.00 sec 698 MBytes 5.86 Gbits/sec
[ 5] 1.00-2.00 sec 788 MBytes 6.61 Gbits/sec
[ 5] 2.00-3.00 sec 737 MBytes 6.19 Gbits/sec
[ 5] 3.00-4.00 sec 728 MBytes 6.10 Gbits/sec
[ 5] 4.00-5.00 sec 705 MBytes 5.91 Gbits/sec
[ 5] 5.00-6.00 sec 746 MBytes 6.26 Gbits/sec
[ 5] 6.00-7.00 sec 707 MBytes 5.93 Gbits/sec
[ 5] 7.00-8.00 sec 725 MBytes 6.08 Gbits/sec
[ 5] 8.00-9.00 sec 784 MBytes 6.57 Gbits/sec
[ 5] 9.00-10.00 sec 785 MBytes 6.59 Gbits/sec
[ 5] 10.00-10.03 sec 19.1 MBytes 5.72 Gbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate
[ 5] 0.00-10.03 sec 7.25 GBytes 6.21 Gbits/sec receiver
CPU Linux-Seite: *gähnreck*
CPU Windows-VM: ~60 %, benutzt mehrere Kerne, aber keinen zu 100 %
Parallel geht ein bisschen was, aber die CPU ist Windows-seitig ganz klar der Bottleneck. htop attribuiert 350 % CPU (VM hat vier Kerne) an qemu. Not sure if accurate.
[ ID] Interval Transfer Bitrate
[ 5] 0.00-10.02 sec 3.82 GBytes 3.28 Gbits/sec receiver
[ 7] 0.00-10.02 sec 3.78 GBytes 3.24 Gbits/sec receiver
[ 10] 0.00-10.02 sec 3.75 GBytes 3.21 Gbits/sec receiver
[ 12] 0.00-10.02 sec 3.72 GBytes 3.19 Gbits/sec receiver
[SUM] 0.00-10.02 sec 15.1 GBytes 12.9 Gbits/sec receiver
UDP Time!
[ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams
[ 5] 0.00-1.00 sec 108 MBytes 909 Mbits/sec 0.006 ms 0/13871 (0%)
[ 5] 1.00-2.00 sec 109 MBytes 918 Mbits/sec 0.009 ms 0/14011 (0%)
[ 5] 2.00-3.00 sec 113 MBytes 946 Mbits/sec 0.004 ms 0/14437 (0%)
[ 5] 3.00-4.00 sec 108 MBytes 907 Mbits/sec 0.006 ms 0/13846 (0%)
[ 5] 4.00-5.00 sec 110 MBytes 926 Mbits/sec 0.007 ms 0/14126 (0%)
[ 5] 5.00-6.00 sec 110 MBytes 926 Mbits/sec 0.005 ms 0/14128 (0%)
[ 5] 6.00-7.00 sec 112 MBytes 939 Mbits/sec 0.006 ms 0/14322 (0%)
[ 5] 7.00-8.00 sec 110 MBytes 924 Mbits/sec 0.009 ms 0/14101 (0%)
[ 5] 8.00-9.00 sec 110 MBytes 924 Mbits/sec 0.011 ms 0/14104 (0%)
[ 5] 9.00-10.00 sec 111 MBytes 932 Mbits/sec 0.009 ms 0/14220 (0%)
[ 5] 10.00-10.01 sec 1.52 MBytes 889 Mbits/sec 0.003 ms 0/194 (0%)
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams
[ 5] 0.00-10.01 sec 1.08 GBytes 925 Mbits/sec 0.003 ms 0/141360 (0%) receiver
CPU Linux-Seite: Ich kann nichtmal sehen, dass da irgendwie Kernel-Streifchen auftauchen. iperf3 gammelt bei 10 % rum.
CPU Windows-Seite: Ein Kern erreicht jetzt ~90 %
GEHT DA NOCH WAS??
Hyper-V Enlightenments in libvirt ankreuzen!
[ 5] 0.00-1.00 sec 1022 MBytes 8.57 Gbits/sec
[ 5] 1.00-2.00 sec 984 MBytes 8.25 Gbits/sec
[ 5] 2.00-3.00 sec 1.03 GBytes 8.86 Gbits/sec
[ 5] 3.00-4.00 sec 1008 MBytes 8.45 Gbits/sec
[ 5] 4.00-5.00 sec 1.03 GBytes 8.84 Gbits/sec
[ 5] 5.00-6.00 sec 1013 MBytes 8.50 Gbits/sec
[ 5] 6.00-7.00 sec 1.00 GBytes 8.62 Gbits/sec
[ 5] 7.00-8.00 sec 998 MBytes 8.37 Gbits/sec
[ 5] 8.00-9.00 sec 1.01 GBytes 8.71 Gbits/sec
[ 5] 9.00-10.00 sec 1.05 GBytes 9.03 Gbits/sec
[ 5] 10.00-10.02 sec 19.5 MBytes 9.02 Gbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate
[ 5] 0.00-10.02 sec 10.1 GBytes 8.62 Gbits/sec receiver
...
[ ID] Interval Transfer Bitrate
[ 5] 0.00-10.01 sec 4.58 GBytes 3.93 Gbits/sec receiver
[ 8] 0.00-10.01 sec 4.59 GBytes 3.93 Gbits/sec receiver
[ 10] 0.00-10.01 sec 4.59 GBytes 3.94 Gbits/sec receiver
[ 12] 0.00-10.01 sec 4.56 GBytes 3.91 Gbits/sec receiver
[SUM] 0.00-10.01 sec 18.3 GBytes 15.7 Gbits/sec receiver
UDP?
[ 5] 0.00-1.00 sec 170 MBytes 1.43 Gbits/sec 0.007 ms 0/21792 (0%)
[ 5] 1.00-2.00 sec 177 MBytes 1.48 Gbits/sec 0.005 ms 0/22625 (0%)
[ 5] 2.00-3.00 sec 191 MBytes 1.60 Gbits/sec 0.005 ms 0/24410 (0%)
[ 5] 3.00-4.00 sec 182 MBytes 1.53 Gbits/sec 0.004 ms 0/23311 (0%)
[ 5] 4.00-5.00 sec 187 MBytes 1.57 Gbits/sec 0.008 ms 0/23930 (0%)
[ 5] 5.00-6.00 sec 167 MBytes 1.40 Gbits/sec 0.008 ms 0/21401 (0%)
[ 5] 6.00-7.00 sec 181 MBytes 1.51 Gbits/sec 0.016 ms 0/23106 (0%)
[ 5] 7.00-8.00 sec 179 MBytes 1.50 Gbits/sec 0.006 ms 0/22939 (0%)
[ 5] 8.00-9.00 sec 189 MBytes 1.59 Gbits/sec 0.017 ms 0/24225 (0%)
[ 5] 9.00-10.00 sec 178 MBytes 1.50 Gbits/sec 0.006 ms 0/22845 (0%)
[ 5] 10.00-10.01 sec 1.67 MBytes 1.31 Gbits/sec 0.003 ms 0/214 (0%)
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams
[ 5] 0.00-10.01 sec 1.76 GBytes 1.51 Gbits/sec 0.003 ms 0/230798 (0%) receiver
immerhinschnelleralsgigabit
Interessanter Nebeneffekt der Hyper-V Settings ist, dass in jedem Test die Host-seitige CPU-Nutzung niedriger war (50-80 %); im Gast wurden gleiche Werte berichtet.
Der Idle-CPU-Verbrauch dieser VM ist nach wie vor ziemlich massiv (80-100 % aufm Host, mit 10-15 % im Gast),
|
|
[Dieser Beitrag wurde 2 mal editiert; zum letzten Mal von csde_rats am 18.02.2020 0:55]
|
|
|
|
|
|
|
|
|
windows als VM gast ist ne frechheit, das ding heizt konstant vor sich hin und frisst cpu.
hab auf der arbeit das "coroporate windows" auch in der VM und schiess das regelmässig ab wenn ich die volle rechenleistung brauch.
dafür dass ich das für 2-3 aktionen im monat brauch, mit den admins aber ausgemacht haben (wegen updates!!!!11!) das mindestens einmal am tag zu starten ist das totaler overkill.
wäre froh wenn das endlich alles auf nem terminal server wär und ich das ding /dev/null-en könnte.
|
|
|
|
|
|
|
|
|
|
|
ne normale Windows-VM ist als Gast eigentlich extrem genügsam. Unsere 2019er Nameserver brauchen aktuell so 20 MHz, VMware meldet so 120 MB Arbeitsspeicher in Nutzung.
Was aber tödlich ist sind leicht ältere Windows-Server (2016 und älter), die darauf konfiguriert sind, sich mit nem WSUS zu unterhalten. Da braucht der "gibts was neues"-Prozess schon mal 15 Minuten lang alles, was so ne CPU hergibt. Das war analog zu Windows 10 15xx/16xx ähnlich, wurde dann irgendwann deutlich besser und ist jetzt zu 1909/Server 2019-Zeiten ganz entspannt.
Und wenn man nen Exchange betreibt, ist sowieso schluss mit Ruhe. Gigabytes an Logs, Last bis unters Dach, fast schon unabhängig davon, was so an Mails reinkommt.
|
|
|
|
|
|
|
|
|
|
|
aber wer bitte nutzt sowas denn in der realität?
|
|
|
|
|
|
|
|
|
|
|
|
nur die, die ihr Geld mit was anderem verdienen. Also fast alle.
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von GarlandGreene
ne normale Windows-VM ist als Gast eigentlich extrem genügsam. Unsere 2019er Nameserver brauchen aktuell so 20 MHz, VMware meldet so 120 MB Arbeitsspeicher in Nutzung.
| |
RES SHR S %CPU %MEM TIME+ COMMAND
6,0g 19036 S 81,2 38,7 108:10.17 qemu-system-x86
weint in kvm weil es kostenlos ist
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von csde_rats
Wekan-Negativa:
- Damit Benachrichtigungsmails verschickt werden, muss man seine Mailaddresse bestätigen, selbst wenn man einen Einladungslink an selbige bekommen hat und sich damit angemeldet hat.
-- Entweder läuft der Link ab (was in der Mail nicht steht) oder das Verifizieren funktioniert aus $Gründen nicht (Ticket existiert, ist schon was älter)
-- Es gibt keine Möglichkeit als Nutzer diese Mail nochmal anzufordern
-- Es gibt keine Möglichkeit als Admin diese Mail nochmal zu verschicken
-- Es wird einem als Nutzer nicht angezeigt, dass man seine Mailaddresse noch verifizieren muss
-- Als Admin kann man nicht einfach sagen "Die Mail ist verifiziert, basta.", bzw. nur per händischem Rumfummeln in der Datenbank
- Generell können Admins nix
- Es gibt keinen Activityfeed insgesamt.
- Feeds (pro Board und Karte) gibt es in der Oberfläche, aber nicht als RSS.
- Man kann nicht einfach Nutzer anlegen.
(- Die deutsche Übersetzung scheint von Google Translate zu sein)
- Es benutzt Markdown, aber das ist teilweise kaputt. Der benutzte Markdown-Parser unterstützt offensichtlich Github-Style-Checklisten (- [ ] foo - [ ] bar), aber dargestellt wird das als - <input type='checkbox' checked='checked'> .
- Erwähnungen von Nutzern funktionieren nur im Happy-Path, man kann z.B. Leerzeichen im Namen haben, und das wird dann auch escaped (@foo => @"foo bar"), nur eben erwähnt es die Person dann halt nicht. Ups.
- Wenn man eine Karte öffnet, ist das kein Popup, sondern eine Spalte rechts von der aktuellen Liste. Das sieht ja ganz nett aus, wenn man maximal eine handvoll Listen hat und der Browser aufm 27" Bildschirm maximiert ist. Ist aber echt blöde UX in allen anderen Fällen.
- Es gibt eine Konfigurationsoption für den HTTP-Port, aber nicht für die Listen-Addresse. Die ist 0.0.0.0. Ergo Firewallregel nötig.
| |
- Standardmäßig stehen alle Boards für jeden Nutzer auf "Stumm", was Benachrichtigungen selbst auf eigenen Karten unterdrückt. Aufgrund des Designs sieht die Anzeige, dass das Board stummgeschaltet ist, aber so aus, als ob es der Knopf zum Stummschalten ist und der nicht gedrückt ist.
- Die Benachrichtigungsmails, wenn sie dann funktionieren, sind seeeeeehr rudimentär. HTML-Mail komplett ohne Markup (also auch ohne klickbare Links) mit diesem Inhalt: {{Nutzer}} commented on card "{{Karte}}": "{{kommentar}}" https://todo....
-- Wenn mehrere Benachrichtigungsmails kurz nacheinander verschickt werden, werden die als eine einzelne Mail verschickt, und zwar so (ohne weiteres Markup): {{Nutzer}} commented on card "{{Karte}}": "{{kommentar}}" https://todo.... [Boardname] {{Karte}} {{Nutzer}} commented on card "{{Karte}}": "{{kommentar}}" https://todo.... [Boardname] {{Karte}} {{Nutzer}} commented on card "{{Karte}}": "{{kommentar}}" https://todo.... [Boardname] {{Karte}} {{Nutzer}} commented on card "{{Karte}}": "{{kommentar}}" https://todo....
(Das unterstrichene wäre der Betreff, wenn es als einzelne Mail verschickt werden würde)
-- Für Benachrichtigungen abseits von Kommentaren wird es dann abenteuerlich:
Karte jemandem zuweisen:
{{nutzer}} act-joinAssignee https://todo...
Karte ein Label hinzufügen:
{{nutzer}} Added label __label__ to card "{{karte}}" at list "{{liste}}" at swimlane Default at board "{{board}}" https://todo...
-- Man kriegt Benachrichtigungsmails für Sachen, die man selber gemacht hat.
- Man kann z.B. seine gebookmarkten Boards, die effektiv als Tabs auftauchen, nicht umsortieren.
Die Funktionalität ist größtenteils da, aber alles was abseits von dem Board an sich passiert ist einfach arg unpolished. Es fühlt sich nicht wirklich wie ein über fünf Jahre altes Projekt an. Wenn man Bock auf JS hat, könnte man aber sicher sehr schnell viele dieser Dinge fixen, es ist ja viel Kleinkram. Andererseits hat es aber evtl. auch Gründe (im Sinne von "nicht gut"), warum diese Dinge alle nicht gefixt sind.
|
|
[Dieser Beitrag wurde 3 mal editiert; zum letzten Mal von csde_rats am 18.02.2020 17:47]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von Oli
| | Zitat von Oli
Geil rats, das mache ich heute Abend auch mal. Ich ergänze dein tutorial dann um android.
Die online community jizzt ja herum wie sonst was wegen wireguard.
| |
Läuft. Dann kann ich ja mein fritzbox vpn abschalten. Danke für die Config.
| |
PS: Bei näherem Drübernachdenken müsste das so auch ohne NAT (Masquerade) funktionieren, wenn der WG-Server das Standardgateway vom fraglichen Netz ist. Wenn er das nicht ist, wird er zwar Pakete ins Netz hinsenden, aber die Antwortpakete aus dem Netz landen beim Standardgateway, was die droppt, weil es keine Route kennt. Alternativ könnte man ggfs. im Standardgateway eine Route hinterlegen ala 10.87.71.0/24 via 192.168.10.<wg server>. Das habe ich aber (noch) nicht probiert.
|
|
|
|
|
|
|
|
|
|
|
Ich komme mit meinem Homeserver etwas vorran hier, allerdings hat sich jetzt ein neues Problem aufgetan, das ich gerne lösen würde.
Folgendes Setup:
PC mit Linuxmint drauf. Darauf läuft Docker. Ich habe einen Nextcloud-Container, der auch läuft und einen Only-Office Communityserver Container, der auch läuft und auf den die Nextcloud auch zugreifen kann.
Ich habe es auch inzwischen geschafft eine meiner Domains mit dem Server zu verknüpfen über den A Record.
Jetzt hätte ich natürlich noch ganz gerne die ganze Sache SSL verschlüsselt. Mein Hirn sagt mir, dass es im Nextcloudcontainer irgendwo ein Verzeichnis gibt in das das Let's encrypt Zertifikat kommt. Das Verzeichnis muss ich mittels Volume persistent machen. Oder muss das SSl-Zertifikat auf den Host außerhalb von Docker?
Ich komme nicht so recht weiter. Jemand einen Tipp oder ne verständliche Anleitung für mich?
|
|
|
|
|
|
|
|
|
|
|
Kommt auf dein Setup an.
Typisch in solchen Hosting-Situation ist ein Reverse-Proxy-Setup. Dabei betreibst du einen "Frontend WebServer" auf dem die öffentlichen Anfragen aufschlagen. Der terminiert typischerweise auch die SSL-Verbindung, d.H. der braucht die Certs.
Der "Frontend Webserver" macht dann sog. Reverse-Proxy requests zu den internen "Backend WebServern". Das wäre dann der Container und der darin laufende "Application WebServer".
Das ganze hat den Vorteil, dass eben der Frontent WebServer nicht im Container ist und man dadurch viel bequemer die SSL-Settings und andere Configs maintainen kann. Außerdem fungiert der Frontend WebServer dann auch als Weiche für z.B. LoadBalancing oder wenn man eine neue Version des Containers hostet, etc. pp.
https://en.wikipedia.org/wiki/Reverse_proxy
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von GH@NDI
Kommt auf dein Setup an.
Typisch in solchen Hosting-Situation ist ein Reverse-Proxy-Setup. Dabei betreibst du einen "Frontend WebServer" auf dem die öffentlichen Anfragen aufschlagen. Der terminiert typischerweise auch die SSL-Verbindung, d.H. der braucht die Certs.
Der "Frontend Webserver" macht dann sog. Reverse-Proxy requests zu den internen "Backend WebServern". Das wäre dann der Container und der darin laufende "Application WebServer".
Das ganze hat den Vorteil, dass eben der Frontent WebServer nicht im Container ist und man dadurch viel bequemer die SSL-Settings und andere Configs maintainen kann. Außerdem fungiert der Frontend WebServer dann auch als Weiche für z.B. LoadBalancing oder wenn man eine neue Version des Containers hostet, etc. pp.
https://en.wikipedia.org/wiki/Reverse_proxy
| |
Ah, der Begriff ist mir schon begegnet. Wird häufig mit nginx gemacht oder? Wie gehe ich vor? Installieren und nach Doku einrichten? Ich forsche mal. Danke!
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von Farbkuh am 21.02.2020 16:27]
|
|
|
|
|
|
|
|
|
|
Nginx ist da ganz beliebt, weil recht angenehm zu konfigurieren. Technisch geben sich da Apache und Nginx aber nicht mehr viel.
|
|
|
|
|
|
|
|
|
|
|
Ich würde das so nicht unterschreiben. 
|
|
|
|
|
|
|
|
|
|
|
|
Ich werfe mal noch Traefik in den Raum, wenn eh schon Docker verwendet wird.
|
|
|
|
|
|
|
|
|
|
|
Vor Jahren musste ich einen Kunden zu Nginx migrieren weil der 50gb+ HTTP Uploads als streaming-multipart-upload wollte. Und Apache damals noch den kompletten Request-Body erst gefressen hat, bevor er an den BackendWebServer geschickt wurde.
Das einzige was mir jetzt spontan einfällt, was evtl. nicht fluffig läuft sind so Sachen wie WebSocket-Verbindungen zum BackendServer relayen. 
Aber ich lass mich gerne eines besseren belehren
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von SwissBushIndian
Ich werfe mal noch Traefik in den Raum, wenn eh schon Docker verwendet wird.
| |
Schau ich mir auch mal an.
@Über mir: ich kenne ein paar dieser Wörter.
|
|
|
|
|
|
|
|
|
|
|
acme.sh und nginx und stateless mode
Eventuell caddy? Das scheint der aktuelle Hypsterserver zu sein
# cat /etc/nginx/tls.conf
listen 443 ssl http2;
ssl_certificate /etc/nginx/deincert.pem;
ssl_certificate_key /etc/nginx/deinkey.pem;
ssl_ciphers "TLS_CHACHA20_POLY1305_SHA256:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES128-GCM-SHA256";
ssl_protocols TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers on;
(iirc kann man bei nginx auch beides in eine Datei packen. Der schickt dann natürlich nicht den PRIVATE KEY über die Leitung ;D)
Und dann
# cat /etc/nginx/sites-enabled/meinecloud.ichbims.de
server {
include tls.conf;
server_name meinecloud.ichbims.de;
location / {
proxy_pass http://127.0.0.1:1234;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "Upgrade";
}
}
# cat /etc/nginx/sites-enabled/default
server {
listen 80 default_server;
server_name _;
return 301 https://$host$request_uri;
}
Die beiden proxy_set_header ermöglichen WebSocket-Verbindungen, die ja häufig von den modernen JS-SPA-Frontends benötigt werden.
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von csde_rats am 21.02.2020 17:11]
|
|
|
|
|
|
|
|
|
| | Zitat von GH@NDI
Das ganze hat den Vorteil, dass eben der Frontent WebServer nicht im Container ist und man dadurch viel bequemer die SSL-Settings und andere Configs maintainen kann.
| |
bis auf dass der nginx meistens innem container nebendran liegt
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von GH@NDI
Das einzige was mir jetzt spontan einfällt, was evtl. nicht fluffig läuft sind so Sachen wie WebSocket-Verbindungen zum BackendServer relayen.
| |
huh? ja klar, die muss man noch extra eintragen, aber das ist täglich brot. was man halt rausfinden muss wenn nextcloud sowas braucht (was ich nicht weiss) welchen endpoint man da weiterleiten muss. aber nginx vor ner nextcloud ist ne kombi die es sicherlich sehr sehr oft gibt, da findet sich sicherlich was.
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von [KdM]MrDeath
| | Zitat von GH@NDI
Das einzige was mir jetzt spontan einfällt, was evtl. nicht fluffig läuft sind so Sachen wie WebSocket-Verbindungen zum BackendServer relayen.
| |
huh? ja klar, die muss man noch extra eintragen, aber das ist täglich brot. was man halt rausfinden muss wenn nextcloud sowas braucht (was ich nicht weiss) welchen endpoint man da weiterleiten muss. aber nginx vor ner nextcloud ist ne kombi die es sicherlich sehr sehr oft gibt, da findet sich sicherlich was.
| |
Ich meinte ja auch, dass Nginx das kann aber ich nicht die Hand dafür ins Feuer legen würde, dass der Apache das gut hinbekommt.
|
|
|
|
|
|
|
|
|
|
Neue ThinkPads im Mai
|
https://www.computerbase.de/2020-02/lenovo-thinkpad-l-t-x-ryzen-4000-2020/
Beim X13 soll AMD, zumindest mit zurechtgepatchen Windowstreibern, minimal länger laufen als das Intel-Modell. Die Modelle mit besserer Grafikleistung - also die von AMD - bekommen kein 4K Display im T14. Komisch wird es dann aber beim X13, da bekommt das richtige Modell kein 4K, das Yogazeug schon. Scheint wohl nur nach vermuteter Absatzmöglichkeit zu gehen. Leider schafft das eine selbsterfüllende Prophezeiung. 4K OLED im T13 wäre schon sehr toll.
Die Intelmodelle scheinen (laut heise.de) nur Comet-Lake mit 14nm zu bekommen, also vor allem die alten Grafikchips mit erheblich weniger Grafikleistung. Der Vorteil von Ice-Lake in 10 nm ist die höhere Grafikleistung. Damit habe ich nicht gerechnet. Ich habe mit AMD geliebäugelt, mit so viel Druck Richtung AMD gestupst zu werden ist eher unerwartet. Hoffentlich passt die Energieverwaltung von AMD unter Linux endlich.
|
|
[Dieser Beitrag wurde 7 mal editiert; zum letzten Mal von hoschi am 24.02.2020 21:44]
|
|
|
|
|
|
|
|
|
|
Golem meint womöglich auch Ice-Lake CPUs.
|
|
|
|
|
|
|
|
| Thema: Der Linux-Thread 100 != 0x24 ( Ein Kernelupgrade später... ) |
