Die URL für Ubuntu 20.04.2 in Schritt 2 lautet:
http://at.archive.ubuntu.com/ubuntu/dists/focal/main/installer-amd64/
Die URL für Ubuntu 20.04.2 in Schritt 2 lautet:
http://at.archive.ubuntu.com/ubuntu/dists/focal/main/installer-amd64/
Advent, Advent,
ein Lichtlein brennt.
Erst eins, dann zwei,
dann drei, dann vier,
dann steht das Christkind vor der Tür.
Wir, die wir alljährlich am christlichen Bedeutungsgehalt des Advents vorbeigelotst werden …
Wir, die wir alljährlich dem Konsumzwang unterworfen werden und letztlich dem Bedürfnis nach der Schnäppchenjagd unterliegen …
… werden sicherlich auch trotz geschlossener Geschäfte heuer ab dem 01. Dezember 2020 00:00:01 Uhr wieder nach Online-Adventkalendern -man beachte die in Österreich gebräuchliche Schreibweise ohne „s“ in der Wortmitte – aller Art suchen. Ich möchte die Suche etwas abkürzen.
Ich fasse im Überblick einmal zusammen, was es heuer so gibt – alle Angaben ohne Gewähr:
Wenn Ihr weitere Tips habt, bitte postet sie als Kommentar. Die Liste wird ergänzt.
Wer ärgert sich nicht, wenn der geliebte Internetbrowser plötzlich ein völlig anderes Verhalten, als das, das man erwartet, an den Tag legt?
Beim Einstellen einer IP-Cam etwa, wenn man http://192.168.1.254 eingibt, weil die Kamera eben nur http kann, er es aber besser weiß und https everywhere versucht. Oder beim Testen eines frisch aufgesetzten haproxy. Die Liste, wo das lästig wird, kann man beliebig fortsetzen.
Aber es gibt Mittel und Wege dagegen:
Chrome:
Etwa beschreibt Howtogeek.com das Vorgehen, wie man Chrome das abgewöhnt.
Kurzfassung. Man rufe chrome://flags/#omnibox-context-menu-show-full-urls auf, aktiviere diese Einstellung und surfe eine Seite an. Der Browser hat das https everywhere immer noch aktiviert. Ich klicke mit der rechten Maustaste auf die URL und wähle im Kontextmenü „Immer vollständige URLs anzeigen“. Voilà http wird nicht mehr automatisch auf https umgeschrieben, und ich sehe die komplette URL wieder. Ich habe das bei mir unter Chromium 85.0.4183.102 getestet.
Firefox:
https-everywhere abschalten: about:config aufrufen. Nach browser.fixup.fallback-to-https suchen. Den Wert auf false setzen.
Vollständige URL in der Adressleiste anzeigen: browser.
Advent, Advent,
ein Lichtlein brennt.
Erst eins, dann zwei,
dann drei, dann vier,
dann steht das Christkind vor der Tür.
Wir, die wir alljährlich dem am christlichen Bedeutungsgehalt des Advents vorbeigelotst werden …
Wir, die wir alljährlich dem Konsumzwang unterworfen werden und letztlich dem Bedürfnis nach der Schnäppchenjagd unterliegen …
… werden sicherlich auch heuer ab dem 01. Dezember 2019 00:00:01 Uhr wieder nach Online-Adventkalendern -man beachte die in Österreich gebräuchliche Schreibweise ohne „s“ in der Wortmitte – aller Art suchen. Ich möchte die Suche etwas abkürzen.
Ich fasse im Überblick einmal zusammen, was es heuer so gibt – alle Angaben ohne Gewähr:
Wenn Ihr weitere Tips habt, bitte postet sie als Kommentar. Die Liste wird ergänzt.
Netz | Betreiber | max. Stückzahl SIM | Kosten brutto (netto) pro Monat 1./2./3. .. Zusatz-SIM | einmalige Zusatzentgelte: Aktivierung [A] | Bedingungen, Einschränkungen (funktioniert nicht), Besonderheiten, Quellenangabe |
---|---|---|---|---|---|
A1 | A1 | 3 | € 6,90/€ 4,90 | € 19,90 [A] | Vertragstarife, keine Datentarife Zusatz-SIM bei A1 |
Drei | Drei | 5 | € 5/€ 2 | € 15 [A] | Telefonievertrag SmartSIM bei Drei |
Drei | Drei | 5 | € 5 (4,17)/€ 2 (1,67) | € 15 (12,50) [A] | keine Wertkarte, keine Internettarife Business SmartSIM bei Drei |
Drei | HELPmobile | 5 | € 2 | Alle Tarife außer „HELP daten“ nicht zur Verfügung: - Umleitungen / Rufweiterleitungen - Mobilbox - diverse Ansagen – bspw. bei Nichterreichbarkeit Facebook-Ankündigung Help mobile | |
Drei | Spusu (Mass Response) | 5 | € 2 | - | Nicht für Spusu Daten und nicht für Spusu Wertkarte Facebook-Ankündigung Spusu - Umleitungen / Rufweiterleitungen - Mobilbox - diverse Ansagen – bspw. bei Nichterreichbarkeit |
Magenta | Magenta | 3 | € 5 (6)/€ 2,5 (3) | € 20 (16,67) [A] | Business Mobile Gold & Business Mobile Platin: pro Zusatz-SIM je € 20 (16,67) Business MultiSIM bei Magenta |
Erstentwurf – Review ausständig; Fehler möglich; Änderungen vorbehalten.
In diesem Artikel beschreibe ich stark vereinfacht und gekürzt ein paar Grundlagen des Domain Name Systems, die für Domaininhaber, die den Registrar wechseln möchten, von Relevanz sind. Immer wieder liest man in Support-Foren von verzweifelten Nutzern, denen offenbar nicht klar ist, dass ein Domain-Umzug nicht in Echtzeit abläuft, sondern, dass ein Domaintransfer ein paar Vorbereitungen und etwas Nachbearbeitung erfordert, damit die Ausfallzeiten möglichst gering ausfallen.
Wenn man sich vorher informiert, schont das die Nerven aller Beteiligten – vor allem aber die eigenen.
Für Laien erklärt, ist das DNS am ehesten mit einem Telefonbuch für eine Region vergleichbar. Es übersetzt Namenseinträge (Domainnamen und Hostnamen) in Nummern (Internetprotokolladressen – kurz IP-Adressen). Die einfachste Art eines solchen Datensatzes ist ein sogenannter „A-Eintrag“ für das Internetprotokoll in der Version 4 (IPv4), dem heutzutage noch gängigen Protokoll, oder einem „AAAA-Eintrag“ für das Nachfolgeprotokoll IPv6.
Solche Einträge sehen in etwa so aus – im Beispiel sind die öffentlich abrufbaren Google-Nameserver:
dns.google.com. IN A 8.8.8.8
dns.google.com. IN AAAA 2001:4860:4860::8888
Dieses „Telefonbuch“ ist hierarchisch aufgebaut, d.h. es gibt einen Haupteintrag, unter dem dann weitere Einträge oder Verweise zu finden sind.
Ganz oben steht die Top Level Domain („TLD“). Ein prominentes Beispiel für eine TLD ist „.com“. Für eine TLD zuständig ist eine Vergabestelle (Registry). Sie regelt, wer unter welchen Voraussetzungen einen Namen unterhalb der TLD registrieren darf. Wer eine Domain registriert, wird zum Domaininhaber (Registrant). Die Registry bedient sich meist mehrerer Vertragspartner (Registrare), um diese Domains zu verkaufen – sprich: Namensrechte auf Zeit zu lizenzieren. Die Registrare sind die primären Vertragspartner der Registrants und vermitteln gegenüber der Registry – sie verrechnen dem Registrant auch die anfallenden Gebühren und rechnen sie mit der Registry ab.
Die Registry betreibt sogenannte Root-Nameserver, die in aller Regel nur einen Verweis vom registrierten Namen vorhalten, der auf untergeordnete Nameserver (DNS-Server) zeigt. Haben diese DNS-Server einen Hostnamen, der innerhalb der Domain, um die es geht, liegen -es geht zum Beispiel um die Domain example.com, und der DNS-Server heißt ns1.example.com- ist zusätzlich ein sogenannter „Glue-Record“ vonnöten. Dabei handelt es sich schlicht um einen „A“ oder „AAAA“ -Eintrag, den allerdings der Registrar bei den Nameservern der Registry hinterlegen muss, damit er funktioniert.
Zusätzlich können die Rootserver auch noch kryptographische Schlüssel und Signaturen ausliefern, anhand derer man gefälschten Domaininformationen vorbeugen kann. Das gegenwärtig vorherrschende System dafür heißt DNSSEC.
Die Verweise vom Root-Nameserver zu den Servern des DNS-Providers (in der der Regel sind das zugleich die des Registrars) heissen „NS-Einträge“.
Im Falle dieses Blogs ist der Registrar der deutsche Hoster „netcup“ und die Einträge sehen so aus:
grundsoli.de. 120 IN NS root-dns.netcup.net.
grundsoli.de. 120 IN NS second-dns.netcup.net.
grundsoli.de. 120 IN NS third-dns.netcup.net.
Wir sehen also, dass für den Namen „grundsoli“ innerhalb der TLD „.de“ drei verschiedene Server zuständig („autoritativ“) sind.
Jeder dieser drei Server hält die sogenannte „Zone“ vor. Die Zone kann im einfachsten Fall eine Textdatei sein, oder die in ihr enthaltenen Informationen liegen in einer Datenbank.
Eine Zone setzt sich aus mehreren Resource Records („RR“) zusammen. Zu diesen RRs gehören auch die zuvor genannten NS, A und AAAA-Einträge.
Resource Records setzen sich zusammen wie folgt:
Am Beginn der Zone steht stets ein Eintrag vom Typ SOA. Kehren wir zum Beispiel mit example.com zurück:
@ 3600 IN SOA dns1.example.com. hostmaster.example.com. (
2019090900 ; serial
3600 ; refresh
1800 ; retry
604800 ; expire
600 ; nc-ttl
);
Wir haben also die Variable für den Domainnamen „@“, die Gültigkeitsdauer des SOA-Eintrag in Caches „3600“, die Klasse Internet „IN“, die Art des Eintrags „SOA“ den primären Nameserver, das ist jener autoritative Nameserver, von dem aus die Zone vervielfältigt wird „dns1.example.com“ und eine E-Mailadresse in besonderer Schreibweise „hostmaster.example.com“ für hostmaster@example.com. Die Punkte am Ende von dns1.example.com. und hostmaster.example.com. sind extrem wichtig, da sie das Ende des Werts markieren. Fehlt der Punkt am Ende wird der Domainname an den Wert erneut angehängt. Aus „dns1.example.com“ würde dann „dns1.example.com.example.com“ – ein von Anfängern häufig gemachter Fehler. Die in Klammern folgenden Zahlenwerte schlüsseln sich wie folgt auf:
1: Die RIPE-Empfehlungen gelten stets für „für kleine und stabile Zonen“.
Der Wert für Retry muss kleiner sein, als der für Refresh. Der Wert für expire darf nicht kleiner sein als die Summe von Refresh und Retry.
Und damit haben wir die technischen Grundlagen für beeinflussbare Verzögerungen beim Domaintransfer im Grunde vollständig besprochen.
Die nicht beeinflussbaren Faktoren liegen bei der Registry, die etwa Widerspruchsfristen für einen Transfer definieren kann. Sie ist es auch, die festlegt, zu welchen Tageszeiten die Root-Nameserver eine neue Information, die von einem ihrer Registrare eingemeldet worden ist – wir reden da von neuen Nameserver-Einträgen – verarbeitet wird.
Um also einen Transfer so durchzuführen, dass er möglichst schnell über die Bühne geht, sollte man Tage oder Wochen vor dem Transfer die Werte für TTL, Refresh und NC-TTL verringern, wodurch in aller Regel auch der Wert für Retry verringert werden wird müssen. Dadurch setzt man sich vorübergehend zwar einem erhöhten Risiko aus, dass die Zone im Fehlerfall des Primärservers auch auf den Sekundärservern schneller mit ausfällt, umgekehrt müssen aber auch DNS-Resolver Dritter, auf die wir im Normalfall keinen Einfluss nehmen können, sofern sie standardkonform arbeiten, die vorgehaltenen Informationen schneller verwerfen.
Wenn man sich nun noch informiert, wann die Registry die Daten neu laden lässt, kann man den Umzug auch dahingehend zeitlich koordinieren.
Laden beispielsweise etwa die Root-Nameserver laut Registry um 13 und um 16 Uhr die Daten neu, und der Registrar aktualisiert alle 15 Minuten, so kann man nach 13 Uhr die Änderungen machen. Die anderen Kunden des Registrars hätten die neuen Informationen so – sofern sie nicht in einem Cache liegen, um 13.15 Uhr, weltweit würde der Verweis auf die neuen Server erst um 16 Uhr aktiv. Um also Gleichzeitigkeit zu erwirken, wären die Änderungen nach 15.45 Uhr, aber vor 16.00 in Auftrag zu geben. Caching Server würden die alte Information aber zumindest noch für die in TTL definierte Zeit ausliefern, wenn sie die Standards einhalten – sonst länger.
Da sich heutzutage aber auch sogenannte Public-DNS-Resolver-Dienste großer Beliebtheit erfreuen – gemeint sind damit Google DNS, Cloudflare, OpenDNS und dergleichen, und diese oft eine Möglichkeit bieten, die Cache-Information über ein Webinterface neu zu laden, also den „Cache“zu „flushen“, kann man auch hier mit globaler Wirkung für alle Nutzer dieses Dienstes Einfluss auf die Erneuerung der Information nehmen. In der Linksammlung stehen einige Dienste gelistet.
Kürzlich habe ich mir gedacht, eine WLAN-Türklingel wäre eine sinnvolle Investition, etwa schon allein deshalb, weil sich manchen Zustelldienste gerne in meiner Gegend verirren. Als Sparfuchs, der ich ja bin, wurde es auf Amazon eine [externer Link zu Amazon: Generic TS-IWP708 Wifi Digital Wireless Video Tür Bell]. Zum Zeitpunkt des Erwerbs lag der Preis bei etwa 30 Euro. Es f olgt eine
Die weiße Schachtel war relativ neutral. Ein Produktbild und der Name des Produkts auf der Oberseite, seitlich rechts noch ein paar Bildchen, Strichcode-Aufkleber, einer davon mit dem Aufdruck „TS-IWP708“ unter dem Code. Keine Herstellerangaben in irgendeiner Form.
#cat /proc/version Linux version 2.6.21 (root@mailzxh-desktop) (gcc version 3.4.2) #655 Wed Nov 21 22:21:46 CST 2012
# busybox BusyBox v1.12.1 (2012-11-21 22:17:05 CST) multi-call binaryCopyright (C) 1998-2008 Erik Andersen, Rob Landley, Denys Vlasenkoand others. Licensed under GPLv2.See source distribution for full notice.
# cat /proc/cpuinfo
system type : Ralink SoC
processor : 0
cpu model : MIPS 24K V4.12
BogoMIPS : 239.10
wait instruction : yes
microsecond timers : yes
tlb_entries : 32
extra interrupt vector : yes
hardware watchpoint : yes
ASEs implemented : mips16 dsp
VCED exceptions : not available
VCEI exceptions : not available
# ls /proc/rt5350
gmac skb_free tx_ring rx_ring cp0 esw_cnt
# cat /proc/meminfo | grep MemTotalMemTotal: 29336 kB
# cat /proc/mtd
dev: size erasesize name
mtd0: 00800000 00010000 "ALL"
mtd1: 00030000 00010000 "Bootloader"
mtd2: 00010000 00010000 "Config"
mtd3: 00010000 00010000 "Factory"
mtd4: 00100000 00010000 "Kernel"
mtd5: 00330000 00010000 "RootFS"
mtd6: 00300000 00010000 "sys"
mtd7: 00080000 00010000 "param"
# mount
rootfs on / type rootfs (rw)
/dev/root on / type squashfs (ro)
proc on /proc type proc (rw)
none on /var type ramfs (rw)
none on /etc type ramfs (rw)
none on /tmp type ramfs (rw)
none on /media type ramfs (rw)
none on /sys type sysfs (rw)
none on /dev/pts type devpts (rw)
/dev/mtdblock6 on /system type jffs2 (rw)
/dev/mtdblock7 on /param type jffs2 (rw
# netstat -aWp
Active Internet connections (servers and established)Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 0.0.0.0:81 0.0.0.0:* LISTEN 133/encoder
tcp 0 0 0.0.0.0:23 0.0.0.0:* LISTEN 28/telnetd
tcp 0 0 0.0.0.0:8600 0.0.0.0:* LISTEN 31/go-daemon
tcp 0 213 192.168.246.1:23 192.168.246.2:32798 ESTABLISHED 28/telnetd
udp 0 0 127.0.0.1:8832 0.0.0.0:* 133/encoder
udp 0 0 0.0.0.0:3073 0.0.0.0:* 133/encoder
udp 0 0 0.0.0.0:3074 0.0.0.0:* 133/encoder
udp 0 0 0.0.0.0:3075 0.0.0.0:* 133/encoder
udp 0 0 127.0.0.1:6666 0.0.0.0:* 133/encoder
udp 0 0 0.0.0.0:8600 0.0.0.0:* 31/go-daemon
udp 0 0 0.0.0.0:9632 0.0.0.0:* 133/encoder
udp 0 0 127.0.0.1:9123 0.0.0.0:* 31/go-daemon
udp 0 0 127.0.0.1:9124 0.0.0.0:* 133/encoder
udp 0 0 0.0.0.0:67 0.0.0.0:* 102/udhcpd
udp 0 0 0.0.0.0:32108 0.0.0.0:* 133/encoder
udp 0 0 127.0.0.1:8813 0.0.0.0:* 133/encoder
udp 0 0 0.0.0.0:15733 0.0.0.0:* 133/encoder
udp 0 0 127.0.0.1:8822 0.0.0.0:* 133/encoder
udp 0 0 127.0.0.1:8831 0.0.0.0:* 30/cmd_threadActive UNIX domain sockets (servers and established)Proto RefCnt Flags Type State I-Node PID/Program name Pat
# ls -la /system/system/bin-rwxr-xr-x 1 0 0 156768
go-daemon-rwxr-xr-x 1 0 0 8260
cmd_thread-rwxr-xr-x 1 0 0 877540
encoder drwxrwxrwx 5 0 0 0
..drwxrwxrwx 2 0 0 0 .