Le retour va être dur, mais il le faut...
Ça va être dur de retourner sur une Debian, comme je l'ai dis j'ai vraiment apprécié cette Nixos, j'ai découvert une communauté Fr plus fréquentable que la communauté internationale d'après les dires de certains, qui la trouve élitiste, la Fr est vraiment au top et sympathique, m'ont guidé tout le long.
J'ai donc compris les principaux trucs qui pouvaient me faire revenir à une distribution plus classique. La création de paquets, la maintenance de paquets, comme faire passer pelican de la version 4.6.0 à la 4.7.1, tout ce fait vraiment simplement. On clone le git puis on lance les deux commandes suivantes:
Builder le paquet avec le nom réel du paquet dans nixos et non dans leur git, pour pelican ça donne ceci:
nix-build -A python39Packages.pelican
pour l'installer:
nix-env -f . -iA python39Packages.pelican
J'ai trouvé la compilation des plus rapides, j'ai fait filezilla, pelican, deluge et quelques autres dont je ne me souviens pas, j'ai gardé ça pour moi, j'aurais certainement dû pousser sur leur git mais encore une fois je ne suis pas trop copain avec git ou github et assimilé, voila.
J'ai aussi totalement compris le principe des services, on peut "exploser" son fichier configuration.nix en plusieurs parties, pour les services ça porte le nom de module, dans mon cas et pour l'utilisation de minidlna, j'aurais pu exporter la config du service dans un dossier minidlna.nix, puis importer le lien de ce fichier dans le fichier configuration.nix. Ça aurait donné un truc du genre:
Mon fichier minidlna.nix ressemblerait à ça plus ou moins, je ne suis pas obligé de tout mettre:
# Module for MiniDLNA, a simple DLNA server.
{ config, lib, pkgs, ... }:
with lib;
let
cfg = config.services.minidlna;
port = 49152;
in
{
###### interface
services.minidlna.mediaDirs = mkOption {
type = types.listOf types.str;
default = ["V,/home/sebastien/Vidéos"];
example = [ "/data/media" "V,/home/alice/video" ];
description =
''
Directories to be scanned for media files. The prefixes
<literal>A,</literal>, <literal>V,</literal> and
<literal>P,</literal> restrict a directory to audio, video
or image files. The directories must be accessible to the
<literal>minidlna</literal> user account.
'';
};
services.minidlna.friendlyName = mkOption {
type = types.str;
default = "${config.networking.hostName} MiniDLNA";
defaultText = literalExpression ''"''${config.networking.hostName} MiniDLNA"'';
example = "rpi3";
description =
''
Name that the DLNA server presents to clients.
'';
};
services.minidlna.rootContainer = mkOption {
type = types.str;
default = "V";
example = "B";
description =
''
Use a different container as the root of the directory tree presented
to clients. The possible values are:
- "." - standard container
- "B" - "Browse Directory"
- "M" - "Music"
- "P" - "Pictures"
- "V" - "Video"
- Or, you can specify the ObjectID of your desired root container
(eg. 1$F for Music/Playlists)
If you specify "B" and the client device is audio-only then
"Music/Folders" will be used as root.
'';
};
services.minidlna.loglevel = mkOption {
type = types.str;
default = "warn";
example = "general,artwork,database,inotify,scanner,metadata,http,ssdp,tivo=warn";
description =
''
Defines the type of messages that should be logged, and down to
which level of importance they should be considered.
The possible types are “artwork”, “database”, “general”, “http”,
“inotify”, “metadata”, “scanner”, “ssdp” and “tivo”.
The levels are “off”, “fatal”, “error”, “warn”, “info” and
“debug”, listed here in order of decreasing importance. “off”
turns off logging messages entirely, “fatal” logs the most
critical messages only, and so on down to “debug” that logs every
single messages.
The types are comma-separated, followed by an equal sign (‘=’),
followed by a level that applies to the preceding types. This can
be repeated, separating each of these constructs with a comma.
Defaults to “general,artwork,database,inotify,scanner,metadata,
http,ssdp,tivo=warn” which logs every type of message at the
“warn” level.
'';
};
services.minidlna.announceInterval = mkOption {
type = types.int;
default = 10;
description =
''
The interval between announces (in seconds).
By default miniDLNA will announce its presence on the network
approximately every 15 minutes.
Many people prefer shorter announce intervals (e.g. 60 seconds)
on their home networks, especially when DLNA clients are
started on demand.
'';
};
services.minidlna.config = mkOption {
type = types.lines;
description =
''
The contents of MiniDLNA's configuration file.
When the service is activated, a basic template is generated
from the current options opened here.
'';
};
services.minidlna.extraConfig = mkOption {
type = types.lines;
default = "";
example = ''
# Not exhaustive example
# Support for streaming .jpg and .mp3 files to a TiVo supporting HMO.
enable_tivo=no
# SSDP notify interval, in seconds.
notify_interval=10
# maximum number of simultaneous connections
# note: many clients open several simultaneous connections while
# streaming
max_connections=50
# set this to yes to allow symlinks that point outside user-defined
# media_dirs.
wide_links=yes
'';
description =
''
Extra minidlna options not yet opened for configuration here
(strict_dlna, model_number, model_name, etc...). This is appended
to the current service already provided.
'';
};
};
###### implementation
config = mkIf cfg.enable {
services.minidlna.config =
''
port=${toString port}
friendly_name=${cfg.friendlyName}
db_dir=/var/cache/minidlna
log_level=${cfg.loglevel}
inotify=yes
root_container=${cfg.rootContainer}
${concatMapStrings (dir: ''
media_dir=${dir}
'') cfg.mediaDirs}
notify_interval=${toString cfg.announceInterval}
${cfg.extraConfig}
'';
users.users.minidlna = {
description = "MiniDLNA daemon user";
group = "minidlna";
uid = config.ids.uids.minidlna;
};
users.groups.minidlna.gid = config.ids.gids.minidlna;
systemd.services.minidlna =
{ description = "MiniDLNA Server";
wantedBy = [ "multi-user.target" ];
after = [ "network.target" ];
serviceConfig =
{ User = "minidlna";
Group = "minidlna";
CacheDirectory = "minidlna";
RuntimeDirectory = "minidlna";
PIDFile = "/run/minidlna/pid";
ExecStart =
"${pkgs.minidlna}/sbin/minidlnad -S -P /run/minidlna/pid" +
" -f ${pkgs.writeText "minidlna.conf" cfg.config}";
};
};
};
}
Comme j'ai dis, j'y ai tout laissé, mais je vais changer et essayer de mettre ça en place avant de revenir sur ma Debian.
Mon fichier configuration.nix donnerait ceci (du moins la partie importation de conf):
# Edit this configuration file to define what should be installed on
# your system. Help is available in the configuration.nix(5) man page
# and in the NixOS manual (accessible by running ‘nixos-help’).
{ config, pkgs, ... }:
{
imports =
[ # Include the results of the hardware scan.
./hardware-configuration.nix
./minidlna.nix
];
...
Alors seb, t'as fait ce que tu voulais, tu as compris et tu adhères à cette façon d'utiliser ton OS, oui mais non... J'adore, je dois dire que la Nixos est la distribution la plus intéressante que j'ai vu depuis Debian, je dois même avouer que je suis à deux doigts de la garder et de virer Debian pour de bon, même le coté totalement atypique, seule au monde, totalement différente des autres et non compatible avec la configuration et la hiérarchie de la racine qu'on connais par ailleurs à la mode FHS pourrait passer. En fait, tout ça on s'y fait, c'est juste nouveau et peu habituel mais on s'y fait et puis comme ça avec cette configuration dans un seul fichier, on sait ce que l'on a fait / modifié et surtout on ne cherche plus tel ou tel fichier. Ce n'est pas orthodoxe mais c'est intelligent! Non ce qui ne va pas, c'est les binaires pré-compilés qu'on peut trouver sur le net, par exemple seamonkey (je prend l'exemple qui me viens comme ça), bah vu que les binaires pré-compilé s'attendent à trouver les libs et autres dans des endroits habituels comme /usr, /bin, /libs ... Et bien ces mêmes paquets pré-compilé ne démarrent pas.
Allez un exemple:
$ Typora-linux-x64/Typora
bash: Typora-linux-x64/Typora: No such file or directory
J'ai essayé sur 11 paquets que j'ai de ce type, aucun n'a voulu se lancer...
Bon pour deux d'entre eux, c'est pas trop grave car ils sont déjà en paquets chez eux (NiXos!). Mais quand même c'est pas super.
L'autre truc qui me gêne, c'est de un la documentation éparpillée de partout, de deux la solitude pour trouver un semblant de ressemblance à une autre distro en cas de soucis. On se sent vraiment bien seul.
Honnêtement, si je retourne sur Debian c'est juste par habitude, par connaissance, pour mes repères, mais en aucun cas parce que celle-ci est supérieur, je trouve que Nixos est vraiment un OS chouette, simple à installer, idéale pour une utilisation desktop ou gaming... C'est la distribution qui m'a le plus tapé dans l'oeil depuis 15-16 ans, c'est celle qui m'a redonné cette attrait à la découverte, la plus solide aussi et la plus sécurisante. Elle fait partie de mon top 3 et ce classe facilement deuxième de celui-ci juste après Debian.
Là je vais tenter de bien mettre mon service en route, puis je retournerai sous Debian, une Sid pour changer un peu car là ça va être réellement dur de revenir sur du gnome 3.38! Mais rien ne dit qu'à la suite de cette mise en pratique d'un service je ne resterai pas sur la Nixos, ou encore qu'une fois sur Sid je ne reviendrai pas sur cette distribution qui me rassure avec ces sauvegardes et son fichier central.
On verra bien!
Commencer la discussion: Venez écrire un commentaire dans le forum
- Précédent: Ça va être dur de revenir sur une distribution plus standard...
- Suivant: Alors Nixos?