The Wiert Corner – irregular stream of stuff

Jeroen W. Pluimers on .NET, C#, Delphi, databases, and personal interests

  • My badges

    Mastodon

  • Twitter Updates

  • My Flickr Stream

    20140508-Delphi-2007--Project-Options--Cannot-Edit-Application-Title-HelpFile-Icon-Theming20140430-Fiddler-Filter-Actions-Button-Run-Filterset-now20140424-VMware-Fusion-6.0.3.-no-reclaimable
    More Photos

  • Pages

  • All categories

  • Enter your email address to subscribe to this blog and receive notifications of new posts by email.

    Join 1,854 other subscribers

Archive for the ‘Internet’ Category

« Previous Entries
Next Entries »

Setting up a GitLab project so it is served over https as a gitlab.io and a custom subdomain

Posted by jpluimers on 2022/05/05

Last week, I posted about Setting up a GitHub project so it is served over https as a custom github.io subdomain.

Today it’s the equivalent, but on GitLab.

Why GitLab? Two major reasons: unlike GitHub:

  1. it’s open source
  2. provides way more granular control over permissions
  3. allows a hierarchy of repositories on which you can specify that permission control

Already 2. and 3. combined are a huge advantage, though we will see that 3. also makes some of the subcases (hosting as user.gitlab.io from account gitlab.com/user where user is your username) is harder than the similar user.github.io, github.com/user combo.

So here we go, starting with a similar set of links:

The goal is to have

  1. page projects as or under wiert.gitlab.io (like wiert.gitlab.io/wiert)
  2. a gitlabstatus.wiert.me plain html (or maybe markdown) page project that eventually will show some status information (kind of like status.gitlab.com, but for different things).

The beauty of GitLab is that it supports hierarchies of repositories through groups and subgroups, so I already had these subgroups hoping they would cover both the first and second kind of page projects:

Steps I did

Since there are quite a few links above, here are the steps I took from my gitlab.com/wiert account and gitlab.com/wiert.me group.

Steps for wiert.gitlab.io/wiert

  1. For wiert.gitlab.io/wiert, try A (failed in part, and therefore interesting to understand why):
    1. Under leaf group gitlab.com/wiert.me/public/web/sites/gitlab.io, created a new GitLab repository
    2. Chose “Create from template”
    3. Chose the template “Pages/Plain HTML”
    4. Named the project “wiert” (with slug “wiert“) so it would appear at gitlab.com/wiert.me/public/web/sites/gitlab.io/wiert
    5. From the left sidebar, navigated to your project’s “CI/CD”, then “Pipelines”
    6. Now I got in a confusing situation as the page indicated “There are currently no pipelines.”, but an enabled blue “Run pipeline” button:
      By default there is no CI/CD pipeline, but there is an enabled blue "Run pipeline" button: confusing.

      By default there is no CI/CD pipeline, but there is an enabled blue “Run pipeline” button: confusing.

    7. Clicked the “Run pipeline” button nonetheless, and that created [Wayback/Archive.is] a pipeline asking for parameters (that already had correct default values) and revealed a new blue “Run pipeline” button.
    8. Clicked that new “Run pipeline button” which created [Wayback/Archive.is] a job and deployed the page.
    9. From the left sidebar, navigated to “Settings”, then “Pages” to get the links to the pages site: http://wiert.me.gitlab.io/public/web/sites/gitlab.io/wiert/ and https://wiert.me.gitlab.io/public/web/sites/gitlab.io/wiert/
      Warning: When using Pages under the general domain of a GitLab instance (gitlab.io), you cannot use HTTPS with sub-subdomains.

      Warning: When using Pages under the general domain of a GitLab instance (gitlab.io), you cannot use HTTPS with sub-subdomains.

      The sites do work (see the [Archive.is http version] and [Archive.is https version]), but the HTTPS fails because wiert.me.gitlab.io does not match the SANs (Subject Alternative Names) in the certificate: *.gitlab.io, gitlab.io

  2. For wiert.gitlab.io/wiert, try B (failed, and therefore interesting to understand why):
    1. In my my groups gitlab.com/dashboard/groups, added a new group wiert
    2. Added subgroups until the leaf gitlab.com/wiert/public/web/sites/gitlab.io which as URL is gitlab.com/wier1/public/web/sites/gitlab.io because user account wiert already occupies gitlab.com/wiert.
    3. Under leaf group gitlab.com/wier1/public/web/sites/gitlab.io, created a new GitLab repository
    4. Chose “Create from template”
    5. Chose the template “Pages/Plain HTML”
    6. Named the project “wiert” (with slug “wiert“) so it would appear at gitlab.com/wiert.me/public/web/sites/gitlab.io/wiert
    7. From the left sidebar, navigated to your project’s “CI/CD”, then “Pipelines”
    8. Again there was “There are currently no pipelines.”, but an enabled blue “Run pipeline” button, which I clicked
    9. That created [Wayback/Archive.is] a pipeline asking for parameters (that already had correct default values) and revealed a new blue “Run pipeline” button.
    10. Clicked that new “Run pipeline button” which created [Wayback/Archive.is] a job deployed the page.
    11. From the left sidebar, navigated to “Settings”, then “Pages” to get the links to the pages site: http://wier1.gitlab.io/public/web/sites/gitlab.io/wiert and https://wier1.gitlab.io/public/web/sites/gitlab.io/wiert.
      Bummer: again not the wiert.gitlab.io/wiert I hoped for
      The sites do work (see the [Archive.is http version] and [Archive.is https version]). The HTTP does not redirect to the HTTP version, as I did not tick the

      ☐ Force HTTPS (requires valid certificates)

    12. If a user wiert exists and occupies gitlab.com/wiert, then a group named wiert cannot occupy gitlab.com/wiert, and therefore a project named wiert within that group won’t be deployed to wiert.gitlab.io/wiert.
      Maybe this can be shortened like “if there is a user wiert, then no group named wiert cannot be used to contain a project named wiert to host as wiert.gitlab.io/wiert“.
      Let’s find out!
  3. For  wiert.gitlab.io/wiert, try C (success, steps 1, 3, 4, 7 and 8 were the key ones):
    1. In my user gitlab.com/wiert, created a new GitLab repository
    2. Chose “Create from template”
    3. Chose the template “Pages/Plain HTML”
    4. Named the project “wiert” (with slug “wiert“) so it would appear at gitlab.com/wiert
    5. The odd but cool thing is that the actual project now ended up at gitlab.com/wiert/wiert:
    6. From the left sidebar, navigated to your project’s “CI/CD”, then “Pipelines”
    7. Again there was “There are currently no pipelines.”, but an enabled blue “Run pipeline” button, which I clicked
    8. That created [Wayback/Archive.is] a pipeline asking for parameters (that already had correct default values) and revealed a new blue “Run pipeline” button.
    9. Clicked that new “Run pipeline button” which created [Wayback/Archive.is] a job deployed the page.
    10. From the left sidebar, navigated to “Settings”, then “Pages” to get the links to the pages site: http://wiert.gitlab.io/wiert/ and https://wiert.gitlab.io/wiert/.
      Success: finally the wiert.gitlab.io/wiert I hoped for:

      Success: published at https://wiert.gitlab.io/wiert/

      Success: published at https://wiert.gitlab.io/wiert/

      The sites do work fine (see the [Archive.is http version] and [Archive.is https version]). The HTTP does not redirect to the HTTP version, as I did not tick the

      ☐ Force HTTPS (requires valid certificates)

Steps for wiert.gitlab.io

  1. For wiert.gitlab.io, try A (failed, and therefore interesting to understand why):
    1. Under leaf group gitlab.com/wiert.me/public/web/sites/gitlab.io, created a new GitLab repository
    2. Chose “Create from template”
    3. Chose the template “Pages/Plain HTML”
    4. Named the project “wiert.gitlab.io” (with slug “wiert.gitlab.io“) so it would appear at gitlab.com/wiert.me/public/web/sites/gitlab.io/wiert.gitlab.io
    5. From the left sidebar, navigated to your project’s “CI/CD”, then “Pipelines”
    6. Again there was “There are currently no pipelines.”, but an enabled blue “Run pipeline” button, which I clicked
    7. That created [Wayback/Archive.is] a pipeline asking for parameters (that already had correct default values) and revealed a new blue “Run pipeline” button.
    8. Clicked that new “Run pipeline button” which created [Wayback/Archive.is] a job deployed the page.
    9. From the left sidebar, navigated to “Settings”, then “Pages” to get the links to the pages site: http://wiert.me.gitlab.io/public/web/sites/gitlab.io/wiert.gitlab.io and https://wiert.me.gitlab.io/public/web/sites/gitlab.io/wiert.gitlab.io.
      Failure: not the wiert.gitlab.io I hoped for.

      The sites do work (see the [Archive.is http version] and [Archive.is https version]), but the HTTPS fails because wiert.me.gitlab.io does not match the SANs (Subject Alternative Names) in the certificate: *.gitlab.io, gitlab.io. The HTTP does not redirect to the HTTP version, as I did not tick the

      ☐ Force HTTPS (requires valid certificates)

  2. For wiert.gitlab.io, try B (failed, and therefore interesting to understand why):
    1. Under leaf group gitlab.com/wier1/public/web/sites/gitlab.io, created a new GitLab repository
    2. Chose “Create from template”
    3. Chose the template “Pages/Plain HTML”
    4. Named the project “wiert.gitlab.io” (with slug “wiert.gitlab.io“) so it would appear at gitlab.com/wier1/public/web/sites/gitlab.io/wiert.gitlab.io
    5. From the left sidebar, navigated to your project’s “CI/CD”, then “Pipelines”
    6. Again there was “There are currently no pipelines.”, but an enabled blue “Run pipeline” button, which I clicked
    7. That created [Wayback/Archive.is] a pipeline asking for parameters (that already had correct default values) and revealed a new blue “Run pipeline” button.
    8. Clicked that new “Run pipeline button” which created [Wayback/Archive.is] a job deployed the page.
    9. From the left sidebar, navigated to “Settings”, then “Pages” to get the links to the pages site: http://wier1.gitlab.io/public/web/sites/gitlab.io/wiert.gitlab.io and https://wier1.gitlab.io/public/web/sites/gitlab.io/wiert.
      Bummer: again not the wiert.gitlab.io I hoped for
      The sites do work (see the [Archive.is http version] and [Archive.is https version]). The HTTP does not redirect to the HTTP version, as I did not tick the

      ☐ Force HTTPS (requires valid certificates)

    10. Try A and B were almost identical to wiert.gitlab.io/wiert try A and B, so let’s see if the solution C for that also works for us:
  3. For wiert.gitlab.io, try C (success, steps 1, 3, 4, 7 and 9 were the key ones)
    1. In my user gitlab.com/wiert, created a new GitLab repository
    2. Chose “Create from template”
    3. Chose the template “Pages/Plain HTML”
    4. Named the project “wiert.gitlab.io” (with slug “wiert.gitlab.io“) so it would appear at gitlab.com/wiert/wiert.gitlab.io.
    5. From the left sidebar, navigated to your project’s “CI/CD”, then “Pipelines”
    6. Again there was “There are currently no pipelines.”, but an enabled blue “Run pipeline” button, which I clicked
    7. That created [Wayback/Archive.is] a pipeline asking for parameters (that already had correct default values) and revealed a new blue “Run pipeline” button.
    8. Clicked that new “Run pipeline button” which created [Wayback/Archive.is] a job deployed the page.
    9. From the left sidebar, navigated to “Settings”, then “Pages” to get the links to the pages site: http://wiert.gitlab.io/ and https://wiert.gitlab.io/.
      Success: finally the wiert.gitlab.io I hoped for with working sites (see the [Archive.is http version] and [Archive.is https version]).
    10. Note the HTTP does not redirect to the HTTP version, as I did not tick the

      ☐ Force HTTPS (requires valid certificates)

Steps for gitlabstatus.wiert.me

Having learned from the GitHub githubstatus.wiert.me procedure (where I had to wait a long time for the default *.wiert.me domain mapping timeout and the githubstatus.wiert.me DNS CNAME record to become effective), I started on the DNS CNAME record side which is documented at [Wayback] Custom domains and SSL/TLS certificates: Section 3. Set up DNS records for Pages: For subdomains | GitLab:

Subdomains (subdomain.example.com) require:

  • A DNS CNAME record pointing your subdomain to the Pages server.
  • A DNS TXT record to verify your domain’s ownership.
From DNS Record To
subdomain.example.com CNAME namespace.gitlab.io
_gitlab-pages-verification-code.subdomain.example.com TXT gitlab-pages-verification-code=00112233445566778899aabbccddeeff

Note that, whether it’s a user or a project website, the CNAME should point to your Pages domain (namespace.gitlab.io), without any /project-name.

DNS CNAME record pointing to GitLab.com project

The value for the TXT record is only known after you created the pages project, but the value for the CNAME record is known beforehand:

From DNS Record To
gitlabstatus.wiert.me CNAME namespace.gitlab.io

So let’s see if I can do this in one try, with these steps:

  1. For gitlabstatus.wiert.me, try A (success, steps 1, 3, 4, 7 and 9 were the key ones)
    1. In my DNS settings of the wiert.me domain, created a CNAME record from gitlabstatus.wiert.me to namespace.gitlab.io:

      gitlabstatus.wiert.me CNAME record pointing to namespace.gitlab.io

      gitlabstatus.wiert.me CNAME record pointing to namespace.gitlab.io

    2. Under leaf group gitlab.com/wiert.me/public/web/sites/wiert.me, created a new GitLab repository
    3. Chose “Create from template”
    4. Chose the template “Pages/Plain HTML”
    5. Named the project “gitlabstatus.wiert.me” (with slug “gitlabstatus.wiert.me“) so it would appear at gitlab.com/wiert.me/public/web/sites/wiert.me/gitlabstatus.wiert.me
    6. From the left sidebar, navigated to your project’s “CI/CD”, then “Pipelines”
    7. Again there was “There are currently no pipelines.”, but an enabled blue “Run pipeline” button, which I clicked
    8. That created [Wayback/Archive.is] a pipeline asking for parameters (that already had correct default values) and revealed a new blue “Run pipeline” button.
    9. Clicked that new “Run pipeline button” which created [Wayback/Archive.is] a job deployed the page.
    10. From the left sidebar, navigated to “Settings”, then “Pages” to get the links to the pages site: http://wiert.me.gitlab.io/public/web/sites/wiert.me/gitlabstatus.wiert.me and https://wiert.me.gitlab.io/public/web/sites/wiert.me/gitlabstatus.wiert.me.
      Intermediate success: working sites (see the [Archive.is http version] and [Archive.is https version]).
    11. Now it is time to get the DNS CNAME record from gitlabstatus.wiert.me to namespace.gitlab.io into operation by clicking the “New Domain” button:
      "New Domain" button in the "Pages" settings.

      “New Domain” button in the “Pages” settings.

    12. There I filled in the correct gitlabstatus.wiert.me domain name, then pressed the “Create New Domain” button:

      New domain becomes gitlabstatus.wiert.me

      New domain becomes gitlabstatus.wiert.me

    13. Then a page appeared voiding the DNS CNAME work I already did: the documentation is clearly wrong as these are the two DNS record entries to be made as shown by gitlab.com/wiert.me/public/web/sites/wiert.me/gitlabstatus.wiert.me/pages/domains/gitlabstatus.wiert.me:
      Correct instructions for the DNS records to get gitlabstatus.wiert.me working

      Correct instructions for the DNS records to get gitlabstatus.wiert.me working

      Subdomains (gitlabstatus.wiert.me) require:

      • A DNS CNAME record pointing your subdomain to the Pages server.
      • A DNS TXT record to verify your domain’s ownership.
      From DNS Record To
      gitlabstatus.wiert.me CNAME wiert.me.gitlab.io.
      _gitlab-pages-verification-code.gitlabstatus.wiert.me TXT gitlab-pages-verification-code=c5619988d386b1a36c253ce05db55dbb

      Basically the whole namespace.gitlab.io part of the documentation is a placeholder for the actual namespace that belongs to the leaf group the pages project is in (in my case wiert.me).

      So this is the new DNS entry, for which I had to wait until the DNS TTL to time out and effectuate:
      New DNS gitlabstatus.wiert.me CNAME record pointing to wiert.me.gitlab.io

      New DNS gitlabstatus.wiert.me CNAME record pointing to wiert.me.gitlab.io

      Note that this DNS administrative interface from WordPress.com does omit the final period of the CNAME destination (officially this would be wiert.me.gitlab.io.)

    14. After the CNAME DNS record, I also made the TXT DNS record:
      New DNS TXT record for verification of gitlabstatus.wiert.me

      New DNS TXT record for verification of gitlabstatus.wiert.me

      Then I waited a little for the DNS TXT record to be saved and try the verification of the TXT record.

    15. Even then, verification took some time. I had to click the refresh button a few times before verification succeeded:
      The DNS TXT record for gitlabstatus.wiert.me finally got verified

      The DNS TXT record for gitlabstatus.wiert.me finally got verified

    16. Now I could press blue “Save Changes” button below and waited for the CNAME record DNS TTL to expire so I could check the domain and – hopefully – the TLS certificate to be requested by Let’s Encrypt:
      After the gitlabstatus.wiert DNS TXT record got verified, I could save the domain information

      After the gitlabstatus.wiert DNS TXT record got verified, I could save the domain information

    17. After the old CNAME record DNS TTL expired and the new CNAME record came into effect, the domain became available as http://gitlabstatus.wiert.me/:
      Waiting for gitlabstatus.wiert.me to become active

      Waiting for gitlabstatus.wiert.me to become active

    18. After verification, the “Domains (1)” bit changed from this:
      Domain gitlabstatus.wiert.me information before verification

      Domain gitlabstatus.wiert.me information before verification

      to this:

      Domain gitlabstatus.wiert.me information after verification

      Domain gitlabstatus.wiert.me information after verification

    19. In the mean time, also the TLS certificate got issued by Let’s Encrypt, so the final sites now both worked: http://gitlabstatus.wiert.me/ and https://gitlabstatus.wiert.me/.
    20. Success: finally the gitlabstatus.wiert.me I hoped for with working sites (see the [Archive.is http version] and [Archive.is https version] for the wiert.me domain, and [Archive.is http version] and [Archive.is https version] for the wiert.me domain).
    21. Note the HTTP does not redirect to the HTTP version, as I did not tick the

      ☐ Force HTTPS (requires valid certificates)

In retrospect, this could have been shorter when I had done the DNS part later, which is contrary to how to do this with GitHub.

Conclusion

The conclusion seems this:

Gitlab Page repositories to be published as or under wiert.gitlab.io need to reside directly under user wiert. Having them reside under a different group like wiert or wiert.me won’t work.

Or in more generic terms:

When creating pages as user.gitlab.io you have to put your pages projects directly under your user account gitlab.com/user.

Putting them under groups or leaf groups fails, no matter if the (leaf) group is named user or otherwise.

In addition, you can add custom domains to any Gitlab repository (even one that never stated out as a GitLab Pages repository). It will work as soon as the domain DNS mapping is setup through both a CNAME mapping record and TXT verification record.

The steps for this in your GitLab repository are:

  1. Ensure you have a valid .gitlab-ci.yml file at the root of your repository; I used the [Wayback/Archive.is] one from [Wayback/Archive] GitLab Pages examples / plain-html · GitLab as my site is purely static
  2. Ensure you have a valid index.html file in the public directory of your repository, similar to [Wayback/Archive] GitLab Pages examples / plain-html · GitLab
  3. When both 1. and 2. are committed in your repository at GitLab, then it will automatically be deployed to a docker container on gitlab.io, which allows the outside world to visit your GitHub Pages sie, and the Let’s Encrypt Certificate to be generated (and prevents this error: [Wayback/Archive] GitLab Pages integration with Let’s Encrypt | GitLab: “Something went wrong while obtaining the Let’s Encrypt certificate”).
  4. Under “Settings” -> “Pages”, add a new domain name to the repository: now it automatically becomes a GitLab Pages repository.
  5. When adding the domain, the settings page will show both a DNS CNAME record and DNS TXT record; ensure both are applied on your primary DNS name server and replicated to all authoritative DNS name servers.
  6. Save the new page.
  7. Check if the page is available on the new domain you added.
  8. Optionally under “Settings” -> “Pages” enable the “Force HTTPS (requires valid certificates)” option and save.

TLS information

Note: I saved the TLS information – including certificates here:

More about the Let’s Encrypt certificates at [Wayback] Chain of Trust – Let’s Encrypt:

–jeroen

Read the rest of this entry »

Posted in Cloud, Communications Development, Development, DNS, Encryption, GitLab, Hosting, HTML, HTTPS/TLS security, Infrastructure, Internet, Internet protocol suite, Let's Encrypt (letsencrypt/certbot), Power User, Software Development, Source Code Management, TCP, TLS, Web Development | Leave a Comment »

SwiftOnSecurity on Twitter: “Web developers and CMS managers literally dance on the smoldering wastes of a million Library of Alexandrias yet we permit them to act as if polite company.… “

Posted by jpluimers on 2022/04/19

[Archive.is: SwiftOnSecurity on Twitter: “Web developers and CMS managers literally dance on the smoldering wastes of a million Library of Alexandrias yet we permit them to act as if polite company.… “] quoting

Hyperlinks are a powerful tool for journalists and their readers. Diving deep into the context of an article is just a click away. But hyperlinks are a double-edged sword; for all of the internet’s boundlessness, what’s found on the Web can also be modified, moved, or entirely vanished.  The fragility of the Web poses an […]

 

It’s all about Link_rot, which is the main reason I have been posting [Wayback] (and when these do not archive, [Archive.is]) archival links in my blog posts since about 2015.
Sometimes I find time to add these to older posts as well, but given there are 7000+ blog posts published, I won’t be able to do that for all past blog posts.

—jeroen

Read the rest of this entry »

Posted in Internet, link rot, Power User, WWW - the World Wide Web of information | Leave a Comment »

Prevent link rot before the public condemns you

Posted by jpluimers on 2022/04/05

I’ve written about link rot quite a few times (it even has a category on my blog).

Preventing it is important, as it improves user experience.

For most users this is an unconscious thing when it works and becomes consciously annoying when it fails.

Some user groups are vocal enough to force you to fix link rot after the fact, causing brand reputation damage.

One good example was last year: [Wayback] Users condemn Microsoft for removing KB IDs from some bug documentation | Computerworld.

Read the rest of this entry »

Posted in Bookmarklet, Development, Internet, link rot, Power User, Software Development, Web Browsers, Web Development, Windows, WWW - the World Wide Web of information | Leave a Comment »

Bookmarklet to force WordPress classic-editor

Posted by jpluimers on 2022/03/29

A while ago, WordPress.com heavily started to de-emphasise the Classic Editor in order to boost the Gutenberg editor which is bloaty (in both browser DOM usage (heavily slowing down editing) and content (lots of meta tags that are added to blog source) and is missing essential features (especially nesting of blocks often breaks things).

With 7000+ blog posts in the Classic Editor format (a few in still supported markdown format: that experiment failed horribly!) that still require editing  (especially because of link rot)

So here is the Bookmarklet code to switch back an editing URL that you can use for as long as the Classic Editor is there:

javascript:location.href=document.location.href+'&classic-editor';

Yup, it is that simple: it appends &classic-editor to the URL.

Read the rest of this entry »

Posted in Bookmarklet, Classic editor, Development, Gutenberg editor, Internet, link rot, Power User, Software Development, Web Browsers, Web Development, WordPress, WWW - the World Wide Web of information | Leave a Comment »

Jan-Pieter Cornet on Twitter: “@rckjnsn @KarinSpaink @jpluimers @Jan_WdeVries @JeroenFrijters @xs4all @corbosman Zodra je lijn gemigreerd is naar KPN, werken de xs4allnl DNS entries niet meer. Zie punt I3 op …”

Posted by jpluimers on 2022/03/25

[Wayback/Archive] Jan-Pieter Cornet on Twitter: “@rckjnsn @KarinSpaink @jpluimers @Jan_WdeVries @JeroenFrijters @xs4all @corbosman Zodra je lijn gemigreerd is naar KPN, werken de xs4all.nl DNS entries niet meer. Zie punt I3 op …”

met verwijzing naar [Wayback/Archive] Overzicht – XS4ALL:

Read the rest of this entry »

Posted in Internet, ISP, KPN, Power User, xs4all | Leave a Comment »

Wayback machine and VMware KB links

Posted by jpluimers on 2022/03/22

The VMware KB is notoriously bad into being saved in the WayBack Machine: saved links hardly render at all because of the VMware KB dynamic page loading structure.

But VMware KB articles expire, so a lot of web-pages point to non-existing links and end up through redirections at [Archive.is] https://kb.vmware.com/s/pagenotfound.

Below are a few link forms of the same VMware KB 2011818 article that vanished from the regular web. The first is saved in the WayBack Machine (but does not render), the second is saved and does render after a redirect to a saved third form, the most recent saved fourth form is actually a 404-error redirecting to a prior third form.

  1. https://kb.vmware.com/s/article/2011818
  2. http://kb.vmware.com/kb/2011818
  3. http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2011818
  4. http://kb.vmware.com:80/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2011818

The first link form does archive as a rendered page in Archive.is if is is archived. t wasn’t, so the current archived version points to the “pagenotfound” page mentioned above.

Sometimes you have to dig deeper, as not all rendering archived versions contain actual content.

Here the first one is not even archived, the other ones are, but none of them have actual usable content:

  1. https://kb.vmware.com/s/article/2007922
  2. http://kb.vmware.com/kb/2007922
  3. http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2007922
  4. http://kb.vmware.com:80/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2007922

This means you have to dig further in history:

  1. https://web.archive.org/web/20140123114343/http://kb.vmware.com:80/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2007922 indicates not authorized
  2. https://web.archive.org/web/20130117041323/http://kb.vmware.com:80/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2007922 shows the actual content.

–jeroen

Posted in Internet, InternetArchive, link rot, Power User, WayBack machine, WWW - the World Wide Web of information | Leave a Comment »

Digital accessibility is hard; Wayback archival of: Formulieren – CIZ

Posted by jpluimers on 2022/03/17

I know that digital accessibility does not come for free, but it is mandatory in Europe for at least documents and web-sites provided by government and semi-government as per [Wayback] EN 301 549 – Wikipedia

EN 301 549 is a European standard for digital accessibility. It specifies requirements for information and communications technology to be accessible for people with disabilities.

I bumped into numerous tab-order issues when filling out CIZ forms. This makes it way harder for my, as now I require a mouse despite having RSI symptoms for some 30+ years.

So, for my link archive so I can document that all these forms have severe tab-order issues (some fields are not even accessible by keyboard, are being emptied when you leave the field, or not even accessible by mouse): [Wayback] Formulieren – CIZ

Doet u een aanvraag bij het CIZ? Op deze pagina vindt u een overzicht van onze formulieren, zoals een machtigingsformulier en het Wlz-aanvraagformulier.

Hopefully by now the forms have been fixed.

Via:

Read the rest of this entry »

Posted in About, InternetArchive, LifeHacker, Personal, Power User, WayBack machine | Leave a Comment »

Cryptosense Discovery

Posted by jpluimers on 2022/03/15

This is cool: [Wayback] Cryptosense Discovery:

Free tool that discovers security configuration errors in SSH and TLS servers and explains how to fix them. Supports STARTTLS and can also scan HTTPS, POP3, IMAP and SMTP servers.

It gives you a list of servers a target domain uses (for purposes like web, email, etc) that can have external encryption enabled, then allows you to test these.

The list by default has only servers within that target domain enabled, but you can optionally include other servers (for instance if a domain uses a third party for their SMTP handling).

Basically it is the web-counterpart of a tool like testssl.sh (which I have written about before).

Found while checking out how to test the MX security of a domain using [Wayback] testssl.sh as I forgot the syntax, which in retrospect is dead easy as per [Wayback] tls – How to use testssl.sh on an SMTP server? – Information Security Stack Exchange (thanks [Wayback] Z.T.!):

…

testssl.sh --mx <domain name>

works fine.

testssl.sh -t smtp <ip>:25

and

testssl.sh -t smtp <ip>:587

also work fine.

Note that not specifying the port assumes port 443, despite specifying protocol smtp. That doesn’t work.

…

Also, you might try discovery.cryptosense.com which does the same thing only better

That website is made by the cool people at [Wayback] Cryptosense.

Both are a lot easier than the alternatives described in [Wayback] Blog · How to test SMTP servers using the command-line · Halon MTA: using nslookup and dig for determining the affected hosts, using nc or telnet for testing basic connectivity, using [Wayback/Archive.is] openssl s_client to test TLS, and [Wayback/Archive.is] smtpping for measuring throughput.

In addition to the above tools mentioned in the blog, I’ve also used sendEmail (note case sensitivity), ehlo-size, and swaks.

This is what I tested:

–jeroen

Posted in *nix, *nix-tools, Awk, bash, bash, Communications Development, Development, DNS, Encryption, grep, HTTPS/TLS security, Internet, Internet protocol suite, Power User, Scripting, Security, SMTP, Software Development, SSH, ssh/sshd, TCP, testssl.sh, TLS | Leave a Comment »

Download pfSense Community Edition: pfSense-CE-2.5.1-RELEASE-amd64.iso.gz

Posted by jpluimers on 2022/03/08

Since this is what I use to VPN home:

pfSense is a free and open source firewall and router that also features unified threat management, load balancing, multi WAN, and more

[Wayback] Download pfSense Community Edition: [Wayback] pfSense-CE-2.5.1-RELEASE-amd64.iso.gz

–jeren

Posted in Internet, pfSense, Power User, routers | Leave a Comment »

Archive.is blog: Twitter archival is slow, so limit the number of tweets you save in it

Posted by jpluimers on 2022/03/04

[Wayback] Archive.is blog — The website has been slow for some time when…

The website has been slow for some time when archiving Twitter pages, but works fine with other websites. Is there a reason for that? Thx!

Anonymous

1. There are too many pages from Twitter in the queue, which reduces their priority (if it wasn’t for this condition, it would slow everything down)

2. Twitter API sometimes responds with “429 Too Many Requests” or other error, so it usually takes more than 1 attempt to capture the page.

I would suggest refraining from saving pages from Twitter for now, especially those people trying to save dozens or hundreds of tweets

–jeroen

Posted in archive.is / archive.today, Internet, Power User, SocialMedia, Twitter | Leave a Comment »

« Previous Entries
Next Entries »