Philippe PITTOLI
3 years ago
parent
74fa9420a6
commit
c5f22f48b9
@ -1,23 +1,309 @@ |
||||
+++ |
||||
title = "dnsmanager - free your zones" |
||||
title = "Baguette - OS, tools and stuff" |
||||
+++ |
||||
|
||||
dnsmanager is a web interface to enable users to register DNS names and manage their zone. It is the software powering [netlib.re](https://netlib.re), a service to provide names for everyone on the Internet. |
||||
# Baguette OS - concise overview |
||||
|
||||
[netlib.re](https://netlib.re) is kindly operated by [Alsace Réseau Neutre](https://arn-fai.net), a neutral and non-profit Internet Service Provider based in Alsace, France. Don't be shy, come and ask questions! |
||||
Baguette OS status: Work In Progress. |
||||
A beta will be available circa mid-2020. |
||||
|
||||
# Features |
||||
## Objectives, for simple users |
||||
|
||||
- [x] User accounts |
||||
- [x] Simple and expert modes for zone edition |
||||
- [x] DynDNS-like automatic IP updates |
||||
- [x] Multiple client and parent zones |
||||
- [ ] DNS delegation |
||||
- [ ] 3rd party authentication (LDAP, OpenID Connect) |
||||
- [ ] Documented client-side API |
||||
- [ ] CAPTCHA? |
||||
BaguetteOS aims at provide a simple unix-like system, with an **unified web interface**. |
||||
|
||||
# Setup |
||||
**No command-line required for simple users.** *let users be just users*<br /> |
||||
Simplicity should not only comes from an interface, but be inherent to the whole system. |
||||
If the OS is simple, there is no need to hack it. |
||||
|
||||
Please refer to the [project's repository](https://github.com/KaneRoot/dnsmanager) for setup instructions. |
||||
**Unified interface is better than features.**<br /> |
||||
We will provide the basic features then build up. |
||||
We do not want a patchwork of very different software, each of them having their own particularities. |
||||
|
||||
**Online services.** *day-to-day use*<br /> |
||||
The web interface should cover online services, providing an unified experience for main usages: mails, calendar, instant messaging, personal website, file sharing, etc. |
||||
|
||||
**One-click management.** *service installs, updates, etc.*<br /> |
||||
The web interface should handle basic system and network configurations, such as adding users, dhcp, DNS, backups, etc. |
||||
|
||||
**Well-known, reliable software.**<br /> |
||||
BaguetteOS relies on robust and independant software. |
||||
At no point the user should be forced to reinstall, a borked configuration has to be easily fixed. |
||||
|
||||
**Hardware support.** *new or old, fast or slow, it doesn't matter*<br /> |
||||
We provide support for RPi and other small cards: if our kernel runs on it, it has to work. |
||||
Minimal hardware requirement should be around 100 MB RAM, 50 MB disk. |
||||
|
||||
**Documentation.** *simple, reliable, useful, all-in-one-place*<br /> |
||||
Similar to the OpenBSD FAQ: updated, complete, concise and well-written. |
||||
|
||||
## Objectives, for advanced users and contributors |
||||
|
||||
**A knowable OS.** *simplicity at (almost) all cost*<br /> |
||||
Any interested user should be able understand the role of every part of the base system: no compromise. |
||||
This means having a very small and consistent set of tools, easy to learn, easy to remember. |
||||
|
||||
**Basic system and network management.** *with the simpliest tools ever*<br /> |
||||
We provide a web interface that should handle basic system and network configurations, such as adding users, firewall management, dhcp, DNS, backups, etc. |
||||
CLI tools are available to manage your services, they are design to be simple, consistent and reliable. |
||||
|
||||
**Robust system.** *for real*<br /> |
||||
Static compilation for system tools *(at least)*: there is almost no way to get a borked system with an update (yes, almost, people are creative these days). |
||||
|
||||
**Officially supported and documented services.** *so you are sure to get them working*<br /> |
||||
We use some services for our own personal usage, so we will provide support for them. |
||||
For instance: gitea, postgresql, a building plateform and a continuous integration tool, etc. |
||||
|
||||
**Simple to contribute to.** |
||||
We want fewer and simpler tools as possible: Baguette OS has very few requirements, and automatic verifications. |
||||
Baguette OS do not suffer from any cumbersome historical decisions: no overly engineered package format, no stupidly complex tooling, etc. |
||||
|
||||
**One need, one tool.** *this time for real*<br /> |
||||
Installing an application or a library is done by [package][package]. |
||||
Other methods are not supported **and the base system will never require them**. |
||||
We avoid to rely on `pip`, `cpanm`, or other third party package manager and dependency tree. |
||||
More on that in the [technical section](#technical-choices). |
||||
|
||||
Starting, stopping, or configuring a service is done by [service][service]. |
||||
This program alone is used to manage services on the OS. |
||||
Users should not be required to manually configure each software; instead, most of the configuration should be done upstream using templates. |
||||
Users should be able to change the default configuration through command-line options. |
||||
Manual configuration is the last option. |
||||
|
||||
**Slotting.** |
||||
[Slotting](#slotting) by default helps to install many programs with peculiar library version requirements. |
||||
No difference between stable and development versions. |
||||
|
||||
**Easy to write documentation.** |
||||
Online documentation is written in Markdown (thanks Zola), and man pages too thanks to `scdoc`. |
||||
Every tool is shipped with a man page: no man page, no integration in base. |
||||
|
||||
## OS content |
||||
|
||||
- kernel: linux + headers (but most of the system should be kernel-agnostic) |
||||
- libc: musl, but any other libc can be easily added |
||||
- init: sysv init |
||||
- /etc/rc: CRUX-like |
||||
- coreutils: `toybox` (or `busybox`) |
||||
- shadow (todo: check if not already included in busybox) |
||||
- building tools: |
||||
- LLVM + Clang |
||||
- autotools (for sysv init and libarchive) |
||||
- libarchive |
||||
- `m4` (required at least for bootstrapping) |
||||
- make: `gnu-make` for compatibility reasons |
||||
- shells: |
||||
- `zsh` for users (not root by default) |
||||
- `ash` (because of busybox) or `ksh` |
||||
- documentation: |
||||
- a full hand-book like the OpenBSD FAQ |
||||
- manpages, written mostly with `scdoc` so anyone can contribute |
||||
- our tools |
||||
- services: [service][service] |
||||
- package management: [package][package] |
||||
- packaging: `packaging` |
||||
|
||||
## Inspiration |
||||
|
||||
- OpenBSD: security, therefore simplicity, no compromise |
||||
- PFSense: system and (even advanced) networking administration, yet through a simple website |
||||
- Plan9: everything is a file *no seriously guys* |
||||
- suckless and cat-v: simplicity, code readability and reusability |
||||
- morpheus: static compilation for the OS, demystified |
||||
|
||||
# Baguette OS - detailed explanation |
||||
|
||||
## Features and objectives |
||||
|
||||
|
||||
## custom tools |
||||
|
||||
- [package][package]: package manager |
||||
- basics: install, remove, search and provide informations about a package |
||||
- rootfs creation |
||||
- used by `packaging` to create low-cost build environments<br /> |
||||
[package][package] knows the minimal set of binaries and configuration required to build the target, so it only installs the minimal environment to perform compilation.<br /> |
||||
This environment is low-cost since we hardlink binaries into the building rootfs.<br /> |
||||
Inspired by the *proot* tool on OpenBSD. |
||||
- slotting by default: no need for custom environments for each software |
||||
- packages format: |
||||
- .tar |
||||
- meta.spec |
||||
- files.tar.xz |
||||
- db format: |
||||
- world |
||||
- installed |
||||
- [package-name]/[slot]/manifest |
||||
- [package-name]/[slot]/meta.spec |
||||
- configuration: |
||||
- list of repositories |
||||
- authorized package signing keys |
||||
- packaging variables (cflags, makeflags, and so on) |
||||
- `packaging`: create packages |
||||
- uses simple, declarative recipe files |
||||
- create build environments to test packages before validation |
||||
- [service][service]: service management |
||||
- add an init script for a service, for a specified domain |
||||
- example: `service add wordpress example.com` |
||||
- the init script verifies if a configuration file is installed<br /> |
||||
The configuration file is created if not present.<br /> |
||||
Configuration templates are provided for all services. |
||||
- the service can be installed in a specific environment (read: a custom rootfs) ← NOT IMPLEMENTED (also, environments == domains atm) |
||||
- example: `service add wordpress example.com testingenv` |
||||
- `service` provides an unified way to configure the system<br /> |
||||
It alleviates the need for manual configuration. For example, adding a wordpress service will automatically change the `nginx` configuration, create a new database and a new user in `mariadb` for this specific service.<br /> |
||||
If several `nginx` are required, ports will be registered and automatically managed for each instance, no need for user input.<br /> |
||||
Behind the scene, it's a simple token system with configuration templating!<br /> |
||||
No heavy machinery here, and we'll keep it that way. |
||||
- `build.cr` (temporary name): Makefile creation |
||||
- create makefiles from simple declarative configuration file |
||||
- can replace most build systems |
||||
- FIXME: design something using .spec format |
||||
- `tap-aggregator`: quality assurance & test results aggregation |
||||
- `webhooksd` |
||||
- automatic verification of the recipes on new application or library version |
||||
- automatic cross-compilation (x86_64, ARM, others will follow) |
||||
- `libipc`: an IPC communication library |
||||
- currently used for |
||||
1. the administration dashboard |
||||
2. the web interface for the services |
||||
3. `todod` (a kanban) 4. several other tools we use for collaboration |
||||
- provides a way to communicate between clients and services |
||||
- uses simple unix sockets behind the scene |
||||
- transparent remote communications |
||||
- clients and services do not need remote communication |
||||
- any client can join remote services via any communication protocol |
||||
- any service is implicitly accessible from anywhere, anyhow |
||||
- C library with Crystal bindings (other languages coming soon) |
||||
- we create services, not libraries<br /> |
||||
Therefore, languages are irrelevant: you can use any *library* in any language. |
||||
|
||||
|
||||
## <a name="technical-choices"></a> Technical choices |
||||
|
||||
**Linux kernel**, but we are lurking on the OpenBSD one.<br /> |
||||
Linux is compatible with most hardware and software, it is fast and we can easily compile a custom version to remove most of the bloat for server usage. |
||||
Still, we don't want to rely on Linux-specific components. |
||||
At some point, our system will be kernel-agnostic and will be able to run on any BSD as well. |
||||
|
||||
**Musl libc.**<br /> |
||||
It has a reasonable amount of features, it is efficient, provides reasonable binary sizes and static compilation. |
||||
Musl is simple, reliable and remove all glibc-specific functions. |
||||
Others can be added easily, which is useful for compatibility and comparisons, through [slotting](#slotting). |
||||
|
||||
**Bootable system and rootfs available.**<br /> |
||||
A bootable system to install in virtual machines or bare metal, a rootFS to use BaguetteOS from any other OS, including non-Linux ones. |
||||
|
||||
**SysV-style init + CRUX rc**.<br /> |
||||
The init could come from toybox or another minimalist project. |
||||
No systemd BS. |
||||
|
||||
|
||||
**Slotting.**<br /> |
||||
|
||||
**Custom file system hierarchy.**<br /> |
||||
Our FS is not FHS-compliant, partially because of the origin-based slotting. |
||||
There is a strict separation between core system and third party software. |
||||
- */usr/baguette* for core system programs |
||||
- */usr/bad* for unslottable software |
||||
- */usr/third-party* for other software |
||||
|
||||
**Crystal language for system tools.** *Syntax and productivity of Ruby, the speed of C*<br /> |
||||
It is as simple to learn as a dynamic language, while at the same time being almost as fast as C. |
||||
Technically, Crystal is strongly typed which catches errors at compile-time, but with type inference so it is not cumbersome to use. |
||||
Applications are compiled in a simple (static) binary, easy to deploy. |
||||
There is a good documentation, we used it for long enough to tell. |
||||
Technical choices are reasonable and documented. |
||||
Finally, Crystal has a large library with all we need for our system components. |
||||
|
||||
- coreutils: busybox<br /> |
||||
- */etc/rc/*: forked from CRUX<br /> |
||||
- Building tools<br /> |
||||
- LLVM + Clang |
||||
- tar -> bsdtar |
||||
- webhooks (libarchive), cpio -> bsdcpio (libarchive) |
||||
- autotools (for SySV init and libarchive) |
||||
- m4 |
||||
- make: gnu-make (since it is required for many projects) |
||||
- `crystal` since we use this language for our tools in the base system |
||||
- shells<br /> |
||||
- sh -> zsh |
||||
|
||||
## Still in discussion |
||||
|
||||
For the simple users, we want to provide an unified web interface to manage the system and online services. |
||||
We currently use `Crystal` to work on service back-ends for a variety of projects, we are satisfied on a technical level and we are productive, it is highly probable we continue using it. |
||||
The front-end is still in discussion: we currently use `livescript` and it is way more usable than plain JS, but it is painful to debug. |
||||
|
||||
So, we need a language for both administration dashboard and online services, here some examples we find interesting for the job: |
||||
- Purescript |
||||
- haskell-like syntax, with a smaller set of notions |
||||
- strongly typed, with type inference |
||||
- good documentation |
||||
- useful compilation errors |
||||
- no runtime error |
||||
- Elm |
||||
- as Purescript but with way fewer documentation |
||||
- less generic code |
||||
- still very young |
||||
- WASM |
||||
- seems to be a very young tech, with no real good language or documentation |
||||
- Zig has wasm as a Tier 1 support, we should investigate |
||||
|
||||
# <a name="slotting"></a> Providing software: the right way |
||||
|
||||
The usual way to provide software is to maintain a version of a software or a library, package it into a distribution, then provide it as *the* OS version of the software. |
||||
In the long run, software and libraries change, which is no big deal since maintainers verify the consistency of the different versions provided by the OS. |
||||
TODO |
||||
|
||||
**Problem:** what happens when two programs need a different version of a library? |
||||
|
||||
**Problem:** what happens when two libraries are compatible but you want both on your system (see libressl and openssl)? |
||||
|
||||
**Problem:** what happens when you want to provide a **very** long term support for your users (see companies running decade-old databases)? |
||||
|
||||
Baguette OS has a simple and safe way to let users and maintainers provide packages: `slotting`. |
||||
Official OS packages are installed under `/usr/baguette/`, for non-essential programs. |
||||
Here, the slot is `baguette`. |
||||
Any package outside the official ones are in another named slot. |
||||
|
||||
TODO |
||||
|
||||
**This in nothing new, however not often used, and still maybe the best way to handle the problem.** |
||||
|
||||
|
||||
- usual directories under root: bin, sbin, lib, boot, dev, proc, sys, home, mnt, root, run, tmp |
||||
- etc |
||||
- rc |
||||
- services |
||||
- environments |
||||
- templates |
||||
- var |
||||
- cache |
||||
- srv |
||||
- "env-name" (see [service][service]) |
||||
- etc |
||||
- data |
||||
- cache |
||||
- run |
||||
- usr |
||||
- local: things that are installed by the local system administrator without using packages |
||||
- baguette: things provided by the system that are not necessary for it to run (and boot, and restart, and do system things) |
||||
- "repo" |
||||
- lib |
||||
- libexec: try to avoid using it whenever possible. May or may not stay. |
||||
- bin |
||||
- share |
||||
- man |
||||
- include |
||||
- bad: things that cannot be properly installed or slotted somewhere else |
||||
|
||||
# Roadmap |
||||
|
||||
We currently aim at providing a rootfs with our tools, when we will have enough spare time to contribute. |
||||
|
||||
|
||||
|
||||
[service]: https://git.baguette.netlib.re/Baguette/service |
||||
[package]: https://git.baguette.netlib.re/Baguette/package |
||||
[packaging]: https://git.baguette.netlib.re/Baguette/packaging |
||||
|
||||
|
||||
@ -1,11 +1,33 @@ |
||||
+++ |
||||
title = "Un nouveau site pour dnsmanager" |
||||
title = "Baguette - Présentation du projet" |
||||
slug = "nouveau-site" |
||||
date = 2020-03-30 |
||||
date = 2020-04-25 |
||||
+++ |
||||
|
||||
Aujourd'hui, nous ouvrons un nouveau site web pour dnsmanager! |
||||
Aujourd'hui, nous ouvrons un nouveau site web pour la communauté Baguette ! |
||||
|
||||
Il devrait fonctionner correctement sur tous vos appareils y compris les téléphones portables. Si ça n'est pas le cas, merci de nous le signaler ou de soumettre un patch. |
||||
Baguette regroupe un paquet de [logiciels et de bibliothèques][baguette] ainsi qu'un système d'exploitation : [BaguetteOS][baguetteos]. |
||||
|
||||
Dans le futur, toutes les nouvelles excitantes à propos de dnsmanager apparaîtront sur ce blog, alors reste connectéE. |
||||
Parmi nos applications phares : |
||||
- [notre système d'exploitation][baguetteos] |
||||
- [LibIPC][libipc], pour permettre aux applications de communiquer le plus simplement possible |
||||
- [Service][service], notre outil pour remplacer `systemd` et `openrc` |
||||
- [Document Oriended Database (dodb)][dodb] |
||||
- [dnsmanager][dnsmanager] |
||||
|
||||
Pour avoir une liste exhaustive : allez directement sur notre [dépot git][gitea]. |
||||
|
||||
Nous publierons de temps en temps des nouvelles du développement, de l'OS, de l'infra sur laquelle nous faisons nos builds sur ce blog. Stay tuned! |
||||
|
||||
N'hésitez pas à venir discuter avec nous sur [Mattermost][mattermost], bientôt des ponts avec IRC et XMPP, stay tuned ! |
||||
|
||||
[baguetteos]: /fr/baguetteos |
||||
[baguette]: /fr/projects |
||||
|
||||
[gitea]: https://git.baguette.netlib.re |
||||
[service]: https://git.baguette.netlib.re/Baguette/service |
||||
[dodb]: https://git.baguette.netlib.re/Baguette/dodb.cr |
||||
[libipc]: https://git.baguette.netlib.re/Baguette/libipc |
||||
[dnsmanager]: https://git.baguette.netlib.re/Baguette/dnsmanager |
||||
|
||||
[mattermost]: https://team.baguette.netlib.re/ |
||||
|
||||
@ -1,15 +0,0 @@ |
||||
+++ |
||||
title = "FAQ" |
||||
+++ |
||||
|
||||
# How to setup dnsmanager? |
||||
|
||||
See the project [README](https://github.com/KaneRoot/dnsmanager) for setup instructions. |
||||
|
||||
# Does dnsmanager support delegation? |
||||
|
||||
At the moment, dnsmanager cannot delegate zones although this feature is on the roadmap. |
||||
|
||||
# Does dnsmanager support 3rd party auth? |
||||
|
||||
At the moment, dnsmanager does not support an external authentication service such as LDAP although this feature is on the roadmap. |
||||
@ -0,0 +1,36 @@ |
||||
+++ |
||||
title = "Projects" |
||||
+++ |
||||
|
||||
dnsmanager is a web interface to enable users to register DNS names and manage their zone. It is the software powering [netlib.re](https://netlib.re), a service to provide names for everyone on the Internet. |
||||
|
||||
[netlib.re](https://netlib.re) is kindly operated by [Alsace Réseau Neutre](https://arn-fai.net), a neutral and non-profit Internet Service Provider based in Alsace, France. Don't be shy, come and ask questions! |
||||
|
||||
# Features |
||||
|
||||
- [x] User accounts |
||||
- [x] Simple and expert modes for zone edition |
||||
- [x] DynDNS-like automatic IP updates |
||||
- [x] Multiple client and parent zones |
||||
- [ ] DNS delegation |
||||
- [ ] 3rd party authentication (LDAP, OpenID Connect) |
||||
- [ ] Documented client-side API |
||||
- [ ] CAPTCHA? |
||||
|
||||
# Setup |
||||
|
||||
Please refer to the [project's repository](https://github.com/KaneRoot/dnsmanager) for setup instructions. |
||||
|
||||
|
||||
|
||||
# How to setup dnsmanager? |
||||
|
||||
See the project [README](https://github.com/KaneRoot/dnsmanager) for setup instructions. |
||||
|
||||
# Does dnsmanager support delegation? |
||||
|
||||
At the moment, dnsmanager cannot delegate zones although this feature is on the roadmap. |
||||
|
||||
# Does dnsmanager support 3rd party auth? |
||||
|
||||
At the moment, dnsmanager does not support an external authentication service such as LDAP although this feature is on the roadmap. |
||||
|
After Width: | Height: | Size: 35 KiB |
Loading…
Reference in new issue