Baguette, first real commit.

This commit is contained in:
Philippe PITTOLI 2020-04-21 23:01:09 +02:00
parent 74fa9420a6
commit c5f22f48b9
13 changed files with 447 additions and 93 deletions

View File

@ -1,5 +1,5 @@
# The URL the site will be built for
base_url = "https://thunix.net/~southerntofu/dnsmanager"
base_url = "https://baguette.netlib.re/"
# Whether to automatically compile all Sass files in the sass directory
compile_sass = true
@ -22,14 +22,14 @@ languages = [
[extra]
# The common part of the title (appended to page/section titles)
title = " | dnsmanager"
title = " | baguette"
[extra.forge]
# The baseURL for files tracked on the forge
browse = "https://tildegit.org/southerntofu/dnsmanager-website/src/branch/master/"
browse = "https://git.baguette.netlib.re/Baguette/website"
# Homepage of the forge
home = "https://tildegit.org/"
home = "https://git.baguette.netlib.re/"
# Name of the forge
name = "tildegit"
name = "Baguette"
[translations]
[translations.fr]

View File

@ -2,11 +2,13 @@
+++
<h1 hidden>dnsmanager</h1>
<img src="/baguette.png" alt="Baguette" class="banner" />
<pre aria-hidden="true"><code>
_
__| |_ __ ___ _ __ ___ __ _ _ __ __ _ __ _ ___ _ __
/ _` | '_ \/ __| '_ ` _ \ / _` | '_ \ / _` |/ _` |/ _ \ '__|
| (_| | | | \__ \ | | | | | (_| | | | | (_| | (_| | __/ |
\__,_|_| |_|___/_| |_| |_|\__,_|_| |_|\__,_|\__, |\___|_|
|___/
____ _ _
| __ ) __ _ __ _ _ _ ___| |_| |_ ___
| _ \ / _` |/ _` | | | |/ _ \ __| __/ _ \
| |_) | (_| | (_| | |_| | __/ |_| || __/
|____/ \__,_|\__, |\__,_|\___|\__|\__\___|
|___/
</code></pre>

View File

@ -1,16 +1,14 @@
+++
+++
[Accueil](@/_index.fr.md)
[Baguette OS](@/_index.fr.md)
---
[Projets](/fr/projects/)
---
[Blog](@/blog/_index.fr.md)
---
[Source](https://github.com/kaneroot/dnsmanager)
---
[FAQ](@/faq/index.fr.md)

View File

@ -1,16 +1,13 @@
+++
+++
[Home](@/_index.md)
[Baguette OS](@/_index.md)
---
[Projects](/projects/)
---
[Blog](@/blog/_index.md)
---
[Source](https://github.com/kaneroot/dnsmanager)
---
[FAQ](@/faq/index.md)

View File

@ -1,23 +1,8 @@
+++
title = "dnsmanager - libérez vos zones"
title = "Baguette - un OS, des outils, des services"
+++
dnsmanager est une interface web pour permettre aux utilisateurices d'enregister un nom DNS et de gérer leur zone. C'est le logiciel derrière les coulisses de [netlib.re](https://netlib.re), un service qui fournit de noms pour tout le monde sur Internet.
[netlib.re](https://netlib.re) est sympathiquement opéré par [Alsace Réseau Neutre](https://arn-fai.net), un Fournisseur d'Accès à Internet neutre et sans-profit situé en Alsace (France). Ne sois pas timide et viens poser tes questions !
# Fonctionalités
- [x] Comptes utilisateurice
- [x] Édition de zone en mode simple et expert
- [x] Mise à jour d'IP automatique à la DynDNS
- [x] Multiple zones clientes et parentes
- [ ] Délégation DNS
- [ ] Authentification tierce (LDAP, OpenID Connect)
- [ ] API client documentée
- [ ] CAPTCHA?
# Installation
Se référer au [dépôt du projet](https://github.com/KaneRoot/dnsmanager) pour les instructions d'installation.
# Baguette OS
La page n'a pas encore été traduite.

View File

@ -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

View File

@ -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/

View File

@ -1,15 +0,0 @@
+++
title = "FAQ"
+++
# Comment installer dnsmanager
Le [README](https://github.com/KaneRoot/dnsmanager) contient les instructions pour installer dnsmanager.
# dnsmanager supporte-t-il la délégation ?
Pour le moment, dnsmanager ne sait pas déléguer une zone. Cette fonctionnalité sera probablement implémentée dans le futur.
# dnsmanager supporte-t-il l'authentification tierce ?
Pour le moment, dnsmanager ne sait pas gérer un serveur d'authentification tierce (par exemple LDAP). Ce sera probablement implémenté dans le futur.

View File

@ -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.

View File

@ -0,0 +1,41 @@
+++
title = "Projets"
+++
# Nous contacter
N'hésitez pas à venir discuter avec nous sur [notre outil de communication][mattermost].
Des passerelles vers IRC est XMPP sont à venir !
[mattermost]: https://team.baguette.netlib.re/
# dnsmanager / netlib.re
`dnsmanager` est une interface web pour permettre aux utilisateurices d'enregister un nom DNS et de gérer leur zone. C'est le logiciel derrière les coulisses de [netlib.re](https://netlib.re), un service qui fournit de noms pour tout le monde sur Internet.
[netlib.re](https://netlib.re) est sympathiquement opéré par [Alsace Réseau Neutre](https://arn-fai.net), un Fournisseur d'Accès à Internet neutre et sans-profit situé en Alsace (France). Ne sois pas timide et viens poser tes questions !
## Fonctionalités
- [x] Comptes utilisateur
- [x] Édition de zone en mode simple et expert
- [x] Mise à jour d'IP automatique à la DynDNS
- [x] Multiple zones clientes et parentes
- [ ] Délégation DNS
- [ ] Authentification tierce (LDAP, OpenID Connect)
- [ ] API client documentée
- [ ] CAPTCHA?
## Comment installer dnsmanager
Le [README](https://github.com/KaneRoot/dnsmanager) contient les instructions pour installer dnsmanager.
## dnsmanager supporte-t-il la délégation ?
Pour le moment, dnsmanager ne sait pas déléguer une zone. Cette fonctionnalité sera probablement implémentée dans le futur.
## dnsmanager supporte-t-il l'authentification tierce ?
Pour le moment, dnsmanager ne sait pas gérer un serveur d'authentification tierce (par exemple LDAP). Ce sera probablement implémenté dans le futur.

36
content/projects/index.md Normal file
View File

@ -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.

View File

@ -1,6 +1,13 @@
@import 'mobile';
@import 'widgets';
.banner {
margin-top: 0.5cm;
float: left;
height: 5cm;
// margin-bottom: -1cm;
}
.nav-menu {
font-weight: bold;
> a { margin: 0 1rem; } // Spacing entries
@ -14,6 +21,16 @@ header {
background-color: rgb(239, 239, 239);
}
// less spacing in lists
li > p {
padding: -1px;
padding-top: -1px;
padding-bottom: -1px;
margin: -1px;
margin-top: -1px;
margin-bottom: -1px;
}
article > div:first-child > h1, section > h1:first-child {
text-align: center;
font-size: 2.6em;

BIN
static/baguette.png Normal file

Binary file not shown.

After

Width:  |  Height:  |  Size: 35 KiB