mirror of
https://github.com/foo-dogsquared/wiki.git
synced 2025-02-22 03:19:01 +00:00
Update systemd- and Neovim-related notes
This commit is contained in:
parent
3fa5539c66
commit
8c378fc029
@ -3,13 +3,17 @@
|
||||
:END:
|
||||
#+title: Neovim help system
|
||||
#+date: 2022-04-01 16:20:55 +08:00
|
||||
#+date_modified: 2022-04-03 16:59:48 +08:00
|
||||
#+date_modified: 2022-04-20 19:04:55 +08:00
|
||||
#+language: en
|
||||
|
||||
|
||||
- the main command is ~:h~ which should open ~help.txt~ if given no arguments;
|
||||
this should be enough if you want to explore much of Neovim itself as the document has
|
||||
- the main command is =:h= which should open =help.txt= if given no arguments;
|
||||
this should be enough if you want to explore much of Neovim itself as the document has an index of tutorials and local additions (most likely from the installed plugins)
|
||||
- the help documents are written in a custom formatting language that is recognized as a separate filetype;
|
||||
in addition to navigating the buffer like any other buffer, you can also run =gO= to show the table of contents
|
||||
- if given an argument, Vim will open the section of the document with the closest match
|
||||
- some points of interest
|
||||
- you can view the complete listing of help tags with ~help-tags~
|
||||
- there is also a index of tags from ~index.txt~
|
||||
- you can view the complete listing of help tags with =help-tags=
|
||||
- there is also a index of tags from =index.txt=
|
||||
- you can easily get the keybind with =CTRL-V= (e.g., =CTRL-V= then =META-D= will quickly print the keymap)
|
||||
- tab completion is present
|
||||
|
19
notebook/editor.neovim.lua-modules.org
Normal file
19
notebook/editor.neovim.lua-modules.org
Normal file
@ -0,0 +1,19 @@
|
||||
:PROPERTIES:
|
||||
:ID: bdcff35e-15e1-4539-9c4e-5fdd5b978c26
|
||||
:END:
|
||||
#+title: Neovim Lua modules
|
||||
#+date: 2022-04-20 18:36:23 +08:00
|
||||
#+date_modified: 2022-04-20 18:39:40 +08:00
|
||||
#+language: en
|
||||
|
||||
|
||||
- Neovim will load the requires files from its runtime paths;
|
||||
see =runtimepath= from the [[id:0a0fe63e-dcf3-4928-9e82-5513784c1244][Neovim help system]]
|
||||
- built on top of the already existing [[id:ffb8b08a-ca0a-48a4-bebc-d2bf11aa5ccf][Lua modules]] system
|
||||
- while searching for the runtime paths, Neovim will search for certain folders
|
||||
- =plugin/= will load all of the Lua files that are placed in that subdirectory
|
||||
- =lua/= also contains Lua files but does not automatically load until some other module will call ~require~ to that module
|
||||
- =init.lua= is basically the =index.html= for HTML files, =default.nix= for [[id:a57e63a7-6daa-4639-910d-c6648df156a3][Nix language]], or =mod.rs= for [[id:d7d7d8f0-adf9-461d-ace5-c8624dab1083][Rust language]]
|
||||
- in module names that are ~require~'d, =.= is treated as a separator and representing as a directory in the file tree;
|
||||
e.g., when running ~require("custom.plugins")~, =custom.plugins= should have a module at =$RUNTIMEPATH/lua/custom/plugins/init.lua=
|
||||
- at some point, Neovim can make use of more Lua modules with [[https://luarocks.org/][Luarocks]]
|
@ -3,34 +3,35 @@
|
||||
:END:
|
||||
#+title: Neovim Lua integration
|
||||
#+date: "2021-07-15 07:45:50 +08:00"
|
||||
#+date_modified: "2021-11-16 19:15:13 +08:00"
|
||||
#+date_modified: "2022-04-20 18:49:17 +08:00"
|
||||
#+language: en
|
||||
|
||||
|
||||
- [[https://github.com/nanotee/nvim-lua-guide][go-to resource when introducing using Lua into Neovim]]
|
||||
- similar to VimL configs, really
|
||||
- init file is =${XDG_CONFIG_HOME}/nvim/init.lua=
|
||||
- Lua configs doesn't configure much by default
|
||||
- you can start with =lua-intro= help section in the =lua= help page from Neovim — i.e., =:h lua=
|
||||
- you can still execute Vimscript with =vim.cmd=;
|
||||
more information is at =:h lua-vimscript=
|
||||
- basics from VimL
|
||||
+ to set options, it's mostly in =vim.opt= — e.g., ~set number relativenumber~ versus ~vim.opt.number, vim.opt.relativenumber = true, true~
|
||||
+ highlight options are mostly in =vim.highlight= — e.g., ~highlight clear SpellCap~ versus ~vim.highlight~
|
||||
+ to set local options, use =vim.opt_local= — e.g., ~setlocal spell~ versus ~vim.opt_local.spell = true~
|
||||
+ otherwise, to set global options, use =vim.opt_global=
|
||||
+ you can access environment variables through =vim.env= — e.g., ~vim.env.HOME~, ~vim.env.MYVIMRC~
|
||||
+ you can manipulate variables of various scales from =vim.{g,b,t}=;
|
||||
to see more details, see =lua-vim-variables= help section
|
||||
+ =vim.opt= will return an Option object, it has a common API;
|
||||
to learn more about it, see =vim.opt= and its subsections
|
||||
+ to run Vimscript, you can use =vim.cmd= — e.g., ~vim.cmd "colorscheme nord"~
|
||||
+ interacting with Neovim API through =vim.api=
|
||||
- there are Neovim configurations written in Lua
|
||||
+ [[https://github.com/mjlbach/defaults.nvim][defaults.nvim]]
|
||||
- with Lua integration, you can create [[id:bdcff35e-15e1-4539-9c4e-5fdd5b978c26][Neovim Lua modules]]
|
||||
- you can start with =lua-intro= section from [[id:0a0fe63e-dcf3-4928-9e82-5513784c1244][Neovim help system]];
|
||||
it gives all of the information on the things you need to get started with configuring Neovim with Lua as well as pointers for more things to do with Lua;
|
||||
- Neovim also extends the Lua standard library found in =vim= object;
|
||||
see the =lua-stdlib= in [[id:0a0fe63e-dcf3-4928-9e82-5513784c1244][Neovim help system]]
|
||||
- comprehensive examples include Neovim plugins that are already written in Lua
|
||||
+ [[https://github.com/savq/paq-nvim][paq-nvim]] is a simple Neovim package manager
|
||||
+ [[https://github.com/wbthomason/packer.nvim][packer.nvim]] is a more comprehensive package manager
|
||||
+ [[https://github.com/L3MON4D3/LuaSnip][LuaSnip]] is a snippet engine
|
||||
+ [[https://github.com/nvim-telescope/telescope.nvim][telescope.nvim]] is a fuzzy finder integrated inside Neovim
|
||||
- for more information to create Lua modules, see =lua-require-example= help section
|
||||
|
||||
|
||||
|
||||
|
||||
* Setting configuration with Lua
|
||||
- you can still execute Vimscript with =vim.cmd=;
|
||||
more information is at =:h lua-vimscript=
|
||||
- to set options, it's mostly in =vim.opt= — e.g., ~set number relativenumber~ versus ~vim.opt.number, vim.opt.relativenumber = true, true~
|
||||
- highlight options are mostly in =vim.highlight= — e.g., ~highlight clear SpellCap~ versus ~vim.highlight~
|
||||
- to set local options, use =vim.opt_local= — e.g., ~setlocal spell~ versus ~vim.opt_local.spell = true~
|
||||
- otherwise, to set global options, use =vim.opt_global=
|
||||
- you can access environment variables through =vim.env= — e.g., ~vim.env.HOME~, ~vim.env.MYVIMRC~
|
||||
- you can manipulate variables of various scales from =vim.{g,b,t}=;
|
||||
to see more details, see =lua-vim-variables= help section
|
||||
- =vim.opt= will return an Option object, it has a common API;
|
||||
to learn more about it, see =vim.opt= and its subsections
|
||||
- to run Vimscript, you can use =vim.cmd= — e.g., ~vim.cmd "colorscheme nord"~
|
||||
- interacting with Neovim API through =vim.api=
|
||||
|
14
notebook/lang.lua.modules.org
Normal file
14
notebook/lang.lua.modules.org
Normal file
@ -0,0 +1,14 @@
|
||||
:PROPERTIES:
|
||||
:ID: ffb8b08a-ca0a-48a4-bebc-d2bf11aa5ccf
|
||||
:END:
|
||||
#+title: Lua modules
|
||||
#+date: 2022-04-20 18:36:59 +08:00
|
||||
#+date_modified: 2022-04-20 18:37:17 +08:00
|
||||
#+language: en
|
||||
|
||||
|
||||
- for future references, this is documented from the [[https://www.lua.org/manual][Lua manual]]
|
||||
- to use the modules from =lua=, you can call =require= builtin;
|
||||
the ~require~'d module are stored in a table =packages.loaded= and its content will be loaded inside of a function;
|
||||
the module will only load once and it will only cache the return value
|
||||
- to unload a module, you can set the package from the package table to null (i.e., ~nil~)
|
@ -3,7 +3,7 @@
|
||||
:END:
|
||||
#+title: Oil shell language
|
||||
#+date: "2021-05-09 16:40:50 +08:00"
|
||||
#+date_modified: "2021-07-28 10:52:44 +08:00"
|
||||
#+date_modified: "2022-04-16 20:18:16 +08:00"
|
||||
#+language: en
|
||||
#+property: header-args:oil :eval no
|
||||
|
||||
@ -21,7 +21,7 @@ Ripping off from the [[https://www.oilshell.org/blog/2020/01/simplest-explanatio
|
||||
Oil is also aimed at people who know say Python or JavaScript, but purposely avoid shell.
|
||||
#+end_quote
|
||||
|
||||
A modern shell attempting the replace Bash slowly.
|
||||
A modern shell attempting the replace [[id:dd9d3ffa-03ff-42a1-8c5d-55dc9fcc70fe][GNU Bash]] slowly.
|
||||
The project has an ambitious goal with a wide scope.
|
||||
It is known for its [[https://oilshell.org/blog][shell-oriented blog]] and the developer is very responsive and active with shell-related posts.
|
||||
|
||||
@ -107,7 +107,7 @@ If you want splitting, you could use =split= Oil function — e.g., ~@split(arra
|
||||
Arrays are mostly similar to Bash arrays except you have more options.
|
||||
|
||||
- You can create a heterogenous list containing different types of data — e.g., ~var a = ['Dogs', 24, true ]~.
|
||||
Useful for JSON compatability.
|
||||
Useful for JSON compatibility.
|
||||
|
||||
- A homogenous array is useful for data consistency.
|
||||
It can accept a list of data of the same type — e.g., ~var b = %("foo" "bar" "baz")~.
|
||||
|
@ -3,16 +3,18 @@
|
||||
:END:
|
||||
#+title: systemd environment directives
|
||||
#+date: 2021-08-07 19:58:29 +08:00
|
||||
#+date_modified: 2021-08-07 19:59:45 +08:00
|
||||
#+date_modified: 2022-04-16 20:19:15 +08:00
|
||||
#+language: en
|
||||
|
||||
|
||||
systemd enables setting the environment through environment directives.
|
||||
|
||||
Just like how [[id:c7edff80-6dea-47fc-8ecd-e43b5ab8fb1e][systemd at user-level]], you can set it at user-level by placing them in certain user-level load paths (e.g., =$XDG_CONFIG_HOME/environment.d=).
|
||||
For some, this is a nice shell-agnostic way of setting environment variables and could replace setting through shell profiles (i.e., =.bashrc=, =.profile=).
|
||||
|
||||
It needs a =*.conf= file in one of the load paths (seen from the =environment.d.5= manual page).
|
||||
Keep in mind it does not use the shell and instead makes use of shell-like syntax.
|
||||
Just like how [[id:c7edff80-6dea-47fc-8ecd-e43b5ab8fb1e][systemd at user-level]], you can set it at user-level by placing them in certain user-level load paths (e.g., =$XDG_CONFIG_HOME/environment.d=).
|
||||
|
||||
Keep in mind it does not use the shell directly and instead makes use of shell-like syntax.
|
||||
The syntax takes variable substitutions and parameter expansion seen from [[id:dd9d3ffa-03ff-42a1-8c5d-55dc9fcc70fe][GNU Bash]].
|
||||
|
||||
The following code block is an example of setting Nix-related environment variables to enable desktop integrations.
|
||||
|
||||
|
@ -3,7 +3,7 @@
|
||||
:END:
|
||||
#+title: systemd
|
||||
#+date: "2021-05-20 22:37:22 +08:00"
|
||||
#+date_modified: "2022-01-03 22:03:26 +08:00"
|
||||
#+date_modified: "2022-04-19 20:21:56 +08:00"
|
||||
#+language: en
|
||||
#+property: header-args :eval no
|
||||
|
||||
@ -21,6 +21,7 @@ Among other things, it has the following list of features.
|
||||
- [[id:e4dba4ef-71dd-4d30-9a2c-4ad97223510b][systemd-networkd]] is the network configuration manager in case you want to do [[id:a208dd50-2ebc-404d-b407-3ec2f556535e][Network configuration in Linux]].
|
||||
- [[id:8505f1f0-f15b-4b04-91fc-12be01913ce6][systemd-boot]] is a bootloader mainly for UEFI-based systems.
|
||||
- [[id:d83c099a-fc11-4ccc-b265-4de97c85dcbe][systemd-journald]] is the system logging service providing a structured way to manage your logs from different units.
|
||||
- [[id:7fce893f-418f-42aa-b2b1-59d9f0993406][systemd unit hardening]] can help your services secure.
|
||||
|
||||
|
||||
|
||||
@ -58,5 +59,7 @@ systemctl --user start $SERVICE
|
||||
Also contains the related manual pages for a deeper references.
|
||||
[fn:: How did I pass a year without knowing this?]
|
||||
|
||||
- On a similar note, =systemd.index.7= is an alphabetical index of the important keywords found in systemd.
|
||||
|
||||
- =systemd.mount= units require the filename to be the mountpoint.
|
||||
Though, it has to be converted to what systemd accepts (e.g., =systemd-escape --path $PATH=).
|
||||
|
@ -3,20 +3,40 @@
|
||||
:END:
|
||||
#+title: systemd timers
|
||||
#+date: 2021-07-19 21:45:47 +08:00
|
||||
#+date_modified: 2021-08-07 19:29:15 +08:00
|
||||
#+date_modified: 2022-04-16 19:37:37 +08:00
|
||||
#+language: en
|
||||
|
||||
|
||||
You can schedule tasks with timers.
|
||||
If systemd is compiled with the feature, it makes cron unnecessary.
|
||||
|
||||
|
||||
|
||||
|
||||
* Timer management
|
||||
|
||||
In a fully-installed systemd-enabled system, there are multiple ways to manage your timers.
|
||||
|
||||
While managing them is practically the same as any other units (see [[id:20830b22-9e55-42a6-9cef-62a1697ea63d][systemd]]), there are timer-specific ways to manage them easier.
|
||||
|
||||
- ~systemctl list-timers~ is the go-to command that displays an overview of all active timers.
|
||||
Just give the =--all= flag to list all timers including disabled timers.
|
||||
|
||||
- ~systemctl status ${TIMER_UNIT}~ is another way for a specific timer unit.
|
||||
It gives the same details as the =list-timers= subcommand so you'll rarely use this subcommand in practice.
|
||||
|
||||
|
||||
|
||||
|
||||
* Timedate formats
|
||||
|
||||
systemd has different ways to denote time.
|
||||
|
||||
- Timespans denote the duration — e.g., =100 seconds=, =5M 3w=.
|
||||
- Timestamps refer to a specific point in time — e.g., =2021-04-02=, =today=, =now=.
|
||||
- Calendar events can refer to more than one point of time — e.g., =*-*-4/2=, =Sun,Wed,Fri *-1/2-1/8=.
|
||||
|
||||
To find more details about time notation, you can view the =systemd.time.5= manual page.
|
||||
To find more details about time notation, you can view the =systemd.time.7= manual page.
|
||||
|
||||
Here's an example of setting a timer for an example backup service.
|
||||
The following timer unit sets it to execute every day at 18:00.
|
||||
|
@ -3,13 +3,13 @@
|
||||
:END:
|
||||
#+title: systemd transient units
|
||||
#+date: 2021-08-02 12:01:49 +08:00
|
||||
#+date_modified: 2021-08-02 12:05:06 +08:00
|
||||
#+date_modified: 2022-04-16 20:01:51 +08:00
|
||||
#+language: en
|
||||
|
||||
|
||||
You can create units on-the-go with =systemd-run=.
|
||||
Very useful for quickly creating and scheduling one-off services.
|
||||
This tool involves [[id:cd5f0d04-d9bb-44e8-a0f2-630ea58c1e94][systemd services]] and [[id:f1b21fc8-86a5-47cd-b3d8-da6ac7a34427][systemd timers]].
|
||||
This tool mainly involves [[id:cd5f0d04-d9bb-44e8-a0f2-630ea58c1e94][systemd services]] and [[id:f1b21fc8-86a5-47cd-b3d8-da6ac7a34427][systemd timers]].
|
||||
|
||||
Like most systemd-related binaries, this can be run at system- and user-level (see [[id:c7edff80-6dea-47fc-8ecd-e43b5ab8fb1e][systemd at user-level]]).
|
||||
|
||||
@ -23,3 +23,5 @@ systemd-run --user borg-backup@external-drive.service --on-calendar=12:00
|
||||
|
||||
The result should give you the generated name of the unit.
|
||||
Then, they can be managed like an ordinary unit.
|
||||
Unit generated this way will persist until the next boot.
|
||||
If you want to manage them on a permanent basis, create the appropriate unit files for them.
|
||||
|
32
notebook/linux.systemd.unit-hardening.org
Normal file
32
notebook/linux.systemd.unit-hardening.org
Normal file
@ -0,0 +1,32 @@
|
||||
:PROPERTIES:
|
||||
:ID: 7fce893f-418f-42aa-b2b1-59d9f0993406
|
||||
:END:
|
||||
#+title: systemd unit hardening
|
||||
#+date: 2022-04-19 20:19:26 +08:00
|
||||
#+date_modified: 2022-04-19 20:21:27 +08:00
|
||||
#+language: en
|
||||
|
||||
|
||||
- main command to interact is ~systemd-analyze security~;
|
||||
this will give a list of units along with their exposure score (lower is better);
|
||||
- take note the goal to a 1.0 score shouldn't be taken as a goal since not all units need are the same;
|
||||
security, after all, is about mitigating against your threat model
|
||||
- the only unit possible to attain the lowest score is a simple "Hello world" program or similar so don't go for a 1.0
|
||||
- several systemd unit options are only available in certain units such as system services
|
||||
- here is a list of sandboxing-related options;
|
||||
for more information, see ~systemd.exec.5~ manual page
|
||||
- ~ProtectHome~ will restrict process to interact with ~/home~, ~/root~, and ~/run/user~;
|
||||
can accept a boolean or certain values: ~read-only~ will set certain directories to read-only and ~tmpfs~ will mount the temporary filesystems to the directories as read-only;
|
||||
- ~ProtectControlGroups~ will make the control group filesystem (i.e., ~/sys/fs/cgroup~) to read-only
|
||||
- ~PrivateUsers~, if enabled, will run the processes through another user
|
||||
- ~ProtectClock~ prohibits interacting with the system clock
|
||||
- ~ProtectKernelModules~ restricts loading of kernel modules
|
||||
- ~ProtectKernelLogs~ prevents logging into the kernel ring buffer
|
||||
- ~PrivateTmp~ will create a new temporary filesystem for the unit
|
||||
- ~PrivateNetwork~ will create a new set of network devices only composing of a loopback network device;
|
||||
this will disallow network access and thus should only use for processes with no business with network access
|
||||
- ~PrivateDevices~ will create a new set of devices with only the pseudo-devices (e.g., ~/dev/null~, ~/dev/zero~);
|
||||
this will restrict device access and should be used for processes with no device access
|
||||
- extra resources
|
||||
- [[https://www.ctrl.blog/entry/systemd-service-hardening.html][systemd service hardening]] from ctrl.blog
|
||||
- also, a [[https://www.ctrl.blog/entry/systemd-opensmtpd-hardening.html][follow-up post that uses a real-life example for service hardening a web server with recent exploits]]
|
Loading…
Reference in New Issue
Block a user