Added first Hilde devlog
continuous-integration/drone the build was successful
Details
continuous-integration/drone the build was successful
Details
parent
d0bdef2dc8
commit
de921c898c
|
@ -46,6 +46,8 @@ params:
|
|||
showTags: true
|
||||
|
||||
custom:
|
||||
- title: "Devlogs"
|
||||
url: "/devlogs"
|
||||
- title: "Projects"
|
||||
url: "https://git.roosens.me/Chewing_Bever"
|
||||
- title: "Source"
|
||||
|
|
|
@ -0,0 +1,4 @@
|
|||
This category contains devlogs for my various projects:
|
||||
|
||||
* [Hilde](hilde): an implementation of a Debian repository using Rust & the
|
||||
Rocket API framework.
|
|
@ -0,0 +1,2 @@
|
|||
Hilde is a "smart" implementation of a Debian repository that aims to be more
|
||||
than just a file server.
|
|
@ -0,0 +1,90 @@
|
|||
---
|
||||
title: "Hilde - The Idea"
|
||||
date: "2021-06-26"
|
||||
tags: [ 'rust', 'api', 'linux' ]
|
||||
---
|
||||
|
||||
Welcome to the first devlog about Hilde, my latest passion project. This post
|
||||
will be diving into what exactly Hilde is, and what I currently have planned
|
||||
for the project.
|
||||
|
||||
## The idea
|
||||
|
||||
My idea behind Hilde is to create a smarter & more modern version of a Debian
|
||||
repository. Currently, a repository simply consists of a file server (e.g.
|
||||
Apache for the official repositories) that serves a strict directory structure.
|
||||
Lots of the files & data stored in this system could however be perfectly
|
||||
stored inside a database. Therefore, I'd like to take a different approach.
|
||||
Instead of just using a file server, my plan is to "mimic" the official
|
||||
structure of the file server, while serving as much content as possible from a
|
||||
database. Control file data, file hashes, indexes, and many other types of
|
||||
metadata could just be indexed and returned when requested.
|
||||
|
||||
I initially thought of this while brainstorming about which distro I should
|
||||
switch to. I've been running Arch on my laptops for about a year now, but I've
|
||||
come to distrust it (partially because I don't use it safely enough probably).
|
||||
As I'm a CS student, I require a stable computer that I can rely on when
|
||||
needed. Therefore, I'd like to switch to Debian. I would however like to keep
|
||||
the luxury of the AUR or something similar, so my idea was to host my own Hilde
|
||||
server that could serve this purpose.
|
||||
|
||||
## Roadmap
|
||||
|
||||
I have a broad idea of which features I would like to add to Hilde (if
|
||||
possible):
|
||||
|
||||
### Mimic a Debian repository
|
||||
|
||||
The first part is pretty self-explanatory. Before I can do anything else, I
|
||||
need to make sure the idea is possible, so I'll have to make a proof of concept
|
||||
that works. My end goal is to have Hilde be the most compliant server possible,
|
||||
by which I mean that it supports every feature that a Debian repository could
|
||||
support. This includes:
|
||||
|
||||
* Arbitrarily nested dists & components
|
||||
* Support for multiple architectures
|
||||
* Support for `by-hash` directories
|
||||
* ...
|
||||
|
||||
A full description of the Debian repository format can be found
|
||||
[here](https://wiki.debian.org/DebianRepository/Format). Not all features are
|
||||
required for the initial release, but eventually I would like to comply with
|
||||
the entire document. The initial release will also contain a folder scanner, so
|
||||
that existing packages can be added on startup.
|
||||
|
||||
### Allowing for package uploads
|
||||
|
||||
The second part of my "AUR" idea requires me to be able to add new packages to
|
||||
the server (e.g. from a CI pipeline). Therefore, I want to be able to send HTTP
|
||||
requests to the server to upload new binary or source packages. I don't have a
|
||||
full grasp yet on how I plan to achieve this (e.g. what endpoints etc.) but the
|
||||
basic idea is to be able to upload deb files to the server and it automatically
|
||||
parsing them.
|
||||
|
||||
### Authentification
|
||||
|
||||
We can't just open up a server that allows uploads to the public, so I'll have
|
||||
to add a form of authentification. I'm still debating on exactly how I plan on
|
||||
doing this, but the basic idea is to use JWT tokens & a login endpoint that can
|
||||
generate said tokens. Initially, I'll probably just use a single admin account,
|
||||
but I have ideas for adding a user system that can generate tokens for specific
|
||||
actions on specific packages (e.g. a token that allows for writing to a
|
||||
particular package).
|
||||
|
||||
### Federation
|
||||
|
||||
This one is one of my more ambitious ideas, but it sounds really interesting to
|
||||
work on. I have this idea of a network of Hilde servers communicating with each
|
||||
other about which packages they have. When a user then requests a certain
|
||||
package, the server can forward the package from another server.
|
||||
|
||||
I know this idea might be quite impossible for me, and it's still far down the
|
||||
road, but it just sounded way too cool to not include it in this introduction
|
||||
devlog.
|
||||
|
||||
## Conclusion
|
||||
|
||||
In my eyes, Hilde looks like a very interesting & fun project to work on, and I
|
||||
hope to be posting a lot more of these devlogs as development progresses!
|
||||
Speaking of development, the Git repo can be found
|
||||
[here](https://git.roosens.me/Chewing_Bever/hilde). See you next time!
|
Reference in New Issue