Point CNAME for www.gnustep.org to GitHub pages

[ivucica]

Proposed tasks:

0. rework anything in the current repo (gnustep.github.io repo) that uses PHP to stop doing so

   • this includes downloads and RSS feeds
   • for RSS, we should explore the jekyll-feed plugin (https://dev.to/dzhavat/adding-an-rss-feed-to-github-pages-2col)

1. create file CNAME in gnustep.github.io with contents www.gnustep.org

2. in hosting control panel, change www.gnustep.org to be old.gnustep.org (to signal that this is a site that is not -- or is rarely -- updated)

   • for example, if there's a record www, change it to old
   • this may require teaching the web server to handle the new hostname ("if you see old.gnustep.org in the Host: header, treat it as if it said www by sending it to the same PHP plugin/PHP fastcgi daemon/PHP cgi daemon")

3. in hosting panel, create new CNAME record www

   • have it point to gnustep.github.io. (including trailing dot)

4. note that wiki has a CNAME to wwwmain already

   • wwwmain, just like www, is an A record pointing at 81.201.190.216
   • wiki is a mediawiki site, so it likely requires PHP
   • proposed: change wiki from CNAME to an A record pointing at 81.201.190.216 to allow for future deprecation of wwwmain

5. handle wwwmain

   • proposed: leave wwwmain as is for now, and track fixing it in another bug
     • we need to update gnustep.github.io not to use PHP URLs from www or wwwmain anyway
     • once that's done, wwwmain should be replaced with 301/302 redirects to www
     • ideally 301/302 redirects can be done by the web server (presumably exposed by the hosting provider, as the bare domain gnustep.org already redirects to www.gnustep.org automatically)
   • fixing this should not be postponed too long, as it will -- like old -- drift away from gnustep.github.io without active maintenance

6. update reverse lookup for 81.201.190.216 to old.gnustep.org. or to wwwmain.gnustep.org.

[gcasa]

I need to make this happen without disturbing the FTP site.

[ivucica]

Is ftp.gnustep.org also a CNAME?

[gcasa]

I am not sure. Perhaps at some point we can share a screen and update it together. I tried it once before. The website was fine, but the FTP site became inaccessible.

On Mon, Apr 27, 2020 at 1:50 PM Ivan Vučica notifications@github.com wrote:

Is ftp.gnustep.org also a CNAME?

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/gnustep/gnustep.github.io/issues/6#issuecomment-620136291, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAG2J5AXVKL4K7O2NWS3DTROXAWZANCNFSM4MIUMQ3A .

-- Gregory Casamento GNUstep Lead Developer / OLC, Principal Consultant http://www.gnustep.org - http://heronsperch.blogspot.com https://www.patreon.com/bePatron?u=352392 - Become a Patron

[ivucica]

Ok, we'll sync about taking some time to reorg that for minimum impact.

[gcasa]

Ok, just let me know.

On Mon, Apr 27, 2020 at 3:03 PM Ivan Vučica notifications@github.com wrote:

Ok, we'll sync about taking some time to reorg that for minimum impact.

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/gnustep/gnustep.github.io/issues/6#issuecomment-620173753, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAG2J33X6SVYP32AN4K4LTROXJJ3ANCNFSM4MIUMQ3A .

-- Gregory Casamento GNUstep Lead Developer / OLC, Principal Consultant http://www.gnustep.org - http://heronsperch.blogspot.com https://www.patreon.com/bePatron?u=352392 - Become a Patron

[alexmyczko]

livecd.gnustep.org got lost as well

[ivucica]

First, note that this issue #6 does not track the actually executed work. I intend to complete the migration on our own machine, then optionally continue move to gh pages. Use of the static site is temporary.

Second, I can only work with what I have from backups. If there’s a DNS entry that needs to be created, that’s easy. I would need to check if the data I received incudes livecd.gnustep.org http://livecd.gnustep.org/. If you have the data or the host to point A/AAAA/CNAME to, happy to do that. But again, that migration work is separate from what was intended in this issue #6.

On 19 Oct 2022, at 15:02, Alex Myczko @.***> wrote:

livecd.gnustep.org got lost as well

— Reply to this email directly, view it on GitHub https://github.com/gnustep/gnustep.github.io/issues/6#issuecomment-1284069567, or unsubscribe https://github.com/notifications/unsubscribe-auth/AADUTHCSDPAVDIQ4HQC5UYDWD75OVANCNFSM4MIUMQ3A. You are receiving this because you authored the thread.

[ivucica]

To add: Please bring any information you have about livecd.github.com http://livecd.github.com/ on the usual mailing lists. There’s at least one thread open there. I’ll review them when I’m continuing migration work.

On 19 Oct 2022, at 15:02, Alex Myczko @.***> wrote:

livecd.gnustep.org got lost as well

— Reply to this email directly, view it on GitHub https://github.com/gnustep/gnustep.github.io/issues/6#issuecomment-1284069567, or unsubscribe https://github.com/notifications/unsubscribe-auth/AADUTHCSDPAVDIQ4HQC5UYDWD75OVANCNFSM4MIUMQ3A. You are receiving this because you authored the thread.

[ivucica]

@dszidi Why did this get closed without discussion?

[gcasa]

This issue should be moved to https://github.com/gnustep/gnustep-www.

[ivucica]

Actually, since I won't address this further and won't work on any migration of the existing website to GH pages, it can be closed. Apologies.

[ivucica]

For future reference, re @gcasa 's comment at https://github.com/gnustep/gnustep.github.io/issues/6#issuecomment-2248508347 :

There's also https://github.com/gnustep/online-service-ops -- which, similar to setup of the gnustep-www repo, is also private.

---

And also for future reference:

Unlike gnustep-www, we should not consider opening up that one, since it mostly contains hosting infra configuration; there isn't any interesting free software code inside, and contents of commits can be sensitive enough that I would not open it beyond the most core of the core team.

For gnustep-www, we certainly should consider opening visibility of the repo -- but after reviewing that there's no leakage of sensitive hosting configuration data.