Philippe PITTOLI
4 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