Mijn website doet het niet

INTERNET TOEGANG
9

Ik zou altijd een _yaml.cfg gebruiken zodat je daarmee minder aan het toeval over laat, dus
maak in de root van je website een bestand: met tenminste inhoud

# General configuration
title: Jouwe titel tekst
baseurl: /
host: cname.jouwdomain.nl

NB: met base-url kan je subdirectoriesvoorvoor andere andere sub/subdomeinen, fgoed kans dat de site van OP is verplaatst (wat zo onze internet vrijheid is).

Aan/in die configuratie kan je dan bv toevoegen dat het een markdown of andere type opmaak heeft, bv dat je markdown opmaak hanteert zodat je “index.md” inhoud wel gaat werken.

# Build settings
markdown: kramdown

etc.etc., lees hier Configuration | Jekyll • Simple, blog-aware, static sites voor veel meer opties.
sommige opties w.o. toml/flags zijn niet zelf in te stellen. Ze zijn bedoeld voor serverbeheerder die jouw website als data in “zijn” servergebied huisvest. Het concept is dat Freedom aka. Soverin je een CMS-skeleton bieden vanwaaruit jouw statische website (periodiek) wordt aangemaakt. Soms is dit idd botertraag en kan het even duren omdat een website die niet mogelijk meer in de cache zit, pas wordt aangemaakt op het moment dat die daadwerkelijk wordt opgevraagd,

10

Dank voor alle tips. Helaas is ook met een _yaml.cfg de site nog altijd down. In verschillende browsers en met curl. https://heesk.nl - zowel met als zonder www subdomein.

Ik heb de site pas een paar dagen geleden voor het eerst opgezet, met alleen de index.md, en het werkte prima… is er niet toch iets anders in de hand? Loopt het jekyll proces misschien niet?

11

Staat je cname (DNS instellingen) wel goed doorverwezen… ? die komt nl. uit op 116.202.65.212, dat imo onjuist is. Jekyll doet het prima op mijn 10+ sites.

Gezien de endless timeout op jouw site, denk ik dat je (onbedoeld) een verkeerd ip/adresverwijzing gebruikt… , verkeerd ms niet eens zozeer door jouzelf maar omdat het IP waar onze cname koppelt koppelt aan de loadbalanced website-server kennelijk - work in progress - wel’s kan veranderen.
Momenteel zijn er sws verschillende wegen die leiden naar de IP locatie(s) die onze website(s) door/verwerken. Hierbij even :sleeping: accepteren dat het/er Work-In-Progress is.

Wat je , denk ik, het beste kan doen, is een cname maken met ‘www’ op jouw domein dat dan verwijst naar zeg ‘lb1.soverin.net’ of zo je wilt, ip 185.233.34.11. De yaml van je website laat je dan reageren op ‘host: www.jouwdomein.nl’.

P.S> zelf gebruik (daarom) geen IP nummers meer in mijn cname verwijzingen voor mijn websites. Ik gebruik een tussenliggende cname binnen in mijn eigen domein die mijn website-cname dorokoppelt aan “soverin.net”.
Mijn websitenaam wijst dan bv naar mijnsites.mijndomein.nl dat, waar “mijnsites” dan weer verwijst naar “soverin.net”. Ik kan dan mijn sites makkelijk (om)schakelen naar een gewenst ip adres en als de boze wereld veranderd hoef ik maar één DNS record te veranderen.

12

Achtergrond: ik heb dit domein aangemaakt bij de start van freedom (2017?), maar ben het pas deze week gaan gebruiken. Misschien dat er daarom wat instellingen niet goed staan. Ik heb nog nooit naar het DNS record gekeken.

Een wijziging in het DNS record naar de naam wil opslaan krijg ik een foutmelding (met ref 8121ba55). (dit is een community forum, maar ik krijg het idee dat de helpdesk hier meeleest. het lijkt het oude xs wel :slight_smile:

Wat ik wel kon doen was beide A records aanpassen aan het IP 185.233.34.11. Nu geeft de site een ongeldig ssl certificaat, want voor *.freedom.nl. Oeps. Eerder deze week werkte https op mijn eigen domein wel.

13

FF onthouden dat wanneer je een cname doorverwijst op naam, de gebruikte domeinnaam dan moet eindigen op een punt. dus “blabla.domein.nl.” . Dit is/mag weer niet wanneer je een A-record instelt.

Dat SSL op eigen domein is idd ook een irritant dingetje waarmee ik in mijn omgeving ook ‘gepest’ word. Freedom zou voor onze domeinen sws een certificaat moet laten registreren zodat onze domeinen legitiemer worden. Wel https afdwingen maar geen http (zonder “s”, meer) als keuze bieden, is vragen om grappen,.
Gek genoeg heeft dat SSL ook eerst niet, dan weer wel een tijdje goed ging en sinds een paar weken zijn (ook) mijn sites ook weer “insecure”. Ik heb vaker een melding gedaan en specifiek t.a.v. ssl nooit iets constructiefs vernomen. Het ligt verder niet aan Freedom, Soverin sites hebben hetzelfde issue.
Na acceptatie van de ontbrekende SSL fout, is de site alsnog bereikbaar.

Maar goed, ik weet dat men in de achtergrond druk bezig is zaken beter op te zetten en ga als pionier niet kniesoren dat een p[rivacy-minded site tenminste zelf een geldig certificaat zou moeten hebben voor door haar gesupporteerde domeinen.

14

Met die punt er achter kan ik het DNS record opslaan, dank!

http altijd redirecten haar https is wel van deze tijd natuurlijk - maar het moet wel werken. Stomme is, tot deze ellende gisteren begon (toen ik een jekyll template uitprobeerde en dat tot een tweede untitled site leidde) heeft het een paar dagen wél gewoon gewerkt - en dat kan toch alleen als er een geldig certificaat op mijn domein aanwezig was?

Voorzichtige aanname: als pionier (ik schreef me in bij de oprichting) kreeg ik instellingen voor het domein, inclusief cert; die instellingen zijn nu overschreven door wat nu vier jaar later de standaard instellingen zijn. Dat cert zal hopelijk nog ergens staan… ik ga maar een ticket voor de helpdesk maken.

Als ik de waarschuwingen negeer zie ik de site nu weer, dat is een win. Maar tot de SSL werkt is de site voor de buitenwereld als visitekaartje niet bruikbaar natuurlijk.

Enfin, ik gun freedom het beste, ben niet voor niets al sinds oprichting slapend steunlid, en het komt vast goed. Vervelend dat dit net op vrijdagavond moet gebeuren :wink:

15

Voor wie deze thread later leest: de DNS settings zijn niet voor alle domeinen hetzelfde! De settings die mij werden aangeraden werken vaak wel, maar in mijn geval niet, volgens de helpdesk.

Lang verhaal kort: helpdesk vroeg om mijn DNS terug te zetten naar de standaardinstellingen. Daarna wordt binnen max 24u een nieuw cert gemaakt. In mijn geval al in een paar uur; en nu werkt het weer! Overigens met de _yaml.cfg die ik eerder niet had, dat was ook een goede tip; dank voor de help PtrO!

2 likes
16

Samen komen we wel ergens (vooruit).
//–//
Weet iemand wat die “standaard” instellingen zijn ?
Oftewel, welke IP resolv gaat zorgen dat er dan wel een certificaat ontstaat ?

Ik heb inmiddels zoveel (ook veranderd) dat ik niet meer weet wat standaard zou moeten zijn, ook omdat die in het verleden - vaak - niet werkte(n).

17

De standaardinstellingen kreeg ik met de knop ‘Herstel’ in de DNS editor (pas de tweede keer!), waren als volgt:

Naam Type Waarde
@ A 116.202.65.212
mail CNAME webmail.freedom.nl
www CNAME @

HTH!

1 like
18

Check :+1:… sites die resolven op 116.202.65.212 krijgen idd een ceritifcaat.

19

Yup, maar 116.202.65.212 valt dus af en toe uit… (begin oktober 2021 en half februari 2022 heb ik het gemerkt iig). Beide keren was het na een helpdeskmelding bij freedom/soverin opgelost. Vraag blijft wel of dit een structurele oplossing gaat krijgen.

Ik hoop dat iemand van Freedom meeleest en zijn/haar licht hierover laat schijnen.

P.S. @ctjacobs tjacobs @kris.freedom misschien even de titel aanpassen naar “Mijn statische (Jekyll) website doet het niet”. Om een duidelijk onderscheid te maken met de webhosting oplossing van Freedom?

20

Dat zal dan idd (mijn) reden geweest kunnen zijn om zo (wel) iets werkend te krijgen. Thx.
Ik vermoed dat @FreedomBot wel zal meelezen.

Verder wel leuk om (af en toe) rechercheur te spelen en gaandeweg dingen werkend te krijgen.
Ik vermoed dat wanneer iemand op 116.202.65.212 een eigen-website aanbied en er nog geen certificaat is, daar dan alsnog een Let’sEncrypt aanvraag voor wordt gelanceerd.
Mijn cert is nu geldig van 17 Feb 2022 14:00:49 tot 18 May 2022 14:00:48 GMT.

update 17u45: er zit wel iets automagisch in. De ene website van mijn domein doet het alleen met lb1.soverin.net (waar dan geen certificaat op zit ). Wanneer ik exact diezelfde website qua DNS doorverwijs naar de standaard (@ =) 116.202.65.212 doet die het daar ineens helemaal niet.
Terwijl mijn andere websites met die instelling het juist weer prima doen en dan voorzien zijn van een prachtig certificaat.

In het geval de site niet bereikbaar is op 116.202.65.212 krijg ik

# This site can’t provide a secure connection
**test.xxxxx.nl** sent an invalid response.
ERR_SSL_PROTOCOL_ERROR

Het gaat interessant worden hoe het onderliggende proces precies in elkaar steekt dat de websites (aan)maakt. ook kan dan duidelijk worden waarom het soms juist wel en soms weer niet functioneert.

1 like
21

Klopt, ik zag het zelfde gisteren nadat ik een tweede (statische Jekyll) website had toegevoegd. Tot gisteravond werkte deze niet, maar vanmorgen deed de website het opeens. Kennelijk moet er dus iets gebeuren voordat de website actief kan worden en een ssl certificaat krijgt. Ben ondertussen wel benieuwd hoe dit nu precies in elkaar zit.

22

Nu je het over twee jekyll sites hebt, beetje off-topic, maar hoe krijg ik dat voor elkaar op 1 hostname? Is dat mogelijk?

Hoofdsite heeft _yaml.cfg met oa deze settings:

General configuration

title: heesk.nl main
baseurl: /
host: www.heesk.nl

Een testsite, op basis van het template in de interface, met een _config.yml met oa deze settings:

Site settings

title: template test
baseurl: “/templatetest/” # the subpath of your site, e.g. /blog/
url: “heesk.nl” # the base hostname & protocol for your site
host: www.heesk.nl # niet in default

Ik had verwacht dat de tweede site (na een paar minuten wachten) zichtbaar zou worden op heesk.nl/templatetest/index.html - maar helaas, een 404. Is dit mogelijk?

23

En nu vanmidddag liggen mijn (statische Jekyll) websites er weer uit… Anderen ook hier last van?

24

zelfde hier, voor zowel hoofdsite als subsite

25

Idem, het werkt niet.

Het is bij @Freedom een zoekplaatje aan het worden. Best vervelend dat er niet gerekend kan worden op stabiliteit. De website die voorheen secure was (verwijzend naar het @=eigendomein) bij Freedom doet het nu niet meer. Terwijl de websites die verwijzen naar “lb1.soverin.net.” het - insecure - wel doen. Bij Freedom een ticket ingeschoten.

Jammer dat Freedom hier geen monitoring op heeft lopen of de website normaal bereikbaar zijn
iets met curl -v op je website, wat niet verder komt dan:

$ curl -v https://www.xxxxxx.nl
* Rebuilt URL to: https://www.xxxxxx.nl/
*   Trying 116.202.65.212...
* TCP_NODELAY set
* Connected to ww4.xxxxxx.nl (116.202.65.212) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/certs/ca-certificates.crt
  CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):

Website die verwijst naar en dan weliswaar insecure wel werkt gaat/komt verder als :

$ curl -v https://test.xxxxxxxx.nl
* Rebuilt URL to: https://test.xxxxxxxx.nl/
*   Trying 185.233.34.11...
* TCP_NODELAY set
* Connected to test.xxxxxxxx.nl (185.233.34.11) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/certs/ca-certificates.crt
  CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS Unknown, Certificate Status (22):
* TLSv1.3 (IN), TLS handshake, Unknown (8):
* TLSv1.3 (IN), TLS Unknown, Certificate Status (22):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS Unknown, Certificate Status (22):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS Unknown, Certificate Status (22):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Client hello (1):
* TLSv1.3 (OUT), TLS Unknown, Certificate Status (22):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_128_GCM_SHA256
* ALPN, server accepted to use h2
* Server certificate:
*  subject: CN=*.freedom.nl
*  start date: Dec 10 10:48:50 2021 GMT
*  expire date: Mar 10 10:48:49 2022 GMT
*  subjectAltName does not match test.xxxxxxxx.nl
* SSL: no alternative certificate subject name matches target host name 'test.xxxxxxxx.nl'
* stopped the pause stream!
* Closing connection 0
* TLSv1.3 (OUT), TLS Unknown, Unknown (21):
* TLSv1.3 (OUT), TLS alert, Client hello (1):
curl: (51) SSL: no alternative certificate subject name matches target host name 'test.xxxxxxxx.nl'
26

De base-url en url functie is vooral voor de hoster (hier Freedom aka Soverin) die dan sites in volledig beheer opbergt in (haar) aangewezen subdirectories.

Voor ons als eindgebruikers, lijkt dat base/url geen echte functie te hebben of te bieden. “Wij” bergen onze sudirectory site gewoon op in en als een nieuwe subfolder binnen in de structuur van de (cname’ed) hoofdwebsite.

website-folder ← bereikbaar via https://cname.jhouwdomein
website-folder/subfolder ← dan bereikbaar via https://cname.jouwdomein.nl/subfolder

Standaard daarin wordt dan de index.html (of index.md ingesteld in de yaml-file) aangevuurd als start pagina.

27

Nog even, ik ben er bijna hoop ik :slight_smile: 1 cname dus, met een website-folder en een subfolder, en voor elk een jekyll-installatie via de interface van freedom aka soverin. Hoe geef ik dan aan dat die elkaar niet bijten, dus dat de een in de root komt te staan en de ander in de subfolder, als dat niet gaat via base-url en url in de _yaml.cfg files?
(misschien werkt het gewoon, maar ik kan het nu niet testen want alles geeft een timeout…)

28

Website 101: Het is niet moeilijker dan het is en of iets elkaar bijt is vooral hoe je in html de “urls” relatief, root-relatief of absoluut structureert. Je kan op je hoofdwebsite (stel www) net zoveel subfolders maken als je wilt die zich elk voordoen als (gesubfolderde/…/…/) website.

Op een eigen apache-server kan je aan de buitenkant een standalone website zoals http://subnaam.website.nl doorverwijzen naar een (sub)folder.
Bij onze Jekyll, naast CMS, werkt dat net weer even anders waarbij Freedom/Soverin onze website opbergt in een database-locatie vanwaaruit dan de website wordt gegenereerd. De Jekyll functies is dan weer dat bepaalde {{…}} attributen , structuren(en ook specifieke html codes) worden gescand en dan omgezet naar absolute eindwaarden.

Expliciet urls zoals http://jouwsite.nl/foldernaam/file.jpg verwijzen in/op jouw cname-website expliciet naar een daar binnenin liggend bestand in subfolder “foldernaam”.
Een plaatje (via ) met bv alleen “file.jpg” verwijst automatische naar het bestand dat in de relatieve ‘root’ van jouw website-foldernaam-url staat.
Een daarin relatief gecodeerde “subfolder/file.jpg” (dus zonder / of http) verwijst automatische naar de subfolder binnenin foldernaam van de gebruikte website url van http://jouwsite.nl/foldernaam/

NB: Normaliter zal je in/op een website niet snel absolute (of root) verwijzingen gebruiken voor elementen die zich binnen in de websitelocaties bevinden wat bv ook een subsubfolder kan zijn.

Wat ik zelf nu heb zijn iets van 20 websites die via cname uitkomen op apart “editable” websites waarin ik sommige websites (dwz cname’d) dan weer via diverse subfolders opsplits in bv http://www.mijnsite.nl/fotoboek1/ en http://www.mijnsite.nl/fotoboek2/

NB: er zijn nog andere, mogelijkheden om websites Jekyll niveau op folderniveau naar/met door te verwijzen. Ik heb bv (cname) websites die via een inhoudelijke “index.link” bestand dan redirecten naar een bepaalde folder van een andere website. In markdown (index.md) kan je ook het “redirect: http:/bla.bl/folder” statement gebruiken. Ik kan bv dan bv (cname’d) http://fotoboek3.mijnsite.nl laten uitkomen op een subfolder van http://www.mijnsite.nl/fotoboek3/

Kortom de mogelijkheden zijn eindeloos en in zekere zin exponentieel groter dan wat ik (ooit) had bij xs4all waar ik alles statisch moest opbergen binnenin de hoofdsite.