Die mening deel ik niet en als je jezelf niet kenbaar maakt dan is het ook lastig voor een bedrijf als freedom om te kunnen beoordelen hoe een maatregel valt.
Het is dus juist belangrijk om aan te geven wat een dergelijke maatregel doet met je als klant.
Tot op heden ben ik tevreden met Freedom als provider juist omdat ik verwacht bij dit bedrijf als klant wel serieus genomen te worden (en dit is tot op heden ook mijn ervaring).
Wellicht is dit een klein brainfartje van iemand die net van een opleiding komt of stagair is ofzo.
Zo komt het althans wel op mij over.
Er wordt meegelezen dus wellicht kan iemand van @Freedom hier wat opheldering in verschaffen.
Werkend met apex-domein op GitHub gaat dus goed zolang dat specifieke A-record IP adres van, vier bij, GitHub operationeel is.
Bij GitHub gebruikt de aanwezigheid van het A-record dat verwijst naar GitHub, vooral als verificatie dat de GitHub website op de apex-naam mag worden aangeboden OMDAT de eigenaar âkennelijkâ een A-record kan vestigen dus dus verwijst naar een GitHub IP-adres.
Met CNAME gebeurd indirect hetzelfde waarbij de CNAME tevens het userid bevat van de GitHub gebruiker.< /small>
Zelf zou ik aanraden om bij GitHub alleen gebruik te maken van de CNAME methode zodat er geen problemen ontstaan met (load)balancing of hacking.
Zoals GitHub ook zegt, vestig NOOIT een generieke â*â verwijzing naar GitHub voor paginaâs omdat daarmee ieder ander - bij GitHub - dan op jouw domeinnaam - mogelijk ongewenste - inhoud kan plaatsen.
In mensentaal wil dat zeggen, dat iemand bij Freedom, de â@â verwijzing veiligheidshalve MOET verwijderen wanneer die gebruik maakt van de A-pex-domein methode.
Freedom heeft geen enkele afweging gedaan en negeert stelselmatig opmerkingen. Ze hanteert simpelweg dat wat haar bevriende leverancier niet (meer) wil* bieden, zij ook niet meer zal (aan)bieden. Dit laatste is zonder eigen en zelf ingerichte servers of âkennis/kundeâ, is ook lastig te faciliteren.
Ik neem het Freedom ( @Anco ) wel kwalijk met een poging om de website-functie af te schilderen als âexperimenteelâ. Waar dus van blijkt dat Soverin die dienst simpelweg volgens contract per 1/1/24 heeft opgezegd. De term âexperimenteelâ lijk mij vooral gebruikt om daarmee geen âverplichtingenâ te hebben.
Soverin zelf is daarin een stuk zakelijker dat zij zich vooral op maildiensten wil gaan richten en derhalve o.a. de website-functie - vanwege zelf veroorzaakte complexiteit - stopt. Hoe âzekerâ andere Freedom âdienstenâ of âdetailsâ blijven bestaan, is zolang dat zo is.
//â//
Verwijzen naar gelieerde âpartnersâ of âvriendjesâ als zg. alternatief om een âfunctieâ voort te kunnen zetten, is een gekende methode om het geld uit de zo âvergrote(nde)â markt te halen. Liefst in het eigen bedrijf maar elders, is dan ook goed.
*Geen âwebsiteâ als onderdeel van een totaalpakket meer willen bieden, heeft en dient generiek helaas ook zeker een (neo-liberaal) marktvergrotend commercieel doel.
Gebruikers die hun âinclusieveâ websites immers willen voortzetten, gaan daar hier of elders, geld voor uitgeven.
Of die websites vinden âgratisâ elders een plek bij zeg een GitHub die daarmee zeggenschap & toegang krijgt tot inhoud. Reken maar dat iemand bij GitHub geen controversieel âverklaardeâ inhoud mag plaatsen.
Je kunt niet ontkennen gezien de problemen, dat het experimenteel was.
Ik neem Freedom het niet kwalijk dat het nu stopt.
Ik was in het begin ook een beetje pissig.
Ik hoop dat er in de toekomst er iets mooiers voor in de plaats komt.
ik ontken wel zeker dat het âexperimenteelâ was.
Dat iemand iets van MijnFreedom onbelangrijk vindt of niet gebruikt, staat los van of dat element voor anderen wel functionele waarde vertegenwoordigt.
Dat iets niet expliciet is omschreven in voorwaarden of (nog) niet is gedocumenteerd (cq. door âdrukteâ), maakt iets daarmee nog niet dus âexperimenteelâ.
De functie was expliciet deel - sws vanuit Soverin - van de geboden dienst en zelfs onbevlekt onderdeel van MijnFreedom.
Ik zou zonder website, laat staan andere ooit beloftevolle verwachtingen, niet zijn overgestapt.
Ik deel ook een hoop maar zie geen aanleiding nog te verwachten dat Freedom dat zelf(s) gaat bieden.
Nope, zo werkt RR niet. RR geeft de bezoeker random een IP-adres en checkt niet of dat IP-adres functioneel is. Dat IP-adres moet dus altijd functioneel zijn. Dat kan je oplossen met bijv. VRRP. Stel dat je 2 nodes hebt:
Node 1 heeft vast IP 192.168.1.1 en is VRRP master voor IP 192.168.1.101 en slave voor IP 192.168.1.102.
Node 2 heeft vast IP 192.168.1.2 en is VRRP master voor IP 192.168.1.102 en slave voor IP 192.168.1.101.
In de DNS zet je twee A-records, 1 naar 192.168.1.101 en 1 naar 192.168.1.102.
De ene bezoeker krijgt nu .101 en de andere .102 toegewezen en de load wordt zo verdeeld over node 1 en node 2. Overigens is dat is in de praktijk niet 50/50. Mocht een van de nodes uitvallen, neemt de andere node dat virtuele IP over en worden bezoekers dus allemaal afgehandeld door die ene node (failover). Zou je niet met virtuele IPâs werken en een van de nodes valt uit, zal ook een deel van de bezoekers downtime ervaren. Wil je meer sturing qua load en inderdaad een node uit de pool kunnen halen als deze niet (goed) reageert, zal je een echte loadbalancer moeten hebben, dan heb je ook maar 1 IP naar buiten nodig. Failover zonder echte loadbalancer kan natuurlijk ook met 1 IP, maar dan staan de failover nodes onder normale omstandigheden niks te doen, het nut van RR is dus om load te kunnen spreiden zonder loadbalancer, niet het verzorgen van redundantie (daar zal je nog steeds iets als VRRP voor nodig hebben).
Conclusie: met verwijzing naar slechts 1 van de 4 IPâs in de DNS zal je geen downtime ervaren als de node die standaard master is voor dat IP uitvalt. GitHub zal het alleen niet leuk vinden, want als iedereen dat doet kunnen ze geen load meer spreiden. Maar ja, dan hadden ze maar een fatsoenlijke (echte) loadbalancer moeten gebruiken.
Vanochtend bericht gehad dat het downloadprobleem van websites zou zijn opgelost door Soverin.
Helaas niet helemaal zoals ik zou (be)denken. De âfixâ is kennelijk dat diverse niet te downloaden bestanden van een website, nu als 0/null-bestand (dwz zonder inhoud) worden ingevoegd op de zip.
NB: Ik vermoed dat die pointer âfoutâ in de verre historie ligt waar bepaalde (database) verwijzingen naar bestanden corrupt raakt(en). Sommige plaatjes en âbinaireâ inhoud die ik daar ooit ordentelijk had ge-upload, hebben nu dus geen inhoud meer en zijn verschwunden.
Ik kan die verdwenen âfilesâ daarom ook niet meer online gebruiken of bewerken.
Kortom het âdownloadâ issue is niet fundamenteel opgelost maar zodanig gefikst dat de site-inhoud tenminste wel grotendeels kan worden gedownload. Het is raadzaam te controleren wat nog wel en niet aanwezig is.
Inmiddels is het 2024. Ik heb voor nu de github-methode gekozen voor mijn domein; op de langere termijn misschien wat anders, maar in minder dan twee maanden (en drukke maanden!) had ik geen zin om het hele domein te verhuizen. Ik heb dus domein en mail bij freedom, en host het www subdomein met een github page met CNAME.
Voor wie deze route ook gekozen heeft, de github jekyll is bijna hetzelfde, maar ik moest dit aanpassen:
voor het formatten van een datum moet je expliciet âdate:â als filter gebruiken in liquid. Op freedom jekyll kon je âsite.date | %YYâ gebruiken, op github moet dat 'site.date | date: â%YYâ zijn.
jekyll verwerkt alleen bestanden met expliciete front matter. Ik had css bestanden in assets/css staan met liquid, hernoemen in .scss en verplaatsen naar sass/ werkte niet; lege front matter (twee regels met â bovenaan) deed het 'm.
Nu kijken of ik een redirect op het kale domein kan zetten naar het www subdomein - want nu toont het kale domein nog de oude jekyll site, die soverin nog niet uit de lucht heeft gehaald blijkbaar.
Wat GitHub bij âforcedâ https doet is (elke 3 maanden) bij LetsEncrypt een certificaat vestigen op het (cnameâd) subdomein.
Wie dat certificaatverzoek technisch doet, is verder niet van belang. Voor LetsEncrypt is alleen belangrijk dat het (sub)domein actief & bereikbaar is⊠dat immers gehost via GitHub dan ook zo is.
NB: de âA/CNAME-recordâ methode duidt ook dat de geregistreerde user bij GitHub kennelijk gemachtigd is voor dat (sub)domein om GitHub de âPagesâ-repository inhoud, als website te presenteren.
//â//
Los daarvan, heb ik ook nog niets vernomen of en hoe Freedom mijn site verwijzingen, met ook https, gaat (in) regelen. Strikt genomen zitten we nu âexperimenteelâ in limbo.
Ik vrees dat die âtoezeggingâ, in de achtergrond wat ingewikkelder is dan men bij de uitspraak (be)dacht. Wanneer men âhttp(s)â op eigen domeinnaam gaat omleiden, wat sws een webserverfunctie impliceert, is de stap om inhoud te hosten bijzonder klein.
Dat men met aangedragen complexiteit (als zwak excuus) afziet van Jekyll om Websites te generen, is een ander stuk van het afzwaai-verhaal.
Update voor de geinteresseerden in deze saga: vandaag merkte ik dat op mijn hoofddomein (zonder www) een redirect was ingesteld naar⊠mijn oude xs4all homepage! Throwback (waar dat vandaan is gekomen⊠misschien ooit ingesteld toen freedom begon?)
Laatste keer dat ik dit had gecheckt was 5 of 6 januari, toen werkte jekyll nog steeds, in het pagina template heb ik toen vast een redirect-link verwerkt.
De redirect is aan te passen in mijn.freedom; zonet gedaan, en het werkt netjes. De hele url wordt doorgestuurd, dus domein.nl/kalender gaat door www.domein.nl/kalender.
Goede uitleg.