https://wiki.archlinux.org/api.php?action=feedcontributions&user=Bitfehler&feedformat=atomArchWiki - User contributions [en]2024-03-29T09:57:09ZUser contributionsMediaWiki 1.41.0https://wiki.archlinux.org/index.php?title=Linux_console&diff=778095Linux console2023-05-15T18:07:59Z<p>Bitfehler: /* Persistent configuration */ Fix configuration file mix-up - the font is specified in vconsole.conf</p>
<hr />
<div>[[Category:Linux console]]<br />
[[es:Linux console]]<br />
[[ja:Linux コンソール]]<br />
[[pt:Linux console]]<br />
[[ru:Linux console]]<br />
[[zh-hans:Linux console]]<br />
{{Related articles start}}<br />
{{Related|/Keyboard configuration}}<br />
{{Related|Screen capture#Virtual console}}<br />
{{Related|Color output in console}}<br />
{{Related|getty}}<br />
{{Related articles end}}<br />
<br />
According to [[Wikipedia:Linux console|Wikipedia]]:<br />
<br />
:The '''Linux console''' is a system console internal to the [[Linux kernel]]. The Linux console provides a way for the kernel and other processes to send text output to the user, and to receive text input from the user. The user typically enters text with a computer keyboard and reads the output text on a computer monitor. The Linux kernel supports virtual consoles — consoles that are logically separate, but which access the same physical keyboard and display.<br />
<br />
This article describes the basics of the Linux console and how to configure the font display. Keyboard configuration is described in the [[/Keyboard configuration]] subpage.<br />
<br />
== Implementation ==<br />
<br />
{{Expansion|In what ways is the Linux console limited compared to terminal emulators?}}<br />
<br />
The console, unlike most services that interact directly with users, is implemented in the kernel. This contrasts with terminal emulation software, such as [[Xterm]], which is implemented in user space as a normal application. The console has always been part of released Linux kernels, but has undergone changes in its history, most notably the transition to using the [[Wikipedia:Linux framebuffer|framebuffer]] and support for [[Wikipedia:Unicode|Unicode]].<br />
<br />
Despite many improvements in the console, its full backward compatibility with legacy hardware means it is limited compared to a graphical terminal emulator.<br />
<br />
=== Virtual consoles ===<br />
<br />
The console is presented to the user as a series of [[Wikipedia:Virtual console|virtual consoles]]. These give the impression that several independent terminals are running concurrently; each virtual console can be logged in with different users, run its own shell and have its own font settings. The virtual consoles each use a device {{ic|/dev/ttyX}}, and you can switch between them by pressing {{ic|Alt+F''x''}} (where {{ic|''x''}} is equal to the virtual console number, beginning with 1). The device {{ic|/dev/console}} is automatically mapped to the active virtual console.<br />
<br />
See also {{man|1|chvt}}, {{man|1|openvt}} and {{man|1|deallocvt}}.<br />
<br />
=== Text mode ===<br />
<br />
Since Linux originally began as a kernel for PC hardware, the console was developed using standard IBM [[Wikipedia:VGA|CGA/EGA/VGA]] graphics, which all PCs supported at the time. The graphics operated in VGA text mode, which provides a simple 80x25 character display with 16 colours. This legacy mode is similar to the capabilities of dedicated text terminals, such as the [[Wikipedia:VT100|DEC VT100]] series. It is still possible to boot in text mode (with {{ic|1=vga=0 nomodeset}}) if the system hardware supports it, but almost all modern distributions (including Arch Linux) use the framebuffer console instead.<br />
<br />
=== Framebuffer console ===<br />
<br />
As Linux was ported to other non-PC architectures, a better solution was required, since other architectures do not use VGA-compatible graphics adapters, and may not support text modes at all. The framebuffer console was implemented to provide a standard console across all platforms, and so presents the same VGA-style interface regardless of the underlying graphics hardware. As such, the Linux console is not a terminal emulator, but a terminal in its own right. It uses the terminal type {{ic|linux}}, and is largely compatible with VT100.<br />
<br />
== Keyboard shortcuts ==<br />
<br />
{| class="wikitable"<br />
! Keyboard Shortcut<br />
! Description<br />
|-<br />
| {{ic|Ctrl+Alt+Del}}<br />
| Reboots the system (specified by the symlink {{ic|/usr/lib/systemd/system/ctrl-alt-del.target}})<br />
|-<br />
| {{ic|Alt+F1}}, {{ic|F2}}, {{ic|F3}}, ...<br />
| Switch to ''n''-th virtual console<br />
|-<br />
| {{ic|Alt+Left}}<br />
| Switch to previous virtual console<br />
|-<br />
| {{ic|Alt+Right}}<br />
| Switch to next virtual console<br />
|-<br />
| {{ic|Scroll Lock}}<br />
| When Scroll Lock is activated, input/output is locked<br />
|-<br />
| {{ic|Ctrl+c}}<br />
| Kills current task<br />
|-<br />
| {{ic|Ctrl+d}}<br />
| Inserts an EOF<br />
|-<br />
| {{ic|Ctrl+z}}<br />
| Pauses current Task<br />
|}<br />
<br />
See also {{man|4|console_codes}}.<br />
<br />
== Fonts ==<br />
<br />
{{Note|This section is about the [[Wikipedia:Linux console|Linux console]]. For alternative console solutions offering more features (full Unicode fonts, modern graphics adapters etc.), see [[KMSCON]] or similar projects.}}<br />
<br />
The [[Wikipedia:Linux console|Linux console]] uses UTF-8 encoding by default, but because the standard VGA-compatible framebuffer is used, a console font is limited to either a standard 256, or 512 glyphs. If the font has more than 256 glyphs, the number of colours is reduced from 16 to 8. In order to assign correct symbol to be displayed to the given Unicode value, a special translation map, often called ''unimap'', is needed. Nowadays, most of the console fonts have the ''unimap'' built-in; historically, it had to be loaded separately.<br />
<br />
By default, the [[Wikipedia:Virtual console|virtual console]] uses the kernel built-in font with a [[Wikipedia:CP437|CP437]] character set[https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/tty/vt/Makefile#n5], but this can be easily changed. The kernel offers about 15 built in fonts to choose from, from which the [[Kernel#Officially supported kernels|officially supported kernels]] provide two: VGA 8x16 font ({{ic|CONFIG_FONT_8x16}}) and Terminus 16x32 font ({{ic|CONFIG_FONT_TER16x32}}). The kernel chooses the one to use based on its evaluation of the screen resolution. Another builtin font can be forced upon by [[kernel parameters]] boot parameter setting such as {{ic|1=fbcon=font:TER16x32}}.<br />
<br />
The {{Pkg|kbd}} package provides tools to override the kernel decision for virtual console font and font mapping. Available fonts are provided in the {{ic|/usr/share/kbd/consolefonts/}} directory; those ending with ''.psfu'' or ''.psfu.gz'' have a Unicode translation map built-in.<br />
<br />
Keymaps, the connection between the key pressed and the character used by the computer, are found in the subdirectories of {{ic|/usr/share/kbd/keymaps/}}; see [[/Keyboard configuration]] for details.<br />
<br />
{{Note|Replacing the font can cause issues with programs that expect a standard VGA-style font, such as those using line drawing graphics.}}<br />
<br />
{{Tip|For European based languages written in Latin/Greek letters, you can use the {{ic|eurlatgr}} font. It includes a broad range of Latin/Greek letter variations as well as<br />
special characters [https://lists.altlinux.org/pipermail/kbd/2014-February/000439.html].}}<br />
<br />
=== Preview and temporary changes ===<br />
<br />
{{Tip|An organized library of images for previewing is available: [https://adeverteuil.github.io/linux-console-fonts-screenshots/ Linux console fonts screenshots].}}<br />
<br />
$ showconsolefont<br />
<br />
shows a table of glyphs or letters of a font.<br />
<br />
{{ic|setfont}} temporarily change the font if passed a font name (in {{ic|/usr/share/kbd/consolefonts/}}) such as<br />
<br />
$ setfont lat2-16 -m 8859-2<br />
<br />
Font names are case-sensitive. With no parameter, {{ic|setfont}} returns the console to the default font.<br />
<br />
So to have a '''small 8x8''' font, with that font installed like seen below, use e.g.:<br />
<br />
$ setfont -h8 /usr/share/kbd/consolefonts/drdos8x8.psfu.gz<br />
<br />
To have a '''bigger''' font, the Terminus font ({{Pkg|terminus-font}}) is available in many sizes, such as {{ic|ter-132b}} which is large.<br />
<br />
{{Tip|All font changing commands can be typed in "blind".}}<br />
<br />
{{Note|''setfont'' only works on the console currently being used. Any other consoles, active or inactive, remain unaffected.}}<br />
<br />
=== Persistent configuration ===<br />
<br />
The {{ic|FONT}} variable in {{ic|/etc/vconsole.conf}} is used to set the font at boot, persistently for all consoles. See {{man|5|vconsole.conf}} for details.<br />
<br />
For displaying characters such as ''Č, ž, đ, š'' or ''Ł, ę, ą, ś'' using the font {{ic|lat2-16.psfu.gz}}:<br />
<br />
{{hc|/etc/vconsole.conf|2=<br />
...<br />
FONT=lat2-16<br />
FONT_MAP=8859-2<br />
}}<br />
<br />
It means that second part of ISO/IEC 8859 characters are used with size 16. You can change font size using other values (e.g. {{ic|lat2-08}}). For the regions determined by 8859 specification, look at the [[Wikipedia:ISO/IEC 8859#The parts of ISO/IEC 8859]].<br />
<br />
Since [https://gitlab.archlinux.org/archlinux/mkinitcpio/mkinitcpio/-/blob/v33/mkinitcpio.conf#L52 mkinitcpio v33], the font specified in {{ic|/etc/vconsole.conf}} gets automatically loaded during early userspace by default via the {{ic|consolefont}} hook, which adds the font to the initramfs. See [[Mkinitcpio#HOOKS]] for more information.<br />
<br />
You may also need to [[restart]] {{ic|systemd-vconsole-setup.service}} after changing {{ic|/etc/vconsole.conf}}.<br />
<br />
If the fonts appear to not change on boot, or change only temporarily, it is most likely that they got reset when graphics driver was initialized and console was switched to framebuffer. By default, all in-tree kernel drivers are loaded early, NVIDIA users should see [[NVIDIA#Early loading]] to load their graphics driver before {{ic|/etc/vconsole.conf}} is applied.<br />
<br />
== HiDPI ==<br />
<br />
See [[HiDPI#Linux console (tty)]].<br />
<br />
== Audible tones ==<br />
<br />
See [[PC speaker#Beep]].<br />
<br />
== See also ==<br />
<br />
* [https://www.linusakesson.net/programming/tty/ The TTY demystified – Linus Åkesson]</div>Bitfehlerhttps://wiki.archlinux.org/index.php?title=Security&diff=653422Security2021-02-25T18:53:03Z<p>Bitfehler: Mention arch-audit in package security. It is a great tool I wish I would have found when first reading this section.</p>
<hr />
<div>[[Category:Security]]<br />
[[Category:File systems]]<br />
[[Category:Networking]]<br />
[[de:Sicherheit]]<br />
[[es:Security]]<br />
[[fa:امنیت]]<br />
[[hu:Security]]<br />
[[ja:セキュリティ]]<br />
[[pt:Security]]<br />
[[ru:Security]]<br />
[[zh-hans:Security]]<br />
{{Related articles start}}<br />
{{Related|Arch Security Team}}<br />
{{Related|General recommendations}}<br />
{{Related|PAM}}<br />
{{Related|Capabilities}}<br />
{{Related|List of Applications/Security}}<br />
{{Related|Arch package guidelines/Security}}<br />
{{Related articles end}}<br />
This article contains recommendations and best practices for [[Wikipedia:Hardening (computing)|hardening]] an Arch Linux system.<br />
<br />
== Concepts ==<br />
<br />
* It ''is'' possible to tighten security to the point where the system is unusable. Security and convenience must be balanced. The trick is to create a secure ''and'' useful system.<br />
* The biggest threat is, and will always be, the user.<br />
* The [[Wikipedia:Principle of least privilege|principle of least privilege]]: Each part of a system should only be able to access what is strictly required, and nothing more.<br />
* Defense in depth: Security works better in independent layers. When one layer is breached, another should stop the attack.<br />
* Be a little paranoid. And be suspicious. If anything sounds too good to be true, it probably is!<br />
* You can never make a system 100% secure unless you unplug the machine from all networks, turn it off, lock it in a safe, smother it in concrete and never use it.<br />
* Prepare for failure. Create a plan ahead of time to follow when your security is broken.<br />
<br />
== Passwords ==<br />
<br />
Passwords are key to a secure Linux system. They secure your [[Users and groups|user accounts]], [[Data-at-rest encryption|encrypted filesystems]], and [[SSH keys|SSH]]/[[GPG]] keys. They are the main way a computer chooses to trust the person using it, so a big part of security is just about picking secure passwords and protecting them.<br />
<br />
=== Choosing secure passwords ===<br />
<br />
Passwords must be complex enough to not be easily guessed from e.g. personal information, or [[Wikipedia:Password cracking|cracked]] using methods like social engineering or brute-force attacks. The tenets of strong passwords are based on ''length'' and ''randomness''. In cryptography the quality of a password is referred to as its [[Wikipedia:Entropic security|entropic security]]. <br />
<br />
Insecure passwords include those containing:<br />
<br />
* Personally identifiable information (e.g., your dog's name, date of birth, area code, favorite video game)<br />
* Simple character substitutions on words (e.g., {{ic|k1araj0hns0n}}), as modern dictionary attacks can easily work with these<br />
* Root "words" or common strings followed or preceded by added numbers, symbols, or characters (e.g., {{ic|DG091101%}})<br />
* Common phrases or strings of dictionary words (e.g. {{ic|photocopyhauntbranchexpose}}) including with character substitution (e.g. {{ic|Ph0toc0pyh4uN7br@nch3xp*se}}) <br />
* Any of the [[wikipedia:List_of_the_most_common_passwords|most common passwords]]<br />
<br />
The best choice for a password is something long (the longer, the better) and generated from a random source. It is important to use a long password. [https://www.theregister.com/2019/02/14/password_length Weak hash algorithms allow an 8-character password hash to be compromised in just a few hours.]<br />
<br />
Tools like {{Pkg|pwgen}} or {{AUR|apg}} can generate random passwords. However, these passwords can be difficult to memorize. One memorization technique (for ones typed often) is to generate a long password and memorize a minimally secure number of characters, temporarily writing down the full generated string. Over time, increase the number of characters typed - until the password is ingrained in muscle memory and need not be remembered. This technique is more difficult, but can provide confidence that a password will not turn up in wordlists or "intelligent" brute force attacks that combine words and substitute characters.<br />
<br />
One technique for memorizing a password is to use a mnemonic phrase, where each word in the phrase reminds you of the next character in the password.<br />
Take for instance “the girl is walking down the rainy street” could be translated to {{ic|t6!WdtR5}} or, less simply, {{ic|t&6!RrlW@dtR,57}}.<br />
This approach could make it easier to remember a password, but note that the various letters have very different probabilities of being found at the start of words ([[Wikipedia:Letter frequency#Relative frequencies of the first letters of a word in the English language|Wikipedia:Letter frequency]]). <br />
<br />
Another effective technique can be to write randomly generated passwords down and store them in a ''safe'' place, such as in a wallet, purse or document safe. Most people do a generally good job of protecting their physical valuables from attack, and it is easier for most people to understand physical security best practices compared to digital security practices. [https://www.schneier.com/news/archives/2010/11/bruce_schneier_write.html Bruce Schneier has endorsed this technique].<br />
<br />
It is also very effective to combine the mnemonic and random technique by saving long randomly generated passwords with a [[password manager]], which will be in turn accessed with a memorable "master password" that must be used only for that purpose. The master password must be memorized and never saved. This requires the password manager to be installed on a system to easily access the password (which could be seen as an inconvenience or a security feature, depending on the situation). Some password managers also have smartphone apps which can be used to display passwords for manual entry on systems without that password manager installed. Note that a password manager introduces a single point of failure if you ever forget the master password.<br />
<br />
Formerly, it was effective to use a memorable long series of unrelated words as a password. The theory is that if a sufficiently long phrase is used, the gained entropy from the password's length can counter the lost entropy from the use of dictionary words. This [https://xkcd.com/936/ xkcd comic] demonstrates the entropy tradeoff of this method. However, password crackers have caught on to this trick and will generate wordlists containing billions of permutations and variants of dictionary words, reducing the effective entropy of the password.<br />
<br />
See Bruce Schneier's article [https://www.schneier.com/blog/archives/2014/03/choosing_secure_1.html Choosing Secure Passwords], [https://www.iusmentis.com/security/passphrasefaq/ The passphrase FAQ] or [[Wikipedia:Password strength]] for some additional background.<br />
<br />
=== Maintaining passwords ===<br />
<br />
Once you pick a strong password, be sure to keep it safe. Watch out for [[Wikipedia:Keylogger|keyloggers]] (software and hardware), screen loggers, [[Wikipedia:Social engineering (security)|social engineering]], [[Wikipedia:Shoulder surfing (computer security)|shoulder surfing]], and avoid reusing passwords so insecure servers cannot leak more information than necessary. [[List of applications/Security#Password managers|Password managers]] can help manage large numbers of complex passwords: if you are copy-pasting the stored passwords from the manager to the applications that need them, make sure to clear the copy buffer every time, and ensure they are not saved in any kind of log (e.g. do not paste them in plain terminal commands, which would store them in files like {{ic|.bash_history}}).<br />
<br />
As a rule, do not pick insecure passwords just because secure ones are harder to remember. Passwords are a balancing act. It is better to have an encrypted database of secure passwords, guarded behind a key and one strong master password, than it is to have many similar weak passwords. Writing passwords down is perhaps equally effective [https://www.schneier.com/blog/archives/2005/06/write_down_your.html], avoiding potential vulnerabilities in software solutions while requiring physical security.<br />
<br />
Another aspect of the strength of the passphrase is that it must not be easily recoverable from other places.<br />
<br />
If you use the same passphrase for disk encryption as you use for your login password (useful e.g. to auto-mount the encrypted partition or folder on login), make sure that {{ic|/etc/shadow}} either also ends up on an encrypted partition, or uses a strong hash algorithm (i.e. sha512/bcrypt, not md5) for the stored password hash (see [[SHA password hashes]] for more information).<br />
<br />
If you are backing up your password database, make sure that each copy is not stored behind any other passphrase which in turn is stored in it, e.g. an encrypted drive or an authenticated remote storage service, or you will not be able to access it in case of need; a useful trick is to protect the drives or accounts where the database is backed up using a simple cryptographic hash of the master password. Maintain a list of all the backup locations: if one day you fear that the master passphrase has been compromised you will have to change it immediately on all the database backups and the locations protected with keys derived from the master password.<br />
<br />
Version-controlling the database in a secure way can be very complicated: if you choose to do it, you must have a way to update the master password of all the database versions. It may not always be immediately clear when the master password is leaked: to reduce the risk of somebody else discovering your password before you realize that it leaked, you may choose to change it on a periodical basis. If you fear that you have lost control over a copy of the database, you will need to change all the passwords contained in it within the time that it may take to brute-force the master password, according to its entropy.<br />
<br />
=== Password hashes ===<br />
<br />
{{Expansion|Mention [[Wikipedia:Key derivation function|key derivation functions]], in particular PBKDF2, bcrypt and scrypt, how to use them, advantages and disadvantages, especially regarding custom-hardware-based brute-force attacks.|section=Removal of incorrect warning}}<br />
<br />
By default, Arch stores the hashed user passwords in the root-only-readable {{ic|/etc/shadow}} file, separated from the other user parameters stored in the world-readable {{ic|/etc/passwd}} file, see [[Users and groups#User database]]. See also [[#Restricting root]].<br />
<br />
Passwords are set with the '''passwd''' command, which [[Wikipedia:Key stretching|stretches]] them with the [[Wikipedia:Crypt (C)|crypt]] function and then saves them in {{ic|/etc/shadow}}. See also [[SHA password hashes]]. The passwords are also [[Wikipedia:Salt (cryptography)|salted]] in order to defend them against [[Wikipedia:Rainbow table|rainbow table]] attacks.<br />
<br />
See also [http://www.slashroot.in/how-are-passwords-stored-linux-understanding-hashing-shadow-utils How are passwords stored in Linux (Understanding hashing with shadow utils)].<br />
<br />
=== Enforcing strong passwords with pam_pwquality ===<br />
<br />
''pam_pwquality'' provides protection against [[Wikipedia:Dictionary attack|Dictionary attacks]] and helps configure a password policy that can be enforced throughout the system. It is based on ''pam_cracklib'', so it is backwards compatible with its options.<br />
<br />
[[Install]] the {{Pkg|libpwquality}} package.<br />
<br />
{{Warning|The ''root'' account is not affected by this policy by default.}}<br />
<br />
{{Note|You can use the ''root'' account to set a password for a user that bypasses the desired/configured policy. This is useful when setting temporary passwords.}}<br />
<br />
If for example you want to enforce this policy:<br />
<br />
* prompt 2 times for password in case of an error (retry option)<br />
* 10 characters minimum length (minlen option)<br />
* at least 6 characters should be different from old password when entering a new one (difok option)<br />
* at least 1 digit (dcredit option)<br />
* at least 1 uppercase (ucredit option)<br />
* at least 1 lowercase (lcredit option)<br />
* at least 1 other character (ocredit option)<br />
* cannot contain the words "myservice" and "mydomain"<br />
* enforce the policy for root<br />
<br />
Edit the {{ic|/etc/pam.d/passwd}} file to read as:<br />
<br />
{{bc|1=<br />
#%PAM-1.0<br />
password required pam_pwquality.so retry=2 minlen=10 difok=6 dcredit=-1 ucredit=-1 ocredit=-1 lcredit=-1 [badwords=myservice mydomain] enforce_for_root<br />
password required pam_unix.so use_authtok sha512 shadow<br />
}}<br />
<br />
The {{ic|password required pam_unix.so use_authtok}} instructs the ''pam_unix'' module to not prompt for a password but rather to use the one provided by ''pam_pwquality''.<br />
<br />
You can refer to the {{man|8|pam_pwquality}} and {{man|8|pam_unix}} man pages for more information.<br />
<br />
== CPU ==<br />
<br />
=== Microcode ===<br />
<br />
See [[microcode]] for information on how to install important security updates for your CPU's microcode.<br />
<br />
=== Hardware vulnerabilities ===<br />
<br />
Some CPUs contain hardware vulnerabilities. See the [https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/ kernel documentation on hardware vulnerabilities] for a list of these vulnerabilities, as well as mitigation selection guides to help customize the kernel to mitigate these vulnerabilities for specific usage scenarios.<br />
<br />
To check if you are affected by a known vulnerability, run the following:<br />
<br />
$ grep -r . /sys/devices/system/cpu/vulnerabilities/<br />
<br />
In most cases, updating the kernel and microcode will mitigate vulnerabilities.<br />
<br />
==== Simultaneous multithreading (hyper-threading) ====<br />
<br />
[[Wikipedia:Simultaneous multithreading|Simultaneous multithreading]] (SMT), also called hyper-threading on Intel CPUs, is a hardware feature that may be a source of [https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/l1tf.html L1 Terminal Fault] and [https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/mds.html Microarchitectural Data Sampling] vulnerabilities. The Linux kernel and microcode updates contain mitigations for known vulnerabilities, but [https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/l1tf.html#virtualization-with-untrusted-guests disabling SMT may still be required on certain CPUs if untrusted virtualization guests are present].<br />
<br />
SMT can often be disabled in your system's firmware. Consult your motherboard or system documentation for more information. You can also disable SMT in the kernel by adding the following [[kernel parameters]]:<br />
<br />
l1tf=full,force mds=full,nosmt mitigations=auto,nosmt nosmt=force<br />
<br />
== Memory ==<br />
<br />
=== Hardened malloc ===<br />
<br />
[https://github.com/GrapheneOS/hardened_malloc hardened_malloc] ({{AUR|hardened_malloc}}, {{AUR|hardened-malloc-git}}) is a hardened replacement for [[Wikipedia:GNU C Library|glibc]]'s malloc(). The project was originally developed for integration into Android's [[Wikipedia:Bionic (software)|Bionic]] and [[Wikipedia:musl|musl]] by Daniel Micay, of GrapheneOS, but he has also built in support for standard Linux distributions on the x86_64 architecture.<br />
<br />
While hardened_malloc is not yet integrated into glibc (assistance and pull requests welcome) it can be used easily with LD_PRELOAD. In testing so far, it only causes issues with a handful of applications if enabled globally in {{ic|/etc/ld.so.preload}}. For example, {{ic|man}} fails to work properly unless its {{ic|seccomp}} environment flag is disabled due to not having {{ic|getrandom}} in the standard whitelist, although this can be easily fixed by rebuilding it with the system call added. Since hardened_malloc has a performance cost, you may want to decide which implementation to use on a case-by-case basis based on attack surface and performance needs.<br />
<br />
To try it out in a standalone manner, use the hardened-malloc-preload wrapper script, or manually start an application with the proper preload value:<br />
<br />
LD_PRELOAD="/usr/lib/libhardened_malloc.so" /usr/bin/firefox<br />
<br />
Proper usage with [[Firejail]] can be found on its wiki page, and some configurable build options for hardened_malloc can be found on the github repo.<br />
<br />
== Storage ==<br />
<br />
=== Data-at-rest encryption ===<br />
<br />
[[Data-at-rest encryption]], preferably full-disk encryption with a [[#Passwords|strong passphrase]], is the only way to guard data against physical recovery. This provides complete security when the computer is turned off or the disks in question are unmounted.<br />
<br />
Once the computer is powered on and the drive is mounted, however, its data becomes just as vulnerable as an unencrypted drive. It is therefore best practice to unmount data partitions as soon as they are no longer needed.<br />
<br />
Certain programs, like [[dm-crypt]], allow the user to encrypt a loop file as a virtual volume. This is a reasonable alternative to full-disk encryption when only certain parts of the system need be secure.<br />
<br />
You may also encrypt a drive with the key stored in a [[TPM]], although it has had [https://tpm.fail vulnerabilites in the past] and the key can be extracted by a [https://pulsesecurity.co.nz/articles/TPM-sniffing bus sniffing attack].<br />
<br />
=== File systems ===<br />
<br />
The kernel now prevents security issues related to hardlinks and symlinks if the {{ic|fs.protected_hardlinks}} and {{ic|fs.protected_symlinks}} sysctl switches are enabled, so there is no longer a major security benefit from separating out world-writable directories.<br />
<br />
File systems containing world-writable directories can still be kept separate as a coarse way of limiting the damage from disk space exhaustion. However, filling {{ic|/var}} or {{ic|/tmp}} is enough to take down services. More flexible mechanisms for dealing with this concern exist (like [[Disk quota|quotas]]), and some [[file systems]] include related features themselves (Btrfs has quotas on subvolumes).<br />
<br />
==== Mount options ====<br />
<br />
Following the principle of least privilege, file systems should be mounted with the most restrictive mount options possible (without losing functionality).<br />
<br />
Relevant mount options are:<br />
<br />
* {{ic|nodev}}: Do not interpret character or block special devices on the file system.<br />
* {{ic|nosuid}}: Do not allow set-user-identifier or set-group-identifier bits to take effect.<br />
* {{ic|noexec}}: Do not allow direct execution of any binaries on the mounted file system.<br />
** Setting {{ic|noexec}} on {{ic|/home}} disallows executable scripts and breaks [[Wine]]*, [[Steam]], PyCharm, etc.<br />
** Some packages (building {{Pkg|nvidia-dkms}} for example) may require {{ic|exec}} on {{ic|/var}}.<br />
<br />
{{Note|Wine does not need the {{ic|exec}} flag for opening Windows executables. It is only needed when Wine itself is installed in {{ic|/home}}.}}<br />
<br />
File systems used for data should always be mounted with {{ic|nodev}}, {{ic|nosuid}} and {{ic|noexec}}.<br />
<br />
Potential file system mounts to consider:<br />
<br />
* {{ic|/var}}<br />
* {{ic|/home}}<br />
* {{ic|/dev/shm}}<br />
* {{ic|/tmp}}<br />
* {{ic|/boot}}<br />
<br />
=== File access permissions ===<br />
<br />
The default [[file permissions]] allow read access to almost everything and changing the permissions can hide valuable information from an attacker who gains access to a non-root account such as the {{ic|http}} or {{ic|nobody}} users.<br />
<br />
For example:<br />
<br />
# chmod 700 /boot /etc/{iptables,arptables}<br />
<br />
The default [[Umask]] {{ic|0022}} can be changed to improve security for newly created files. The [https://apps.nsa.gov/iaarchive/library/ia-guidance/security-configuration/operating-systems/guide-to-the-secure-configuration-of-red-hat-enterprise.cfm NSA RHEL5 Security Guide] suggests a umask of {{ic|0077}} for maximum security, which makes new files not readable by users other than the owner. To change this, see [[Umask#Set the mask value]].<br />
<br />
=== Backups ===<br />
<br />
{{Merge|System backup|There is a dedicated page for system backups.}}<br />
<br />
Regularly create backups of important data. Regularly test the integrity of the backups. Regularly test that the backups can be restored.<br />
<br />
Make sure that at least one copy of the data is stored offline, i.e. not connected to the system under threat in any way. [[Wikipedia:Ransomware|Ransomware]] and other destructive attacks may also attack any connected backup systems.<br />
<br />
== User setup ==<br />
<br />
=== Do not use the root account for daily use ===<br />
<br />
Following the principle of least privilege, do not use the root user for daily use. Create a non-privileged user account for each person using the system. Use [[sudo]] as necessary for temporary privileged access.<br />
<br />
=== Enforce a delay after a failed login attempt ===<br />
<br />
Add the following line to {{ic|/etc/pam.d/system-login}} to add a delay of at least 4 seconds between failed login attempts:<br />
<br />
{{hc|/etc/pam.d/system-login|2=<br />
auth optional pam_faildelay.so delay=4000000<br />
}}<br />
<br />
{{ic|4000000}} is the time in microseconds to delay.<br />
<br />
=== Lock out user after three failed login attempts ===<br />
<br />
As of {{Pkg|pambase}} 20200721.1-2, {{ic|pam_faillock.so}} is enabled by default to lock out users for 10 minutes after 3 failed login attempts in a 15 minute period (see {{Bug|67644}}). The lockout only applies to password authentication (e.g. login and sudo), public key authentication over SSH is still accepted. To prevent complete denial-of-service, this lockout is disabled on root.<br />
<br />
To unlock a user, do:<br />
<br />
$ faillock --reset --user ''username''<br />
<br />
By default, the lock mechanism is a file per-user located at {{ic|/run/faillock/}}. Deleting or emptying the file unlocks that user - the directory is owned by root, but the file is owned by the user, so the {{ic|faillock}} command only empties the file, therefore does not require root.<br />
<br />
The module {{ic|pam_faillock.so}} can be configured with the file {{ic|1=/etc/security/faillock.conf}}. The lockout parameters:<br />
<br />
* {{ic|unlock_time}} — the lockout time (in seconds, default 10 minutes).<br />
* {{ic|fail_interval}} — the time in which failed logins can cause a lockout (in seconds, default 15 minutes).<br />
* {{ic|deny}} — the number of failed logins before lockout (default 3).<br />
<br />
{{Note|{{ic|1=deny = 0}} will disable the lockout.}}<br />
<br />
No restart is required for changes to take effect. See {{man|5|faillock.conf}} for further configuration options, such as enabling lockout for the root account, disabling for centralized login (e.g. LDAP), etc.<br />
<br />
=== Limit amount of processes ===<br />
<br />
On systems with many, or untrusted users, it is important to limit the number of processes each can run at once, therefore preventing [[Wikipedia:Fork bomb|fork bombs]] and other denial of service attacks. {{ic|/etc/security/limits.conf}} determines how many processes each user, or group can have open, and is empty (except for useful comments) by default. Adding the following lines to this file will limit all users to 100 active processes, unless they use the {{ic|prlimit}} command to explicitly raise their maximum to 200 for that session. These values can be changed according to the appropriate number of processes a user should have running, or the hardware of the box you are administrating. <br />
<br />
* soft nproc 100<br />
* hard nproc 200<br />
<br />
The current number of threads for each user can be found with {{ic|ps --no-headers -Leo user {{!}} sort {{!}} uniq --count}}. This may help with determining appropriate values for the limits.<br />
<br />
=== Run Xorg rootless ===<br />
<br />
[[Xorg]] is commonly [https://security.stackexchange.com/questions/4641/why-are-people-saying-that-the-x-window-system-is-not-secure/4646#4646 considered insecure] because of its architecture and dated design. Thus it is recommended to avoid running it as root.<br />
<br />
See [[Xorg#Rootless Xorg]] for more details how to run it without root privileges. Alternatively, use [[Wayland]] instead of Xorg.<br />
<br />
== Restricting root ==<br />
<br />
The root user is, by definition, the most powerful user on a system. It is also difficult to audit the root user account. It is therefore important to restrict usage of the root user account as much as possible. There are a number of ways to keep the power of the root user while limiting its ability to cause harm.<br />
<br />
=== Use sudo instead of su ===<br />
<br />
{{Merge|sudo|There is a dedicated article.}}<br />
<br />
Using [[sudo]] for privileged access is preferable to [[su]] for [[Su#Sudo, an alternative|a number of reasons]].<br />
<br />
* It keeps a log of which normal privilege user has run each privileged command.<br />
* The root user password need not be given out to each user who requires root access.<br />
* {{ic|sudo}} prevents users from accidentally running commands as ''root'' that do not need root access, because a full root terminal is not created. This aligns with the [[Wikipedia:Principle of least privilege|principle of least privilege]].<br />
* Individual programs may be enabled per user, instead of offering complete root access just to run one command. For example, to give the user ''alice'' access to a particular program:<br />
<br />
# visudo<br />
<br />
{{hc|/etc/sudoers|2=<br />
alice ALL = NOPASSWD: /path/to/program<br />
}}<br />
<br />
Or, individual commands can be allowed for all users. To mount Samba shares from a server as a regular user:<br />
<br />
%users ALL=/sbin/mount.cifs,/sbin/umount.cifs<br />
<br />
This allows all users who are members of the group users to run the commands {{ic|/sbin/mount.cifs}} and {{ic|/sbin/umount.cifs}} from any machine (ALL).<br />
<br />
{{Tip|<br />
To use restricted version of {{ic|nano}} instead of {{ic|vi}} with {{ic|visudo}},<br />
<br />
{{hc|/etc/sudoers|2=<br />
Defaults editor=/usr/bin/rnano<br />
}}<br />
<br />
Exporting {{ic|1=EDITOR=nano visudo}} is regarded as a severe security risk since everything can be used as an {{ic|EDITOR}}.<br />
}}<br />
<br />
==== Editing files using sudo ====<br />
<br />
See [[Sudo#Editing files]]. Alternatively, you can use an editor like {{ic|rvim}} or {{ic|rnano}} which has restricted capabilities in order to be safe to run as root.<br />
<br />
=== Restricting root login ===<br />
<br />
Once [[sudo]] is properly configured, full root access can be heavily restricted or denied without losing much usability. To disable root, but still allowing to use [[sudo]], you can use {{ic|passwd --lock root}}.<br />
<br />
==== Allow only certain users ====<br />
<br />
The [[PAM]] {{ic|pam_wheel.so}} lets you allow only users in the group {{ic|wheel}} to login using [[su]]. See [[su#su and wheel]].<br />
<br />
==== Denying SSH login ====<br />
<br />
Even if you do not wish to deny root login for local users, it is always good practice to [[OpenSSH#Deny|deny root login via SSH]]. The purpose of this is to add an additional layer of security before a user can completely compromise your system remotely.<br />
<br />
==== Specify acceptable login combinations with access.conf ====<br />
<br />
When someone attempts to log in with [[PAM]], {{ic|/etc/security/access.conf}} is checked for the first combination that matches their login properties. Their attempt then fails or succeeds based on the rule for that combination. <br />
<br />
+:root:LOCAL<br />
-:root:ALL<br />
<br />
Rules can be set for specific groups and users. In this example, the user archie is allowed to login locally, as are all users in the wheel and adm groups. All other logins are rejected:<br />
<br />
+:archie:LOCAL<br />
+:(wheel):LOCAL<br />
+:(adm):LOCAL<br />
-:ALL:ALL<br />
<br />
Read more at {{man|5|access.conf}}<br />
<br />
== Mandatory access control ==<br />
<br />
[[Wikipedia:Mandatory Access Control|Mandatory access control]] (MAC) is a type of security policy that differs significantly from the [[Wikipedia:Discretionary Access Control|discretionary access control]] (DAC) used by default in Arch and most Linux distributions. MAC essentially means that every action a program could perform that affects the system in any way is checked against a security ruleset. This ruleset, in contrast to DAC methods, cannot be modified by users. Using virtually any mandatory access control system will significantly improve the security of your computer, although there are differences in how it can be implemented.<br />
<br />
=== Pathname MAC ===<br />
<br />
Pathname-based access control is a simple form of access control that offers permissions based on the path of a given file. The downside to this style of access control is that permissions are not carried with files if they are moved about the system. On the positive side, pathname-based MAC can be implemented on a much wider range of filesystems, unlike labels-based alternatives.<br />
<br />
* [[AppArmor]] is a [[Wikipedia:Canonical_(company)|Canonical]]-maintained MAC implementation seen as an "easier" alternative to SELinux.<br />
* [[Tomoyo]] is another simple, easy-to-use system offering mandatory access control. It is designed to be both simple in usage and in implementation, requiring very few dependencies.<br />
<br />
=== Labels MAC ===<br />
<br />
Labels-based access control means the extended attributes of a file are used to govern its security permissions. While this system is arguably more flexible in its security offerings than pathname-based MAC, it only works on filesystems that support these extended attributes.<br />
<br />
* [[SELinux]], based on a [[Wikipedia:NSA|NSA]] project to improve Linux security, implements MAC completely separate from system users and roles. It offers an extremely robust multi-level MAC policy implementation that can easily maintain control of a system that grows and changes past its original configuration.<br />
<br />
=== Access Control Lists ===<br />
<br />
[[Access Control Lists]] (ACLs) are an alternative to attaching rules directly to the filesystem in some way. ACLs implement access control by checking program actions against a list of permitted behavior.<br />
<br />
== Kernel hardening ==<br />
<br />
=== Kernel self-protection / exploit mitigation ===<br />
<br />
The {{pkg|linux-hardened}} package uses a [https://github.com/anthraxx/linux-hardened basic kernel hardening patch set] and more security-focused compile-time configuration options than the {{pkg|linux}} package. A custom build can be made to choose a different compromise between security and performance than the security-leaning defaults.<br />
<br />
However, it should be noted that several packages will not work when using this kernel. For example:<br />
<br />
* {{AUR|skypeforlinux-preview-bin}}<br />
* {{AUR|skypeforlinux-stable-bin}}<br />
* {{pkg|throttled}}<br />
<br />
If you use an out-of-tree driver such as [[NVIDIA]], you may need to switch to its [[DKMS]] package.<br />
<br />
==== Userspace ASLR comparison ====<br />
<br />
The {{pkg|linux-hardened}} package provides an improved implementation of Address Space Layout Randomization for userspace processes. The {{pkg|paxtest}} command can be used to obtain an estimate of the provided entropy:<br />
<br />
===== 64-bit processes =====<br />
<br />
{{hc|linux-hardened 5.4.21.a-1-hardened|<br />
Anonymous mapping randomization test : 32 quality bits (guessed)<br />
Heap randomization test (ET_EXEC) : 40 quality bits (guessed)<br />
Heap randomization test (PIE) : 40 quality bits (guessed)<br />
Main executable randomization (ET_EXEC) : 32 quality bits (guessed)<br />
Main executable randomization (PIE) : 32 quality bits (guessed)<br />
Shared library randomization test : 32 quality bits (guessed)<br />
VDSO randomization test : 32 quality bits (guessed)<br />
Stack randomization test (SEGMEXEC) : 40 quality bits (guessed)<br />
Stack randomization test (PAGEEXEC) : 40 quality bits (guessed)<br />
Arg/env randomization test (SEGMEXEC) : 44 quality bits (guessed)<br />
Arg/env randomization test (PAGEEXEC) : 44 quality bits (guessed)<br />
Offset to library randomisation (ET_EXEC): 34 quality bits (guessed)<br />
Offset to library randomisation (ET_DYN) : 34 quality bits (guessed)<br />
Randomization under memory exhaustion @~0: 32 bits (guessed)<br />
Randomization under memory exhaustion @0 : 32 bits (guessed)<br />
}}<br />
<br />
{{hc|linux 5.5.5-arch1-1|<br />
Anonymous mapping randomization test : 28 quality bits (guessed)<br />
Heap randomization test (ET_EXEC) : 28 quality bits (guessed)<br />
Heap randomization test (PIE) : 28 quality bits (guessed)<br />
Main executable randomization (ET_EXEC) : 28 quality bits (guessed)<br />
Main executable randomization (PIE) : 28 quality bits (guessed)<br />
Shared library randomization test : 28 quality bits (guessed)<br />
VDSO randomization test : 20 quality bits (guessed)<br />
Stack randomization test (SEGMEXEC) : 30 quality bits (guessed)<br />
Stack randomization test (PAGEEXEC) : 30 quality bits (guessed)<br />
Arg/env randomization test (SEGMEXEC) : 22 quality bits (guessed)<br />
Arg/env randomization test (PAGEEXEC) : 22 quality bits (guessed)<br />
Offset to library randomisation (ET_EXEC): 28 quality bits (guessed)<br />
Offset to library randomisation (ET_DYN) : 28 quality bits (guessed)<br />
Randomization under memory exhaustion @~0: 29 bits (guessed)<br />
Randomization under memory exhaustion @0 : 29 bits (guessed)<br />
}}<br />
<br />
{{hc|linux-lts 4.19.101-1-lts|<br />
Anonymous mapping randomization test : 28 quality bits (guessed)<br />
Heap randomization test (ET_EXEC) : 28 quality bits (guessed)<br />
Heap randomization test (PIE) : 28 quality bits (guessed)<br />
Main executable randomization (ET_EXEC) : 28 quality bits (guessed)<br />
Main executable randomization (PIE) : 28 quality bits (guessed)<br />
Shared library randomization test : 28 quality bits (guessed)<br />
VDSO randomization test : 19 quality bits (guessed)<br />
Stack randomization test (SEGMEXEC) : 30 quality bits (guessed)<br />
Stack randomization test (PAGEEXEC) : 30 quality bits (guessed)<br />
Arg/env randomization test (SEGMEXEC) : 22 quality bits (guessed)<br />
Arg/env randomization test (PAGEEXEC) : 22 quality bits (guessed)<br />
Offset to library randomisation (ET_EXEC): 28 quality bits (guessed)<br />
Offset to library randomisation (ET_DYN) : 28 quality bits (guessed)<br />
Randomization under memory exhaustion @~0: 28 bits (guessed)<br />
Randomization under memory exhaustion @0 : 28 bits (guessed)<br />
}}<br />
<br />
===== 32-bit processes (on an x86_64 kernel) =====<br />
<br />
{{hc|linux-hardened|<br />
Anonymous mapping randomization test : 16 quality bits (guessed)<br />
Heap randomization test (ET_EXEC) : 22 quality bits (guessed)<br />
Heap randomization test (PIE) : 27 quality bits (guessed)<br />
Main executable randomization (ET_EXEC) : No randomization<br />
Main executable randomization (PIE) : 18 quality bits (guessed)<br />
Shared library randomization test : 16 quality bits (guessed)<br />
VDSO randomization test : 16 quality bits (guessed)<br />
Stack randomization test (SEGMEXEC) : 24 quality bits (guessed)<br />
Stack randomization test (PAGEEXEC) : 24 quality bits (guessed)<br />
Arg/env randomization test (SEGMEXEC) : 28 quality bits (guessed)<br />
Arg/env randomization test (PAGEEXEC) : 28 quality bits (guessed)<br />
Offset to library randomisation (ET_EXEC): 18 quality bits (guessed)<br />
Offset to library randomisation (ET_DYN) : 16 quality bits (guessed)<br />
Randomization under memory exhaustion @~0: 18 bits (guessed)<br />
Randomization under memory exhaustion @0 : 18 bits (guessed)<br />
}}<br />
<br />
{{hc|linux|<br />
Anonymous mapping randomization test : 8 quality bits (guessed)<br />
Heap randomization test (ET_EXEC) : 13 quality bits (guessed)<br />
Heap randomization test (PIE) : 13 quality bits (guessed)<br />
Main executable randomization (ET_EXEC) : No randomization<br />
Main executable randomization (PIE) : 8 quality bits (guessed)<br />
Shared library randomization test : 8 quality bits (guessed)<br />
VDSO randomization test : 8 quality bits (guessed)<br />
Stack randomization test (SEGMEXEC) : 19 quality bits (guessed)<br />
Stack randomization test (PAGEEXEC) : 19 quality bits (guessed)<br />
Arg/env randomization test (SEGMEXEC) : 11 quality bits (guessed)<br />
Arg/env randomization test (PAGEEXEC) : 11 quality bits (guessed)<br />
Offset to library randomisation (ET_EXEC): 8 quality bits (guessed)<br />
Offset to library randomisation (ET_DYN) : 13 quality bits (guessed)<br />
Randomization under memory exhaustion @~0: No randomization<br />
Randomization under memory exhaustion @0 : No randomization<br />
}}<br />
<br />
=== Restricting access to kernel logs ===<br />
<br />
{{Remove|All [[Kernel#Officially supported kernels|officially supported kernels]] have {{ic|1=CONFIG_SECURITY_DMESG_RESTRICT=y}}.}}<br />
<br />
The kernel logs contain useful information for an attacker trying to exploit kernel vulnerabilities, such as sensitive memory addresses. The {{ic|kernel.dmesg_restrict}} flag was to forbid access to the logs without the {{ic|CAP_SYS_ADMIN}} capability (which only processes running as root have by default).<br />
<br />
{{hc|/etc/sysctl.d/51-dmesg-restrict.conf|2=<br />
kernel.dmesg_restrict = 1<br />
}}<br />
<br />
{{Note|This is enabled by default in {{pkg|linux}}[https://github.com/archlinux/svntogit-packages/commit/b78bc292e2218661a3b70163ec30711c87100941], {{Pkg|linux-lts}}[https://github.com/archlinux/svntogit-packages/commit/283332609549a479357d2d58adf80d12e89e345f], {{Pkg|linux-zen}}[https://github.com/archlinux/svntogit-packages/commit/5962e24fe3062a3a96dbc1876ba8ea4ef1d500c9] and {{pkg|linux-hardened}}.}}<br />
<br />
=== Restricting access to kernel pointers in the proc filesystem ===<br />
<br />
Setting {{ic|kernel.kptr_restrict}} to 1 will hide kernel symbol addresses in {{ic|/proc/kallsyms}} from regular users without {{ic|CAP_SYSLOG}}, making it more difficult for kernel exploits to resolve addresses/symbols dynamically. This will not help that much on a pre-compiled Arch Linux kernel, since a determined attacker could just download the kernel package and get the symbols manually from there, but if you are compiling your own kernel, this can help mitigating local root exploits. This will break some {{Pkg|perf}} commands when used by non-root users (but many {{Pkg|perf}} features require root access anyway). See {{Bug|34323}} for more information.<br />
<br />
Setting {{ic|kernel.kptr_restrict}} to 2 will hide kernel symbol addresses in {{ic|/proc/kallsyms}} regardless of privileges.<br />
<br />
{{hc|/etc/sysctl.d/51-kptr-restrict.conf|2=<br />
kernel.kptr_restrict = 1<br />
}}<br />
<br />
{{Note|{{pkg|linux-hardened}} sets {{ic|1=kptr_restrict=2}} by default rather than {{ic|0}}.}}<br />
<br />
=== BPF hardening ===<br />
<br />
BPF is a system used to load and execute bytecode within the kernel dynamically during runtime. It is used in a number of Linux kernel subsystems such as networking (e.g. XDP, tc), tracing (e.g. kprobes, uprobes, tracepoints) and security (e.g. seccomp). It is also useful for advanced network security, performance profiling and dynamic tracing.<br />
<br />
BPF was originally an acronym of [[Wikipedia:Berkeley Packet Filter|Berkeley Packet Filter]] since the original classic BPF was used for packet capture tools for BSD. This eventually evolved into Extended BPF (eBPF), which was shortly afterwards renamed to just BPF (not an acronym). BPF should not be confused with packet filtering tools like iptables or netfilter, although BPF can be used to implement packet filtering tools.<br />
<br />
BPF code may be either interpreted or compiled using a [[Wikipedia:Just-in-time compilation|Just-In-Time (JIT) compiler]]. The Arch kernel is built with {{ic|CONFIG_BPF_JIT_ALWAYS_ON}} which disables the BPF interpreter and forces all BPF to use JIT compilation. This makes it harder for an attacker to use BPF to escalate attacks that exploit SPECTRE-style vulnerabilities. See [https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=290af86629b25ffd1ed6232c4e9107da031705cb the kernel patch which introduced CONFIG_BPF_JIT_ALWAYS_ON] for more details.<br />
<br />
The kernel includes a hardening feature for JIT-compiled BPF which can mitigate some types of JIT spraying attacks at the cost of performance and the ability to trace and debug many BPF programs. It may be enabled by setting {{ic|net.core.bpf_jit_harden}} to {{ic|1}} (to enable hardening of unprivileged code) or {{ic|2}} (to enable hardening of all code).<br />
<br />
See the {{ic|net.core.bpf_*}} settings in the [https://www.kernel.org/doc/html/latest/admin-guide/sysctl/net.html kernel documentation] for more details.<br />
<br />
{{Tip|{{pkg|linux-hardened}} sets {{ic|1=net.core.bpf_jit_harden=2}} by default rather than {{ic|0}}.}}<br />
<br />
=== ptrace scope ===<br />
<br />
The {{man|2|ptrace}} syscall provides a means by which one process (the "tracer") may observe and control the execution of another process (the "tracee"), and examine and change the tracee's memory and registers. {{ic|ptrace}} is commonly used by debugging tools including ''gdb'', ''strace'', ''perf'', ''reptyr'' and other debuggers. However, it also provides a means by which a malicious process can read data from and take control of other processes.<br />
<br />
Arch enables the [https://www.kernel.org/doc/html/latest/admin-guide/LSM/Yama.html Yama LSM] by default, which provides a {{ic|kernel.yama.ptrace_scope}} [[kernel parameter]]. This parameter is set to {{ic|1}} (restricted) by default which prevents tracers from performing a {{ic|ptrace}} call on tracees outside of a restricted scope unless the tracer is privileged or has the {{ic|CAP_SYS_PTRACE}} [[Capabilities|capability]]. This is a significant improvement in security compared to the classic permissions. Without this module, there is no separation between processes running as the same user (in the absence of additional security layers such as {{man|7|pid_namespaces}}).<br />
<br />
{{Note|By default, you can still use tools which require {{ic|ptrace}} by running them as privileged processes, e.g. using [[sudo]].}}<br />
<br />
If you do not need to use debugging tools, consider setting {{ic|kernel.yama.ptrace_scope}} to {{ic|2}} (admin-only) or {{ic|3}} (no {{ic|ptrace}} possible) to harden the system.<br />
<br />
=== hidepid ===<br />
<br />
{{Expansion|1=[https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0fb5ce62c5920b6e0a8a061f2fe80e0403281e10 Linux 5.8 implemented private instances] and new values for {{ic|1=hidepid=}}.}}<br />
<br />
{{Warning|<br />
* This may cause issues for certain applications like an application running in a sandbox and [[Xorg]] (see workaround).<br />
* This causes issues with [[D-Bus]], [[PulseAudio]] and [[bluetooth]] when using {{Pkg|systemd}} > 237.64-1.<br />
}}<br />
<br />
The kernel has the ability to hide other users' processes, normally accessible via {{ic|/proc}}, from unprivileged users by mounting the {{ic|proc}} filesystem with the {{ic|1=hidepid=}} and {{ic|1=gid=}} options documented in https://www.kernel.org/doc/html/latest/filesystems/proc.html. <br />
<br />
This greatly complicates an intruder's task of gathering information about running processes, whether some daemon runs with elevated privileges, whether other user runs some sensitive program, whether other users run any program at all, makes it impossible to learn whether any user runs a specific program (given the program does not reveal itself by its behaviour), and, as an additional bonus, poorly written programs passing sensitive information via program arguments are now protected against local eavesdroppers.<br />
<br />
The {{ic|proc}} [[Users_and_groups#System_groups|group]], provided by the {{Pkg|filesystem}} package, acts as a whitelist of users authorized to learn other users' process information. If users or services need access to {{ic|/proc/<pid>}} directories beyond their own, [[Users_and_groups#Group_management|add them to the group]].<br />
<br />
For example, to hide process information from other users except those in the {{ic|proc}} group:<br />
<br />
{{hc|/etc/fstab|2=<br />
proc /proc proc nosuid,nodev,noexec,hidepid=2,gid=proc 0 0<br />
}}<br />
<br />
For user sessions to work correctly, an exception needs to be added for ''systemd-logind'':<br />
<br />
{{hc|/etc/systemd/system/systemd-logind.service.d/hidepid.conf|2=<br />
[Service]<br />
SupplementaryGroups=proc<br />
}}<br />
<br />
=== Restricting module loading ===<br />
<br />
The default Arch kernel has {{ic|CONFIG_MODULE_SIG_ALL}} enabled which signs all kernel modules build as part of the {{Pkg|linux}} package. This allows the kernel to restrict modules to be only loaded when they are signed with a valid key, in practical terms this means that all out of tree modules compiled locally or provides by packages such as {{Pkg|virtualbox-host-modules-arch}} cannot be loaded. Kernel module loading can be restricted by setting the [[kernel parameter]] {{ic|1=module.sig_enforce=1}}. More information can be found at the [https://www.kernel.org/doc/html/latest/admin-guide/module-signing.html kernel documentation].<br />
<br />
=== Disable kexec ===<br />
<br />
Kexec allows replacing the current running kernel.<br />
<br />
{{hc|/etc/sysctl.d/51-kexec-restrict.conf|2=<br />
kernel.kexec_load_disabled = 1<br />
}}<br />
<br />
{{Tip|kexec is disabled by default in {{pkg|linux-hardened}}.}}<br />
<br />
=== Kernel lockdown mode ===<br />
<br />
Since Linux 5.4 the kernel [https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=aefcf2f4b58155d27340ba5f9ddbe9513da8286d has gained] an optional [https://mjg59.dreamwidth.org/55105.html lockdown feature], intended to strengthen the boundary between UID 0 (root) and the kernel. When enabled some applications may cease to work who rely on low-level access to either hardware or the kernel.<br />
<br />
To use lockdown, its LSM must be initialized and a lockdown mode must be set.<br />
<br />
All [[Kernel#Officially supported kernels|officially supported kernels]] initialize the LSM, but none of them enforce any lockdown mode. <br />
<br />
{{Tip|Enabled LSMs can be verified by running {{ic|cat /sys/kernel/security/lsm}}.}}<br />
<br />
Lockdown has two modes of operation:<br />
<br />
* {{ic|integrity}}: kernel features that allow userland to modify the running kernel are disabled (kexec, bpf).<br />
* {{ic|confidentiality}}: kernel features that allow userland to extract confidential information from the kernel are also disabled.<br />
<br />
To enable kernel lockdown at runtime, run:<br />
<br />
# echo ''mode'' > /sys/kernel/security/lockdown<br />
<br />
To enable kernel lockdown on boot, use the [[kernel parameter]] {{ic|1=lockdown=''mode''}}.<br />
<br />
{{Note|<br />
* Kernel lockdown cannot be disabled at runtime.<br />
* Kernel lockdown disables [[hibernation]].<br />
}}<br />
<br />
See also {{man|7|kernel_lockdown}}.<br />
<br />
== Sandboxing applications ==<br />
<br />
See also [[Wikipedia:Sandbox (computer security)]].<br />
<br />
{{Note|The user namespace configuration item {{ic|CONFIG_USER_NS}} is currently enabled in {{Pkg|linux}} (4.14.5 or later), {{Pkg|linux-lts}} (4.14.15 or later) and {{Pkg|linux-hardened}}. Lack of it may prevent certain sandboxing features from being made available to applications.}}<br />
<br />
{{Warning|Unprivileged user namespace usage ({{ic|CONFIG_USER_NS_UNPRIVILEGED}}) is enabled by default in {{Pkg|linux}} (5.1.8 or later), {{Pkg|linux-lts}} (4.19.55-2 or later) and {{Pkg|linux-zen}} (5.1.14.zen1-2 or later) unless the {{ic|kernel.unprivileged_userns_clone}} [[sysctl]] is set to {{ic|0}}. Since this greatly increases the attack surface for local privilege escalation, it is advised to disable this manually, or use the {{Pkg|linux-hardened}} kernel. For more information see {{Bug|36969}}.}}<br />
<br />
=== Firejail ===<br />
<br />
[[Firejail]] is an easy to use and simple tool for sandboxing applications and servers alike. Firejail is suggested for browsers and internet facing applications, as well as any servers you may be running.<br />
<br />
=== bubblewrap ===<br />
<br />
[[bubblewrap]] is a sandbox application developed from [[Wikipedia:Flatpak|Flatpak]] with an even smaller resource footprint than Firejail. While it lacks certain features such as file path whitelisting, bubblewrap does offer bind mounts as well as the creation of user/IPC/PID/network/cgroup namespaces and can support both simple and complex sandboxes.<br />
<br />
=== chroots ===<br />
<br />
Manual [[chroot]] jails can also be constructed.<br />
<br />
=== Linux containers ===<br />
<br />
[[Linux Containers]] are another good option when you need more separation than the other options (short of KVM and VirtualBox) provide. LXC is run on top of the existing kernel in a pseudo-chroot with their own virtual hardware.<br />
<br />
=== Other virtualization options ===<br />
<br />
Using full virtualization options such as [[VirtualBox]], [[KVM]], [[Xen]] or [https://www.qubes-os.org/ Qubes OS] (based on Xen) can also improve isolation and security in the event you plan on running risky applications or browsing dangerous websites.<br />
<br />
== Network and firewalls ==<br />
<br />
=== Firewalls ===<br />
<br />
While the stock Arch kernel is capable of using [[Wikipedia:Netfilter|Netfilter]]'s [[iptables]] and [[nftables]], they are not enabled by default. It is highly recommended to set up some form of firewall to protect the services running on the system. Many resources (including ArchWiki) do not state explicitly which services are worth protecting, so enabling a firewall is a good precaution.<br />
<br />
* See [[iptables]] and [[nftables]] for general information.<br />
* See [[Simple stateful firewall]] for a guide on setting up an iptables firewall.<br />
* See [[:Category:Firewalls]] for other ways of setting up netfilter.<br />
* See [[Ipset]] for blocking lists of ip addresses, such as those from Bluetack.<br />
<br />
==== Open ports ====<br />
<br />
{{Style|"Open ports" is not a good title since it disregards interfaces and addresses that the application may be bound to. From the firewalls' point of view, ports may be "open" even if no application listens on them at the moment.}}<br />
<br />
Some services listen for inbound traffic on open network ports. It is important to only bind these services to the addresses and interfaces that are strictly necessary. It may be possible for a remote attacker to [https://samy.pl/slipstream/ exploit flawed network protocols to access exposed services]. This can even happen with [https://nvd.nist.gov/vuln/detail/CVE-2019-13450 processes bound to localhost].<br />
<br />
In general, if a service only needs to be accessible to the local system, bind to a Unix domain socket ({{man|7|unix}}) or a loopback address such as {{ic|localhost}} instead of a non-loopback address like {{ic|0.0.0.0/0}}.<br />
<br />
If a service needs to be accessible to other systems via the network, control the access with strict [[firewall]] rules and configure authentication, authorization and encryption whenever possible.<br />
<br />
You can list all current open ports with {{ic|ss -l}}. To show all '''l'''istening '''p'''rocesses and their '''n'''umeric '''t'''cp and '''u'''dp port numbers:<br />
<br />
# ss -lpntu<br />
<br />
See {{man|8|ss}} for more options.<br />
<br />
=== Kernel parameters ===<br />
<br />
Kernel parameters which affect networking can be set using [[Sysctl]]. For how to do this, see [[Sysctl#TCP/IP stack hardening]].<br />
<br />
=== SSH ===<br />
<br />
To mitigate [[Wikipedia:Brute-force attack|brute-force attacks]] it is recommended to enforce key-based authentication. For OpenSSH, see [[OpenSSH#Force public key authentication]]. Alternatively [[Fail2ban]] or [[Sshguard]] offer lesser forms of protection by monitoring logs and writing [[firewall]] rules but open up the potential for a denial of service, since an attacker can [[wikipedia:Spoofing_attack#Spoofing_and_TCP/IP|spoof]] packets as if they came from the administrator after identifying their address. Spoofing IP has lines of defense, such as by [[sysctl#Reverse path filtering|reverse path filtering]] and [[sysctl#Disable ICMP redirects|disabling ICMP redirects]].<br />
<br />
You may want to harden authentication even more by using two-factor authentication. [[Google Authenticator]] provides a two-step authentication procedure using one-time passcodes (OTP).<br />
<br />
Denying root login is also a good practice, both for tracing intrusions and adding an additional layer of security before root access. For OpenSSH, see [[OpenSSH#Deny]].<br />
<br />
Mozilla publishes an [https://infosec.mozilla.org/guidelines/openssh.html OpenSSH configuration guide] which configures more verbose audit logging and restricts ciphers.<br />
<br />
=== DNS ===<br />
<br />
The default domain name resolution (DNS) configuration is highly compatible but has security weaknesses. See [[Domain name resolution#Privacy_and_security|DNS privacy and security]] for more information.<br />
<br />
=== Proxies ===<br />
<br />
Proxies are commonly used as an extra layer between applications and the network, sanitizing data from untrusted sources. The attack surface of a small proxy running with lower privileges is significantly smaller than a complex application running with the end user privileges.<br />
<br />
For example the DNS resolver is implemented in {{Pkg|glibc}}, that is linked with the application (that may be running as root), so a bug in the DNS resolver might lead to a remote code execution. This can be prevented by installing a DNS caching server, such as [[dnsmasq]], which acts as a proxy. [https://googleonlinesecurity.blogspot.it/2016/02/cve-2015-7547-glibc-getaddrinfo-stack.html]<br />
<br />
=== Managing TLS certificates ===<br />
<br />
See [[TLS#Trust management]].<br />
<br />
== Physical security ==<br />
<br />
Physical access to a computer is root access given enough time and resources. However, a high ''practical'' level of security can be obtained by putting up enough barriers.<br />
<br />
An attacker can gain full control of your computer on the next boot by simply attaching a malicious IEEE 1394 (FireWire), Thunderbolt or PCI Express device as they are given full memory access.[https://www.breaknenter.org/projects/inception/]{{Dead link|2020|04|03|status=SSL error}} There is little you can do from preventing this, or modification of the hardware itself - such as flashing malicious firmware onto a drive. However, the vast majority of attackers will not be this knowledgeable and determined.<br />
<br />
[[#Data-at-rest encryption]] will prevent access to your data if the computer is stolen, but malicious firmware can be installed to obtain this data upon your next log in by a resourceful attacker.<br />
<br />
=== Locking down BIOS ===<br />
<br />
Adding a password to the BIOS prevents someone from booting into removable media, which is basically the same as having root access to your computer. You should make sure your drive is first in the boot order and disable the other drives from being bootable if you can.<br />
<br />
=== Boot loaders ===<br />
<br />
It is highly important to protect your [[boot loader]]. An unprotected boot loader can bypass any login restrictions, e.g. by setting the {{ic|1=init=/bin/sh}} [[kernel parameter]] to boot directly to a shell.<br />
<br />
==== Syslinux ====<br />
<br />
Syslinux supports [[Syslinux#Security|password-protecting your bootloader]]. It allows you to set either a per-menu-item password or a global bootloader password.<br />
<br />
==== GRUB ====<br />
<br />
[[GRUB]] supports bootloader passwords as well. See [[GRUB/Tips and tricks#Password protection of GRUB menu]] for details. It also has support for [[GRUB#Encrypted /boot|encrypted /boot]], which only leaves some parts of the bootloader code unencrypted. GRUB's configuration, [[kernel]] and [[initramfs]] are encrypted.<br />
<br />
=== Secure Boot ===<br />
<br />
[[Secure Boot]] is a feature of [[UEFI]] that allows authentication of the files your computer boots. This helps preventing some [[Wikipedia:Evil maid attack|evil maid attacks]] such as replacing files inside the boot partition. Normally computers come with keys that are enrolled by vendors (OEM). However these can be removed and allow the computer to enter ''Setup Mode'' which allows the user to enroll and manage their own keys.<br />
<br />
The secure boot page guides you through how to set secure boot up by [[Unified Extensible Firmware Interface/Secure Boot#Using your own keys|using your own keys]].<br />
<br />
=== Trusted Platform Module (TPM) ===<br />
<br />
[[Trusted Platform Module|TPMs]] are hardware microprocessors which have cryptographic keys embedded. This forms the fundamental root of trust of most modern computers and allows end-to-end verification of the boot chain. They can be used as internal smartcards, attest the firmware running on the computer and allow users to insert secrets into a tamper-proof and brute-force resistant store.<br />
<br />
=== Boot partition on removable flash drive ===<br />
<br />
One popular idea is to place the boot partition on a flash drive in order to render the system unbootable without it. Proponents of this idea often use [[#Data-at-rest encryption|full-disk encryption]] alongside, and some also use [[Dm-crypt/Specialties#Encrypted_system_using_a_detached_LUKS_header|detached encryption headers]] placed on the boot partition.<br />
<br />
This method can also be merged with [[Dm-crypt/Specialties#Encrypted_/boot_and_a_detached_LUKS_header_on_USB|encrypting /boot]].<br />
<br />
=== Automatic logout ===<br />
<br />
If you are using [[Bash]] or [[Zsh]], you can set {{ic|TMOUT}} for an automatic logout from shells after a timeout.<br />
<br />
For example, the following will automatically log out from virtual consoles (but not terminal emulators in X11):<br />
<br />
{{hc|/etc/profile.d/shell-timeout.sh|<nowiki><br />
TMOUT="$(( 60*10 ))";<br />
[ -z "$DISPLAY" ] && export TMOUT;<br />
case $( /usr/bin/tty ) in<br />
/dev/tty[0-9]*) export TMOUT;;<br />
esac<br />
</nowiki>}}<br />
<br />
If you really want EVERY Bash/Zsh prompt (even within X) to timeout, use:<br />
<br />
$ export TMOUT="$(( 60*10 ))";<br />
<br />
Note that this will not work if there is some command running in the shell (eg.: an SSH session or other shell without {{ic|TMOUT}} support). But if you are using VC mostly for restarting frozen GDM/Xorg as root, then this is very useful.<br />
<br />
=== Protect against rogue USB devices ===<br />
<br />
Install [[USBGuard]], which is a software framework that helps to protect your computer against rogue USB devices (a.k.a. [https://srlabs.de/badusb BadUSB], [https://github.com/samyk/poisontap PoisonTap] or [https://lanturtle.com/ LanTurtle]) by implementing basic whitelisting and blacklisting capabilities based on device attributes.<br />
<br />
=== Volatile data collection ===<br />
<br />
A computer that is powered on may be vulnerable to [https://fedvte.usalearning.gov/courses/CSI/course/videos/pdf/CSI_D01_S05_T01_STEP.pdf volatile data collection]. It is a best practice to turn a computer completely off at times it is not necessary for it to be on, or if the computer's physical security is temporarily compromised (e.g. when passing through a security checkpoint).<br />
<br />
== Packages ==<br />
<br />
=== Authentication ===<br />
<br />
[https://www2.cs.arizona.edu/stork/packagemanagersecurity/attacks-on-package-managers.html#overview Attacks on package managers] are possible without proper use of package signing, and can affect even package managers with [https://www2.cs.arizona.edu/stork/packagemanagersecurity/faq.html proper signature systems]. Arch uses package signing by default and relies on a web of trust from 5 trusted master keys. See [[Pacman-key]] for details.<br />
<br />
=== Upgrades ===<br />
<br />
It is important to regularly [[System_maintenance#Upgrading_the_system|upgrade the system]].<br />
<br />
=== Follow vulnerability alerts ===<br />
<br />
Subscribe to the Common Vulnerabilities and Exposure (CVE) Security Alert updates, made available by National Vulnerability Database, and found on the [https://nvd.nist.gov/download.cfm NVD Download webpage]. The [https://security.archlinux.org/ Arch Linux Security Tracker] serves as a particularly useful resource in that it combines Arch Linux Security Advisory (ASA), Arch Linux Vulnerability Group (AVG) and CVE data sets in tabular format. The tool {{Pkg|arch-audit}} can be used to check for vulnerabilities affecting the running system. See also [[Arch Security Team]].<br />
<br />
You should also consider subscribing to the release notifications for software you use, especially if you install software through means other than the main repositories or AUR. Some software have mailing lists you can subscribe to for security notifications. Source code hosting sites often offer RSS feeds for new releases.<br />
<br />
=== Rebuilding packages ===<br />
<br />
Packages can be rebuilt and stripped of undesired functions and features as a means to reduce attack surface. For example, {{Pkg|bzip2}} can be rebuilt without {{ic|bzip2recover}} in an attempt to circumvent [https://security.archlinux.org/CVE-2016-3189 CVE-2016-3189]. Custom hardening flags can also be applied either manually or via a wrapper.<br />
<br />
== See also ==<br />
<br />
* [https://security.archlinux.org/ Arch Linux Security Tracker]<br />
* [https://wiki.centos.org/HowTos/OS_Protection CentOS Wiki: OS Protection]<br />
* [https://www.ibm.com/developerworks/linux/tutorials/l-harden-desktop/index.html Hardening the Linux desktop]<br />
* [https://www.ibm.com/developerworks/linux/tutorials/l-harden-server/index.html Hardening the Linux server]<br />
* [https://github.com/lfit/itpol/blob/master/linux-workstation-security.md Linux Foundation: Linux workstation security checklist]<br />
* [https://www.privacytools.io/ privacytools.io Privacy Resources]<br />
* [https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Security_Guide/ Red Hat Enterprise Linux 7 Security Guide]<br />
* [https://www.debian.org/doc/manuals/securing-debian-manual/index.en.html Securing Debian Manual]<br />
* [https://web.archive.org/web/20140220055801/http://crunchbang.org:80/forums/viewtopic.php?id=24722 The paranoid #! Security Guide]</div>Bitfehlerhttps://wiki.archlinux.org/index.php?title=Talk:Arch_Linux_AMIs_for_Amazon_Web_Services&diff=645627Talk:Arch Linux AMIs for Amazon Web Services2020-12-14T17:17:19Z<p>Bitfehler: Response to Qqsullivan's question</p>
<hr />
<div>I also updated the page, removed outdated information, added another link. I also removed the merging note, as I think having a page about AMIs is very valuable. In fact, it would be great if Arch were to offer "official" AMIs, like some other distros do. But until then, it is at least great to have this page for people looking for that. <br />
[[User:Bitfehler|Bitfehler]] ([[User talk:Bitfehler|talk]]) 10:40, 15 April 2019 (UTC)<br />
<br />
I updated the page, and most likely keep it updated.. please remove the outdated logo.<br />
[[User:Rek2|Rek2]] ([[User talk:Rek2|talk]]) 01:43, 7 February 2017 (UTC)<br />
<br />
<br />
<br />
<br />
Compiling the arch linux kernel for PV-GRUB<br />
<br />
http://worldmodscode.wordpress.com/2011/10/28/ec2-ami-creation-without-magic/<br />
<br />
#It's comprehensive<br />
#It's recent<br />
#It includes compiling the arch linux kernel for PV-GRUB<br />
<br />
<br />
== New Page: Creating Amazon Machine Instances (AMIs) for Arch ==<br />
<br />
I'm interested in writing a wiki page on how to create<br />
an Arch Linux AMI (Amazon machine instance) for AWS EC2.<br />
Would that be useful?<br />
<br />
This current page is useful for people who want to use an existing Arch<br />
AMI. It does not discuss how someone can create their own AMI.<br />
The Uplink Labs webpage has some super helpful notes,<br />
but a lot is missing.<br />
<br />
Thoughts?<br />
[[User:Qqsullivan|Qqsullivan]] ([[User talk:Qqsullivan|talk]]) 15:38, 14 December 2020 (UTC)<br />
<br />
Did you see the link to the Gitlab project below the Uplink Labs link? I maintain it and it contains both code and explanations of how to do it. PRs or issues welcome if anything is not working. If you think this is something that should be maintained in the wiki itself, why not, but it's a lot of content and also somewhat of a moving target. [[User:Bitfehler|Bitfehler]] ([[User talk:Bitfehler|talk]]) 17:17, 14 December 2020 (UTC)</div>Bitfehlerhttps://wiki.archlinux.org/index.php?title=Cloud-init&diff=594600Cloud-init2020-01-11T13:43:58Z<p>Bitfehler: Update cloud-init configuration documentation, a lot has changed here recently</p>
<hr />
<div>[[Category:Virtualization]]<br />
[[Category:Networking]]<br />
[[ja:Cloud-init]]<br />
[https://cloud-init.io/ Cloud-init] is a package that contains utilities for early initialization of cloud instances. It is needed in Arch Linux images that are built with the intention of being launched in cloud environments like [[OpenStack]], [[AWS]] etc.<br />
<br />
== Installation ==<br />
<br />
[[Install]] the {{Pkg|cloud-init}} package.<br />
<br />
If you intend to use the [https://cloudinit.readthedocs.io/en/latest/topics/modules.html#growpart growpart module] you will also need the {{AUR|growpart}} package.<br />
<br />
== Configuration ==<br />
<br />
This section only discusses the most basic settings. For a full list of available configuration options, please see the [https://cloudinit.readthedocs.io cloud-init documentation].<br />
<br />
The main configuration file is {{ic|/etc/cloud/cloud.cfg}}. Optionally, additional {{ic|*.cfg}} files to be loaded can be placed in {{ic|/etc/cloud/cloud.cfg.d}}. All of their contents will be [https://cloudinit.readthedocs.io/en/latest/topics/merging.html merged].<br />
<br />
The default configuration shipped with cloud-init 19.3 and later should work out of the box with most major cloud environments. In rough terms, it does the following:<br />
<br />
* Disable the root user, create a user {{ic|arch}} for logging in<br />
* Rely on cloud-init's built-in detection for data sources<br />
* Run all modules known to work on Arch Linux <br />
<br />
Depending on the use case, the default configuration might need to be adapted.<br />
<br />
=== Default user configuration ===<br />
<br />
As of January 2020, the configuration includes the following contents (comments omitted for brevity):<br />
<br />
users:<br />
- default<br />
<br />
The users to be added to the system. The special name {{ic|default}} is just a reference to the {{ic|default_user}} in the {{ic|sytem_info}} section (see below), but [https://cloudinit.readthedocs.io/en/latest/topics/examples.html#including-users-and-groups the syntax] supports configuring arbitrary users with many options. The first user in this list will be considered the "default" user by other modules, for example the one that sets up SSH keys passed in from the cloud environment.<br />
<br />
disable_root: true<br />
<br />
Disable root SSH access. You may also delete the root user password on the cloud image:<br />
<br />
# passwd -d root<br />
<br />
system_info:<br />
default_user:<br />
name: arch<br />
lock_passwd: True<br />
gecos: arch Cloud User<br />
groups: [wheel, users]<br />
sudo: ["ALL=(ALL) NOPASSWD:ALL"]<br />
shell: /bin/bash<br />
<br />
This is the specification of the distribution's default user:<br />
* the default user's name will be {{ic|arch}}<br />
* the default user is password locked, which means you can only log into the instance with the SSH keys configured during boot<br />
* the default user will be added to the groups {{ic|users}} and {{ic|wheel}}<br />
* the default user is allowed passwordless {{ic|sudo}} usage<br />
* the default user's shell is {{ic|/bin/bash}}<br />
<br />
Note that the user specified here will only be created if the special user "default" is included in the {{ic|users:}} section above (or the section is omitted entirely).<br />
<br />
=== Configuring data sources ===<br />
<br />
Data Sources define how the instance metadata is pulled during boot. This depends on the cloud environment (OpenStack, AWS, OpenNebula etc.) you are running your instance in. Under the hood, this translates to a corresponding module which implements a few methods defined in a common interface.<br />
<br />
The default config specifies no data sources, which means that cloud-init will attempt to auto-detect the cloud environment. However, some environments cannot be detected or may require special configuration to work. In this case, the data sources to be used can be explictly specified and configured. Refer to the [https://cloudinit.readthedocs.io/en/latest/topics/datasources.html#known-sources list of known data sources] in the documentation.<br />
<br />
To specify a list of data sources to be used in your {{ic|/etc/cloud/cloud.cfg}} add something like this:<br />
<br />
datasource_list: [ NoCloud, ConfigDrive, OpenNebula, Azure, AltCloud, OVF, MAAS, GCE, OpenStack, CloudSigma, Ec2, CloudStack, None ]<br />
<br />
This instructs cloud-init what modules to load while trying to download instance metadata. Optionally further configuration parameters may be passed specific to each datasource as follows:<br />
<br />
datasource:<br />
OpenStack:<br />
metadata_urls: [ '<nowiki>http://169.254.169.254:80</nowiki>' ]<br />
dsmode: net<br />
<br />
The above configuration tells OpenStack datasource to use the url {{ic|<nowiki>http://169.254.169.254:80</nowiki>}} to download metadata and to run after network initialization, both of which are the default behaviour and may be omitted.<br />
<br />
=== Modules ===<br />
<br />
Cloud-init comes with a [https://cloudinit.readthedocs.io/en/latest/topics/modules.html set of modules] the can be enabled or disabled in the configuration. The default config enables all modules that are known to work on Arch Linux. Omitted modules include e.g. those specific to other distributions or operating systems.<br />
<br />
The fact that a module is enabled usually does not mean that it will actually do anything. It will however check if any configuration relevant to it was passed in, e.g. from the cloud environment via the data source. Only then it will attempt to act. As such, enabling all modules usually helps to maximize compatibility with cloud environments. Nevertheless, modules known to be not needed can be removed from configuration, e.g. to improve start-up times. You can use {{ic|cloud-init analyze}} on a booted instance to see how much time was spent on individual modules.<br />
<br />
Some modules declare to cloud-init which distros they have been verified for. Even if you specify that you want to run them, they will refuse to run unless the distro specified in {{ic|cloud.cfg}} is one of the verified distros for that module. If you need to override this behaviour to run a module on Arch anyway, add the module to the {{ic|unverified_modules}} section in the cloud config, e.g.:<br />
<br />
unverified_modules: ['ssh-import-id']<br />
<br />
== Systemd integration ==<br />
<br />
Package cloud-init provides four systemd [https://www.freedesktop.org/software/systemd/man/systemd.service.html services], two systemd [https://www.freedesktop.org/software/systemd/man/systemd.target.html targets], and a systemd [https://www.freedesktop.org/software/systemd/man/systemd.generator.html generator], whose dependencies are constructed in a way that they are activated in the sequence listed:<br />
* {{ic|cloud-init-generator}}. Determines availability of any data source and enables or disables {{ic|cloud-init.target}}<br />
* {{ic|cloud-init-local.service}}. Only requires the filesystems to be up. Executes {{ic|cloud-init init --local}}<br />
* {{ic|cloud-init.service}}. Requires the network to be up. Executes {{ic|cloud-init init}}<br />
* {{ic|cloud-config.target}}. Corresponds to the cloud-config upstart event "to inform third parties that cloud-config is available"<br />
* {{ic|cloud-config.service}}. Executes {{ic|1=cloud-init modules --mode=config}}<br />
* {{ic|cloud-final.service}}. Executes {{ic|1=cloud-init modules --mode=final}}<br />
* {{ic|cloud-init.target}}. Reached when all services have been started<br />
<br />
The [[Arch_Linux_AMIs_for_Amazon_Web_Services|Uplink Labs EC2 images]] have all of them enabled, although that appears to be overkill due to the dependencies. When preparing an image, enabling {{ic|cloud-init.service}} and {{ic|cloud-final.service}} should be sufficient. Note that this does not mean that the cloud-init services will actually be run - that still depends on the generator enabling the {{ic|cloud-init.target}} on early boot.<br />
<br />
See also the [https://cloudinit.readthedocs.io/en/latest/topics/boot.html cloud-init boot stages documentation] for more info.</div>Bitfehlerhttps://wiki.archlinux.org/index.php?title=Cloud-init&diff=594415Cloud-init2020-01-10T22:04:40Z<p>Bitfehler: /* Installation */ Remove mention of netplan, it is now a hard dependency</p>
<hr />
<div>[[Category:Virtualization]]<br />
[[Category:Networking]]<br />
[[ja:Cloud-init]]<br />
[https://cloud-init.io/ Cloud-init] is a package that contains utilities for early initialization of cloud instances. It is needed in Arch Linux images that are built with the intention of being launched in cloud environments like [[OpenStack]], [[AWS]] etc.<br />
<br />
== Installation ==<br />
<br />
[[Install]] the {{Pkg|cloud-init}} package.<br />
<br />
If you intend to use the [https://cloudinit.readthedocs.io/en/latest/topics/modules.html#growpart growpart module] you will also need the {{AUR|growpart}} package.<br />
<br />
== Configuration ==<br />
<br />
This section only discussed the most basic settings. For a full list of available configuration options, please see the [https://cloudinit.readthedocs.io cloud-init documentation].<br />
<br />
In order to make an Arch image cloud ready, a few steps have to be followed:<br />
<br />
* Create a default user. You can login to your instance as this user. We will create and use a user called {{ic|arch}}.<br />
* Install [[sudo]] and add the default user to sudo group. This can be used later to execute commands as privileged user.<br />
* Enable password less sudo for the default user.<br />
* Configure cloud-init to pull instance metadata to configure the instance. This includes, but is not limited to:<br />
** Setting up the instance {{ic|hostname}}<br />
** Configuring instance's {{ic|resolv.conf}}<br />
** Configuring {{ic|~/.ssh/authorized_keys}} file for the default user <br />
<br />
The cloud-init's main configuration file is {{ic|/etc/cloud/cloud.cfg}}. Optionally, the user can place additional {{ic|*.cfg}} files in {{ic|/etc/cloud/cloud.cfg.d}} to be loaded.<br />
<br />
=== Default user configuration ===<br />
<br />
As of September 2019, the default {{ic|/etc/cloud/cloud.cfg}} includes the following contents:<br />
<br />
users:<br />
- default<br />
<br />
This tells cloud-init to use the user configured under {{ic|system_info}} > {{ic|default_user}} as the default user:<br />
<br />
system_info:<br />
distro: arch<br />
default_user:<br />
name: arch <br />
lock_passwd: true<br />
gecos: Archlinux<br />
groups: [users, power, audio, video, wheel]<br />
sudo: ["ALL=(ALL) NOPASSWD:ALL"]<br />
shell: /bin/bash<br />
<br />
Under {{ic|system_info}} we specify the distro as "arch". This will instruct cloud-init to use {{ic|arch.py}} module for configuration. Further we specify that:<br />
<br />
* the default user's name would be {{ic|arch}}<br />
* the default user is password locked, which means you can not login to the instance without the ssh keys configured during boot<br />
* the default user should be added to the groups {{ic|users}}, {{ic|power}}, {{ic|audio}}, {{ic|video}}, {{ic|wheel}}<br />
* the default user is allowed passwordless sudo usage<br />
* the default user's shell is {{ic|/bin/bash}}<br />
<br />
=== Disable login as root ===<br />
<br />
To do this you can specify in {{ic|/etc/cloud/cloud.cfg}}:<br />
disable_root: true<br />
<br />
You may also delete the root user password:<br />
# passwd -d root<br />
<br />
Do not perform this step unless you are sure the configuration in previous section works. Otherwise you might be completely locked out of your instance.<br />
<br />
=== Configuring data sources ===<br />
<br />
Data Sources define how the instance metadata is pulled during boot. This depends on what cloud (OpenStack, AWS, OpenNebula etc.) you are running your instance on. Under the hood this translates to a corresponding module which implement a few methods defined in a common interface. Edit your {{ic|/etc/cloud/cloud.cfg}} to have the below contents:<br />
datasource_list: [ NoCloud, ConfigDrive, OpenNebula, Azure, AltCloud, OVF, MAAS, GCE, OpenStack, CloudSigma, Ec2, CloudStack, None ]<br />
<br />
This instructs cloud-init what modules to load while trying to download instance metadata. Optionally further configuration parameters may be passed specific to each datasource as below:<br />
<br />
datasource:<br />
OpenStack:<br />
metadata_urls: [ '<nowiki>http://169.254.169.254:80</nowiki>' ]<br />
dsmode: net<br />
<br />
The above configuration tells OpenStack datasource to use the url {{ic|<nowiki>http://169.254.169.254:80</nowiki>}} to download metadata and to run after network initialization, both of which are the default behaviour and may be omitted.<br />
<br />
== Other sections in cloud.cfg ==<br />
<br />
{{ic|cloud.cfg}} defines several other sections which includes but not limited to {{ic|cloud_init_modules}}, {{ic|cloud_config_modules}} and {{ic|cloud_final_modules}} that define the modules that would be run at various stages during instance initialization. These modules are loaded dynamically from the path {{ic|/usr/lib/python2.7/site-packages/cloudinit/config/}} and run at boot time. The user may define their own modules and configure them to be called during every boot like say to:<br />
<br />
* perform disk resize<br />
* perform package update<br />
etc.<br />
<br />
The various modules declare to cloud-init which distros they have been verified for. Even if you specify that you want to run them, they will refuse to run unless the distro specified in {{ic|cloud.cfg}} is one of the verified distros for the given module. If you want to run a module on Arch anyway that does not specify {{ic|arch}}, add the module to the {{ic|unverified_modules:}} section in {{ic|cloud.cfg}}, e.g.:<br />
<br />
unverified_modules: ['ssh-import-id']<br />
<br />
== Systemd integration ==<br />
<br />
Package cloud-init provides four systemd [https://www.freedesktop.org/software/systemd/man/systemd.service.html services], two systemd [https://www.freedesktop.org/software/systemd/man/systemd.target.html targets], and a systemd [https://www.freedesktop.org/software/systemd/man/systemd.generator.html generator], whose dependencies are constructed in a way that they are activated in the sequence listed:<br />
* {{ic|cloud-init-generator}}. Determines availability of any data source and enables or disables {{ic|cloud-init.target}}<br />
* {{ic|cloud-init-local.service}}. Only requires the filesystems to be up. Executes {{ic|cloud-init init --local}}<br />
* {{ic|cloud-init.service}}. Requires the network to be up. Executes {{ic|cloud-init init}}<br />
* {{ic|cloud-config.target}}. Corresponds to the cloud-config upstart event "to inform third parties that cloud-config is available"<br />
* {{ic|cloud-config.service}}. Executes {{ic|1=cloud-init modules --mode=config}}<br />
* {{ic|cloud-final.service}}. Executes {{ic|1=cloud-init modules --mode=final}}<br />
* {{ic|cloud-init.target}}. Reached when all services have been started<br />
<br />
The [[Arch_Linux_AMIs_for_Amazon_Web_Services|Uplink Labs EC2 images]] have all of them enabled, although that appears to be overkill due to the dependencies. When preparing an image, enabling {{ic|cloud-init.service}} and {{ic|cloud-final.service}} should be sufficient. Note that this does not mean that the cloud-init services will actually be run - that still depends on the generator enabling the {{ic|cloud-init.target}} on early boot.<br />
<br />
See also the [https://cloudinit.readthedocs.io/en/latest/topics/boot.html cloud-init boot stages documentation] for more info.</div>Bitfehlerhttps://wiki.archlinux.org/index.php?title=Cloud-init&diff=586853Cloud-init2019-10-21T09:24:49Z<p>Bitfehler: cloud-init moved back into community</p>
<hr />
<div>[[Category:Virtualization]]<br />
[[Category:Networking]]<br />
[[ja:Cloud-init]]<br />
[https://cloud-init.io/ Cloud-init] is a package that contains utilities for early initialization of cloud instances. It is needed in Arch Linux images that are built with the intention of being launched in cloud environments like [[OpenStack]], [[AWS]] etc.<br />
<br />
== Installation ==<br />
<br />
[[Install]] the {{Pkg|cloud-init}} package.<br />
<br />
If you intend to use the [https://cloudinit.readthedocs.io/en/latest/topics/modules.html#growpart growpart module] you will also need the {{AUR|growpart}} package.<br />
<br />
As of cloud-init 19.2 you can also use [https://netplan.io/ netplan] to render the network config. Install the {{AUR|netplan}} package to do so.<br />
<br />
== Configuration ==<br />
<br />
This section only discussed the most basic settings. For a full list of available configuration options, please see the [https://cloudinit.readthedocs.io cloud-init documentation].<br />
<br />
In order to make an Arch image cloud ready, a few steps have to be followed:<br />
<br />
* Create a default user. You can login to your instance as this user. We will create and use a user called {{ic|arch}}.<br />
* Install [[sudo]] and add the default user to sudo group. This can be used later to execute commands as privileged user.<br />
* Enable password less sudo for the default user.<br />
* Configure cloud-init to pull instance metadata to configure the instance. This includes, but is not limited to:<br />
** Setting up the instance {{ic|hostname}}<br />
** Configuring instance's {{ic|resolv.conf}}<br />
** Configuring {{ic|~/.ssh/authorized_keys}} file for the default user <br />
<br />
The cloud-init's main configuration file is {{ic|/etc/cloud/cloud.cfg}}. Optionally, the user can place additional {{ic|*.cfg}} files in {{ic|/etc/cloud/cloud.cfg.d}} to be loaded.<br />
<br />
=== Default user configuration ===<br />
<br />
As of September 2019, the default {{ic|/etc/cloud/cloud.cfg}} includes the following contents:<br />
<br />
users:<br />
- default<br />
<br />
This tells cloud-init to use the user configured under {{ic|system_info}} > {{ic|default_user}} as the default user:<br />
<br />
system_info:<br />
distro: arch<br />
default_user:<br />
name: arch <br />
lock_passwd: true<br />
gecos: Archlinux<br />
groups: [users, power, audio, video, wheel]<br />
sudo: ["ALL=(ALL) NOPASSWD:ALL"]<br />
shell: /bin/bash<br />
<br />
Under {{ic|system_info}} we specify the distro as "arch". This will instruct cloud-init to use {{ic|arch.py}} module for configuration. Further we specify that:<br />
<br />
* the default user's name would be {{ic|arch}}<br />
* the default user is password locked, which means you can not login to the instance without the ssh keys configured during boot<br />
* the default user should be added to the groups {{ic|users}}, {{ic|power}}, {{ic|audio}}, {{ic|video}}, {{ic|wheel}}<br />
* the default user is allowed passwordless sudo usage<br />
* the default user's shell is {{ic|/bin/bash}}<br />
<br />
=== Disable login as root ===<br />
<br />
To do this you can specify in {{ic|/etc/cloud/cloud.cfg}}:<br />
disable_root: true<br />
<br />
You may also delete the root user password:<br />
# passwd -d root<br />
<br />
Do not perform this step unless you are sure the configuration in previous section works. Otherwise you might be completely locked out of your instance.<br />
<br />
=== Configuring data sources ===<br />
<br />
Data Sources define how the instance metadata is pulled during boot. This depends on what cloud (OpenStack, AWS, OpenNebula etc.) you are running your instance on. Under the hood this translates to a corresponding module which implement a few methods defined in a common interface. Edit your {{ic|/etc/cloud/cloud.cfg}} to have the below contents:<br />
datasource_list: [ NoCloud, ConfigDrive, OpenNebula, Azure, AltCloud, OVF, MAAS, GCE, OpenStack, CloudSigma, Ec2, CloudStack, None ]<br />
<br />
This instructs cloud-init what modules to load while trying to download instance metadata. Optionally further configuration parameters may be passed specific to each datasource as below:<br />
<br />
datasource:<br />
OpenStack:<br />
metadata_urls: [ '<nowiki>http://169.254.169.254:80</nowiki>' ]<br />
dsmode: net<br />
<br />
The above configuration tells OpenStack datasource to use the url {{ic|<nowiki>http://169.254.169.254:80</nowiki>}} to download metadata and to run after network initialization, both of which are the default behaviour and may be omitted.<br />
<br />
== Other sections in cloud.cfg ==<br />
<br />
{{ic|cloud.cfg}} defines several other sections which includes but not limited to {{ic|cloud_init_modules}}, {{ic|cloud_config_modules}} and {{ic|cloud_final_modules}} that define the modules that would be run at various stages during instance initialization. These modules are loaded dynamically from the path {{ic|/usr/lib/python2.7/site-packages/cloudinit/config/}} and run at boot time. The user may define their own modules and configure them to be called during every boot like say to:<br />
<br />
* perform disk resize<br />
* perform package update<br />
etc.<br />
<br />
The various modules declare to cloud-init which distros they have been verified for. Even if you specify that you want to run them, they will refuse to run unless the distro specified in {{ic|cloud.cfg}} is one of the verified distros for the given module. If you want to run a module on Arch anyway that does not specify {{ic|arch}}, add the module to the {{ic|unverified_modules:}} section in {{ic|cloud.cfg}}, e.g.:<br />
<br />
unverified_modules: ['ssh-import-id']<br />
<br />
== Systemd integration ==<br />
<br />
Package cloud-init provides four systemd [https://www.freedesktop.org/software/systemd/man/systemd.service.html services], two systemd [https://www.freedesktop.org/software/systemd/man/systemd.target.html targets], and a systemd [https://www.freedesktop.org/software/systemd/man/systemd.generator.html generator], whose dependencies are constructed in a way that they are activated in the sequence listed:<br />
* {{ic|cloud-init-generator}}. Determines availability of any data source and enables or disables {{ic|cloud-init.target}}<br />
* {{ic|cloud-init-local.service}}. Only requires the filesystems to be up. Executes {{ic|cloud-init init --local}}<br />
* {{ic|cloud-init.service}}. Requires the network to be up. Executes {{ic|cloud-init init}}<br />
* {{ic|cloud-config.target}}. Corresponds to the cloud-config upstart event "to inform third parties that cloud-config is available"<br />
* {{ic|cloud-config.service}}. Executes {{ic|1=cloud-init modules --mode=config}}<br />
* {{ic|cloud-final.service}}. Executes {{ic|1=cloud-init modules --mode=final}}<br />
* {{ic|cloud-init.target}}. Reached when all services have been started<br />
<br />
The [[Arch_Linux_AMIs_for_Amazon_Web_Services|Uplink Labs EC2 images]] have all of them enabled, although that appears to be overkill due to the dependencies. When preparing an image, enabling {{ic|cloud-init.service}} and {{ic|cloud-final.service}} should be sufficient. Note that this does not mean that the cloud-init services will actually be run - that still depends on the generator enabling the {{ic|cloud-init.target}} on early boot.<br />
<br />
See also the [https://cloudinit.readthedocs.io/en/latest/topics/boot.html cloud-init boot stages documentation] for more info.</div>Bitfehlerhttps://wiki.archlinux.org/index.php?title=Cloud-init&diff=582809Cloud-init2019-09-18T12:44:18Z<p>Bitfehler: FIx required version for netplan rendering</p>
<hr />
<div>[[Category:Virtualization]]<br />
[[Category:Networking]]<br />
[[ja:Cloud-init]]<br />
[https://cloud-init.io/ Cloud-init] is a package that contains utilities for early initialization of cloud instances. It is needed in Arch Linux images that are built with the intention of being launched in cloud environments like [[OpenStack]], [[AWS]] etc.<br />
<br />
== Installation ==<br />
<br />
[[Install]] the {{AUR|cloud-init}} package.<br />
<br />
If you intend to use the [https://cloudinit.readthedocs.io/en/latest/topics/modules.html#growpart growpart module] you will also need the {{AUR|growpart}} package.<br />
<br />
As of cloud-init 19.2 you can also use [https://netplan.io/ netplan] to render the network config. Install the {{AUR|netplan}} package to do so.<br />
<br />
== Configuration ==<br />
<br />
This section only discussed the most basic settings. For a full list of available configuration options, please see the [https://cloudinit.readthedocs.io cloud-init documentation].<br />
<br />
In order to make an Arch image cloud ready, a few steps have to be followed:<br />
<br />
* Create a default user. You can login to your instance as this user. We will create and use a user called {{ic|arch}}.<br />
* Install [[sudo]] and add the default user to sudo group. This can be used later to execute commands as privileged user.<br />
* Enable password less sudo for the default user.<br />
* Configure cloud-init to pull instance metadata to configure the instance. This includes, but is not limited to:<br />
** Setting up the instance {{ic|hostname}}<br />
** Configuring instance's {{ic|resolv.conf}}<br />
** Configuring {{ic|~/.ssh/authorized_keys}} file for the default user <br />
<br />
The cloud-init's main configuration file is {{ic|/etc/cloud/cloud.cfg}}. Optionally, the user can place additional {{ic|*.cfg}} files in {{ic|/etc/cloud/cloud.cfg.d}} to be loaded.<br />
<br />
=== Default user configuration ===<br />
<br />
As of September 2019, the default {{ic|/etc/cloud/cloud.cfg}} includes the following contents:<br />
<br />
users:<br />
- default<br />
<br />
This tells cloud-init to use the user configured under {{ic|system_info}} > {{ic|default_user}} as the default user:<br />
<br />
system_info:<br />
distro: arch<br />
default_user:<br />
name: arch <br />
lock_passwd: true<br />
gecos: Archlinux<br />
groups: [users, power, audio, video, wheel]<br />
sudo: ["ALL=(ALL) NOPASSWD:ALL"]<br />
shell: /bin/bash<br />
<br />
Under {{ic|system_info}} we specify the distro as "arch". This will instruct cloud-init to use {{ic|arch.py}} module for configuration. Further we specify that:<br />
<br />
* the default user's name would be {{ic|arch}}<br />
* the default user is password locked, which means you can not login to the instance without the ssh keys configured during boot<br />
* the default user should be added to the groups {{ic|users}}, {{ic|power}}, {{ic|audio}}, {{ic|video}}, {{ic|wheel}}<br />
* the default user is allowed passwordless sudo usage<br />
* the default user's shell is {{ic|/bin/bash}}<br />
<br />
=== Disable login as root ===<br />
<br />
To do this you can specify in {{ic|/etc/cloud/cloud.cfg}}:<br />
disable_root: true<br />
<br />
You may also delete the root user password:<br />
# passwd -d root<br />
<br />
Do not perform this step unless you are sure the configuration in previous section works. Otherwise you might be completely locked out of your instance.<br />
<br />
=== Configuring data sources ===<br />
<br />
Data Sources define how the instance metadata is pulled during boot. This depends on what cloud (OpenStack, AWS, OpenNebula etc.) you are running your instance on. Under the hood this translates to a corresponding module which implement a few methods defined in a common interface. Edit your {{ic|/etc/cloud/cloud.cfg}} to have the below contents:<br />
datasource_list: [ NoCloud, ConfigDrive, OpenNebula, Azure, AltCloud, OVF, MAAS, GCE, OpenStack, CloudSigma, Ec2, CloudStack, None ]<br />
<br />
This instructs cloud-init what modules to load while trying to download instance metadata. Optionally further configuration parameters may be passed specific to each datasource as below:<br />
<br />
datasource:<br />
OpenStack:<br />
metadata_urls: [ '<nowiki>http://169.254.169.254:80</nowiki>' ]<br />
dsmode: net<br />
<br />
The above configuration tells OpenStack datasource to use the url {{ic|<nowiki>http://169.254.169.254:80</nowiki>}} to download metadata and to run after network initialization, both of which are the default behaviour and may be omitted.<br />
<br />
== Other sections in cloud.cfg ==<br />
<br />
{{ic|cloud.cfg}} defines several other sections which includes but not limited to {{ic|cloud_init_modules}}, {{ic|cloud_config_modules}} and {{ic|cloud_final_modules}} that define the modules that would be run at various stages during instance initialization. These modules are loaded dynamically from the path {{ic|/usr/lib/python2.7/site-packages/cloudinit/config/}} and run at boot time. The user may define their own modules and configure them to be called during every boot like say to:<br />
<br />
* perform disk resize<br />
* perform package update<br />
etc.<br />
<br />
The various modules declare to cloud-init which distros they have been verified for. Even if you specify that you want to run them, they will refuse to run unless the distro specified in {{ic|cloud.cfg}} is one of the verified distros for the given module. If you want to run a module on Arch anyway that does not specify {{ic|arch}}, add the module to the {{ic|unverified_modules:}} section in {{ic|cloud.cfg}}, e.g.:<br />
<br />
unverified_modules: ['ssh-import-id']<br />
<br />
== Systemd integration ==<br />
<br />
Package cloud-init provides four systemd [https://www.freedesktop.org/software/systemd/man/systemd.service.html services], two systemd [https://www.freedesktop.org/software/systemd/man/systemd.target.html targets], and a systemd [https://www.freedesktop.org/software/systemd/man/systemd.generator.html generator], whose dependencies are constructed in a way that they are activated in the sequence listed:<br />
* {{ic|cloud-init-generator}}. Determines availability of any data source and enables or disables {{ic|cloud-init.target}}<br />
* {{ic|cloud-init-local.service}}. Only requires the filesystems to be up. Executes {{ic|cloud-init init --local}}<br />
* {{ic|cloud-init.service}}. Requires the network to be up. Executes {{ic|cloud-init init}}<br />
* {{ic|cloud-config.target}}. Corresponds to the cloud-config upstart event "to inform third parties that cloud-config is available"<br />
* {{ic|cloud-config.service}}. Executes {{ic|1=cloud-init modules --mode=config}}<br />
* {{ic|cloud-final.service}}. Executes {{ic|1=cloud-init modules --mode=final}}<br />
* {{ic|cloud-init.target}}. Reached when all services have been started<br />
<br />
The [[Arch_Linux_AMIs_for_Amazon_Web_Services|Uplink Labs EC2 images]] have all of them enabled, although that appears to be overkill due to the dependencies. When preparing an image, enabling {{ic|cloud-init.service}} and {{ic|cloud-final.service}} should be sufficient. Note that this does not mean that the cloud-init services will actually be run - that still depends on the generator enabling the {{ic|cloud-init.target}} on early boot.<br />
<br />
See also the [https://cloudinit.readthedocs.io/en/latest/topics/boot.html cloud-init boot stages documentation] for more info.</div>Bitfehlerhttps://wiki.archlinux.org/index.php?title=Cloud-init&diff=582788Cloud-init2019-09-18T11:30:58Z<p>Bitfehler: Reflect changes to the package's shipped default config</p>
<hr />
<div>[[Category:Virtualization]]<br />
[[Category:Networking]]<br />
[[ja:Cloud-init]]<br />
[https://cloud-init.io/ Cloud-init] is a package that contains utilities for early initialization of cloud instances. It is needed in Arch Linux images that are built with the intention of being launched in cloud environments like [[OpenStack]], [[AWS]] etc.<br />
<br />
== Installation ==<br />
<br />
[[Install]] the {{AUR|cloud-init}} package.<br />
<br />
If you intend to use the [https://cloudinit.readthedocs.io/en/latest/topics/modules.html#growpart growpart module] you will also need the {{AUR|growpart}} package.<br />
<br />
As of cloud-init 19.1 you can also use [https://netplan.io/ netplan] to render the network config. Install the {{AUR|netplan}} package to do so.<br />
<br />
== Configuration ==<br />
<br />
This section only discussed the most basic settings. For a full list of available configuration options, please see the [https://cloudinit.readthedocs.io cloud-init documentation].<br />
<br />
In order to make an Arch image cloud ready, a few steps have to be followed:<br />
<br />
* Create a default user. You can login to your instance as this user. We will create and use a user called {{ic|arch}}.<br />
* Install [[sudo]] and add the default user to sudo group. This can be used later to execute commands as privileged user.<br />
* Enable password less sudo for the default user.<br />
* Configure cloud-init to pull instance metadata to configure the instance. This includes, but is not limited to:<br />
** Setting up the instance {{ic|hostname}}<br />
** Configuring instance's {{ic|resolv.conf}}<br />
** Configuring {{ic|~/.ssh/authorized_keys}} file for the default user <br />
<br />
The cloud-init's main configuration file is {{ic|/etc/cloud/cloud.cfg}}. Optionally, the user can place additional {{ic|*.cfg}} files in {{ic|/etc/cloud/cloud.cfg.d}} to be loaded.<br />
<br />
=== Default user configuration ===<br />
<br />
As of September 2019, the default {{ic|/etc/cloud/cloud.cfg}} includes the following contents:<br />
<br />
users:<br />
- default<br />
<br />
This tells cloud-init to use the user configured under {{ic|system_info}} > {{ic|default_user}} as the default user:<br />
<br />
system_info:<br />
distro: arch<br />
default_user:<br />
name: arch <br />
lock_passwd: true<br />
gecos: Archlinux<br />
groups: [users, power, audio, video, wheel]<br />
sudo: ["ALL=(ALL) NOPASSWD:ALL"]<br />
shell: /bin/bash<br />
<br />
Under {{ic|system_info}} we specify the distro as "arch". This will instruct cloud-init to use {{ic|arch.py}} module for configuration. Further we specify that:<br />
<br />
* the default user's name would be {{ic|arch}}<br />
* the default user is password locked, which means you can not login to the instance without the ssh keys configured during boot<br />
* the default user should be added to the groups {{ic|users}}, {{ic|power}}, {{ic|audio}}, {{ic|video}}, {{ic|wheel}}<br />
* the default user is allowed passwordless sudo usage<br />
* the default user's shell is {{ic|/bin/bash}}<br />
<br />
=== Disable login as root ===<br />
<br />
To do this you can specify in {{ic|/etc/cloud/cloud.cfg}}:<br />
disable_root: true<br />
<br />
You may also delete the root user password:<br />
# passwd -d root<br />
<br />
Do not perform this step unless you are sure the configuration in previous section works. Otherwise you might be completely locked out of your instance.<br />
<br />
=== Configuring data sources ===<br />
<br />
Data Sources define how the instance metadata is pulled during boot. This depends on what cloud (OpenStack, AWS, OpenNebula etc.) you are running your instance on. Under the hood this translates to a corresponding module which implement a few methods defined in a common interface. Edit your {{ic|/etc/cloud/cloud.cfg}} to have the below contents:<br />
datasource_list: [ NoCloud, ConfigDrive, OpenNebula, Azure, AltCloud, OVF, MAAS, GCE, OpenStack, CloudSigma, Ec2, CloudStack, None ]<br />
<br />
This instructs cloud-init what modules to load while trying to download instance metadata. Optionally further configuration parameters may be passed specific to each datasource as below:<br />
<br />
datasource:<br />
OpenStack:<br />
metadata_urls: [ '<nowiki>http://169.254.169.254:80</nowiki>' ]<br />
dsmode: net<br />
<br />
The above configuration tells OpenStack datasource to use the url {{ic|<nowiki>http://169.254.169.254:80</nowiki>}} to download metadata and to run after network initialization, both of which are the default behaviour and may be omitted.<br />
<br />
== Other sections in cloud.cfg ==<br />
<br />
{{ic|cloud.cfg}} defines several other sections which includes but not limited to {{ic|cloud_init_modules}}, {{ic|cloud_config_modules}} and {{ic|cloud_final_modules}} that define the modules that would be run at various stages during instance initialization. These modules are loaded dynamically from the path {{ic|/usr/lib/python2.7/site-packages/cloudinit/config/}} and run at boot time. The user may define their own modules and configure them to be called during every boot like say to:<br />
<br />
* perform disk resize<br />
* perform package update<br />
etc.<br />
<br />
The various modules declare to cloud-init which distros they have been verified for. Even if you specify that you want to run them, they will refuse to run unless the distro specified in {{ic|cloud.cfg}} is one of the verified distros for the given module. If you want to run a module on Arch anyway that does not specify {{ic|arch}}, add the module to the {{ic|unverified_modules:}} section in {{ic|cloud.cfg}}, e.g.:<br />
<br />
unverified_modules: ['ssh-import-id']<br />
<br />
== Systemd integration ==<br />
<br />
Package cloud-init provides four systemd [https://www.freedesktop.org/software/systemd/man/systemd.service.html services], two systemd [https://www.freedesktop.org/software/systemd/man/systemd.target.html targets], and a systemd [https://www.freedesktop.org/software/systemd/man/systemd.generator.html generator], whose dependencies are constructed in a way that they are activated in the sequence listed:<br />
* {{ic|cloud-init-generator}}. Determines availability of any data source and enables or disables {{ic|cloud-init.target}}<br />
* {{ic|cloud-init-local.service}}. Only requires the filesystems to be up. Executes {{ic|cloud-init init --local}}<br />
* {{ic|cloud-init.service}}. Requires the network to be up. Executes {{ic|cloud-init init}}<br />
* {{ic|cloud-config.target}}. Corresponds to the cloud-config upstart event "to inform third parties that cloud-config is available"<br />
* {{ic|cloud-config.service}}. Executes {{ic|1=cloud-init modules --mode=config}}<br />
* {{ic|cloud-final.service}}. Executes {{ic|1=cloud-init modules --mode=final}}<br />
* {{ic|cloud-init.target}}. Reached when all services have been started<br />
<br />
The [[Arch_Linux_AMIs_for_Amazon_Web_Services|Uplink Labs EC2 images]] have all of them enabled, although that appears to be overkill due to the dependencies. When preparing an image, enabling {{ic|cloud-init.service}} and {{ic|cloud-final.service}} should be sufficient. Note that this does not mean that the cloud-init services will actually be run - that still depends on the generator enabling the {{ic|cloud-init.target}} on early boot.<br />
<br />
See also the [https://cloudinit.readthedocs.io/en/latest/topics/boot.html cloud-init boot stages documentation] for more info.</div>Bitfehlerhttps://wiki.archlinux.org/index.php?title=Cloud-init&diff=582779Cloud-init2019-09-18T11:22:50Z<p>Bitfehler: Add link to main cloud-init documentation</p>
<hr />
<div>[[Category:Virtualization]]<br />
[[Category:Networking]]<br />
[[ja:Cloud-init]]<br />
[https://cloud-init.io/ Cloud-init] is a package that contains utilities for early initialization of cloud instances. It is needed in Arch Linux images that are built with the intention of being launched in cloud environments like [[OpenStack]], [[AWS]] etc.<br />
<br />
== Installation ==<br />
<br />
[[Install]] the {{AUR|cloud-init}} package.<br />
<br />
If you intend to use the [https://cloudinit.readthedocs.io/en/latest/topics/modules.html#growpart growpart module] you will also need the {{AUR|growpart}} package.<br />
<br />
As of cloud-init 19.1 you can also use [https://netplan.io/ netplan] to render the network config. Install the {{AUR|netplan}} package to do so.<br />
<br />
== Configuration ==<br />
<br />
This section only discussed the most basic settings. For a full list of available configuration options, please see the [https://cloudinit.readthedocs.io cloud-init documentation].<br />
<br />
In order to make an Arch image cloud ready, a few steps have to be followed:<br />
<br />
* Create a default user. You can login to your instance as this user. We will create and use a user called {{ic|arch}}.<br />
* Install [[sudo]] and add the default user to sudo group. This can be used later to execute commands as privileged user.<br />
* Enable password less sudo for the default user.<br />
* Configure cloud-init to pull instance metadata to configure the instance. This includes, but is not limited to:<br />
** Setting up the instance {{ic|hostname}}<br />
** Configuring instance's {{ic|resolv.conf}}<br />
** Configuring {{ic|~/.ssh/authorized_keys}} file for the default user <br />
<br />
The cloud-init's main configuration file is {{ic|/etc/cloud/cloud.cfg}}. Optionally, the user can place additional {{ic|*.cfg}} files in {{ic|/etc/cloud/cloud.cfg.d}} to be loaded.<br />
<br />
=== Default user configuration ===<br />
<br />
As of February 2016, the default {{ic|/etc/cloud/cloud.cfg}} shipped with the package has not been adapted to Arch, and still states that the distro is Ubuntu, therefore it requires editing.<br />
<br />
Edit {{ic|/etc/cloud/cloud.cfg}} to have the following contents:<br />
<br />
users:<br />
- default<br />
<br />
This tells cloud-init to use the user configured under {{ic|system_info}} > {{ic|default_user}} as the default user:<br />
<br />
system_info:<br />
distro: arch<br />
default_user:<br />
name: arch <br />
lock_passwd: true<br />
gecos: Arch<br />
groups: [adm, audio, cdrom, dialout, dip, floppy, netdev, plugdev, sudo, video]<br />
sudo: ["ALL=(ALL) NOPASSWD:ALL"]<br />
shell: /bin/bash<br />
<br />
Under {{ic|system_info}} we specify the distro as "arch". This will instruct cloud-init to use {{ic|arch.py}} module for configuration. Further we specify that:<br />
<br />
* the default user's name would be {{ic|arch}}<br />
* the default user is password locked, which means you can not login to the instance without the ssh keys configured during boot<br />
* the default user should be added to the groups {{ic|adm}}, {{ic|audio}}, {{ic|cdrom}}, {{ic|dialout}}, {{ic|dip}}, {{ic|floppy}}, {{ic|netdev}}, {{ic|plugdev}}, {{ic|sudo}}, {{ic|video}}<br />
* the default user is allow passwordless sudo usage<br />
* the default user's shell is {{ic|/bin/bash}}<br />
<br />
=== Disable login as root ===<br />
<br />
To do this you can specify in {{ic|/etc/cloud/cloud.cfg}}:<br />
disable_root: true<br />
<br />
You may also delete the root user password:<br />
# passwd -d root<br />
<br />
Do not perform this step unless you are sure the configuration in previous section works. Otherwise you might be completely locked out of your instance.<br />
<br />
=== Configuring data sources ===<br />
<br />
Data Sources define how the instance metadata is pulled during boot. This depends on what cloud (OpenStack, AWS, OpenNebula etc.) you are running your instance on. Under the hood this translates to a corresponding module which implement a few methods defined in a common interface. Edit your {{ic|/etc/cloud/cloud.cfg}} to have the below contents:<br />
datasource_list: [ NoCloud, ConfigDrive, OpenNebula, Azure, AltCloud, OVF, MAAS, GCE, OpenStack, CloudSigma, Ec2, CloudStack, None ]<br />
<br />
This instructs cloud-init what modules to load while trying to download instance metadata. Optionally further configuration parameters may be passed specific to each datasource as below:<br />
<br />
datasource:<br />
OpenStack:<br />
metadata_urls: [ '<nowiki>http://169.254.169.254:80</nowiki>' ]<br />
dsmode: net<br />
<br />
The above configuration tells OpenStack datasource to use the url {{ic|<nowiki>http://169.254.169.254:80</nowiki>}} to download metadata and to run after network initialization, both of which are the default behaviour and may be omitted.<br />
<br />
== Other sections in cloud.cfg ==<br />
<br />
{{ic|cloud.cfg}} defines several other sections which includes but not limited to {{ic|cloud_init_modules}}, {{ic|cloud_config_modules}} and {{ic|cloud_final_modules}} that define the modules that would be run at various stages during instance initialization. These modules are loaded dynamically from the path {{ic|/usr/lib/python2.7/site-packages/cloudinit/config/}} and run at boot time. The user may define their own modules and configure them to be called during every boot like say to:<br />
<br />
* perform disk resize<br />
* perform package update<br />
etc.<br />
<br />
The various modules declare to cloud-init which distros they have been verified for. Even if you specify that you want to run them, they will refuse to run unless the distro specified in {{ic|cloud.cfg}} is one of the verified distros for the given module. If you want to run a module on Arch anyway that does not specify {{ic|arch}}, add the module to the {{ic|unverified_modules:}} section in {{ic|cloud.cfg}}, e.g.:<br />
<br />
unverified_modules: ['ssh-import-id']<br />
<br />
== Systemd integration ==<br />
<br />
Package cloud-init provides four systemd [https://www.freedesktop.org/software/systemd/man/systemd.service.html services], two systemd [https://www.freedesktop.org/software/systemd/man/systemd.target.html targets], and a systemd [https://www.freedesktop.org/software/systemd/man/systemd.generator.html generator], whose dependencies are constructed in a way that they are activated in the sequence listed:<br />
* {{ic|cloud-init-generator}}. Determines availability of any data source and enables or disables {{ic|cloud-init.target}}<br />
* {{ic|cloud-init-local.service}}. Only requires the filesystems to be up. Executes {{ic|cloud-init init --local}}<br />
* {{ic|cloud-init.service}}. Requires the network to be up. Executes {{ic|cloud-init init}}<br />
* {{ic|cloud-config.target}}. Corresponds to the cloud-config upstart event "to inform third parties that cloud-config is available"<br />
* {{ic|cloud-config.service}}. Executes {{ic|1=cloud-init modules --mode=config}}<br />
* {{ic|cloud-final.service}}. Executes {{ic|1=cloud-init modules --mode=final}}<br />
* {{ic|cloud-init.target}}. Reached when all services have been started<br />
<br />
The [[Arch_Linux_AMIs_for_Amazon_Web_Services|Uplink Labs EC2 images]] have all of them enabled, although that appears to be overkill due to the dependencies. When preparing an image, enabling {{ic|cloud-init.service}} and {{ic|cloud-final.service}} should be sufficient. Note that this does not mean that the cloud-init services will actually be run - that still depends on the generator enabling the {{ic|cloud-init.target}} on early boot.<br />
<br />
See also the [https://cloudinit.readthedocs.io/en/latest/topics/boot.html cloud-init boot stages documentation] for more info.</div>Bitfehlerhttps://wiki.archlinux.org/index.php?title=Cloud-init&diff=582777Cloud-init2019-09-18T11:19:12Z<p>Bitfehler: Minor grammar fixes</p>
<hr />
<div>[[Category:Virtualization]]<br />
[[Category:Networking]]<br />
[[ja:Cloud-init]]<br />
[https://cloud-init.io/ Cloud-init] is a package that contains utilities for early initialization of cloud instances. It is needed in Arch Linux images that are built with the intention of being launched in cloud environments like [[OpenStack]], [[AWS]] etc.<br />
<br />
== Installation ==<br />
<br />
[[Install]] the {{AUR|cloud-init}} package.<br />
<br />
If you intend to use the [https://cloudinit.readthedocs.io/en/latest/topics/modules.html#growpart growpart module] you will also need the {{AUR|growpart}} package.<br />
<br />
As of cloud-init 19.1 you can also use [https://netplan.io/ netplan] to render the network config. Install the {{AUR|netplan}} package to do so.<br />
<br />
== Configuration ==<br />
<br />
In order to make an Arch image cloud ready, a few steps have to be followed:<br />
<br />
* Create a default user. You can login to your instance as this user. We will create and use a user called {{ic|arch}}.<br />
* Install [[sudo]] and add the default user to sudo group. This can be used later to execute commands as privileged user.<br />
* Enable password less sudo for the default user.<br />
* Configure cloud-init to pull instance metadata to configure the instance. This includes, but is not limited to:<br />
** Setting up the instance {{ic|hostname}}<br />
** Configuring instance's {{ic|resolv.conf}}<br />
** Configuring {{ic|~/.ssh/authorized_keys}} file for the default user <br />
<br />
The cloud-init's main configuration file is {{ic|/etc/cloud/cloud.cfg}}. Optionally, the user can place additional {{ic|*.cfg}} files in {{ic|/etc/cloud/cloud.cfg.d}} to be loaded.<br />
<br />
=== Default user configuration ===<br />
<br />
As of February 2016, the default {{ic|/etc/cloud/cloud.cfg}} shipped with the package has not been adapted to Arch, and still states that the distro is Ubuntu, therefore it requires editing.<br />
<br />
Edit {{ic|/etc/cloud/cloud.cfg}} to have the following contents:<br />
<br />
users:<br />
- default<br />
<br />
This tells cloud-init to use the user configured under {{ic|system_info}} > {{ic|default_user}} as the default user:<br />
<br />
system_info:<br />
distro: arch<br />
default_user:<br />
name: arch <br />
lock_passwd: true<br />
gecos: Arch<br />
groups: [adm, audio, cdrom, dialout, dip, floppy, netdev, plugdev, sudo, video]<br />
sudo: ["ALL=(ALL) NOPASSWD:ALL"]<br />
shell: /bin/bash<br />
<br />
Under {{ic|system_info}} we specify the distro as "arch". This will instruct cloud-init to use {{ic|arch.py}} module for configuration. Further we specify that:<br />
<br />
* the default user's name would be {{ic|arch}}<br />
* the default user is password locked, which means you can not login to the instance without the ssh keys configured during boot<br />
* the default user should be added to the groups {{ic|adm}}, {{ic|audio}}, {{ic|cdrom}}, {{ic|dialout}}, {{ic|dip}}, {{ic|floppy}}, {{ic|netdev}}, {{ic|plugdev}}, {{ic|sudo}}, {{ic|video}}<br />
* the default user is allow passwordless sudo usage<br />
* the default user's shell is {{ic|/bin/bash}}<br />
<br />
=== Disable login as root ===<br />
<br />
To do this you can specify in {{ic|/etc/cloud/cloud.cfg}}:<br />
disable_root: true<br />
<br />
You may also delete the root user password:<br />
# passwd -d root<br />
<br />
Do not perform this step unless you are sure the configuration in previous section works. Otherwise you might be completely locked out of your instance.<br />
<br />
=== Configuring data sources ===<br />
<br />
Data Sources define how the instance metadata is pulled during boot. This depends on what cloud (OpenStack, AWS, OpenNebula etc.) you are running your instance on. Under the hood this translates to a corresponding module which implement a few methods defined in a common interface. Edit your {{ic|/etc/cloud/cloud.cfg}} to have the below contents:<br />
datasource_list: [ NoCloud, ConfigDrive, OpenNebula, Azure, AltCloud, OVF, MAAS, GCE, OpenStack, CloudSigma, Ec2, CloudStack, None ]<br />
<br />
This instructs cloud-init what modules to load while trying to download instance metadata. Optionally further configuration parameters may be passed specific to each datasource as below:<br />
<br />
datasource:<br />
OpenStack:<br />
metadata_urls: [ '<nowiki>http://169.254.169.254:80</nowiki>' ]<br />
dsmode: net<br />
<br />
The above configuration tells OpenStack datasource to use the url {{ic|<nowiki>http://169.254.169.254:80</nowiki>}} to download metadata and to run after network initialization, both of which are the default behaviour and may be omitted.<br />
<br />
== Other sections in cloud.cfg ==<br />
<br />
{{ic|cloud.cfg}} defines several other sections which includes but not limited to {{ic|cloud_init_modules}}, {{ic|cloud_config_modules}} and {{ic|cloud_final_modules}} that define the modules that would be run at various stages during instance initialization. These modules are loaded dynamically from the path {{ic|/usr/lib/python2.7/site-packages/cloudinit/config/}} and run at boot time. The user may define their own modules and configure them to be called during every boot like say to:<br />
<br />
* perform disk resize<br />
* perform package update<br />
etc.<br />
<br />
The various modules declare to cloud-init which distros they have been verified for. Even if you specify that you want to run them, they will refuse to run unless the distro specified in {{ic|cloud.cfg}} is one of the verified distros for the given module. If you want to run a module on Arch anyway that does not specify {{ic|arch}}, add the module to the {{ic|unverified_modules:}} section in {{ic|cloud.cfg}}, e.g.:<br />
<br />
unverified_modules: ['ssh-import-id']<br />
<br />
== Systemd integration ==<br />
<br />
Package cloud-init provides four systemd [https://www.freedesktop.org/software/systemd/man/systemd.service.html services], two systemd [https://www.freedesktop.org/software/systemd/man/systemd.target.html targets], and a systemd [https://www.freedesktop.org/software/systemd/man/systemd.generator.html generator], whose dependencies are constructed in a way that they are activated in the sequence listed:<br />
* {{ic|cloud-init-generator}}. Determines availability of any data source and enables or disables {{ic|cloud-init.target}}<br />
* {{ic|cloud-init-local.service}}. Only requires the filesystems to be up. Executes {{ic|cloud-init init --local}}<br />
* {{ic|cloud-init.service}}. Requires the network to be up. Executes {{ic|cloud-init init}}<br />
* {{ic|cloud-config.target}}. Corresponds to the cloud-config upstart event "to inform third parties that cloud-config is available"<br />
* {{ic|cloud-config.service}}. Executes {{ic|1=cloud-init modules --mode=config}}<br />
* {{ic|cloud-final.service}}. Executes {{ic|1=cloud-init modules --mode=final}}<br />
* {{ic|cloud-init.target}}. Reached when all services have been started<br />
<br />
The [[Arch_Linux_AMIs_for_Amazon_Web_Services|Uplink Labs EC2 images]] have all of them enabled, although that appears to be overkill due to the dependencies. When preparing an image, enabling {{ic|cloud-init.service}} and {{ic|cloud-final.service}} should be sufficient. Note that this does not mean that the cloud-init services will actually be run - that still depends on the generator enabling the {{ic|cloud-init.target}} on early boot.<br />
<br />
See also the [https://cloudinit.readthedocs.io/en/latest/topics/boot.html cloud-init boot stages documentation] for more info.</div>Bitfehlerhttps://wiki.archlinux.org/index.php?title=Cloud-init&diff=582747Cloud-init2019-09-18T10:58:53Z<p>Bitfehler: Mention growpart and netplan as optional dependencies</p>
<hr />
<div>[[Category:Virtualization]]<br />
[[Category:Networking]]<br />
[[ja:Cloud-init]]<br />
[https://cloud-init.io/ Cloud-init] is a package that contains utilities for early initialization of cloud instances. It is needed in Arch Linux images that are built with the intention of being launched in cloud environments like [[OpenStack]], [[AWS]] etc.<br />
<br />
== Installation ==<br />
<br />
[[Install]] the {{AUR|cloud-init}} package.<br />
<br />
If you intend to use the [https://cloudinit.readthedocs.io/en/latest/topics/modules.html#growpart growpart module] you will also need the {{AUR|growpart}} package.<br />
<br />
As of cloud-init 19.1 you can also use [https://netplan.io/ netplan] to render the network config. Install the {{AUR|netplan}} package to do so.<br />
<br />
== Configuration ==<br />
<br />
In order to make an Arch image cloud ready, a few steps have to be followed:<br />
<br />
* Create a default user. You can login to your instance as this user. We will create and use a user called {{ic|arch}}.<br />
* Install [[sudo]] and add the default user to sudo group. This can be used later to execute commands as privileged user.<br />
* Enable password less sudo for the default user.<br />
* Configure cloud-init to pull instance metadata to configure the instance. This includes but not limited to:<br />
** Setting up the instance {{ic|hostname}}<br />
** Configuring instance's {{ic|resolv.conf}}<br />
** Configuring {{ic|~/.ssh/authorized_keys}} file for the default user <br />
<br />
The cloud-init's main configuration file is {{ic|/etc/cloud/cloud.cfg}}. Optionally the user can place {{ic|*.cfg}} files in {{ic|/etc/cloud/cloud.cfg.d}} to be loaded.<br />
<br />
=== Default user configuration ===<br />
<br />
As of February 2016, the default {{ic|/etc/cloud/cloud.cfg}} shipped with the package has not been adapted to Arch, and still states that the distro is Ubuntu, therefore it requires editing.<br />
<br />
Edit {{ic|/etc/cloud/cloud.cfg}} to have the following contents:<br />
<br />
users:<br />
- default<br />
<br />
This tells cloud-init to use the user configured under {{ic|system_info}} > {{ic|default_user}} as the default user:<br />
<br />
system_info:<br />
distro: arch<br />
default_user:<br />
name: arch <br />
lock_passwd: true<br />
gecos: Arch<br />
groups: [adm, audio, cdrom, dialout, dip, floppy, netdev, plugdev, sudo, video]<br />
sudo: ["ALL=(ALL) NOPASSWD:ALL"]<br />
shell: /bin/bash<br />
<br />
Under {{ic|system_info}} we specify the distro as "arch". This will instruct cloud-init to use {{ic|arch.py}} module for configuration. Further we specify that:<br />
<br />
* the default user's name would be {{ic|arch}}<br />
* the default user is password locked, which means you can not login to the instance without the ssh keys configured during boot<br />
* the default user should be added to the groups {{ic|adm}}, {{ic|audio}}, {{ic|cdrom}}, {{ic|dialout}}, {{ic|dip}}, {{ic|floppy}}, {{ic|netdev}}, {{ic|plugdev}}, {{ic|sudo}}, {{ic|video}}<br />
* the default user is allow passwordless sudo usage<br />
* the default user's shell is {{ic|/bin/bash}}<br />
<br />
=== Disable login as root ===<br />
<br />
To do this you can specify in {{ic|/etc/cloud/cloud.cfg}}:<br />
disable_root: true<br />
<br />
You may also delete the root user password:<br />
# passwd -d root<br />
<br />
Do not perform this step unless you are sure the configuration in previous section works. Otherwise you might be completely locked out of your instance.<br />
<br />
=== Configuring data sources ===<br />
<br />
Data Sources define how the instance metadata is pulled during boot. This depends on what cloud (OpenStack, AWS, OpenNebula etc.) you are running your instance on. Under the hood this translates to a corresponding module which implement a few methods defined in a common interface. Edit your {{ic|/etc/cloud/cloud.cfg}} to have the below contents:<br />
datasource_list: [ NoCloud, ConfigDrive, OpenNebula, Azure, AltCloud, OVF, MAAS, GCE, OpenStack, CloudSigma, Ec2, CloudStack, None ]<br />
<br />
This instructs cloud-init what modules to load while trying to download instance metadata. Optionally further configuration parameters may be passed specific to each datasource as below:<br />
<br />
datasource:<br />
OpenStack:<br />
metadata_urls: [ '<nowiki>http://169.254.169.254:80</nowiki>' ]<br />
dsmode: net<br />
<br />
The above configuration tells OpenStack datasource to use the url {{ic|<nowiki>http://169.254.169.254:80</nowiki>}} to download metadata and to run after network initialization, both of which are the default behaviour and may be omitted.<br />
<br />
== Other sections in cloud.cfg ==<br />
<br />
{{ic|cloud.cfg}} defines several other sections which includes but not limited to {{ic|cloud_init_modules}}, {{ic|cloud_config_modules}} and {{ic|cloud_final_modules}} that define the modules that would be run at various stages during instance initialization. These modules are loaded dynamically from the path {{ic|/usr/lib/python2.7/site-packages/cloudinit/config/}} and run at boot time. The user may define their own modules and configure them to be called during every boot like say to:<br />
<br />
* perform disk resize<br />
* perform package update<br />
etc.<br />
<br />
The various modules declare to cloud-init which distros they have been verified for. Even if you specify that you want to run them, they will refuse to run unless the distro specified in {{ic|cloud.cfg}} is one of the verified distros for the given module. If you want to run a module on Arch anyway that does not specify {{ic|arch}}, add the module to the {{ic|unverified_modules:}} section in {{ic|cloud.cfg}}, e.g.:<br />
<br />
unverified_modules: ['ssh-import-id']<br />
<br />
== Systemd integration ==<br />
<br />
Package cloud-init provides four systemd [https://www.freedesktop.org/software/systemd/man/systemd.service.html services], two systemd [https://www.freedesktop.org/software/systemd/man/systemd.target.html targets], and a systemd [https://www.freedesktop.org/software/systemd/man/systemd.generator.html generator], whose dependencies are constructed in a way that they are activated in the sequence listed:<br />
* {{ic|cloud-init-generator}}. Determines availability of any data source and enables or disables {{ic|cloud-init.target}}<br />
* {{ic|cloud-init-local.service}}. Only requires the filesystems to be up. Executes {{ic|cloud-init init --local}}<br />
* {{ic|cloud-init.service}}. Requires the network to be up. Executes {{ic|cloud-init init}}<br />
* {{ic|cloud-config.target}}. Corresponds to the cloud-config upstart event "to inform third parties that cloud-config is available"<br />
* {{ic|cloud-config.service}}. Executes {{ic|1=cloud-init modules --mode=config}}<br />
* {{ic|cloud-final.service}}. Executes {{ic|1=cloud-init modules --mode=final}}<br />
* {{ic|cloud-init.target}}. Reached when all services have been started<br />
<br />
The [[Arch_Linux_AMIs_for_Amazon_Web_Services|Uplink Labs EC2 images]] have all of them enabled, although that appears to be overkill due to the dependencies. When preparing an image, enabling {{ic|cloud-init.service}} and {{ic|cloud-final.service}} should be sufficient. Note that this does not mean that the cloud-init services will actually be run - that still depends on the generator enabling the {{ic|cloud-init.target}} on early boot.<br />
<br />
See also the [https://cloudinit.readthedocs.io/en/latest/topics/boot.html cloud-init boot stages documentation] for more info.</div>Bitfehlerhttps://wiki.archlinux.org/index.php?title=Cloud-init&diff=582744Cloud-init2019-09-18T10:47:33Z<p>Bitfehler: small grammar correction</p>
<hr />
<div>[[Category:Virtualization]]<br />
[[Category:Networking]]<br />
[[ja:Cloud-init]]<br />
[https://cloud-init.io/ Cloud-init] is a package that contains utilities for early initialization of cloud instances. It is needed in Arch Linux images that are built with the intention of being launched in cloud environments like [[OpenStack]], [[AWS]] etc.<br />
<br />
== Installation ==<br />
<br />
[[Install]] the {{AUR|cloud-init}} package.<br />
<br />
== Configuration ==<br />
<br />
In order to make an Arch image cloud ready, a few steps have to be followed:<br />
<br />
* Create a default user. You can login to your instance as this user. We will create and use a user called {{ic|arch}}.<br />
* Install [[sudo]] and add the default user to sudo group. This can be used later to execute commands as privileged user.<br />
* Enable password less sudo for the default user.<br />
* Configure cloud-init to pull instance metadata to configure the instance. This includes but not limited to:<br />
** Setting up the instance {{ic|hostname}}<br />
** Configuring instance's {{ic|resolv.conf}}<br />
** Configuring {{ic|~/.ssh/authorized_keys}} file for the default user <br />
<br />
The cloud-init's main configuration file is {{ic|/etc/cloud/cloud.cfg}}. Optionally the user can place {{ic|*.cfg}} files in {{ic|/etc/cloud/cloud.cfg.d}} to be loaded.<br />
<br />
=== Default user configuration ===<br />
<br />
As of February 2016, the default {{ic|/etc/cloud/cloud.cfg}} shipped with the package has not been adapted to Arch, and still states that the distro is Ubuntu, therefore it requires editing.<br />
<br />
Edit {{ic|/etc/cloud/cloud.cfg}} to have the following contents:<br />
<br />
users:<br />
- default<br />
<br />
This tells cloud-init to use the user configured under {{ic|system_info}} > {{ic|default_user}} as the default user:<br />
<br />
system_info:<br />
distro: arch<br />
default_user:<br />
name: arch <br />
lock_passwd: true<br />
gecos: Arch<br />
groups: [adm, audio, cdrom, dialout, dip, floppy, netdev, plugdev, sudo, video]<br />
sudo: ["ALL=(ALL) NOPASSWD:ALL"]<br />
shell: /bin/bash<br />
<br />
Under {{ic|system_info}} we specify the distro as "arch". This will instruct cloud-init to use {{ic|arch.py}} module for configuration. Further we specify that:<br />
<br />
* the default user's name would be {{ic|arch}}<br />
* the default user is password locked, which means you can not login to the instance without the ssh keys configured during boot<br />
* the default user should be added to the groups {{ic|adm}}, {{ic|audio}}, {{ic|cdrom}}, {{ic|dialout}}, {{ic|dip}}, {{ic|floppy}}, {{ic|netdev}}, {{ic|plugdev}}, {{ic|sudo}}, {{ic|video}}<br />
* the default user is allow passwordless sudo usage<br />
* the default user's shell is {{ic|/bin/bash}}<br />
<br />
=== Disable login as root ===<br />
<br />
To do this you can specify in {{ic|/etc/cloud/cloud.cfg}}:<br />
disable_root: true<br />
<br />
You may also delete the root user password:<br />
# passwd -d root<br />
<br />
Do not perform this step unless you are sure the configuration in previous section works. Otherwise you might be completely locked out of your instance.<br />
<br />
=== Configuring data sources ===<br />
<br />
Data Sources define how the instance metadata is pulled during boot. This depends on what cloud (OpenStack, AWS, OpenNebula etc.) you are running your instance on. Under the hood this translates to a corresponding module which implement a few methods defined in a common interface. Edit your {{ic|/etc/cloud/cloud.cfg}} to have the below contents:<br />
datasource_list: [ NoCloud, ConfigDrive, OpenNebula, Azure, AltCloud, OVF, MAAS, GCE, OpenStack, CloudSigma, Ec2, CloudStack, None ]<br />
<br />
This instructs cloud-init what modules to load while trying to download instance metadata. Optionally further configuration parameters may be passed specific to each datasource as below:<br />
<br />
datasource:<br />
OpenStack:<br />
metadata_urls: [ '<nowiki>http://169.254.169.254:80</nowiki>' ]<br />
dsmode: net<br />
<br />
The above configuration tells OpenStack datasource to use the url {{ic|<nowiki>http://169.254.169.254:80</nowiki>}} to download metadata and to run after network initialization, both of which are the default behaviour and may be omitted.<br />
<br />
== Other sections in cloud.cfg ==<br />
<br />
{{ic|cloud.cfg}} defines several other sections which includes but not limited to {{ic|cloud_init_modules}}, {{ic|cloud_config_modules}} and {{ic|cloud_final_modules}} that define the modules that would be run at various stages during instance initialization. These modules are loaded dynamically from the path {{ic|/usr/lib/python2.7/site-packages/cloudinit/config/}} and run at boot time. The user may define their own modules and configure them to be called during every boot like say to:<br />
<br />
* perform disk resize<br />
* perform package update<br />
etc.<br />
<br />
The various modules declare to cloud-init which distros they have been verified for. Even if you specify that you want to run them, they will refuse to run unless the distro specified in {{ic|cloud.cfg}} is one of the verified distros for the given module. If you want to run a module on Arch anyway that does not specify {{ic|arch}}, add the module to the {{ic|unverified_modules:}} section in {{ic|cloud.cfg}}, e.g.:<br />
<br />
unverified_modules: ['ssh-import-id']<br />
<br />
== Systemd integration ==<br />
<br />
Package cloud-init provides four systemd [https://www.freedesktop.org/software/systemd/man/systemd.service.html services], two systemd [https://www.freedesktop.org/software/systemd/man/systemd.target.html targets], and a systemd [https://www.freedesktop.org/software/systemd/man/systemd.generator.html generator], whose dependencies are constructed in a way that they are activated in the sequence listed:<br />
* {{ic|cloud-init-generator}}. Determines availability of any data source and enables or disables {{ic|cloud-init.target}}<br />
* {{ic|cloud-init-local.service}}. Only requires the filesystems to be up. Executes {{ic|cloud-init init --local}}<br />
* {{ic|cloud-init.service}}. Requires the network to be up. Executes {{ic|cloud-init init}}<br />
* {{ic|cloud-config.target}}. Corresponds to the cloud-config upstart event "to inform third parties that cloud-config is available"<br />
* {{ic|cloud-config.service}}. Executes {{ic|1=cloud-init modules --mode=config}}<br />
* {{ic|cloud-final.service}}. Executes {{ic|1=cloud-init modules --mode=final}}<br />
* {{ic|cloud-init.target}}. Reached when all services have been started<br />
<br />
The [[Arch_Linux_AMIs_for_Amazon_Web_Services|Uplink Labs EC2 images]] have all of them enabled, although that appears to be overkill due to the dependencies. When preparing an image, enabling {{ic|cloud-init.service}} and {{ic|cloud-final.service}} should be sufficient. Note that this does not mean that the cloud-init services will actually be run - that still depends on the generator enabling the {{ic|cloud-init.target}} on early boot.<br />
<br />
See also the [https://cloudinit.readthedocs.io/en/latest/topics/boot.html cloud-init boot stages documentation] for more info.</div>Bitfehlerhttps://wiki.archlinux.org/index.php?title=Cloud-init&diff=577077Cloud-init2019-07-08T14:11:48Z<p>Bitfehler: /* Systemd integration */ Mention the systemd generator used by cloud-init, provide some helpful links, add one missing target</p>
<hr />
<div>[[Category:Virtualization]]<br />
[[Category:Networking]]<br />
[[ja:Cloud-init]]<br />
[https://cloud-init.io/ Cloud-init] is a package that contains utilities for early initialization of cloud instances. It is needed in Arch Linux images that are built with the intention of being launched in cloud like [[OpenStack]], [[AWS]] etc.<br />
<br />
== Installation ==<br />
<br />
[[Install]] the {{AUR|cloud-init}} package.<br />
<br />
== Configuration ==<br />
<br />
In order to make an Arch image cloud ready, a few steps have to be followed:<br />
<br />
* Create a default user. You can login to your instance as this user. We will create and use a user called {{ic|arch}}.<br />
* Install [[sudo]] and add the default user to sudo group. This can be used later to execute commands as privileged user.<br />
* Enable password less sudo for the default user.<br />
* Configure cloud-init to pull instance metadata to configure the instance. This includes but not limited to:<br />
** Setting up the instance {{ic|hostname}}<br />
** Configuring instance's {{ic|resolv.conf}}<br />
** Configuring {{ic|~/.ssh/authorized_keys}} file for the default user <br />
<br />
The cloud-init's main configuration file is {{ic|/etc/cloud/cloud.cfg}}. Optionally the user can place {{ic|*.cfg}} files in {{ic|/etc/cloud/cloud.cfg.d}} to be loaded.<br />
<br />
=== Default user configuration ===<br />
<br />
As of February 2016, the default {{ic|/etc/cloud/cloud.cfg}} shipped with the package has not been adapted to Arch, and still states that the distro is Ubuntu, therefore it requires editing.<br />
<br />
Edit {{ic|/etc/cloud/cloud.cfg}} to have the following contents:<br />
<br />
users:<br />
- default<br />
<br />
This tells cloud-init to use the user configured under {{ic|system_info}} > {{ic|default_user}} as the default user:<br />
<br />
system_info:<br />
distro: arch<br />
default_user:<br />
name: arch <br />
lock_passwd: true<br />
gecos: Arch<br />
groups: [adm, audio, cdrom, dialout, dip, floppy, netdev, plugdev, sudo, video]<br />
sudo: ["ALL=(ALL) NOPASSWD:ALL"]<br />
shell: /bin/bash<br />
<br />
Under {{ic|system_info}} we specify the distro as "arch". This will instruct cloud-init to use {{ic|arch.py}} module for configuration. Further we specify that:<br />
<br />
* the default user's name would be {{ic|arch}}<br />
* the default user is password locked, which means you can not login to the instance without the ssh keys configured during boot<br />
* the default user should be added to the groups {{ic|adm}}, {{ic|audio}}, {{ic|cdrom}}, {{ic|dialout}}, {{ic|dip}}, {{ic|floppy}}, {{ic|netdev}}, {{ic|plugdev}}, {{ic|sudo}}, {{ic|video}}<br />
* the default user is allow passwordless sudo usage<br />
* the default user's shell is {{ic|/bin/bash}}<br />
<br />
=== Disable login as root ===<br />
<br />
To do this you can specify in {{ic|/etc/cloud/cloud.cfg}}:<br />
disable_root: true<br />
<br />
You may also delete the root user password:<br />
# passwd -d root<br />
<br />
Do not perform this step unless you are sure the configuration in previous section works. Otherwise you might be completely locked out of your instance.<br />
<br />
=== Configuring data sources ===<br />
<br />
Data Sources define how the instance metadata is pulled during boot. This depends on what cloud (OpenStack, AWS, OpenNebula etc.) you are running your instance on. Under the hood this translates to a corresponding module which implement a few methods defined in a common interface. Edit your {{ic|/etc/cloud/cloud.cfg}} to have the below contents:<br />
datasource_list: [ NoCloud, ConfigDrive, OpenNebula, Azure, AltCloud, OVF, MAAS, GCE, OpenStack, CloudSigma, Ec2, CloudStack, None ]<br />
<br />
This instructs cloud-init what modules to load while trying to download instance metadata. Optionally further configuration parameters may be passed specific to each datasource as below:<br />
<br />
datasource:<br />
OpenStack:<br />
metadata_urls: [ '<nowiki>http://169.254.169.254:80</nowiki>' ]<br />
dsmode: net<br />
<br />
The above configuration tells OpenStack datasource to use the url {{ic|<nowiki>http://169.254.169.254:80</nowiki>}} to download metadata and to run after network initialization, both of which are the default behaviour and may be omitted.<br />
<br />
== Other sections in cloud.cfg ==<br />
<br />
{{ic|cloud.cfg}} defines several other sections which includes but not limited to {{ic|cloud_init_modules}}, {{ic|cloud_config_modules}} and {{ic|cloud_final_modules}} that define the modules that would be run at various stages during instance initialization. These modules are loaded dynamically from the path {{ic|/usr/lib/python2.7/site-packages/cloudinit/config/}} and run at boot time. The user may define their own modules and configure them to be called during every boot like say to:<br />
<br />
* perform disk resize<br />
* perform package update<br />
etc.<br />
<br />
The various modules declare to cloud-init which distros they have been verified for. Even if you specify that you want to run them, they will refuse to run unless the distro specified in {{ic|cloud.cfg}} is one of the verified distros for the given module. If you want to run a module on Arch anyway that does not specify {{ic|arch}}, add the module to the {{ic|unverified_modules:}} section in {{ic|cloud.cfg}}, e.g.:<br />
<br />
unverified_modules: ['ssh-import-id']<br />
<br />
== Systemd integration ==<br />
<br />
Package cloud-init provides four systemd [https://www.freedesktop.org/software/systemd/man/systemd.service.html services], two systemd [https://www.freedesktop.org/software/systemd/man/systemd.target.html targets], and a systemd [https://www.freedesktop.org/software/systemd/man/systemd.generator.html generator], whose dependencies are constructed in a way that they are activated in the sequence listed:<br />
* {{ic|cloud-init-generator}}. Determines availability of any data source and enables or disables {{ic|cloud-init.target}}<br />
* {{ic|cloud-init-local.service}}. Only requires the filesystems to be up. Executes {{ic|cloud-init init --local}}<br />
* {{ic|cloud-init.service}}. Requires the network to be up. Executes {{ic|cloud-init init}}<br />
* {{ic|cloud-config.target}}. Corresponds to the cloud-config upstart event "to inform third parties that cloud-config is available"<br />
* {{ic|cloud-config.service}}. Executes {{ic|1=cloud-init modules --mode=config}}<br />
* {{ic|cloud-final.service}}. Executes {{ic|1=cloud-init modules --mode=final}}<br />
* {{ic|cloud-init.target}}. Reached when all services have been started<br />
<br />
The [[Arch_Linux_AMIs_for_Amazon_Web_Services|Uplink Labs EC2 images]] have all of them enabled, although that appears to be overkill due to the dependencies. When preparing an image, enabling {{ic|cloud-init.service}} and {{ic|cloud-final.service}} should be sufficient. Note that this does not mean that the cloud-init services will actually be run - that still depends on the generator enabling the {{ic|cloud-init.target}} on early boot.<br />
<br />
See also the [https://cloudinit.readthedocs.io/en/latest/topics/boot.html cloud-init boot stages documentation] for more info.</div>Bitfehlerhttps://wiki.archlinux.org/index.php?title=Talk:Arch_Linux_AMIs_for_Amazon_Web_Services&diff=571250Talk:Arch Linux AMIs for Amazon Web Services2019-04-15T10:40:59Z<p>Bitfehler: Commented on removing out-of-date and merge-candidate headers</p>
<hr />
<div>I also updated the page, removed outdated information, added another link. I also removed the merging note, as I think having a page about AMIs is very valuable. In fact, it would be great if Arch were to offer "official" AMIs, like some other distros do. But until then, it is at least great to have this page for people looking for that. <br />
[[User:Bitfehler|Bitfehler]] ([[User talk:Bitfehler|talk]]) 10:40, 15 April 2019 (UTC)<br />
<br />
I updated the page, and most likely keep it updated.. please remove the outdated logo.<br />
[[User:Rek2|Rek2]] ([[User talk:Rek2|talk]]) 01:43, 7 February 2017 (UTC)<br />
<br />
<br />
<br />
<br />
Compiling the arch linux kernel for PV-GRUB<br />
<br />
http://worldmodscode.wordpress.com/2011/10/28/ec2-ami-creation-without-magic/<br />
<br />
#It's comprehensive<br />
#It's recent<br />
#It includes compiling the arch linux kernel for PV-GRUB</div>Bitfehlerhttps://wiki.archlinux.org/index.php?title=Arch_Linux_AMIs_for_Amazon_Web_Services&diff=571249Arch Linux AMIs for Amazon Web Services2019-04-15T10:36:17Z<p>Bitfehler: Remove outdated info, add another link for building your own.</p>
<hr />
<div>[[Category:Installation process]]<br />
[[es:Arch Linux AMIs for Amazon Web Services]]<br />
[[ja:Amazon Web Services の Arch Linux AMI]]<br />
<br />
==Public community Arch AMIs==<br />
<br />
{{Note|Arch Linux currently does not offer official AMIs. The AMIs listed here are created by the community.}}<br />
<br />
===AMI Images from Uplink Labs===<br />
<br />
Uplink Labs creates new images approximately twice a month. Images are being built<br />
for a number of regions, and cover the following configurations:<br />
<br />
* ebs hvm x86_64 lts <br />
* s3 hvm x86_64 lts<br />
* ebs hvm x86_64 stable<br />
* s3 hvm x86_64 stable<br />
<br />
AMI links and more information are available at https://www.uplinklabs.net/projects/arch-linux-on-ec2/ .<br />
<br />
==Building Arch AMIs==<br />
<br />
You can also build your own Arch Linux AMIs.<br />
<br />
{{AUR|linux-ec2}} in [[AUR]] compiles the Arch linux kernel for AWS with Xen modules enabled and the XSAVE patch applied. Note that at least some instance types will also work with the stock Arch Linux kernel.<br />
<br />
Aforementioned [https://www.uplinklabs.net/projects/arch-linux-on-ec2/ Uplink Labs webpage] also has a manual on the build process.<br />
<br />
Another tutorial on building your own AMIs can be found at https://gitlab.com/bitfehler/archlinux-ec2</div>Bitfehlerhttps://wiki.archlinux.org/index.php?title=Getting_involved&diff=569432Getting involved2019-03-22T09:29:22Z<p>Bitfehler: Add sub-section about mailing lists with link, they are otherwise hard to find in the wiki</p>
<hr />
<div>[[Category:About Arch]]<br />
[[ar:Getting involved]]<br />
[[bg:Getting involved]]<br />
[[da:Getting involved]]<br />
[[el:Getting involved]]<br />
[[es:Getting involved]]<br />
[[fa:مشارکت]]<br />
[[fr:Aider]]<br />
[[hr:Getting involved]]<br />
[[id:Getting involved]]<br />
[[it:Getting involved]]<br />
[[ja:コミュニティに貢献]]<br />
[[ko:Getting involved]]<br />
[[lt:Getting involved]]<br />
[[nl:Getting involved]]<br />
[[pl:Getting involved]]<br />
[[pt:Getting involved]]<br />
[[ru:Getting involved]]<br />
[[zh-hans:Getting involved]]<br />
[[zh-hant:Getting involved]]<br />
{{Related articles start}}<br />
{{Related|FAQ}}<br />
{{Related|ArchWiki:Contributing}}<br />
{{Related articles end}}<br />
In evolutionary biology, [[Wikipedia:Co-operation (evolution)|cooperation]] describes interactions where an individual pays a small cost to yield a larger benefit to one or more others. If this costly contribution is reciprocated, everyone involved can benefit tremendously. This principle also applies to proactive members of the Arch community wanting to get involved and contribute to their favorite Linux distribution. Their participation benefits not only the community member and their fellow Archers, but all users of [[Wikipedia:Free and open source software|free and open source software]].<br />
<br />
This article describes how both new and experienced Arch users can contribute to the community. Note that this is not an exhaustive list. Before contributing, please get accustomed with the [[Code of conduct]].<br />
<br />
== Community ==<br />
<br />
=== Post on the forums ===<br />
<br />
One of the easiest ways to get involved is participating in the [https://bbs.archlinux.org/ Arch Linux Forums], which allow getting to know the community and help new users.<br />
<br />
=== Improve this wiki ===<br />
<br />
[[ArchWiki]] is a collaboratively maintained Arch Linux documentation. All users are encouraged to [[ArchWiki:Contributing|contribute]].<br />
<br />
=== Join the chatroom ===<br />
<br />
You can help other users solve problems on the [[IRC channel]]. It is of vital importance however, that you read the [[Code_of_conduct#IRC|channel rules]] before participating. [[IRC channel#Other channels|Further channels]] are available for specific topics.<br />
<br />
=== Join the mailing lists ===<br />
<br />
Join the discussion on one or more of the public [https://lists.archlinux.org/ mailing lists]. Make sure to stay on topic as provided in the list description.<br />
<br />
== Packaging ==<br />
<br />
=== Report installed packages ===<br />
<br />
[[pkgstats]] provides a [[systemd/Timers|systemd timer]] that sends a list of the packages installed on your system, along with the architecture and the mirrors you use, to the Arch Linux developers in order to help them prioritize their efforts and make the distribution even better. The information is sent anonymously and cannot be used to identify you. You can view the collected data at the [https://www.archlinux.de/?page=Statistics Statistics page]. More information is available in [https://bbs.archlinux.org/viewtopic.php?id=105431 this forum thread].<br />
<br />
=== Fix and report bugs ===<br />
<br />
Reporting and fixing bugs on the [https://bugs.archlinux.org/ bug tracker] is one of the possible ways to help the community.<br />
<br />
However, ineffective use can be counter-productive. Please read the [[Reporting bug guidelines]].<br />
<br />
=== Inform about security issues ===<br />
<br />
New vulnerabilites are found all the time. Help the [[Arch Security Team]] keep track of new vulnerabilities.<br />
<br />
=== Help test packages ===<br />
<br />
Packages on the testing repositories need to be tried out and signed off before they are promoted to the main repositories. Help the [[Arch Testing Team]] test new packages.<br />
<br />
=== Create and adopt AUR packages ===<br />
<br />
The [[Arch User Repository]] contains community-made package scripts, allowing users to easily install software not part of the [[official repositories]]. Popular packages get included into the [[Official repositories#community|official community repository]].<br />
<br />
{{Pkg|aurphan}} can help you identify orphaned packages you use, so that you can adopt them.<br />
<br />
== Events ==<br />
<br />
There are regular events open to the community for bugfixing, cleanup, and other activities.<br />
<br />
* [[Bug Day]]<br />
* [[AUR Cleanup Day]]<br />
<br />
== Software projects ==<br />
<br />
The [[Arch Linux]] distribution comprises of many components, such as the package manager [[pacman]], the [https://archlinux.org archlinux.org] website (''archweb''), or the supporting system for the [[Arch User Repository]] (''aurweb''). Each of these projects can be contributed to individually.<br />
<br />
See [[DeveloperWiki:Projects]] for an overview of team members, communication channels and used programming languages. The projects themselves are hosted with [[git]] on [https://git.archlinux.org git.archlinux.org].<br />
<br />
== Donate money ==<br />
<br />
You can find out how to help sustaining server costs on the [https://www.archlinux.org/donate/ official Arch Linux donate page].<br />
<br />
== Unofficial projects ==<br />
<br />
{{Note|Entries listed here are ''not'' part of the [[Arch Linux]] project.}}<br />
<br />
Arch's community maintains many projects. Feel free to include yours!<br />
<br />
=== Groups ===<br />
<br />
Arch-specific groups that you can engage in.<br />
<br />
; [[ArchMap]]<br />
: The ArchMap project creates a map of Arch Linux users all over the world.<br />
<br />
; [http://www.reddit.com/r/archlinux/ Arch Linux Subreddit]<br />
: Place for reddit users to discuss Arch related issues.<br />
<br />
; [[International communities]]<br />
: Local communities and meet-up places for users.<br />
<br />
; [http://archwomen.org/ Arch Women]<br />
: Group with the intention of resolving possible hurdles for female Arch users ([https://bbs.archlinux.org/viewtopic.php?id=136184 forum thread]).<br />
<br />
=== Software ===<br />
<br />
Community-developed software that focuses on Arch Linux.<br />
<br />
; [http://xyne.archlinux.ca/projects/ Xyne's Arch Linux Projects]<br />
: A trusted user's arch-related projects.<br />
<br />
== FAQ ==<br />
<br />
{{Merge|FAQ|Little point in separating these sections. The [[FAQ]] entry can be linked from this article.}}<br />
<br />
=== How can I become an Arch Developer? ===<br />
<br />
The main motivation for your work on Arch should be helping the whole community, and not simply trying to become an ''Arch developer'' by any means.<br />
<br />
Usually, new developers are picked by the existing developers as the workload increases. Sometimes they post a position and you can apply to fill it, but more often, they just invite somebody they know would be good at it and would fit in well with the rest of the team. Having a portfolio of Arch contributions is the best way to make it on the team.<br />
<br />
Here is a list of things that you may do in order to gain some "popularity" towards Arch's developers:<br />
<br />
* Establish a reputation as being helpful by offering assistance whenever possible.<br />
* Answer questions on the forum, IRC, and mailing lists.<br />
* Join the [[Trusted Users]] to gain packaging experience to show your skills.<br />
* Submit packages to the AUR.<br />
* Join one of the offshoot projects that may be incorporated into Arch mainstream someday, or start your own.<br />
* Work on ''pacman'', ''makepkg'' or other [https://git.archlinux.org/ Arch projects] and submit patches to the bug tracker.<br />
* Traverse the [https://bugs.archlinux.org/ bug tracker] and fix existing bugs.<br />
* Find and submit new bugs.<br />
* Fix wiki errors, add new pages, clean up existing pages, and make sure the procedures are up-to-date.<br />
* Submit translations.<br />
<br />
=== How can I become a Trusted User? ===<br />
<br />
Please read [[Trusted Users#How do I become a TU?]].<br />
<br />
=== What can I do as an artist? ===<br />
<br />
Feel free to share wallpapers, splash screens, color palettes, widgets, themes, etc. with the community on the [https://bbs.archlinux.org/viewforum.php?id=47 art subforum].<br />
<br />
See also [https://www.archlinux.org/art/ Arch Linux Art].</div>Bitfehler