[Sammelthread] Proxmox Stammtisch

Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Brauche ich da nur den alte Netzwerk Adpater löschen im LXC! Legen dann eine neuen Netzwerk Adpater an, mit der gleich IP Adresse und der MAC Adresse? Das man das aus der alten Adpater raus kopiert und wieder ein fügt im neuen.

Oder gibt es da ein Ordner, wo man es auch manuell umschreiben kann?
 
Zuletzt bearbeitet:
Keine Ahnung wie das bei LXC ist, aber bei einer VM trägt man das unter Hardware -> Netwrok Device -> Fenster oben links: Brige = vmbr0 ein.
Ev. hast Du ja auch mehrere Bridges und das dort noch nicht angepasst. Oder noch keinen neustart gemacht, das die geänderten Einstellungen noch nicht angewendet werden.
 
Im Endeffekt genauso

1715169959568.png
 
Ich hab ne Debian lxc mit docker und portainer (drauf dann pihole etc).
Aber Debian startet portainer nicht automatisch nach einem Neustart des containers.
Restart always hab ich drin (die Standard Installation eben.
docker run -d -p 8000:8000 -p 9443:9443 --name portainer --restart=always -v /var/run/docker.sock:/var/run/docker.sock -v portainer_data:/data portainer/portainer-ce:latest

edit:
Lösung war dass der Container einfach nur extrem langsam bootet. Aufgrund des IPv6 Protokolls auf "DHCP". Jetzt passt alles
 
Zuletzt bearbeitet:
Abend zusammen,

ich habe seit kurzem Proxmox auf meinem Homeserver laufen, als VM in Proxmox habe ich nun TrueNAS Scale als NAS eingerichtet. Jedoch möchte ich meine VMs etc. auf dem ZFS Pool, welcher in TrueNAS konfiguriert wurde backuppen. Ich habe gesehen das manche ein SMB Share dafür einrichten, andere wieder herum iSCSI nutzen, hat jemand Erfahrung damit, bzw. ist das eine besser als das andere?
 
Ich habe gesehen das manche ein SMB Share dafür einrichten, andere wieder herum iSCSI nutzen, hat jemand Erfahrung damit, bzw. ist das eine besser als das andere?
Fürn VM-Backup (Linux/Proxmox => Linux/TrueNAS) würde ich eher NFS nutzen (nicht SMB). iSCSI ist ein Blocklevel-Storage und somit eigentlich nicht für den Zugriff mehrerer Clients ausgelegt. Man nutzt das eher für Netzwerk-Boot und nicht für gemeinsame Shares. SMB nimmt man eher für Plattform unabhängige Shares (Linux,Windows,macOS) oder Shares mit komplexer Berechtigungsstruktur (z.B. Domain Controller).
 
Um SSL ging es mir gar nicht wirklich, das war nur eine Nebensache, die mir aufgefallen war.

Ich wollte eigentlich eher wissen, ob man für den Betrieb von napp-it auf dem Server (in diesem Fall Proxmox)
  • a) einen Apache + von dir entwickelte perl-Scripte installiert oder
  • b) napp-it nur als client über standardisierte Protokolle (wie z.B. SSH oder die Proxmox-API) mit dem Server kommuniziert und man das prinzipiell auf jedem PC als reine Client-Anwendung laufen lassen kann, ohne den Server via perl-API zu erweitern
Sorry, ich hab mich da vielleicht etwas missverständlich ausgedrückt. Ich gehe von a) aus und beziehe mich deshalb wegen der Security-Anforderungen auf eben genau diese perl-Scripte, welche die API für die napp-it Storage-Verwaltung als root bereit stellen.
Falls in deinen perl-Scripten also eine Sicherheitslücke aufträte, könnte man diese (ohne die von dir vorgeschlagenen zusätzlichen Firewall-Restriktionen) ausnutzen, um als root Befehle auf dem Server auszuführen... Ich hab mir den Quellcode nicht näher angeschaut - es war nur eine Verständnisfrage, wie napp-it aufgebaut ist.

Im aktuellen napp-it cs kann man einen https Server nutzen (mit "unsicherem" selbst signiertem Zertifikat oder einen beliebigen https Server mit gültigem Zertifikat) um Befehle an einen Server oder dessen Antwort verschlüsselt zu übertragen. Damit umgeht man das Problem dass web-guis auf Servern im LAN meist kein valides öffentliches Zertifikat haben.
 
Im aktuellen napp-it cs kann man einen https Server nutzen
Sehr schön.

Damit umgeht man das Problem dass web-guis auf Servern im LAN meist kein valides öffentliches Zertifikat haben.
Das habe ich tatsächlich so gelöst, dass ich von Nginx-Proxy-Manager über meine meinedomain.duckdns.org Adresse ein Letsencrypt-Wildcard-Zertifikat abholen lasse und den lokalen DNS als Standarddomain meinedomain.duckdns.org auflösen lasse.
So kann ich das Wildcard-Zertfikat auch für mein internes LAN nutzen (z.B. https://napp-it.meinedomain.duckdns.org wird dann auf die 192.168.100.21 aufgelöst, nicht auf eine IPv4 im Internet). Das hat auch ein paar "Gefahren" aber bisher fahre ich damit sehr gut - einziger wirklicher Nachteil ist der sehr lange Domain-Name, aber das kriegt man mit QR-Codes ganz gut in den Griff :-)
 
Zuletzt bearbeitet:
Hat mal jemand über Proxmox auf ARM64 nachgedacht?
Ich frage deshalb:
und:
80 ARMv8 Kerne sollten für das ganz normale Glump daheim doch reichen?
 
Ich verzweifel gerade meinen Conbee2 USB-Stick erfolgreich in einem unprivigled LXC zu nutzen bzw. dass er in der deConz/Phoscon-App Software auftaucht/sich verbindet.
Proxmox 8.2 und ein Debian 12 LXC

Host Infos und Ausgaben:
lsusb
Bus 001 Device 106: ID 1cf1:0030 Dresden Elektronik ZigBee gateway [ConBee II]
ls -l /dev/bus/usb/001/106
crw-rw-rw- 1 root users 189, 105 May 17 13:58 /dev/bus/usb/001/106
ls -l /dev/serial/by-id/
total 0
lrwxrwxrwx 1 root root 13 May 17 13:58 usb-dresden_elektronik_ingenieurtechnik_GmbH_ConBee_II_DE2696692-if00 -> ../../ttyACM0
ls -l /dev/ttyACM*
crw-rw-rw- 1 root root 166, 0 May 17 14:49 /dev/ttyACM0

Und es gibt folgende udev Regel
SUBSYSTEMS=="tty", ATTRS{idVendor}=="1cf1", ATTRS{idProduct}=="0030", MODE="0666"

In der .conf des LXC habe ich folgende eingetragen:
lxc.cgroup2.devices.allow: c 189:* rwm
lxc.mount.entry: usb-dresden_elektronik_ingenieurtechnik_GmbH_ConBee_II_DE2696692-if00 dev/serial/by-id/usb-dresden_elektronik_ingenieurtechnik_GmbH_ConBee_II_DE2696692-if00 none bind,optional,create=file
lxc.cgroup2.devices.allow: c 166:* rwm
lxc.mount.entry: /dev/ttyACM0 dev/ttyACM0 none bind,optional,create=file

Im Container bekomme ich folgende Ausgaben
lsusb
Bus 001 Device 108: ID 1cf1:0030 Dresden Elektronik ZigBee gateway [ConBee II]
ls -l /dev/bus/usb/001/108
crw-rw-rw- 1 root root 189, 107 May 17 15:38 /dev/bus/usb/001/108
ls -l /dev/serial/by-id/
total 0
---------- 1 root root 0 May 17 15:39 usb-dresden_elektronik_ingenieurtechnik_GmbH_ConBee_II_DE2696692-if00
ls -l /dev/ttyACM0
crw-rw-rw- 1 nobody nogroup 166, 0 May 17 15:38 /dev/ttyACM0


Meine Vermutung:
Das Gerät ist also sichtbar im unpriviligierten LXC, aber es stimmt etwas mit den Rechten und Zugehörigenkeiten nicht.
Daher erscheint der Stick auch als nicht verbunden in der Phoscon-App als Gateway.
(habe es mit --dev=/dev/serial/by-id/usb-dresden_elektronik_ingenieurtechnik_GmbH_ConBee_II_DE2696692-if00 als Startparameter für deConz probiert)

Was ist mein Fehler und was genau, muss ich wie korrigieren?
 
Achtung, bin mir da jetzt auch nicht sicher. Bei meiner Recherche zu NFS und Docker im LXC hab ich was ähnliches gefunden. Der User der den Dienst startet, hat damit afaik keinen Zugriff auf /dev/tty... Entweder User in die Gruppe nogroup, oder dem Port andere User/Gruppen zuweisen. Soweit wäre das jetzt zumindest meine Interpretation
 
Hm, schräg, es geht nun.
Korrektur auf dem Host war noch ein
chmod o+rw /dev/ttyACM0
nötig.
Was ich geändert habe war noch geändert haben war der Startparameter von deConz statt von --dev=/dev/serial/by-id/usb....
auf --dev=/dev/ttyACM0
Und nun läuft es.
Mal schauen, ob es einen reboot überlebt.
 
Zuletzt bearbeitet:
Proxmox als SMB Server ohne Storage VM

 
Proxmox als SMB Server ohne Storage VM
Weißt du was ich mal interessant finden würde:

OmniOS ist ja schon länger etwas, mit dem ich liebäugele, insbesondere wegen dem In-Kernel-SMB Server, der die Benutzerverwaltung relativ einfach macht. Wenn man jetzt OmniOS IN einem LXC laufen lassen könnte, wäre es via
Code:
mp0: /rpool/data/shared,mp=/mnt/shared
möglich, den Share durchzumappen und die Zugriffs-Verwaltung komplett innerhalb des LXC durchzuführen, inkl. allen Vorteilen von OmniOS bezüglich Samba.

Alternativ könnte man vielleicht auch nen custom kernel mit ksmbd nehmen.

Zusätzlich wäre das Feature des bashclub zamba Servers übernehmen könnte, unter Windows eine rückrollbare "Versionshistorie" über ZFS+Samba anzuzeigen, dann wäre das ziemlich cool, aber das würde bei gemappten Storage leider nicht funktionieren.

Echt schade, dass es keine (einfache) Möglichkeit gibt, ZFS features an einen LXC oder eine VM durchzureichen, OHNE dass man sich auf die Storage-Größe festlegen muss - ich kenne jedenfalls keine. Hab mal über iSCSI nachgedacht, aber das war mir dann doch zu viel Aufwand.

Ich würde mir für LXCs irgendwie sowas wünschen:
Code:
zvol: /rpool/data/my-zvol,mp=/dev/zvol0

Dann könnte man in den LXCs das zvol durchmappen und im Host einfach ein Growing zvol anlegen. Für VMs wäre das vielleicht sogar möglich... mach ich vielleicht mal auf meinem Testsystem.
 
Beim kernelbasierten Solaris/ Illumos SMB Server tut vieles ohne dass man sich darum kümmern muss wie

ZFS Snaps=Windows previous versions (out of the box ohne irgendwelche Settings
liegt daran, dass hier sowohl SMB Shares und ZFS Snaps zu einem ZFS Dateisystem gehören

Mit SAMBA kann das ein größeres Unterfangen werden da SAMBA nix von ZFS weiß und nur "Ordner" sieht und man die Zuordnung Share -> ZFS Snap Verzeichnis manuell konfigurieren muss.

Windows Passworte vs Unix Passworte
Da die gespeicherten Hashwerte strukturell anders sind, muss man die getrennt/doppelt speichern.
Unter Solaris/Illumos macht ein passwd user beide Varianten, mit SAMBA gibts zwei Tools passwd und smbpasswd und man muss händisch syncronisieren.

User Mapping (vor allem mit AD)
Ein Graus mit SAMBA das nur Unix uid/gid kennt die man händisch auf Windows SID mappen muss, vor allem wenn man ein Dateisystem kopiert oder aus Backup zurücksichert. Solaris/Illumos SMB nutzt die Windows SID zusätzlich als file attribut für SMB. Damit bleiben Rechte nach einem Restore aus Backup erhalten. Jeder User und jede SMB Gruppe hat eine Windows SID. Damit sind auch SMB Gruppen in SMB Gruppen möglich (AD und lokal) ohner dass der SMB Server dies faken muss.

Windows ntfs ACL mit Vererbung
Ein Segen wenn man umfangreiche Rechte Absicherung mit vielen Usern/Gruppen braucht insbesondere weil Solaris/Illumos direkt NFSv4 ACL kann. Die sind kompatibel zu ntfs ACL. Mit SAMBA muss man das alles faken weil SAMBA insbesondere unter Linux das nicht hat. Wer sich mal die seitenlange Doku zu smb.conf ansieht, kann erahnen wie das gehen könnte. Überhaupt die smb.conf. Bei Solaris setzt man share=on für ein Dateisystem und muss sich dann nur noch um ACL Zugriffsrechte (Windows > Eigenschaft > Sicherheit) kümmern. Für die wenigen einstellbaren SMB Server Eigenschaften wie SMB Version oder locking Verhalten gibt es ein Management Tool

Kann man alles haben mit einer Solaris/Illumos Storage VM die dazu noch besonders resourceneffizient ist. Ob man der Platten für ZFS per zvol, passthrough oder iSCSI Target anbietet ist zunächst egal.

Mir gehts aber zunächst darum Proxmox selber (und andere wie Free-BSD, Windows, SmartOS etc) nicht nur als Virtualisierungsplattform sondern ohne Storage VM auch als vollwertigen ZFS und einfachen SMB Server zu nutzen und zu managen, also die Mankos der Proxmox GUI in diesen Punkten auszugleichen die da außer VM Management rein garnichts bietet.
 
Zuletzt bearbeitet:
Bei mir steht auch das Thema Speicherpool Übernahme von einem NAS in mein Proxmox an.
Der Proxmox hat jedoch keinen Storage Controller den ich beispielsweise direkt an TrueNAS Scale oder Unraid durchreichen könnte. Was ich bisher gelesen habe scheint das durchreichen der Festplatte direkt nicht empfohlen zu sein da es auch eher zu Datenverlust beim Unraid führen kann.

Das NAS System wäre aber nur zur Bequemlichkeit. Auf meinem Proxmox wird ein kleiner Container erstellt für Docker und Portainer. Daher brauche ich auch die Funktionen in den NAS Systemen nicht.
Ich habe mir daher überlegt, meine Datenplatten in Proxmox als ZRAID zu konfigurieren und die Volumes direkt an andere Container durchzureichen. Beispielsweise ein LXC mit Debian für die SMB Freigabe für die MAC's, und eventuell ein Docker Container mit Netatalk für Timemachine Backups. Wir sprechen hier von maximal 15 verschiedene SMB Benutzer die nur extremst selten bearbeitet werden müssen. Somit könnte ich mir den Overload eines NAS Systems sparen.
Vielleicht müsste ich mal schauen ob ich noch ein Monitoring System für Proxmox finde der auch den RAID Zustand überwacht.
Informiert Proxmox eigentlich per Mail wenn mit dem RAID was nicht stimmt? Habe ich noch gar nicht geschaut :d

Vielleicht hat ja jemand dazu schon Erfahrungen gesammelt ob etwas dagegen sprechen könnte die Volumen direkt über Proxmox zu verwalten.
 
Ob man an eine Storage VM Platten durchreicht oder Controller ist von der Sicherheit zunächst ein gleichwertiges Unterfangen. Das physikalische Durchreichen von Platten ist allerdings oft ein Problem, bei ESXi z.B. war das nur bei SAS Controllern vorgesehen und ansonst Bastelei das mal tat und mal nicht. Duchreichen von PCI Devices wird dagegen immer viel besser unterstützt. In beiden Fällen ist ein Datenverlust sehr unwahrscheinlich wenn sich kein (Schreib) Cache zwischen Platte und VM befindet die damit arbeiten will. Ein Raid-Controller mit Cache sollte man nicht nehmen und auch der Virtualisierer darf beim Platten durchreichen keinen Cache nutzen, ein dumme SAS HBA oder auch Sata AHCI macht üblicherweise kein Problem.

Die Frage ob man eine Storage VM nimmt (damit virtualisiert man ein komplettes Linux oder Solaris, verbraucht manchmal mehr Resourcen als Proxmox selber) muss jeder selbst beantworten. Die Proxmox GUI bietet nahezu keine Unterstützung beim Verwalten von ZFS. Man landet sehr schnell auf der Console mit zfs und zpool. Auch User und Sharemanagement ist Fehlanzeige.

Man kann allerdings sehr wohl Proxmox auch für Storage nehmen, ist ja praktisch Debian optimiert für VM Management mit aktuellem ZFS on Linux. Man sollte nur vermeiden, Proxmox als Ersatz für einen ESXi zu sehen mit vielen VMs und dann noch zusätzlich einen vollwertigen Dateiserver draufzusetzen. Ein Proxmox als VM Server und ein Proxmox als Dateiserver ist perfekt, damit hat man nur ein Linux mit dem man kämpfen muss.

Ein Proxmox als Dateiserver und wenige Dienste als VM ist auch perfekt, z.B. eine AD oder Web/Cloudserver VM zusätzlich ist ok. Die fehlenden ZFS, User und Sharemanagement Funktionen der Proxmox GUI kann man neben einer Storage VM auch mit einer zuätzlichen ZFS Management GUI für diese Funktionen ergänzen (oder mit ein paar Scripten für einfache Routineaufgaben)
 
Ich häng mich hier mal mit TrueNAS Scale als Host rein, gibt keinen passenderen Thread.
Wollte schon einen aufmachen, aber ich fühl mich nicht kompetent genug um so nen "Sammelthread" zu starten... wenn wer will, sehr gern.

Verzeiht die eventuell falsche Ausdrucksweise in meiner Frage, mit so Netzwerkkram hatte ich nie sonderlich viel zu tun...

Damit die VM den Host sehen kann, muss ich ja so ne Network Bridge als virtuellen Adapter einrichten.
Soweit sogut, funktioniert auch.

- Geh ich recht in der Annahme, dass ich für jede VM ne eigene Bridge einrichten muss? Oder können alle VMs die gleiche verwenden? (Für die meisten hier ist das sicher trivial und logisch... für mich nicht :d)
- Was ist bei der Angabe der IP eigentlich die Zahl hinter dem Slash? Also 192.168.0.2/20 das /20? Hab schon so Netzwerk Basics gelernt vor vielen Jahren, da war das aber ned dabei, und gebraucht hab ichs bisher wohl nie :d...


Nochwas...
Ab und zu stürzt mir die VM ab, speziell beim Video abspielen (das ist nicht ihr Zweck, aber wenn mans halt tut), manchmal aber auch so, merke ich, wenn ich beim Verbinden per Spice zum Login Screen komm.
Ist bei Debian KDE und bei Kubuntu so.
Das NAS selbst läuft sauber durch, hab auch keine Fehlermeldungen im TrueNAS.
Ist ein Ryzen Pro, hab ihn per PBO geundervoltet, allcore -30, war mit dem CoreCycler stabil (wie gesagt, TNS selbst noch nie abgestürzt), ob das daran liegen kann? Ich glaub ja fast nicht aber...
Mein nächster Versuch wär EndeavourOS in der VM, aber ... das beantwortet die Frage ja auch nicht.
 
Zum Mitmeißeln:
Du hast nen TrueNAS Scale (TNS) als Hypervisor baremetal auf nem Ryzen Pro laufen?
Welches Betriebssystem hast du in der VM unter TNS am Laufen?
Debian?
Eine Brücke sollte erstmal reichen, je nachdem wie dein Netzwerk verschaltet ist.
Die VMs kannst alle als Ports in die Brücke hängen.

Das /20 ist die Netzmaske, aka 255.255.240.0.
Besser bekannt ist die /24er Maske: 255.255.255.0
Sie gibt an, wie groß das Netz unter deiner IP ist.
Im /20er Fall eben 4096 IPs und 4094 Rechner, im /24er sinds 254 Rechner und 256 IPs.
 
Du hast nen TrueNAS Scale (TNS) als Hypervisor baremetal auf nem Ryzen Pro laufen?
Ja, primär als NAS.
Als Hypervisor isses wohl... "nicht ideal"... sanft ausgedrückt. Hab mich aber gegen TrueNAS virtuell entschieden, da das Gebiet für mich neu war und mir die NAS-Funktion mit Abstand am wichtigsten ist.

Hab ich eh gesagt, ein Debian früher (die VM gibts nicht mehr), jetzt ein Kubuntu (jeweils aktuell), beide mit KDE 5.irgendwas.
Zugreifen tu ich per Virt-Viewer / Spice. Geht eigentlich ganz gut... paar Sachen fehlen mir irgendwie, aber im Prinzip ists mal okay und besser als alles, was ich bisher so hatte (naja, der Win RDP auf Arbeit geht auch gut).

Im /20er Fall eben 4096 IPs und 4094 Rechner, im /24er sinds 254 Rechner und 256 IPs.
Danke, damit fang ich was an.
 
sind die guest tools in der VM installiert?
(Keine Ahnung, welchen Hypervisor TNS mit bringt, KVM oder XEN?)

//Edith:
Es ist KVM.
Welche Version von TNS nutzt du, die neue 24.04?
Schau mal, ob in der VM folgende Pakete installiert sind:
qemu-guest-agent
spice-vdagent

Zudem wäre ein Crashlog aus der VM hilfreich. =)
 
Zuletzt bearbeitet:
Zudem wäre ein Crashlog aus der VM hilfreich. =)
Wie komm ich an den? 🙈

Neue Version, ja.
spice-vdagent, ja
qemu-guest-agent, muss ich daheim nochmal schauen, glaube aber schon

Kann es was mit dem CPU Modell zu tun haben, das man für die VM auswählen kann? Ich meine, ich habe host passthrough oder so.
Das Virtualisierungszeug im Bios sollte alles an oder auto sein.

Nochwas, gibts ne Möglichkeit auf der VM mehr als 2560x1600 zu haben? Mit 2560x1600 kann ich zwar ganz gut leben, aber wär trotzdem interessant.

PS: Die Session ist (natürlich) X11, Wayland mag Spice so gar nicht (zumindest bei KDE 5.xx), EndeavourOS mit KDE 6 hab ich noch nicht probiert.
PPS: Ich würde eigentlich ganz gern KDE als DE nutzen, nutz das auch am Desktop und da tu ich mir allgemein etwas leichter mich einzuarbeiten, langfristig mag ich ganz von Win weg...
 
KDE ist mir zu überbordend, aber wers mag. =)
Host CPU Features habe ich auch in ProxMox so eingestellt.
Tatsächlich ist die einzige VM mit DE die Compactor-VM, ein Relikt aus ESXi-Zeiten, damit ich die VMDKs nullen konnte, die läuft mit lxde(?) und immer nur ein paar Minuten...
Deshalb kann ich das noch nicht nachvollziehen...
Für Journalctl müsste es nen Parameter geben: "journalctl -b -1"
Damit kannst den letzten Boot ansehen, am Ende des Logs müsste es einen Hinweis auf den Crash geben.
 
Ich denke, es war die CPU Einstellung.
Ich hatte den Modus auf "Host Model" und nicht auf "Host Passthrough", jetzt hab ich auf Host Passthrough gestellt und kein Problem mehr gehabt. Werde das beobachten.

Wie stellt man das denn sinnigerweise ein, bezüglich Cores/Threads/Pin vcpus?
 

Anhänge

  • 1717530096348.png
    1717530096348.png
    14 KB · Aufrufe: 34
ZFS GUI unter Proxmox vs Storage VM mit GUI

Ich habe mir mal mit top den CPU und RAM Bedarf meiner Web-GUI napp-it cs für ZFS unter "GUI Last" unter Proxmox (Perl Prozesse) anzeigen lassen
Ist mit anderen ZFS GUIs zur Ergänzung der Proxmox webgui sicher nicht erheblich höher.

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
1425592 root 20 0 22888 18304 5632 R 1.3 0.2 0:03.46 perl
1425556 root 20 0 17968 11144 9344 S 0.7 0.1 0:02.81 sshd
1428148 root 20 0 11624 5376 3328 R 0.7 0.1 0:00.34 top

Das ist mit gut 1% CPU und 22 K RAM sicher um eine Größenordnung unter dem CPU und RAM Bedarf einer Storage VM
(Voll virtualisierte Linux oder Solaris Storage VM).

Wenn man nicht gerade eine 32Kern CPU mit 128 GB RAM hat, sicher ein Kriterium bei der Frage ob man eine fullsize Storage VM braucht,
vor allem wenn man dann auch nur die eine oder andere SAMBA Freigabe benötigt die Proxmox exakt genauso bereitstellen kann.
 
Ich möchte mich noch bei allen bedanken, die in diesem Thread und allgemein in diesem Unterforum unterwegs sind und ihr fachliches Wissen und ihre Erfahrung teilen.


Ich schätze die Hilfsbereitschaft, den Umgang miteinander und die fachliche Kompetenz im ganzen Unterforum hier sehr.
 
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh