Ongoing Investigations

Tag: reclaim cloud

  • Running Ghost on Reclaim Cloud

    So in my last post, I mentioned offhand towards the end that I was experimenting with running Ghost on Reclaim Cloud, and while it was working all right, I was running into this error when I tried to update to the latest version:

    A circular and frustrating error.

    Essentially, I started with the default one-click installer of Ghost, which is set up originally by Jelastic. Ghost has some documentation for installing/updating Ghost-CLI, which is a tool for installing or updating Ghost in turn. So, naturally, I installed Ghost-CLI with the hope of being able to update Ghost from 4.5.0 (what comes out of the box with the one-click installer) to 4.32.0 (the most recent version, released on GitHub five days ago).

    It did not work.

    From the error above, you can see that Ghost-CLI is up and running, and that everything I need for Ghost is present in the directory. But when I try to update, it says that I can’t, because Ghost-CLI commands don’t work on git clones, zip downloads, or versions of Ghost earlier than 1.0.0. Then it suggests I try ‘grunt update’.

    (When I tried ‘grunt update’, I got an error saying that Grunt didn’t exist in this directory. I installed Grunt using the steps in their Getting Started doc, got an error saying that Grunt couldn’t be properly installed because Grunt files already existed in this directory, reran the command, and got told Grunt didn’t exist in this directory.)

    Jim Groom and I got together on a Slack huddle to try and troubleshoot this, but ended up not having any luck — we went back and forth in this lemniscate loop of “Update Ghost! No, update Grunt! No, that’s working! No it’s not!”. Finally we had to stop at a question we weren’t really sure how to answer: is the one-click installer using a Git clone? If it is, how would we get in to update it?

    That’s not something we can really see under the hood, because it’s part of the setup process. Instead Jim, thinking outside the box, said, “What about Docker?”

    I’ve posted a little bit about Docker before, in the context of a tutorial that I was working through alongside some other people at Reclaim (that post series is currently on hold, To Be Returned To), but what’s relevant here is that Docker lets you set up containers for various apps, including ones from the Docker Hub, where people can share their work with the world. Including, for example, Ghost.

    Setting Up Ghost through Docker through Reclaim Cloud

    We actually have some documentation on setting up a Docker Engine environment written by Jim and available here, as part of an article on setting up Peertube. The concept’s pretty much the same, so I won’t reproduce it here, but once you’ve hit the big green Install button, here’s where the work diverges.

    Setting Up Ghost on Docker

    First, get into your web SSH tool. Here’s a quick look at what that looks like on my setup using the environment ghosttest2, showing both the button you want and the command line it’ll pull up.

    A Docker Engine node with the web SSH button highlighted in red.

    From here, the Ghost image on Docker Hub includes instructions for how to set up the image from the command line. Run one of these two commands, depending on what you want; we used the second one.

    Commands for setting up a Ghost container through Docker using the command line.

    Which yields, for my ghosttest2 environment, this:

    A default Ghost site, installed on http://ghosttest2.us.reclaim.cloud:3001/

    And there you go! This currently extremely basic site is going to be my testing grounds for experiments with Ghost as a platform. You can check in if you want, but be warned, it’s probably going to be pinging back and forth, up and down, as I turn the Reclaim Cloud environment off and on.

    For the Future

    • making sure the site is secure in browser
    • figuring out how to not have the port in the URL/general URL cleanup
    • making posts and visual customization (Ghost also recently put up new features in celebration of Cardmas, and there’s an article on planning a newsletter I’m hoping to read soon…)
    • Revisit the question: how does the one-click installer set up Ghost, and how can I push it to the newest version? Can I update using Git in the command line?

    All this and more, in FUTURE INVESTIGATIONS! (maybe)

  • Reclaim Cloud & Troubleshooting Dates

    I actually did this work on Friday, but I didn’t have the opportunity to write it up – just took a couple of notes so I could put this out today.

    As of Friday, I’ve figured out, at least for now, how I want to store and retrieve dates. When I retrieve dates, I want them to be reverse chronological, so the most recent date can be accessed easily. For now, that means that my retrieval function reads the CSV where the dates are stored into a list, then reverses the list & returns it. Whatever asked for the dates to be retrieved receives a list in reverse chronological order. (My write function appends the date to the CSV, simple enough.)

    During the initial working-out-the-kinks phase, the retrieval function actually iterated over the reversed list, printing off the dates rather than returning them. But after that caused some issues with redundancy, that got revised to returning a list.

    I also ended up setting up a helper function for the printing which essentially iterates over the list, appends each item to a string with a new line at the end (so, 2022-12-17 \n), and returns that very long string (which gets longer with every update), which can then be printed by whatever requested the dates. This is super inelegant, obviously, so a priority is going to be to figure out a nicer way of handling this.

    Another priority is going to be just… figuring out how to denote updates that happen on the same date. Every time I run the program to test it, it’s counted as a separate update and logged to the CSV. This is good! This is what I want! But I ran this program twenty-three times on Friday, so now the datelog reads (reverse chronologically):

    2022-12-17
2022-12-17
2022-12-17
2022-12-17
2022-12-17
...

    … and so on. You see the issue.

    I put together some questions to ask myself about how to solve this. Still haven’t answered them yet, but essentially they consist of: how do I denote the number of updates on a particular day? How do I store that information as separate from the date, and access it easily to update it?

    One way, which sounds very clunky to me, would be to store the date alongside a number of updates (so, 2022-12-17 for the first update, and then edit that to 2022-12-17 (2) for the second update, and so on. The formatting is still under consideration). The second way, which is even worse, is to store the information as above (every date listed neatly for every time updated, which will get super long very fast), and then every time I would need to return or display a list of previous dates, iterate over the information so that I can return it in a nicer format. No, thank you.

    I think the next step might be MySQL, which means that I’ll have to (re-learn) SQL and how to use it in Python. I’ll also have to pick a database, which will probably be MariaDB, mostly because I picked it randomly from the available MySQL databases when I was setting up the Reclaim Cloud environment which I’m hoping to test this on.

    Oh, right, I have some Reclaim Cloud environments now. The environment for this project isn’t currently online and won’t be for the foreseeable future, unless it turns out I absolutely require the MariaDB from Reclaim Cloud to store the information. Which I probably will.

    For the other environment, I’ve also been poking around a little bit with Ghost — not much yet, as I’m still working on getting it updated to the newest edition from 4.5.0, which is what I’m currently on. Once I do, I’ll be experimenting with the blogging features, as Reclaim is considering using it for our newsletter, which start being released at the end of January 2022. That environment is also offline for now until I figure out what I’m missing trying to update from the command line. Currently I’m dealing with this error:

    A very frustrating error.

    What that sums up to is mostly “You need to update using Ghost-CLI, but you can’t, because you didn’t install this using Ghost-CLI” (I used a one-click installer). Once I get the answer I’ll be able to write this up better, maybe as an article for our support docs, but in the meantime: still working on it.

css.php