Bei den Rootservern bekommst du fast alle CPU Flags durchgereicht, bei den VPS nicht.
Wobei eine wichtige Ausnahme vmx ist...
Bei den VPS stört, wenn man sie für Tunnelserver benützen möchte, das Fehlen von aes besonders.
Bei den Rootservern bekommst du fast alle CPU Flags durchgereicht, bei den VPS nicht.
Wobei eine wichtige Ausnahme vmx ist...
Bei den VPS stört, wenn man sie für Tunnelserver benützen möchte, das Fehlen von aes besonders.
Ob das Problem neu ist weiß ich nicht, aber es verschwinden alle neu angelegten Dateien ausser jene mit Punkt wie ".history". bis zum nächsten Login.
Platte voll? -> df -h
Kennt Ihr neben
froxlor
plesk
cPanel
LiveConfignoch andere Webhosting Panels?
ISPConfig - https://www.ispconfig.org/ - das habe ich neben Froxlor seit SysCP-Zeiten in Verwendung. Es kommt IMO Plesk noch am nächsten, spielt aber doch in einer anderen Liga.
Bitte ISPConfig nicht mit ispCP verwechseln (https://sourceforge.net/projects/ispcp/) - das ist ein Fork von VHCS (http://www.vhcs.net/).
ispCP Omega - http://isp-control.net/ - das habe ich zuletzt getestet, als ich noch SysCP verwendet habe. Ist ewig her, aber es dürfte sich dort auch was getan haben.
Und weitere Panels findest Du unter https://alternativeto.net/software/plesk/
Als Antwort bekam ich die Aussage, das dies keine Failover-IP sei, ein Neurouting nicht möglich wäre.
IMO ist das so nicht ok. Der Vorteil der Failover-IP ist ja nur, dass man die Zuweisung über das SCP selbst vornehmen kann - weswegen die auch teurer sind.
Bei zusätzlichen IP verhält es sich laut Website so:
https://www.netcup.de/bestellen/produkt.php?produkt=1072
Vielleicht wäre das Zauberwort „Produktwechsel“ gewesen.
Wobei wieder einmal nirgendwo erklärt wird, was konkret ein Produktwechsel bedeuten soll - im Wiki finde ich das Wort nur einmal, und da bezieht es sich auf den Wechsel von Linux-vserver auf KVM.
https://www.netcup-wiki.de/wiki/Produkte_CCP
Bei einem Produktupgrade vermute ich einmal, dass eh alles diesbezüglich gleich bliebe.
Wenn die IPs nicht mit dem Server, dem sie zugewiesen sind, zugleich gekündigt werden, dann sind die Adressen relativ eigenständige Produkte und müssten neu zugewiesen werden können. Ansonsten würde ich die Kosten hierfür reklamieren. Fällt die Hauptleistung weg, ist die Nebenleistung auch nicht erbracht.
Irgendwer ne Idee? Ich hab echt 0 Plan von Autos ?
Beim Volvo kenne ich mich nicht aus. Aber das mit dem Knarren kommt mir von einem Chrysler Voyager ('86) bekannt vor. Ich bilde mir auch ein, dass dass ein Opel Astra ('01?) solche Geräusche gemacht hat. Der Opel hat überhaupt sehr früh sehr viele Geräusche gemacht und war recht bald am Zerfallen. Bei Mercedes habe ich das auch schon gehört, aber eher selten und leise.
Die vorderen Radlager und die Servolenkung waren nach 15 Jahren schon etwas bedient. Die Vermutung, dass die Bremse bei dem Geräusch mitspielt, halte ich für realistisch. Die Automatikfahrzeuge haben immerhin allesamt etwas mehr Standgas als die Handschaltungsfahrzeuge und die Bremsen sind auch recht kräftig. Die Erklärung von janxb klingt für mich plausibel.
BTW: ich hatte kürzlich auch den Fall, dass eine Fachwerkstätte bei einem Mercedes hinten und vorne verwechselt hat, und die breiteren Hinterräder beim Umstecken vorne montiert hat, was beim Volleinschlag der Räder gescheuert hat...
mit IPv6 ist doch auch NAT ausgestorben
Du verwechselst da was. Hier geht es um einen Translation-Mechanismus, bei dem IPv4 über IPv6 verkapselt wird, wobei ein Mapping des IPv4-Adressraums auf einen IPv6 Prefix, meist ein /72, obwohl /96 stattfindet. Natürlich braucht man für RFC1918-Adressen dann immer noch NAT. Was die Provider mit DS-Lite tun, ist im Grunde nichts anderes. Am Ende des CGN steht ein Translator.
Bei Funkfeuer Wien ist so ein Translator in Verwendung und ist schemenhaft öffentlich dokumentiert:
https://wiki.funkfeuer.at/wiki/Projekte/v642/IPv4_Support
Dort allerdings mit 4in6 über ipip6 statt tun.
Kann man eigentlich in iptables Traffic der via IPv6 reinkommt an einen IPv4 Host forwarden? (Prerouting/Portforwarding)
Mit iptables und NAT64 über http://www.litech.org/tayga/
Anleitung: https://www.linux-magazin.de/ausgaben/2014/…konferenz-wlan/
geekmonkey du verstehst einfach nicht das das alles nicht sein Problem löst.
Das sind die Momente, wo denkende Wesen den Stellenwert von Grundrechten erst so richtig zu würdigen wissen:
Sind wird nicht alle fallweise ein bisschen PEBKAC?
Also ich kenn mich mit dem ganzen Zeug nicht so richtig aus... Ich kenn mich nur damit aus was ich machen möchte... Ich weiß wie ich mich einlogge ich weiß die Commands die ich benötige... Ich hätte jetzt nicht gedacht das ich jetzt so weit zurück gehen muss um mein Root Passwort zu ändern oder so...
Nur eine Frage am Rande... in Fortsetzung von #2 von nan0 :
Es wäre nicht völlig an den Haaren herbeigezogen, wenn die Tastatur während der Installation in der VNC - Konsole auf Englisch eingestellt war - Wenn das so war, dann gibt es in den Passwörtern jetzt Vertauschungen aufgrund der anderen Tastaturbelegung (in SSH).
Umfrage: wonach benennt ihr so eure Server (Hostnamen)?
Ich entschlage mich der Aussage ![]()
Aber vielleicht interessiert Dich eine legendäre Liste historischer Hostnamen:
bei nur einer Adresse wohl eher Quark, meinst nicht?
Der Normalfall ist eine Adresse pro Interface. In Deinem Fall wan und br0, wobei auf WAN die „routing address“ des /48 und die /128 des Tunnelendpunkts liegt. Die sind üblicherweise nicht mit demselben Prefix behaftet. Ob, das, was Du da gemacht hast, Topfen ist, oder nicht weiß ich nicht, ich schreib ja Dir nur, wie es klappen wird.
Nö, warum. AJAX ist eine Frontendtechnologie wo der Request in einem anderen Thread als der Mainthread läuft und der alte Content bestehen bleibt.
Was das Backend da am Ende raussendet ist vollkommen egal. Meistens ist es beides HTTP, aber der Inhalt ist egal.
Wenn ein Javascript eventbasiert permanent das Backend abfragt, wie es einige Programmierbeispiele im Netz als Extremfall suggerieren (Autocomplete/onkey), verursacht dies mehr Last auf dem Backend, als wenn man eine Abfrage macht und die lokal cacht. Es ist also ein Tradeoff von übertragenen Bytes zu Queries(=Last). Ich behaupte jetzt nicht, dass dies so beim CCP der Fall ist, wenn dort aber ein einzelner Seitenaufruf drei XHTTPRequests mit denselben Parametern durchführt, nur um die Sessionhashes zu prüfen/zu setzen, wie ich es in der Firefox-Konsole gesehen habe, dann sind das schon einmal 2 Requests mehr als im Grunde dafür eigentlich notwendig wären.
seit dem verwende ich nur noch einen einzigen /64 prefix,
und hier ist es egal ob es Teil vom /48 od. das geroutete /64 selbst ist;
So, wie ich he.net in Erinnerung habe, hast Du einen Tunnel mit Linknetz, wo PtP jeder Endpunkt somit quasi ein /128 ist.
An die Linknetzadresse Deines lokalen Endpunkts wird das eigentliche /64 geroutet.
Optional ist ein /48 zusätzlich möglich, das ebenso geroutet wird.
Die Problematik, die Du hast, resultiert wohl daraus, dass die Absenderadresse der Antwortpakete wahlweise einer dieser drei auf WAN existenten Prefices sein kann. Für diesen Zweck gibt es die Möglichkeit, deprecated addresses (preferred_lft 0) zu verwenden, um die nicht primären Adressen festzulegen. Alternativ kann man mit address labels arbeiten. Damit ist es möglich, den größeren Prefix auf WAN als IP-Alias festzulegen.
Das entsprechende LAN/WLAN bekommt dann wieder einen /64-Prefix daraus. Das muss so klappen.
Außerdem ist es denkbar, den /48-er Alias auch auf dem Loopback Interface zu definieren. Der Prefix ja stets an WAN geroutet wird und somit lokal ist, muss er auch diese Weise erreichbar sein - das gilt aber so nur für geroutete Prefices.
Die Frontendtechnologie ist irrelevant, wenn das Backend nicht hinterher kommt.
Das spräche dann aber im Average Case gegen AJAX, oder?
bei mir gibts am Router nur EIN Bridge-Interface im LAN; WLAN und LAN müssen die selben IPs haben;
es gibt auch nur EINEN DHCP(v6) Range;
Wenn es für mehrere Prefices klappt, wird es auch für nur einen, wie in Deinem Fall genügen. Eventuell macht die Bridge bei Dir Probleme mit der Neighbor Discovery? Die Bridge hat sicher eine andere MAC als die Bridgeports, was im Fall von WLAN mittel 4address-mode (=WDS) kein Problem ist, im LAN eventuell schon. Hier wäre die eventuell Verwendung eines npd-proxy (Kernel-Setting sollte genügen) indiziert. Allerdings kenne ich das Problem nur dann, wenn der Übernachbar über ein Device in meinem Fall ein UBNT WLAN-Outdoor-AP im Bridge-Mode keine IPv6-Connection bekommt. ip -6 neigh gibt Auskunft.
ja und gewaltige Probleme damit gehabt; seitdem nur noch eine einzige /64 Adresse am LAN interface
Kannst Du bitte präzisieren, worin diese „gewaltigen Probleme damit“ bestanden?
Das Ajax braucht in der Tat etwas lang. Etwa beim Gutscheine erstellen, Produkte anzeigen und überall, wo etwas nachgeladen wird.
Ich wollte mir kürzlich ein Skript basteln, mit dem ich die Liste der Gutscheine aus dem CCP exportieren kann (via curl) - denn das Feature gibt es noch nicht. Es ist mir bisher nicht gelungen, denn ich bin ein lausiger Programmierer, und ich kenne ja den Source nicht und, curl fehlt die entsprechende Javascript-Komponente. Meine verfehlte Hoffnung war, dass das partnerprogramm_ajax.php beim Erstaufruf ein Json mit der Liste retournieren würde. Bei den Versuchen ist mir aufgefallen, dass das noscrf_ajax.php auf einigen Seiten im CCP mehrfach (/partnerprogramm.php gleich 3x) aufgerufen wird, und dabei eine URL verwendet, wo der erste Parameter nicht mit "?", sondern mit "?&" beginnt. (https://www.customercontrolpanel.de/nocrfs_ajax.php?&action=getnocsrftoken&sessionhash=blabla123uoblabla456. Wobei da noch Ungereimtheiten wie Aufrufe vom Typ POST mit URL-Parametern (wie bei GET) etc. sind:
„Angefragte Adresse:https://www.customercontrolpanel.de/nocrfs_ajax.ph…abla123456uo789
Anfragemethode:POST [...]“
Außerdem verlangen die HTTP-Header UTF-8, aber einer der Parameter verlangt iso-8859-15... Auch bei der index.php.
Der Firefox-Inspector moniert auch, dass manche XHttpRequests synchron statt asynchron ausgeführt werden - was aber durchaus in einigen Use Cases Sinn ergibt, und daher nichts bedeuten muss. Das, was ich gefunden habe, lag in der prototype.js (1730:21), vermutlich aus der Scriptaculous-Klasse.
Vermutlich lässt sich noch einiges optimieren.
weil sich ein paar Quacksalber etwas derart stranges ausgedacht haben, daß der /48er f. den primitiven Use case¹ unbrauchbar ist;
sprich: zu meinen einfach _48-prefix::1/48 als IPv6-Adresse am Interface zu definieren und dann jede beliebige IPv6-Adresse von dem Prefix im LAN verwenden zu können ist ein Irrtum; es braucht f. jeden /64-Sub-prefix eine entsprechende IPv6 am Interface und das ist mehr als Humbug;
Schon einmal einen Interface- oder IP-Alias (48er-prefix::/48) probiert?
Ich konnte den he-Tunnel vor ein paar Jahren abdrehen, hatte davor aber immer das /48 in Verwendung - mit Linux und selbstgestricktem ip(6)tables-Script. Nativ habe ich jetzt auch ein /48 und da brauche ich (auf der pfsense) freilich nur den IP-Alias auf WAN und den jeweiligen kleineren Prefix auf dem jeweiligen Interface für das jeweilige Segment.
die komischen fe80:: Adressen haben die MAC-Adresse dabei und werden intensivst verwendet;
wenn ich folgende Regel von IP6tables entferne ist IPv6 quasi tot ...
-A INPUT -i br0 -s HE-IPv6-routed-prefix::/64 -d fe80::/10 -j ACCEPT
Ergibt diese Regel einen Sinn? Du lässt Pakete, die auf br0 hereinkommen, an die linklokalen Clients der br0 zu?
Normalerweise würdest Du den Rückverkehr mittels ACCEPTED,RELATED für eine ausgehende Verbindung für einen öffentlichen Prefix zulassen, und fe80 untereinander zulassen, respektive eingehenden Verkehr für den externen Prefix für bestimmte Ports erlauben.
Der Rest sollte Linklokal funktionieren?
Anmerkung: Antwortpakete werden ja an -d Prefix vom Client gesendet. Die Fe80 dringt ja gar nicht nach außen.
Außerdem frag ich mich, wieso Du nur den kleinen Routed Prefix von he und nicht den /48er nimmst? Oder ist dieses /64 Teil des gerouteten /48?