aboutsummaryrefslogtreecommitdiffstats
path: root/modules/Working
diff options
context:
space:
mode:
Diffstat (limited to 'modules/Working')
-rw-r--r--modules/Working/pages/apk.adoc28
-rw-r--r--modules/Working/pages/openrc.adoc24
-rw-r--r--modules/Working/pages/post-install.adoc5
3 files changed, 15 insertions, 42 deletions
diff --git a/modules/Working/pages/apk.adoc b/modules/Working/pages/apk.adoc
index 67cd450..f77c470 100644
--- a/modules/Working/pages/apk.adoc
+++ b/modules/Working/pages/apk.adoc
@@ -1,15 +1,13 @@
-= Working with the Alpine Package Keeper (`apk`)
// MAINT: apk-tools - whole page
+= Working with the Alpine Package Keeper (`apk`)
`apk` is the Alpine Package Keeper - the distribution's package manager.
It is used to manage the packages (software and otherwise) of the system.
It is the primary method for installing additional software, and is available in the `apk-tools` package.
== Normal Usage
-
-=== Repositories and Mirrors
// MAINT: repositories and versions
-
+=== Repositories and Mirrors
`apk` fetches information about available packages, as well as the packages themselves from various mirrors, which contain various repositories.
Sometimes, those terms are used interchangeably.
Here is a summary of relevant definitions:
@@ -54,9 +52,8 @@ NOTE: This example uses the `http://` protocol. `ftp://` and `https://` protocol
// TODO: xref to installation part that's relevant
NOTE: This file should already have been been partially populated when you installed alpine.
-=== Searching for Packages
// MAINT: apk-search and pkgs.alpinelinux.org
-
+=== Searching for Packages
In order to know what package to install, one must be able to find packages.
Alpine has a specialized https://pkgs.alpinelinux.org[web interface] dedicated to looking through various available packages.
However, `apk` also provides a built-in searching mechanism.
@@ -78,9 +75,8 @@ apk search -e so:libsqlite3.so.* <4>
<3> You can exclude partial matches using `-e`.
<4> You can specify that what you're searching for is a library using the `so:` prefix (or the `cmd:` prefix for commands, and `pc:` prefix for pkg-config files) - it will work with `-e` (in fact, the prefix is required for this use-case if `-e` is used).
-=== Installing Packages
// MAINT: apk-add
-
+=== Installing Packages
Once you know what package you want to install, you must know how to do that.
Apk's `add` command is more strict than the `search` command - wildcards are not available, for instance.
// TODO: gotchas, already asked in #a-docs
@@ -117,9 +113,8 @@ apk add pc:msgpack <5>
NOTE: If `apk add` finds multiple matching packages (for example multiple `cmd:` matches), it will select the one with the highest version number.
-=== Upgrading Packages
// MAINT: apk-update, apk-upgrade
-
+=== Upgrading Packages
Updating the system using apk is very simple.
One need only run `apk upgrade`.
Technically, this is two steps: `apk update`, followed by `apk upgrade` proper.
@@ -134,9 +129,8 @@ Simply invoking it normally with present you with the difference between the two
NOTE: `apk update` is only ran once your cache is invalidated, which by default happens every 4 hours.
-=== Querying Package Information
// MAINT: apk-info
-
+=== Querying Package Information
In some cases, it may be useful to inspect packages or files to see various details.
For this use, the `info` subcommand exists.
It may be used on any package, installed or not, though the information on the latter will be more limited.
@@ -146,9 +140,8 @@ By default, `info` will list the package description, webpage and installed size
// MAINT: apk-info: `apk info -h` output
For more details (such as a list of flags the subcommand supports), you can use the `apk info -h` output's "Info options" section or see the manual page.
-=== Removing Packages
// MAINT: apk-del
-
+=== Removing Packages
Often, it is desirable to remove a package.
This can be done using the `del` subcommand, with a base syntax that is identical to the `add` subcommand.
@@ -159,7 +152,6 @@ NOTE: Removing a package will automatically remove all of its dependencies that
The `del` subcommand also supports the `-r` flag, which will remove all packages that depend on the package being removed as well, rather than error out due to the package being needed.
=== Cleanup
-
Many package managers have specific features to "clean up".
A common one is `apt`, which has an `autoremove` subcommand.
Apk does this by default when removing packages.
@@ -168,18 +160,15 @@ It is also possible to clear out the apk cache, assuming it is enabled.
You can do this using `apk cache clean`.
== Advanced Usage
-
=== World
-
The packages you want to have explicitly installed are listed in the "world file", available in `/etc/apk/world`.
It is safe to edit it by hand.
If you've edited it by hand, you may run `apk add` with no arguments to bring the package selection to a consistent state.
NOTE: Virtuals like `cmd:`, `so:` and `pc:` will appear as such in your world file - this is why using `so:` is discouraged - the soname might get bumped!
-=== Virtuals
// MAINT: apk-add -t
-
+=== Virtuals
While `cmd:`, `so:` and `pc:` packages are automatically created virtuals, you can create your own as well.
These allow for quick removal of purpose-specific packages.
See the following examples for details:
@@ -194,7 +183,6 @@ apk add a b c --virtual abc <3>
<3> This is equivalent to the first example.
=== Swapping Repositories
-
When alpine has a new release, the repository path will change.
Assuming you are going forward in time (e.g from `3.8` to `3.9`), you can simply edit `/etc/apk/repositories` and run `apk upgrade --available`.
diff --git a/modules/Working/pages/openrc.adoc b/modules/Working/pages/openrc.adoc
index 9fe464c..3c617f9 100644
--- a/modules/Working/pages/openrc.adoc
+++ b/modules/Working/pages/openrc.adoc
@@ -1,5 +1,5 @@
-= Working with OpenRC
// MAINT: openrc, whole page
+= Working with OpenRC
OpenRC is the init system used in alpine.
The init system manages the services, startup and shutdown of your computer.
@@ -13,12 +13,9 @@ If in doubt, use the canonical name, as is shown in this document.
====
== Normal Usage
-
=== Manipulating Services
-
+// MAINT: openrc, whole page
==== Runtime Service Manipulation
-// MAINT: rc-service
-
You manipulate services on a running system using the `rc-service` command.
This allows you to start, stop, and check the status of a given service, amongst other things.
See the following basic examples:
@@ -47,9 +44,8 @@ Only run the specified command if the service is currently started.
NOTE: Services may define additional commands you can use. See more on this in <<_custom_service_commands>>.
-==== On-Boot Service Manipulation
// MAINT: rc-update
-
+==== On-Boot Service Manipulation
OpenRC operates under a system called "runlevels".
More on that in <<_switching_runlevels>> and <<_custom_runlevels>>.
Enabling a service means putting it in a runlevel, usually one that will get loaded automatically (but not necessarily so!).
@@ -72,16 +68,14 @@ rc-update delete chronyd -a <5>
<5> Remove the chronyd service from all runlevels.
=== Configuring Services
-
Various services may need additional configuration.
Most will have dedicated configuration files in `/etc` - you can see documentation on the specific service for more details.
However, some services need configuration applied to them as part of the launch procedure - such as passing a flag to the binary when first started.
This can be done in the `/etc/conf.d` directory, under the name of the service in question.
For example, for a service named "base", the configuration file would be `/etc/conf.d/base`.
-=== System Status
// MAINT: rc-status
-
+=== System Status
The `rc-status` utility is a fast way to view the current state of your system's services.
By default, it will list all the services in the current runlevel.
You can select a different runlevel by specifying it, for instance, `rc-status boot` will list all the services in the boot runlevel.
@@ -110,7 +104,6 @@ For example, adding the `sshd` service to the `default` runlevel is creating a s
Creating a new runlevel thus involves creating a new directory under `/etc/runlevels`.
==== Runlevel Stacking
-
Most of the time, you do not want to shut down all of your `default` services if you're switching to the `office` runlevel.
Runlevel "inheritance" is acheived through runlevel stacking.
If you pass the `-s` flag to `rc-update`, you can actually add a runlevel to a runlevel.
@@ -124,17 +117,14 @@ rc-update add myvpn office
----
==== Switching Runlevels
-
Once you have a custom runlevel you want to switch to, you can do so using the `openrc` command.
As per the above example, you would use `openrc office` to switch to your new runlevel, and `openrc default` to switch back.
-=== System Configuration
// TODO: expand
-
+=== System Configuration
System-wide configuration of OpenRC happens in `/etc/rc.conf`.
=== Multi-Services
-
In some cases, you may want the same bit of code to do different things under different circumstances.
For example, normally, the difference between various instances of `agetty` are just the tty they run on.
In these cases, you can use symlinks to manage dynamic configuration differences.
@@ -146,16 +136,14 @@ The intended way to use this is by symlinking the "base" service (`agetty`) to t
This mechanism also allows you to specify custom configuration for that service, for more details, see <<_extended_conf_d_names>>.
=== Custom Service Commands
-
Commands other than `start`, `stop` and `status` may be available.
A common example is `save`, used by `iptables`.
Their usage is identical to that of the built-in ones.
You can look inside the `init.d` script at various `extra*commands` variables which give a listing of the available ones.
// TODO: what's extra_started_commands etc?
-=== Extended `conf.d` Names
// MAINT: the insanity in sh/opnenrc-init.sh.in
-
+=== Extended `conf.d` Names
There are 4 total files that may play a role in the configuration of a service.
Assume that `base` stands for the name of the base server, `ext` is the extension (as per <<_multi_services>>) and `runlevel` is the runlevel it's in.
Under those conditions, the files involved are:
diff --git a/modules/Working/pages/post-install.adoc b/modules/Working/pages/post-install.adoc
index cf7c23a..2584e63 100644
--- a/modules/Working/pages/post-install.adoc
+++ b/modules/Working/pages/post-install.adoc
@@ -5,7 +5,6 @@ The following sections will provide a list of general recommendations to ease yo
The remaining sections will describe how to use (on a user level) various Alpine-native solutions, such as the package manager, firewall, and so on.
== Creating a Normal User
-
Now that you are up and running, you will want a normal, non-root user to perform most daily tasks with.
You can either use the built-in busybox utility `adduser`, or the utility available in the `shadow` package named `useradd`.
@@ -26,7 +25,6 @@ useradd -m -U -s /bin/ash jane <1>
Once your user has been created, if the utility you used has not asked you to set a password, you should do so now, using `passwd foo`, where "foo" is the username in question.
== Granting Your User Administrative Access
-
Sometimes, you'll want to do something that *does* require administrative powers.
While you may switch to a different tty and log in as root, this is often inconvenient.
You may gain root privileges ad-hoc using either the built-in busybox utility `su`, or the common external utility `sudo`, available in the package named the same way.
@@ -58,9 +56,8 @@ sudo command with arguments <5>
<4> You may need to log out and log back in for the group listing to update. `sudo -i` is the equivalent of `su -` otherwise.
<5> This will run "command with arguments" as the default `sudo` user - root.
-== Getting a Graphical Environment
// MAINT: alpine-desktop, alpine-conf (setup-xorg-base)
-
+== Getting a Graphical Environment
Most people will often want something more than just a raw tty.
This section describes how to get a supported graphical interface, as well as some additional notes (for example, how to use a different type of GUI).