Vai al contenuto
TextArray1.53.0
100% locale

generatore di file di unità systemd

Crea un file .service, .timer, .socket o .mount systemd valido da alcuni campi.

Uscita
Strumenti correlati
Cron a systemd timernuovoStrumenti per sviluppatori
Generatore di DockerfilenuovoStrumenti per sviluppatori
Generatore di configurazione NGINXStrumenti per sviluppatori
Differenza chiave i18nStrumenti per sviluppatori
Convertitore da TOML a JSONStrumenti per sviluppatori
SQL in JSONStrumenti per sviluppatori
generatore di file di unità systemd
Nessun file di configurazione necessario — basta riempire alcuni campi e questo strumento scrive un file di unità systemd completo che puoi inserire direttamente in /etc/systemd/system/. Copre i quattro tipi di unità che gli amministratori di systemd scrivono più spesso a mano: servizio, timer, socket e mount, e produce le sezioni [Unit], [Service] e [Install] con le direttive nell'ordine che systemd si aspetta.
Per un'unità di servizio, imposta la descrizione e l'URL della documentazione, il comando ExecStart (con hook facoltativi ExecStartPre e ExecStop), il Tipo di servizio (simple, exec, forking, oneshot o notify), l'utente e il gruppo con cui eseguire, una directory di lavoro e variabili di ambiente inline o via EnvironmentFile. La politica di riavvio e RestartSec controllano come systemd reagisce quando il processo muore; After e Requires configurano l'ordine delle dipendenze, e WantedBy imposta quale target estrae l'unità all'avvio. Un blocco di hardening aggiunge NoNewPrivileges, PrivateTmp, ProtectSystem e ProtectHome con un clic ciascuno, il che è la maggior parte di ciò che i file di servizio forniti dalle distribuzioni usano per il sandboxing.
Scegliere invece timer, socket o mount riempie ancora le sezioni condivise [Unit] e [Install], ma lascia il blocco specifico del tipo come commento piuttosto che indovinare la sintassi OnCalendar=, ListenStream= o What=/Where= che non può verificare — vedi il convertitore da cron a timer di systemd per una programma pronta. Il nome dell'unità viene disinfettato ai caratteri che systemd consente, e lo strumento avverte invece di bloccarsi se un campo viene incollato in una dimensione assurdamente grande.
Tutto viene eseguito localmente nel tuo browser: nulla di ciò che digiti, inclusi nomi host, percorsi o credenziali in EnvironmentFile, viene mai inviato. Copia il risultato, scaricalo come file .txt da rinominare e installare tu stesso, o invialo a un altro strumento per continuare la modifica.
FAQ
Dove metto il file generato?
Salvalo come /etc/systemd/system/<nome>.service (o .timer/.socket/.mount), quindi esegui systemctl daemon-reload seguito da systemctl enable --now <nome>.
Perché scegliere "timer" o "socket" lascia parte del file come commento?
Questi tipi di unità utilizzano direttive che questo generatore non crea per te — OnCalendar= per un timer, ListenStream= per un socket, What=/Where= per un mount. Aggiungile dove il commento lo indica invece di copiare la sintassi indovinata.
Che cosa fa davvero il blocco di hardening?
NoNewPrivileges blocca l'escalation dei privilegi, PrivateTmp dà al servizio il suo /tmp privato, e ProtectSystem/ProtectHome rendono la maggior parte del filesystem di sola lettura o inaccessibile ad esso. Insieme, corrispondono al sandboxing che molti servizi forniti dalla distribuzione usano già.
Posso generare un'unità per più variabili di ambiente contemporaneamente?
Sì. Elencali separati da virgole o nuove righe come coppie KEY=VALUE nel campo delle variabili di ambiente; ciascuno diventa la sua propria riga Environment=, e le voci malformate vengono saltate piuttosto che rompere il file.
Qualcosa che digito viene inviato a un server?
No. Il file di unità viene generato interamente nel tuo browser — inclusi qualsiasi percorso, nome host o valore di ambiente che inserisci — e nulla viene caricato.