Doorverwijzing website (redirect) lukt niet

Mijn eerste post, eens even kijken of de Freedom community net zo lekker werkt als Xs4all …

Ik had destijds (tig maanden geleden) mijn domein laten doorverwijzen naar een rf.gd website (infinity webhosting). Dat deed het keurig.
Maar ik kreeg afgelopen weeek een bericht van iemand dat mijn … .nl account niet meer in de lucht was.

Dus maar eens even ingelogd bij Freedom om te ervaren dat de UI nogal verandert is.

Bij mijn instellingen stond keurig een redirect to URL met daarbij drie bestanden: readme.md, config.yml en index.link. Dat laatste bestand bevat netjes een regel met de website waar ik naar doorverwijs.

De help pagina’s gelezen. Dan blijkt dat je dit schijnbaar twee keer moet doen (???) dus dat ook maar gedaan.

Nu heb ik dus twee redirect to url’s. Beide gelijk.

En toch werkt het niet!

Is dit een bug of hebben anderen hier geen last van?

Welkom. Waar heb je de redirect precies ingesteld ?
Dat je dit ooit werkend had, kan zijn.

En ja de UI varieert als Work In Progress. De positie/plaats van knoppen is niet altijd even doorzichtig. ook moet je even wachten totat dat de pagina echt volledig ingeladen is voordat je clicht omdat je anders zomaar (onbedoeld) een andere knop indrukt. Maar goed, dat is pionieren met te weinig personeel en komt op termijn wel goed.

Persoonlijk was en ben ik niet zo gecharmeerd van de Jekyll read/me/yml & markdown constructie (die is/lijkt overgenomen van Soverin) en zou liever zien dat men gewoon een ordinaire platte html (en nog liever php)-constructie heeft. Zodat die met ftp/scp en nog liever als shell) te onderhouden is.

redirect ingesteld via de normale inlog, dan domeinen, vervolgens klikken selecteren van het betreffende domein.
Dan krijg je in het linkwerdeel van je browser een menu. Daarin kies ik website en zie ik in het hofdvenster de redirects. (beiden) en de regel daaronder andere maniern om een website te uploaden of aan te maken.

En ja, graag normale SFTP. Dan kan ik vanuit mijn editors direct uploaden/editen/etc.

Dit is leuk voor dummies maar ik weet hoe het werkt en doe het liver met zo min mogelijk laagjes er tussen.

Thx (terug)gevonden. Behalve editen, kan ik er verder niets mee en dit heeft een paar weken geleden nog gewerkt. Had nl. mijn xs4all homepage naar Jekyll template laten verwijzen.
Zelf zou ik het ook een misser vinden als Freedom die Website4Dummies methode gaat bewandelen.

Probleem gemeld via mail, na een week gebeld naar de helpdesk. Keurig geholpen, medewerker kijkt en ineens doet de doorverwijzing het nadat medewerker er ook naar gaat kijken
Onbekend of dit nu kwam omdat hij er nar kijkt (en misschien er toch wat permissies gewijzigd zijn) of dat het op een andere toevallige wijze nu ineens wel werkt.

Moet denk ik wat geduld hebben, dingen gaan steeds beter en sneller.
Ik kan nu websites aanmaken, benaderen en openen.
Moet erg wennen aan het CMS-look-a-like mechanisme.

Hiervoor, zover men nog niet bekend:

  1. In DNS een CNAME record ‘websitenaam’ als prefix met verwijzing naar @-apestaart
  2. Website met daarin _config.yml file met inhoud:
    title: websitenaam.domein.nl
    host: websitenaam.domein.nl

En de rest van files/riedles/data voor een werkende website.

@jippe :sunglasses: ik kan nu ook volgens Jekyll redirect link - Stack Overflow doorverwijzen.

Dit werkt helaas niet bij mij.
Een paar instellingen van DNS:
‘@ A 116.202.65.212 5 minutes’
‘* A 116.202.65.212 5 minutes’
‘website CNAME @ 5 minutes’

en in _config.yml (ivm privacy in deze post even […] voor domeinnaam bij freedom hieronder gezet)
'# General configuration
title: website.[…].nl
host: website.[…].nl

TLDR; Helder… ipv 116.202.65.212 moet daar 116.202.126.227 staan.

Ip 116.202.65.212 is kennelijk voor/bij Freedom in gebruik en werkt dan niet. Ip 116.202.126.227 verwijst naar de wel werkende loadbalancer van Soverin, waar Freedom onze/haar zaken allemaal heeft ondergebracht. Check zelf e.e.a. met nslookup/dig.
Ik weet, allemaal vaag en vermoed dat de boys & girls, nog het nodige te stroomlijnen hebben om de gele saus er over heen te zetten.

Wat je ter onderscheid/test kan doen. is je te testen website-cname rechtstreeks doorverwijzen naar dus dat ip 116.202.126.227.
De andere (generieke/catchall) referenties op het eigen domein blijven dan in dat - niet werkende - zwarte gat komen.
Zelf heb ik overigens de ‘*’ verwijzing compleet verwijderd omdat ik geen catchall website wil(de) hebben.
NB: mensen die dat generiek wel willen kunnen op Jekyll/CMS dat ook anders in & afregelen.
Om mijn eigen DNS leven wat makkelijker te maken laat ik mijn ‘@’ verwijzen naar 116.202.126.227.
Mijn 'website´ CNAME’s van/bij ‘Freedom’ verwijs ik dan naar die @ zodat ik makkelijk alles kan schakelen (bv naar mijn eigen servers).

NB: DNS/caching e.d. kan soms (flink) wat vertraagd zijn. Om zeker te weten of je website CNAME idd goed doorverwijst naar 116.202.126.227, doe even een ping/nslookup. Of gebruik de 1.1.1.1 (privacy respected) als DNS die vrijwel direct is/ wordt bijgewerkt wanneer je wat veranderd op DNS.

Suc6 en laat weten.

1 like

Dat eerste werkt niet dat geeft een foutmelding en gebeurt vervolgens niet.
Het tweede werkt wel. Dan gaat het goed met website.[…].nl die dan naar de simpele website bij freedom uitkomt op mijn domeinnaam.
Maar helaas geen https:
enig idee hoe je dat aan de praat kan krijgen?

Excuses voor mijn typo verwarring, je moet een website die moet omleiden naar een IP adres natuurlijk definiëren als A-record. Een CNAME is bedoeld om op naam (dus ook @) om herleiden naar een naam die ergens/elders weer zal uitkomen op een IP adres (dwz A-record).

Die foutmelding dat onze websites geen https ondersteunen komt omdat Soverin en dus Freedom, alleen Let’s encrypt certifcaten heeft voor het ‘*.caldav.soverin.net’ domein.

Dus je/ik zal het moeten doen met die https ‘fout’. Onduidelijk is, al jaren, of er ooit iets zal worden gedaan aan die certificaten kwestie. Zelf vind ik dat overigens onbelangrijk omdat ik de website-functie vooral zie als simpele test/presentatie. Voor echte hosting en meer controle, kan je een hosting/pakket overwegen.

Ik vind het wel belangrijk omdat browsers er tegenwoordig flink over zeuren. Voor een simpele website is een hosting pakket veel te veel van het goede.

Een https certificaat op de simpele website zou toch door Freedom te regelen moeten zijn. Wat doet anders de ACME challenge op mijn DNS instellingen pagina bij freedom?

Die ACME is d8 ik bedoeld voor dns/mailplugin toepassingen. Zover ik weet wordt ACME challenges (nog) niet ondersteund door wildcard domainen noch NGINX, onderliggende webserver, van Soverin. Zelf zou ik sws niet snel daarin willen rommelen. Voor je het weet doet er niets meer - goed - van je (mail)domein.

Het https certificaat zal Freedom per eigen domein dan via Soverin moeten zien in gaan te regelen, Ik voorzie dat dit proces via ACME een ingewikkelde uitvoering, zie voorbeeld, zal (gaan) hebben.
Het certificaat verkrijgen of activeren is weliswaar een eenvoudige edoch complexe handeling dat dan ook onderhouden moet worden (omdat certificaten doorgaans verlopen).
Zelf zou ik, zonder reden, er niet snel toe overgaan. Dat de wereld om ons heen dat zo fijntjes gewoon vindt of zelfs vereist, is weer een andere discussie.

NB: Veel hostingbedrijven bieden SSL certificaten - deels als (nofi) verdienmodel - alleen in combinatie met hun gefaciliteerde webhosting. Het certificaat - bv. Let’s Encrypt, kost relatief weinig of is soms zelfs gratis (bestaat niet !!!).
Het in/aanbrengen als handeling kost dan een beheerder geld of vaak alleen mogelijk in combinatie met (extra) webhosting. Homepages bij providers zoals bv xs4all, hebben doorgaans automatisch ook SSL omdat zij binnenin het provider (hier eindigend op xs4all.nl) domein automatisch ook SSL bieden voor hun gebruikspagina’s.
Dat browsers er over zeuren is vooral omdat de check optie dan aanstaat.