L'option suid est liée à la façon dont on veut démarrer netbumpd.
Le choix de proposer plusieurs modes de démarrage découle d'un prérequis: netbumpd n'impose pas d'être démarré en permanence.
L'option de démarrage de netbumpd est choisie à la compilation parmi les options (exclusives) suivantes:
- systemd
- daemon
- nodaemon
option systemd
permet (à l'aide des fichiers de conf fournis dans le dépôt) de laisser systemd écouter sur la socket Unix et démarrer netbumpd lors de la première requête reçue. Il démarrera tel un daemon classique et pourra (si compilé avec l'option autoclose) s'éteindre après une période d'inactivité (plus précisément une période d'inutilité) et redonner la socket Unix à systemd afin de répéter cette boucle.
On n'a donc pas besoin de suid tant que systemd permet à netbumpd de démarrer avec les droits root.
option daemon
correspond à la méthode classique pour démarrer un serveur "autonome", on a donc besoin des droits root mais pas du suid.
option nodaemon
est celle qui peut avoir besoin du bit suid.
Dans ce mode, on peut démarrer netbumpd dans un terminal mais il faut disposer des droits root. Ce n'est pas pratique et ça va à l'encontre de se présenter comme un utilitaire pour l'utilisateur final. Je pense à une machine multi-users, à des terminaux X et certainement plein d'autres cas.
L'idée est donc de permettre (optionnellement) au client netbump, de pouvoir démarrer netbumpd, imposant le bit suid à netbumpd dans ce cas.
On pourra donc choisir de compiler netbumpd avec le suid: cargo xtask netbumpd --suid ...
Ca m'a été très utile pendant le développement, me permettant de compiler et démarrer netbumpd en une seule commande tout en restant sur un compte non-root (cargo xtask netbumpd --features ... --suid --run—-v)
impossibilité de modifier les limites après le début de la sauvegarde
en utilisant les outils existants, on peut démarrer la sauvegarde avec une limite en download et /ou upload, mais on ne va pas pouvoir modifier cette limite. C'est le cas courant auquel j'étais confronté:
A l'époque, je plafonnais à 1Mo/s en download, je devais donc limité à 100ko/s pour laisser de la place pour les possibles appels visio des autres utilisateurs de la ligne internet. Je voulais pouvoir modifier la limite à tout instant afin d'utiliser pleinement mon débit maximum.
Krunch a mentionné les options de wget, mais ça limite à quelques protocoles, au bon vouloir du peer et surtout il aurait fallu que je modifie un script shell ...
impossibilité de mettre en place des limites sur une sauvegarde déjà en cours
c'est la situation où je lançais directement ma sauvegarde sans l'avoir limitée, j'étais en incapacité d'ajouter une limite.
On peut s'en sortir avec tc et ntfables/iptables mais ce n'est pas user-friendly.
[^] # Re: questions
Posté par tigrou3tac . En réponse au journal présentation de netbump, un outil en ligne de commande pour limiter la bande passante (LINUX ONLY). Évalué à 3 (+2/-0).
Effectivement ce n'est pas clair.
L'option suid est liée à la façon dont on veut démarrer netbumpd.
Le choix de proposer plusieurs modes de démarrage découle d'un prérequis: netbumpd n'impose pas d'être démarré en permanence.
L'option de démarrage de netbumpd est choisie à la compilation parmi les options (exclusives) suivantes:
- systemd
- daemon
- nodaemon
option systemd
permet (à l'aide des fichiers de conf fournis dans le dépôt) de laisser systemd écouter sur la socket Unix et démarrer netbumpd lors de la première requête reçue. Il démarrera tel un daemon classique et pourra (si compilé avec l'option autoclose) s'éteindre après une période d'inactivité (plus précisément une période d'inutilité) et redonner la socket Unix à systemd afin de répéter cette boucle.
On n'a donc pas besoin de suid tant que systemd permet à netbumpd de démarrer avec les droits root.
option daemon
correspond à la méthode classique pour démarrer un serveur "autonome", on a donc besoin des droits root mais pas du suid.
option nodaemon
est celle qui peut avoir besoin du bit suid.
Dans ce mode, on peut démarrer netbumpd dans un terminal mais il faut disposer des droits root. Ce n'est pas pratique et ça va à l'encontre de se présenter comme un utilitaire pour l'utilisateur final. Je pense à une machine multi-users, à des terminaux X et certainement plein d'autres cas.
L'idée est donc de permettre (optionnellement) au client netbump, de pouvoir démarrer netbumpd, imposant le bit suid à netbumpd dans ce cas.
On pourra donc choisir de compiler netbumpd avec le suid: cargo xtask netbumpd --suid ...
Ca m'a été très utile pendant le développement, me permettant de compiler et démarrer netbumpd en une seule commande tout en restant sur un compte non-root (cargo xtask netbumpd --features ... --suid --run—-v)
impossibilité de modifier les limites après le début de la sauvegarde
en utilisant les outils existants, on peut démarrer la sauvegarde avec une limite en download et /ou upload, mais on ne va pas pouvoir modifier cette limite. C'est le cas courant auquel j'étais confronté:
A l'époque, je plafonnais à 1Mo/s en download, je devais donc limité à 100ko/s pour laisser de la place pour les possibles appels visio des autres utilisateurs de la ligne internet. Je voulais pouvoir modifier la limite à tout instant afin d'utiliser pleinement mon débit maximum.
Krunch a mentionné les options de wget, mais ça limite à quelques protocoles, au bon vouloir du peer et surtout il aurait fallu que je modifie un script shell ...
impossibilité de mettre en place des limites sur une sauvegarde déjà en cours
c'est la situation où je lançais directement ma sauvegarde sans l'avoir limitée, j'étais en incapacité d'ajouter une limite.
On peut s'en sortir avec tc et ntfables/iptables mais ce n'est pas user-friendly.