Hello fellow Soylentils, I could use some of your insights and suggestions.
I am looking for a lean, mean, and safe open source solution that implements a small blog where I can rant and rave to my heart's delight to my two followers.
To set the scene, I am not looking for something big and/or unwieldy, which basically rules out the major platforms like Drupal, Joomla and Wordpress. The software is going to be self hosted on my existing web server, which already runs Linux with Apache2, MySQL, PHP, Perl, and PostgreSQL (LAMPPP?) on a Debian platform.
I would like the following features:
[Ed. addition follows.]
I am not familiar with the minimum resource requirements for running SoylentNews, but if it would not reasonably fit on a single RPi, maybe adding one or two more would suffice?
What suggestions do YOU have for our fellow Soylentil?
(Score: 2) by c0lo on Monday July 29 2019, @02:09PM (8 children)
The "user comments" section will require some workflow contortions to adjust to static HTML pages approach.
https://www.youtube.com/watch?v=aoFiw2jMy-0 https://soylentnews.org/~MichaelDavidCrawford
(Score: 2) by meustrus on Monday July 29 2019, @05:53PM (7 children)
Not really. Assuming your "static" html uses some kind of templating (and it will unless you like copy-pasting your header in every file), just set up a script to regenerate the HTML any time a comment gets posted. Store the comments in a db like a sane person, of course, and put a timestamp on it and the generated HTML so that if things get out of sync, you can tell what happened.
The main problem is security. You will need to make sure that the final HTML can be overwritten by your script, but the input HTML and your script can't.
If there isn't at least one reference or primary source, it's not +1 Informative. Maybe the underused +1 Interesting?
(Score: 0) by Anonymous Coward on Monday July 29 2019, @08:05PM (5 children)
You just described a dynamic site + static cache.
(Score: 2) by meustrus on Monday July 29 2019, @08:56PM (4 children)
Sort of. Dynamic site + static cache implies that there is no signaling to the cache when it should be regenerated, it just knows somehow. Systems like that will drive you mad. Don't think of it as a cache. Think of it as a view that needs updating when the underlying data changes, and you won't have as many problems with stale caches.
If there isn't at least one reference or primary source, it's not +1 Informative. Maybe the underused +1 Interesting?
(Score: 0) by Anonymous Coward on Tuesday July 30 2019, @03:57PM (3 children)
I run several sites like this based on code I wrote many years ago. It's a similar idea to using a caching reverse proxy like varnish - check for cached data above web root and potentially send that before initiating a db connection. These are still dynamic sites. I don't see how you can have a static site as you suggest without signaling from the web process and giving a web process write access to your web root?
(Score: 2) by meustrus on Tuesday July 30 2019, @04:50PM (2 children)
Here's a dumb solution:
1. Serve main page from /static
2. Point forms to scripts in /cgi
3. Scripts in /cgi rewrite pages in /static, but can't rewrite themselves
- Or if you can install your own daemons, write update requests to a queue and have a daemon reading from the queue to rewrite pages
If you don't like the site being in /static, figure out another way (subdomain, etc). But the scripts do not need access to overwrite themselves or anything else that is executed dynamically in order to make this work.
You could implement it in AWS by serving static content from S3+CloudFront and pointing forms to write to DynamoDB via API Gateway, then have Dynamo write updates to a Kinesis stream that is consumed by a Lambda that rewrites your static content based on the latest data in Dynamo. I don't believe there are any fundamental security flaws in this design. But I would only recommend it if it doesn't mean learning those 6 AWS technologies. In any case, it won't run on a Pi.
If there isn't at least one reference or primary source, it's not +1 Informative. Maybe the underused +1 Interesting?
(Score: 0) by Anonymous Coward on Tuesday July 30 2019, @05:16PM (1 child)
The point being that what we're describing is dynamic generation + static caching and not really a static site.
Also, despite 23 years experience, I have no idea what you're talking about with AWS. When you say "consumed by a lambda", are you talking about the lambda function I know or is this another sick perversion where concept is promoted to product name by wretched, overpaid marketing genii?
(Score: 3, Informative) by meustrus on Wednesday July 31 2019, @12:21AM
If you just wanted a static site, you would skip the last half and just have HTML files in S3 served through CloudFront. But the OP wants comments, which is decidedly dynamic. Well, unless you implemented the comment section as an empty div that gets filled in by JavaScript. But I will not help you build a JavaScript-only web site.
S3 = File storage
CloudFront = distributed CDN, can act as an HTTP server for files in S3
DynamoDB = NoSQL database, glorified key-value store
API Gateway = HTTP REST proxy for specific actions in AWS
Kinesis = distributed sharded stream, glorified distributed ring buffer
Lambda = execution of terminating programs based on triggers from other AWS services
The point of all this is to avoid running any daemons yourself by having them all execute in a massive distributed cluster. They call it "serverless", which makes about as much sense as co-opting "lambda" as they have done.
There are similar concepts in Azure, Google Cloud Platform, and OpenStack.
If there isn't at least one reference or primary source, it's not +1 Informative. Maybe the underused +1 Interesting?
(Score: 2) by c0lo on Tuesday July 30 2019, @02:41AM
You say "script to regenerate" I say "workflow contortions"... potato/patayto
https://www.youtube.com/watch?v=aoFiw2jMy-0 https://soylentnews.org/~MichaelDavidCrawford