We’ve done some final touches on the project, and it’s finally coming together pretty nicely. While it’s in a finalized used state, there are tons of more features to add in the future.
Log in to leave a comment
We’ve done some final touches on the project, and it’s finally coming together pretty nicely. While it’s in a finalized used state, there are tons of more features to add in the future.
Log in to leave a comment
Publish Site v2: Improved stability since last release. Previously it was too unstable and too much dynamic configuration to manage so that it was unreliable. But right now it’s almost as simple as GitHub Actions! Start a docker container, run a script, open a port and BAM! Supercharge your workflows with this.
I had a hard time figuring out the proper solutions to my problems, but I did!
Transitioning from version one to two, I’ve made major changes regarding security (confidentiality, integrity), availability, usability (ease of setup), stability and features.
I’ve added another docker image dedicated to “php”, that adds PHP support seamlessly integrated into the container. It is very much optimized as usual
Instead of using the previous HTTP backend I’ve switched to SSH to improve stability, security and ease of use. SSH only requires one config point for the backend and the client (GitHub Actions), a public key and a private key, generated seamlessly by my PKI script. The project is now as stable as it gets and really easy to configure! Time for you to publish a web application!
The old rust backend will be in a legacy unstable state, do not use it!
Log in to leave a comment
One thing I’ve always wanted in the tools is a image converter, like PNG to AVIF, JPEG to webp etc.
Now, it’s finally done, and in a fairly simple and lightweight solution! I wrote it in rust, in a separate WebAssembly file to not slow down the other hash digest users. It’s about 1.3MB, which is a good size of package.
Most online converters use a backend that transcodes your files, however that’s bad for your privacy, and requires processing from the backend.
The few local online converters usually use imagemagick-wasm, however the binary size of that is about 14 MB, about 10x bigger than my binary.
I also wrote a DNS Lookup utility using Quad9 DoH!
We are still working on styling.
Log in to leave a comment
Phew, we have continued on styling the website.
Previously hashing didn’t work for data in a specific size, however to increase hashing times and fix this issue I’ve rewritten it in Rust/WASM. This is working flawlessly, however I removed RIPEMD, SHA-224, SHA-384 as I deemed them unneccessary.
Log in to leave a comment
I’ve worked with these features today:
Log in to leave a comment
We have come further with our project. At the moment we have these tools:
Log in to leave a comment
Me and my coprogrammer started working on the project. I implemented a local archive converter that at the moment supports
Log in to leave a comment
I built a stable deployment plugin/action to GitHub actions.
The backend is written in rust, and has 2 Docker images, Alpine and Debian, for both x86_64 and ARM! I use mTLS for authentication, and I proxy the backend through NGINX for security.
The most difficult part for me was the NGINX/docker configuration.
If you still don’t understand what my project does, you can look at the graph above, or my demo, or heck, even the code! Thanks to my seamless docker image and PKI script anyone should be able to deploy it.
To all data nerds out there, the Docker image is only 13.3 MB! Wow.
I’m proud I barely used any AI in this project. Have fun!
debian tag.
Log in to leave a comment
During this period of time, I’ve accomplished this:
Writing documentation is boring, but it has to be done. You can find it at https://publish-site.rvid.eu/
Log in to leave a comment
We are almost done, and I’ve came far enough to confidently make a demo, with the API being on here.
I deployed this on my local server with docker compose:
services:
deploy-server:
environment:
API_URL: api.publish-site.rvid.eu
CLIENT_CA: >-
[REDACTED]
image: ghcr.io/publish-site/backend:latest
ports:
- '443:443'
volumes:
- /etc/certificates/pub.crt:/etc/nginx/ssl/fullchain.pem:ro
- /etc/certificates/pub.key:/etc/nginx/ssl/privkey.pem:ro
- /mnt/SSD/publish-site:/var/www/html # Persistence
Log in to leave a comment
Phew… I’ve finally completed the difficult (but fun) part of the backend… Now, I mostly have docker/nginx configuration up ahead, and of course the actual workflow. I’ve successfully converted to Hyper and I use the Base64 crate, instead of the hacky and unreliable previous solution.
Instead of this:
The API is in a working state, but at the moment insecure. I call the version: PRE-01-INSECURE
You feel so good when you’ve accomplished something on your own (:
Simple and seamless.
Log in to leave a comment
Cool! I’ve started rewriting the backend codebase to use the HTTP Library hyper! This will eventually make the application more stable and secure, and it will probably be able to handle larger and more requests. I also modified the docker building workflow, so now we have a docker container for all fellow ARM/Raspberry Pi lovers! 
Log in to leave a comment
Ugh… Sometimes you just have bad luck when programming… I’ve been trying to fix this one single line, commit 34f7b4d832db0df3e47796c5543adbf6df62725c line 73 (https://github.com/publish-site/backend/blob/34f7b4d832db0df3e47796c5543adbf6df62725c/src/main.rs#L73) for an hour now. At this point, I plan on moving my backend to a lightweight web framework called hyper. I planned on using as few dependencies and crates as possible, however using the hyper web framework will likely make my program less susceptible to risks such as denial of service and RCE. I’d just need to rewrite the majority of the backend API, but it’ll be simpler.
Either way, I’ve still done some progress! I changed some entries in the docker container and made the example site contain links to relevant documentation.
Log in to leave a comment
YAHOO! I’ve finally completed the write part of the program, where it takes the site.tar.gz and decompresses the archive into a target directory! This means that the project can technically be used at this point of time, however with no security/confidentiality at all. I also used the base64 command from GNU Coreutils which should be temporary… I tried using the base64 crate but it was difficult. I also need to implement automatic removal of the files, but that’s pretty simple.
Log in to leave a comment
Woo! The docker container is finally published! I’ve created a workflow that builds and publishes to https://github.com/publish-site/backend/pkgs/container/backend.
Log in to leave a comment
Hello! For the last few hours I’ve worked on getting colors into my program, YAY! Of course it checks if it is interactive, so the potential docker logs doesn’t risk getting cluttered with ANSI. I also removed some annoying debugging stuff, so that’s good to have out of the way. I made the program print the user agent for logging purposes, I may include more stuff like content length and such. I also started creating a wiki for both the backend and action! This will make it easier for the user to spin up their server and workflow.
NOTE: I don’t know why, but no time got logged with my neovim. Switching to Code OSS temporarily (?)
Log in to leave a comment
Phew! This was a long one. I finally implemented the upload logic for the backend server, meaning that I can finally upload the actual files! There is a few rough edges on the actions workflow, and I still have a bunch of debugging lines on the backend, and it’s still not writing anything. Either way I’m getting closer to done. I’m gonna focus on the completion, so first the upload part, then the authentication part. Finally after that I’ll clean up. Wish me luck!
Log in to leave a comment
Also, the server never actually completes the request yet (:
I continued working on the backend side of this project, and made a docker image server to be deployed on the server. I implemented HTTPS by reverse-proxying through NGINX. The certs in the docker-compose file are intentionally left in the commit so you guys can check it out easier. Next steps are to create the actual frontend to be published to, and to initiate mTLS through nginx. Should be easy enough.
Log in to leave a comment
I worked on the server-side part and has come up with a multithreaded HTTP server written in rust, see https://github.com/publish-site/backend. The next step is to implement HTTPS. I’m not sure if I wanna use this implementation due to potential security issues by user error (?) but I’ll try.
Log in to leave a comment
Today I worked on the base actions workflow. The workflow is executing a script so far. Haven’t worked any on the “backend”. I also created a example workflow implementation.
Log in to leave a comment