En nu vanmidddag liggen mijn (statische Jekyll) websites er weer uit… Anderen ook hier last van?
zelfde hier, voor zowel hoofdsite als subsite
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'
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.
Nog even, ik ben er bijna hoop ik 
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…)
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.
Ik zie dat de mijne nu offline is.
Weer storing?
Update:
Soms doet hij het…de verbinding is heel slecht.
Ook https://isitup.org/ gaf aan dat het down was net.
Vandaag de W3C HTML test gedaan op mijn homepage.
Het veroorzaakt een 502 Error.
Minuutje later is alles weer 100% oké.
Vandaag weer een storing.
Krijg een foutmelding in de browser dat de afbeelding fouten bevat.
Ter controle het nog even op GSM gecontroleerd, hetzelfde.
Aanvulling:
Als ik in mijn.freedom kijk, zijn de 4 png afbeeldingen ook niet meer zichtbaar.
De bestandsnamen van de bestanden zijn er nog wel.
Ik kan zelf idd (ook) geen plaatjes meer in de online editor bewerken noch die (sleur-pleur) uploaden. Plaatsjes op bestaande website, worden ook niet meer getoond.
Zal toch niet dat de data foetsie is … 
Gedoe met de website 
, is iets dat veel vaker voorkomt. Ik blijf mij verbazen dat dit probleem steeds weer blijft terugkomen. Helaas ook geen aanbeveling voor betrouwbaarheid.
Ik vermoed dat jouw “valse” plaatje, mogelijk een leeg bestand (0-bytes) is geworden.
Ook maar ins-blues-hinein een helpdesk melding gedaan.
Hier hetzelfde probleem 
Iemand al een ticket gelogd?
Heb gebeld en doorverbonden en toen van de lijn gemikt vanwege de drukte.
Mailen doe ik niet meer, lezen ze toch niet.
Dat met het lege bestand, dacht ik ook aan.
Met het huidige systeem, lukt het me niet een bestand overzicht te maken.
Dit is aan Soverin om op te lossen.
Ik hoop wel dat de functionaliteit blijft, en dat ze niet ‘door het gedoe’ ervoor kiezen om met eenvoudige statische websites te stoppen.
Nee het is aan Freedom om dat op te lossen, als Freedom daar Soverin voor nodig heeft dan is het aan Freedom om dat te regelen.
De website staat bij Hetzner in Duitsland.
Al die verschillende bedrijven maakt het ingewikkeld.
Ik vermoed, zomaar, dat de plaatjes en andere binaire zaken van wbsites op/in een andere storagepool staan die het nu even niet doet.
Ook mijn platte (binaire) testbestanden varierend van 1Byte tot 100MByte doen het nu niet.
Maar goed dit is inmiddels een terugkerend probleem waarbij ik hoop dat dit niet weer maanden gaat duren.
Nu 2 keer helpdesk gebeld.
Op een gegeven moment gaan ze je doorverbinden met hosting.
En dan wordt je van de lijn gegooid wegens drukte.
Ik weet nog steeds niet of de melding nu een ticket heeft.
En er staat ook niets op storingen, waardoor de helpdesk nog meer belast wordt.
Dit probleem heeft 0,0, nada en niets met hosting te maken. Het probleem zelf zit bij Soverin waar ik inmiddels ook tegen een betonnen plaat aanloop.
Inmiddels werkt ook de expliciete webmail/authenticatie niet meer doet en ik dus mail met het opengestelde hoofdwachtwoord moet (laten) lezen.
Best lullig om “hier” ter verantwoording te worden geroepen omdat personen hun webmail niet meer kunnen lezen en het mijn “lumineuze” idee was om ivm veiligheid, daar authenticatie “restricties” in aan te brengen.
BTW: mail sturen naar helpdesk@freedomnet.nl levert/geeft een ticketnummer.
Ik stuur mail vanuit mijn hoofdaccount. Zorg wel dat je in je ondertekening je klantnummer, postcode/huisnummer e.d. zet. In een ver verleden wel eens snuggere Heijn gehad die het anders niet wilde behandelen. Ik hanteer een aparte mail identiteit (en model ondertekening) om de helpdesk te mailen.
Afbeelding is inmiddels weer zichtbaar.
1 like
Yep, Soverin heeft een fix doorgevoerd.