https://wiki.archlinux.org/api.php?action=feedcontributions&user=Tuxsavvy&feedformat=atomArchWiki - User contributions [en]2024-03-29T14:15:56ZUser contributionsMediaWiki 1.41.0https://wiki.archlinux.org/index.php?title=Talk:Mozc&diff=695731Talk:Mozc2021-09-14T12:33:34Z<p>Tuxsavvy: /* Removal of cloud handwriting and character palette support */ section added, talk/discussion page created. Adding notes with more references on why I made the changes as indicated.</p>
<hr />
<div>== Removal of cloud handwriting and character palette support ==<br />
In connection to my [https://wiki.archlinux.org/index.php?title=Mozc&diff=695728&oldid=669109 recent edit], the following are also related to the removal of said tool(s):<br />
* [https://github.com/google/mozc/issues/484#issuecomment-731554418 Current mozc maintainer responding to one of Gentoo package maintainer's inquiry on the matter]<br />
* [https://gitweb.gentoo.org/repo/gentoo.git/tree/app-i18n/mozc/mozc-2.23.2815.102.ebuild Gentoo package maintainer appears to still be keeping an older ebuild where it still has said tools]<br />
[[User:Tuxsavvy|Tuxsavvy]] ([[User talk:Tuxsavvy|talk]]) 12:33, 14 September 2021 (UTC)</div>Tuxsavvyhttps://wiki.archlinux.org/index.php?title=Mozc&diff=695728Mozc2021-09-14T11:54:21Z<p>Tuxsavvy: /* Launching Mozc tools from command line */ Removed (cloud) handwriting mode/tool as well as character palette. Both of these modes has unfortunately been stripped from [https://github.com/google/mozc/commit/a1dcadabd3a1c604e8beff1e45830c1d9adfce84 upstream for a while]. Ditto with tegaki-models-zinnia note below it as upstream no longer depends on it via third_party. /* Troubleshooting */ Added how to troubleshoot mozc tools section.</p>
<hr />
<div>[[Category:Input methods]]<br />
[[ja:Mozc]]<br />
From the project's [https://github.com/google/mozc home page]:<br />
:'''Mozc''' is a Japanese [[input method]] editor (IME) designed for multi-platform such as Android OS, Apple OS X, Chromium OS, GNU/Linux and Microsoft Windows. This OpenSource project originates from [https://www.google.com/intl/ja/ime/ Google Japanese Input].<br />
<br />
The differences between Mozc and Google Japanese Input are described in detail at the project's [https://github.com/google/mozc/blob/master/docs/about_branding.md About Branding] page, but in short, Mozc's open-source code does not include Google's extensive word conversion tables (so called "dictionaries"), so its conversion quality is not equivalent to that of Google's branded product. This can be mostly mitigated with custom dictionaries though (see below).<br />
<br />
== Installation ==<br />
<br />
There are several available Mozc packages to choose from, and depending on your needs there are some precautions that should be taken into consideration:<br />
<br />
Besides its core files, Mozc also requires modules to integrate with the various input method frameworks (IMF); a separate module is needed for each of [[Fcitx]], [[IBus]], [[Uim]] and [[Emacs]] (which contains its own internal IMF).<br />
<br />
Most Mozc packages split the core and the IMF module into separate parts, but some of the Fcitx packages (including the one in the official repository) instead come with the Mozc core and the Fcitx module combined into a single package.<br />
<br />
{{Note|Trying to install these combined packages alongside any other Mozc package will produce conflicts. If for some reason you'll be needing more than one IMF modules active at the same time, the solution is to either build the offending packages yourself and manually resolve any conflicts, or to choose a different package combination.}}<br />
<br />
On the other hand, some of the seemingly standalone IBus, Uim and Emacs packages are actually a single, split [[PKGBUILD]] that can install one or more IMF modules at the same time, by using toggles to enable or disable them; e.g. {{AUR|mozc-ut2}} is the package actually responsible for building {{AUR|ibus-mozc-ut2}}, {{AUR|emacs-mozc-ut2}} and {{AUR|uim-mozc-ut2}}:<br />
## Build configuration <br />
##<br />
## You can choose the input method framework to use either ibus and/or uim.<br />
## If you will not be using ibus, comment out below.<br />
_ibus_mozc="yes"<br />
## If you will be using uim, uncomment below.<br />
#_uim_mozc="yes"<br />
<br />
## If you will be using mozc.el on Emacs, uncomment below.<br />
#_emacs_mozc="yes"<br />
{{Note|Care must be taken to properly enable or disable the desired toggles before installing such a package so that the correct modules will be installed.}}<br />
<br />
Last, but certainly not least, there exists a family of '''custom dictionaries''' that can elevate Mozc's conversion quality to more closely resemble that of Google Japanese Input: The '''UT''', '''UT2''' and '''NEologd UT''' dictionaries. The first two contain extra words aggregated from several popular online sources (based on hit numbers from Google/Yahoo and Wikipedia, respectively) while the third one is based on the [https://github.com/neologd/mecab-ipadic-neologd mecab-ipadic-NEologd] Neologism dictionary, which contains "neologisms (new words), which are extracted from many language resources on the Web", in the words of its creator.<br />
<br />
The UT dictionary was deprecated in 2016 in favor of UT2 and NEologd UT, which were both intended to be its successors; but as of November 2020, UT has been revived into an updated version that now also incorporates the UT2 and NEologd dictionaries, which have in turn been deprecated themselves (source: [http://linuxplayers.g1.xrea.com/index.html UT home page]).<br />
<br />
{{Tip|The short version of the above is that in most cases the Mozc packages based on the UT dictionary should be preferable.}}<br />
<br />
The following table shows the various packages available; purple cells indicate combined packages, while yellow cells indicate packages containing toggles for additional modules. Some of these packages can also be found in the [[Unofficial user repository#pnsft-pur|pnsft-pur]] repository.<br />
<br />
{| class="wikitable" style="text-align:center;"<br />
|-<br />
! <br />
! [[Fcitx]]<br />
! [[Fcitx5]]<br />
! [[IBus]]<br />
! [[Emacs]]<br />
! [[Uim]]<br />
|-<br />
| style="font-weight:bold; | Official<br />
| style="background-color:#d7d7ff;" | {{Pkg|fcitx-mozc}}<br />
| style="background-color:#d7d7ff;" | {{Pkg|fcitx5-mozc}}<br />
| style="background-color:#eff1ae;" | {{AUR|ibus-mozc}}<br />
| style="background-color:#eff1ae;" | {{AUR|emacs-mozc}}<br />
| {{AUR|uim-mozc}}<br />
|-<br />
| rowspan="2" | [http://linuxplayers.g1.xrea.com/mozc-ut.html UT]<br />
| {{AUR|fcitx-mozc-ut}}<br />
| {{AUR|fcitx5-mozc-ut}}<br />
| {{AUR|ibus-mozc-ut}}<br />
| {{AUR|emacs-mozc-ut}}<br />
| rowspan="2" | <br />
|-<br />
| {{AUR|fcitx-mozc-ut-unified}}<br />
| <br />
| style="background-color:#eff1ae;" | {{AUR|ibus-mozc-ut-united}}<br />
| style="background-color:#eff1ae;" | {{AUR|emacs-mozc-ut-united}}<br />
|-<br />
| [http://linuxplayers.g1.xrea.com/mozc-ut2.html UT2]<br />
| style="background-color:#d7d7ff;" | {{AUR|fcitx-mozc-ut2}}<br />
| <br />
| style="background-color:#eff1ae;" | {{AUR|ibus-mozc-ut2}}<br />
| style="background-color:#eff1ae;" | {{AUR|emacs-mozc-ut2}}<br />
| style="background-color:#eff1ae;" | {{AUR|uim-mozc-ut2}}<br />
|-<br />
| [http://linuxplayers.g1.xrea.com/mozc-neologd-ut.html NEologd UT]<br />
| {{AUR|fcitx-mozc-neologd-ut}}<br />
| <br />
| <br />
| <br />
|}<br />
<br />
<br />
{{Note|Once Mozc is installed, you may need to restart X or your input method framework before you can use it.}}<br />
<br />
== Configuration ==<br />
<br />
=== IBus ===<br />
''See also [[IBus]] for IBus configuration.''<br />
<br />
If you use Mozc by default, set it up via ''ibus-setup'':<br />
$ ibus-setup<br />
Choose ''Input Method'' tab and move ''Mozc'' to top of the list.<br />
<br />
You can switch input method by {{ic|Alt+Shift_L}} (as per the IBus default).<br />
<br />
{{Tip|When used with IBus, by default Mozc will launch in Direct (Eisu) input mode, which can be problematic on keyboards that lack the Eisu key. To change this behavior and make Mozc launch in Hiragana input mode instead, edit {{ic|~/.config/mozc/ibus_config.textproto}} and append the following line:<br />
<br />
{{hc|~/.config/mozc/ibus_config.textproto|2=<br />
...<br />
}<br />
'''active_on_launch: True'''<br />
}}<br />
}}<br />
<br />
=== uim ===<br />
''See also [[Uim]] for uim configuration.''<br />
<br />
Configure uim preferences by running:<br />
$ uim-pref-gtk (Or, uim-pref-gtk3/uim-pref-qt4)<br />
which brings forth a GUI.<br />
<br />
Choose your preferring input method as ''Default input method''.<br />
{{Note|Mozc will be not listed in ''Default input method'' at first time so you will need to add it into ''Enabled input methods'' to use.}}<br />
<br />
{{Warning|You '''must''' run the following command whenever you upgrade or (re-)install '''uim'''.<br/><br />
# uim-module-manager --register mozc}}<br />
<br />
=== Fcitx ===<br />
''See also [[Fcitx]] for Fcitx configuration.''<br />
<br />
Open the configuration dialog of Fcitx by running:<br />
$ fcitx-configtool<br />
In the ''Input Method'' tab, click on the plus sign and choose Mozc from the list in the dialog. Depending on your configuration, you might need to disable the ''Only Show Current Language'' option for Mozc to be available. After confirming the dialog, you can activate Mozc as input method using the usual keyboard shortcuts.<br />
<br />
=== Mozc for Emacs ===<br />
<br />
You can use mozc.el (mozc-mode) to input Japanese via LEIM (Library of Emacs Input Method). To use mozc-mode, write the following into your {{Ic|.emacs.d/init.el}} or some other file for Emacs customizing:<br />
(require 'mozc) ; or (load-file "/path/to/mozc.el")<br />
(setq default-input-method "japanese-mozc")<br />
mozc.el provides "overlay" mode in the styles of showing candidates (from mozc r77) which shows a candidate window in box style close to the point. If you want to use it by default, add the following:<br />
(setq mozc-candidate-style 'overlay)<br />
<br />
{{ic|C-\}} (''toggle-input-method'') enables and disables use of mozc-mode.<br />
<br />
==== Disabling XIM on Emacs ====<br />
<br />
When you are using input method on your desktop and assigning activation/deactivation of input method to C-SPC, you will be not able to use C-SPC/C-@ as set-mark-command on Emacs. To avoid this problem, add the following into your {{Ic|~/.Xresources}} or {{Ic|~/.Xdefaults}}. xim will be disabled on Emacs.<br />
Emacs*UseXIM: false<br />
<br />
== Tips and tricks ==<br />
<br />
=== Confirming Mozc version which you are using now ===<br />
<br />
Type "ばーじょん" ("version") and convert it while activating Mozc. The version number of Mozc will be shown in the candidate list like follows:<br />
{{hc|<u>ばーじょん</u>|<br />
バージョン<br />
ヴァージョン<br />
ばーじょん<br />
Mozc-1.6.1187.102 ''⇐ Current version of Mozc''<br />
...}}<br />
<br />
=== Launching Mozc tools from command line ===<br />
<br />
The followings are commands to launch Mozc tools.<br />
* Mozc Settings: {{ic|1=$ /usr/lib/mozc/mozc_tool --mode=config_dialog}}<br />
* Mozc Dictionary Tool: {{ic|1=$ /usr/lib/mozc/mozc_tool --mode=dictionary_tool}}<br />
* Mozc Word Register: {{ic|1=$ /usr/lib/mozc/mozc_tool --mode=word_register_dialog}}<br />
<br />
=== Use CapsLock as Eisu_toggle key on ASCII layout keyboard ===<br />
<br />
In all of the preset keymap styles of Mozc, the command ''Toggle alphanumeric mode'' on ''Composition'' mode is assigned to the {{ic|Eisu}} (Eisu_toggle), {{ic|Hiragana/Katakana}} or {{ic|Muhenkan}} key, but the ASCII keyboard has none of them.<br />
<br />
One solution for it is to use Caps Lock key as Eisu_toggle (Mozc does not recognize the Caps Lock key as of r124). The following is a way to assign Eisu_toggle to {{ic|Caps Lock}} (without any modifier keys) and Caps_Lock to {{ic|Shift+CapsLock}}, as on the OADG keyboard layout.<br />
{{Warning|This will affect all applications.}}<br />
<br />
Edit {{ic|~/.Xmodmap}} as follows:<br />
keycode 66 = Eisu_toggle Caps_Lock<br />
clear Lock<br />
<br />
Then, restart X or run ''xmodmap'' to apply the changes immediately:<br />
$ xmodmap ~/.Xmodmap<br />
<br />
== Troubleshooting ==<br />
<br />
=== Building Mozc fails (process is killed) ===<br />
<br />
If the build process fails with an error message like the following:<br />
...<br />
/bin/sh: line 1: xxxx killed<br />
...<br />
make: *** [xxx/xxx...] error 137<br />
...<br />
Make sure you have not run out of memory.<br />
<br />
=== New version of Mozc does not appear though I upgraded Mozc and restarted X or Input Method Framework (not rebooted) ===<br />
<br />
The old version of Mozc may be still on your memory. Try to kill the existing ''mozc_server'' process:<br />
$ killall mozc_server<br />
<br />
=== mozc_server becomes defunct ===<br />
<br />
Mozc cannot run in root. Start X in normal user.<br />
<br />
=== mozc_emacs_helper not found in emacs ===<br />
<br />
When installing mozc.el you need to install a helper program called {{ic|mozc_emacs_helper}}.<br />
<br />
You need to install {{AUR|emacs-mozc}} or {{AUR|emacs-mozc-ut2}} for this helper program.<br />
<br />
=== mozc tool(s) does not launch ===<br />
It is also possible to launch Mozc tools with log sent directly to console, which is useful for debugging. To enable this, simply append {{ic|--logtostderr}} like this for example:<br />
<br />
{{ic|1=$ /usr/lib/mozc/mozc_tool --mode=config_dialog --logtostderr}}<br />
<br />
[https://github.com/google/mozc/issues/438 See also]</div>Tuxsavvyhttps://wiki.archlinux.org/index.php?title=Talk:Systemd-networkd&diff=647976Talk:Systemd-networkd2021-01-02T09:17:22Z<p>Tuxsavvy: /* Setting up and connecting to wireless networks using systemd-networkd via wpa_supplicant */ Replying to my own topic.</p>
<hr />
<div>== Static IP example for single host ==<br />
<br />
(moved from [[Talk:Network_configuration#Systemd-networkd]])<br />
<br />
Now that networkd is maturing and much simpler to configure for VMs, containers, etc should we include a section with an example?<br />
{{unsigned|21:42, 1 January 2015|Chetwisniewski}}<br />
<br />
:There is a whole page on [[systemd-networkd]] already, and it is linked from [[Network_configuration#Configure_the_IP_address]]. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 21:52, 1 January 2015 (UTC)<br />
<br />
:It doesn't include any decent static examples. Perhaps I should post these points to that page? Something with example config, like:<br />
<br />
{{hc|/etc/systemd/network/enp3s0.network|<nowiki><br />
[Match]<br />
Name=enp3s0<br />
[Network]<br />
DNS=fe80:a3c1::1<br />
DNS=192.168.0.1<br />
Address=192.168.0.10/24<br />
Address=2001:DB8::1/64<br />
Gateway=192.168.0.1<br />
</nowiki>}}<br />
<br />
[[User:Chetwisniewski|Chetwisniewski]] ([[User talk:Chetwisniewski|talk]]) 21:59, 1 January 2015 (UTC)<br />
<br />
::Re-opening. That would make sense imo. But we need to take care not to break the existing [[Systemd-networkd#Static IP network]] instructions. Maybe it is just necessary to clarify which steps are required to set up static for a single host before leading over to the bridge/container setup (analoguous to the first example in [[Systemd-networkd#Basic DHCP network]]). Ok?--[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 23:57, 1 January 2015 (UTC)<br />
::Comparing your example config again to what we have, the only major difference is the IPv6 which is not covered in this article yet. Still the basic instructions for a single host could be made clearer in this article. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 18:11, 9 February 2015 (UTC)<br />
<br />
== standalone vs containers ==<br />
<br />
Yes, I agree with the discussion and the style warning on the main page: we should break this out into two parts to make it clear which are for standalone systems and which are for containers which are likely foreign to some users.<br />
[[User:Graysky|Graysky]] ([[User talk:Graysky|talk]]) 12:06, 27 March 2015 (UTC)<br />
<br />
: There, I made a pretty major edit to the main article in an attempt to break out "basic" from "complex" usage cases. I don't have inclination or knowledge to comb through the original article targeted mainly at container usage. [[User:Graysky|Graysky]] ([[User talk:Graysky|talk]]) 19:49, 27 March 2015 (UTC)<br />
<br />
::Thanks. How about moving the whole container section to a subpage. Relevant parts can be merged back to the main article; as of now, the container section is not very usable anyway. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 19:53, 27 March 2015 (UTC)<br />
<br />
::: Feel free to do it. I'm out of time for now. [[User:Graysky|Graysky]] ([[User talk:Graysky|talk]]) 20:03, 27 March 2015 (UTC)<br />
<br />
:::: Neat edit that was! Good to have the basic examples on top. As for moving the container section to a subpage, sure why not. Yet, I would vote for keeping [[Systemd-networkd#Configuration files]] on the main page (to see how it works I moved it like it is now). It would be a strange article ending with a section like that though.? The container section uses some configuration files content as practical examples on the other hand. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 20:39, 27 March 2015 (UTC)<br />
<br />
== Usage with containers -- Static IP network ==<br />
<br />
Not having worked with systemd-networkd before (moving over from the custom systemd script method) this section looks like it has a typo, an omission, or a missing explanation. The list of configuration files uses a .netdev extension on MyBridge, and the example uses a .network extension on MyBridge.<br />
<br />
Again, being new to systemd-networkd, I think there is supposed to be both a MyBridge.netdev file with "[NetDev] Name=br0 Kind=bridge" and a MyBridge.bridge file with "[Match] Name=br0 [Network] DNS= Address= Gateway=". Or, maybe I'm using more files than I needed and just one of the extensions needs to be changed. Or maybe I'm totally off, and a clarification would prevent someone else from making the same mistake. [[User:Jamespharvey20|Jamespharvey20]] ([[User talk:Jamespharvey20|talk]]) 06:44, 20 July 2015 (UTC)<br />
<br />
:My guess is that you need MyBridge.netdev from [[Systemd-networkd#Bridge_interface]], MyEth.network from [[Systemd-networkd#Bind_ethernet_to_bridge]] and MyBridge.network from [[Systemd-networkd#Static_IP_network]] (this is the change against [[Systemd-networkd#Bridge_network]], hence the only file actually shown in that section). If you manage to get it working, please fix the listing of necessary files accordingly. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 07:39, 20 July 2015 (UTC)<br />
<br />
::This is correct. The MyBridge.netdev file is needed to create the virtual device br0 first. This way the device now exists when MyEth.network refers to it with Bridge=br0 and MyBridge.network refers to it with Name=br0. Note: In a DHCP setup, I think it may be important to use file names to specify the order, since in theory a physical adapter needs to be bound to the bridge first before the bridge can request an IP address. Perhaps naming the files 10-MyBridge.netdev, 20-MyEth.network, and 30-MyBridge.network would help clarify the meaning behind these files better? This setup worked well for me. [[User:Xerion567|Xerion567]] ([[User talk:Xerion567|talk]]) 09:31, 30 January 2016 (UTC)<br />
<br />
== I couldn't find /run/systemd/resolve/resolv.conf ==<br />
<br />
I had read this line and I couldn't find the file<br />
# ln -s /run/systemd/resolve/resolv.conf /etc/resolv.conf<br />
But I can see /etc/systemd/resolved.conf. should I just do not link anything?<br />
<br />
Answer: you need to run systemd-resolved, which will create it.<br />
:This symlink should not be needed since systemd-226. In a typical setup, you should simply remove /etc/resolv.conf. Posted here, rather than edit wiki directly, in the event that this is not good for more advanced setups. [[User:DJ L|DJ L]] ([[User talk:DJ L|talk]]) 04:51, 4 February 2016 (UTC)<br />
:: Oops, good thing I didn't edit. This is not covered in systemd documentation. I don't see any issue with this, but I'll reach out to the devs on it. Should probably be addressed in systemd-resolved manpage (even if not supported). [[User:DJ L|DJ L]] ([[User talk:DJ L|talk]]) 05:48, 4 February 2016 (UTC)<br />
<br />
== Note about systemd-resolved.service ==<br />
<br />
In my today's contribution (https://wiki.archlinux.org/index.php?title=Systemd-networkd&oldid=408408) I've added a note about the systemd-resolved service. I never needed that service in a wired/static-ip/single user environment, checking the LFS doc http://www.linuxfromscratch.org/lfs/view/systemd/chapter07/network.html seems to confirm that in that scenario you don't actually need it. Please double check.<br />
<br />
{{unsigned|12:51, 7 November 2015|Matt3o}}<br />
<br />
:I have no idea what you mean by "single user environment", but the official documentation is [http://www.freedesktop.org/software/systemd/man/systemd-resolved.html here]. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 13:14, 7 November 2015 (UTC)<br />
<br />
::The previous comment (by Matt3o) is incorrect. I'm not sure where exactly we differ (I only comment because I was actually the one who rewrote that part of BLFS page linked above), but the systemd-networkd service does not seem to be enabled by default in Arch's systemd package (I'm sure there is a reason, since it is enabled by default in a fresh build of systemd, I'm just not familiar with the decision to exclude it). As to where "single user environment" came from, I've no idea. That concept is pretty much dead, no more runlevel 2 since systemd has arrived, and networking wouldn't have been present in any case. Maybe he was referring to a single PC (very small network) where static networking is acceptable? :-/ [[User:DJ L|DJ L]] ([[User talk:DJ L|talk]]) 05:34, 4 February 2016 (UTC)<br />
<br />
== More static/DHCP examples ==<br />
<br />
The Wiki mentions as a note "The Metric option is for static routes while the RouteMetric option is for setups not using static routes."<br />
While not clear why two different keywords are needed (but let's leave that for upstream to discuss), the Wiki has no example of how "Metric" is used in a static configuration.<br />
<br />
I think the reader is left somewhat in a trial&error loop here (at least I am as I intend to keep my configuration I used in another distro: static for wired, DHCP for wireless). While I'll figure it out eventually, I think at least some clues here would have been helpful as I do not think that config is so exotic. (use static wired in home office, DHCP wireless abroad) Unfortunately, I'm still lacking sufficient systemd experience to make the amendments myself [[User:Archer666|Archer666]] ([[User talk:Archer666|talk]]) 20:48, 2 November 2016 (UTC)<br />
<br />
== Systemd-networkd dhcp configuration ==<br />
<br />
I'm getting confused with dhcp configuration parameters for ipv4. While SYSTEMD.NETWORK(5) suggests setting DHCP=ipv4 under the [Network] section, systemd-networkd refuses to start and logs a unknown parameter error. Setting DHCP=v4 resolves the issue, as the german Arch wiki article suggests: https://wiki.archlinux.de/title/Systemd/systemd-networkd<br />
Does anyone else see this with systemd 232? [[User:anarki|anarki]] ([[User talk:anarki|talk]]) 22:40, 2016-12-06 UTC<br />
<br />
== nsswitch.conf ==<br />
<br />
I removed the recommended nsswitch.conf configuration; it was misleading and out-of-date. The latest filesystem package configures nsswitch.conf correctly to use nss-resolve and fall back in the proper way to nss-dns. The recommended setup breaks glibc DNS resolution in several situations, notably with GPG. [[User:Tad|Tad]] ([[User talk:Tad|talk]]) 20:25, 21 February 2017 (UTC)<br />
<br />
== Why link /run/systemd/resolve/resolv.conf instead of /usr/lib/systemd/resolv.conf ? ==<br />
<br />
{{man|8|systemd-resolved}} says linking from {{ic|/etc/resolv.conf}} to {{ic|/usr/lib/systemd/resolv.conf}} is preferred over linking to {{ic|/run/systemd/resolve/resolv.conf}}.<br />
<br />
{{unsigned| 15:50, 15 November 2017|Mearon}}<br />
<br />
:Could you provide a literal quote of the confusing part? -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 16:58, 15 November 2017 (UTC)<br />
<br />
::Sorry for being unspecific. It's the first codeblock here [[Systemd-networkd#Required_services_and_setup]], immediately after the sentence "For compatibility with resolv.conf, delete or rename the existing file and create the following symbolic link when using systemd-resolved:" [[User:Mearon|Mearon]] ([[User talk:Mearon|talk]]) 18:22, 15 November 2017 (UTC)<br />
<br />
:::So it's not from the {{man|8|systemd-resolved}} man page. Maybe it's a relatively new feature? -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 18:51, 15 November 2017 (UTC)<br />
<br />
::::"•A static file /usr/lib/systemd/resolv.conf is provided that lists the 127.0.0.53 DNS stub (see above) as only DNS server. This file may be symlinked from /etc/resolv.conf in order to connect all local clients that bypass local DNS APIs to systemd-resolved. This mode of operation is recommended."<br />
::::Considering this seems to be in perpetual flux as most systemd things, I'd say we delete that sentence and just refer to the man page. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 19:29, 15 November 2017 (UTC)<br />
<br />
::::{{man|8|systemd-resolved}} lists three alternatives for dealing with /etc/resolv.conf: [http://jlk.fjfi.cvut.cz/arch/manpages/man/systemd-resolved.8#/ETC/RESOLV.CONF]<br />
::::The Arch Wiki currently only mentions option 2 ({{ic|ln -s /run/systemd/resolve/resolv.conf /etc/resolv.conf}}) while {{man|8|systemd-resolved}} recommends option 1 ({{ic|ln -s /usr/lib/systemd/resolv.conf /etc/resolv.conf}}) as quoted by [[User:Alad|Alad]]. [[User:Mearon|Mearon]] ([[User talk:Mearon|talk]]) 20:49, 15 November 2017 (UTC)<br />
<br />
:::::It seems that in systemd 236 the recommended option is changing. As per [https://lists.freedesktop.org/archives/systemd-devel/2017-December/039996.html]: ''"systemd-resolved now maintains a new dynamic /run/systemd/resolve/stub-resolv.conf compatibility file. It is recommended to make /etc/resolv.conf a symlink to it. This file points at the systemd-resolved stub DNS 127.0.0.53 resolver and includes dynamically acquired search domains, achieving more correct DNS resolution by software that bypasses local DNS APIs such as NSS."''<br />
:::::It seems the best of both worlds since this way programs that directly read {{ic|resolv.conf}} don't bypass ''systemd-resolved'''s per-interface DNS server configuration (very problematic in the case of VPN's, for example) but search domains are still accessible for them.<br />
:::::When {{pkg|systemd}} 236 is finally available in ''core'', I think we should update this page to recommend using the new {{ic|stub-resolv.conf}}. --[[User:Icycat|Icycat]] ([[User talk:Icycat|talk]]) 16:30, 16 December 2017 (UTC)<br />
::::::Now that {{pkg|systemd}} 236 is in ''core'', I have updated the page with this new recommendation. --[[User:Icycat|Icycat]] ([[User talk:Icycat|talk]]) 08:50, 22 December 2017 (UTC)<br />
<br />
== <s>Static IP example for Wireless adapter</s> ==<br />
<br />
Simply create /etc/systemd/network/25-wireless.network <br />
with, e.g.<br />
[Match]<br />
Name=wlan0<br />
<br />
[Network]<br />
Address=192.168.0.12/24<br />
Gateway=192.168.0.254<br />
<br />
needs no other file to work<br />
<br />
{{Unsigned|06:19, 18 July 2019 (UTC)|Waitnsea}}<br />
<br />
:There is already an example in [[systemd-networkd#Wired adapter using a static IP]]. Changing {{ic|1=Name=wlan0}} or whatever is trivial, no other example is needed. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 09:32, 24 December 2020 (UTC)<br />
<br />
== systemd-networkd + Dm-crypt/Swap = system not booting ==<br />
<br />
:See also [[Talk:Dm-crypt/Swap encryption#Dm-crypt/Swap + systemd-networkd = system not booting]]<br />
<br />
I encountered issue on fresh install on small VPS (1Gb RAM, 1vCPU) that if I have systemd-networkd and crypt-swap then boot process hangs while waiting for crypt-swap device. Posted workaround here: https://bbs.archlinux.org/viewtopic.php?pid=1882917#p1882917<br />
<br />
[[User:Gregosky|Gregosky]] ([[User talk:Gregosky|talk]]) 06:31, 16 January 2020 (UTC)<br />
<br />
== Setting up and connecting to wireless networks using systemd-networkd via wpa_supplicant ==<br />
<br />
systemd-networkd is great for configuring wired networks, but it lacks the ability to authenticate or associate (connect) with/to a wireless network. This leaves the user wondering and looking for alternatives. There is a clever trick, and that is to use something like [[Wpa_supplicant|wpa_supplicant]]. There are advantages to use systemd-networkd with wpa_supplicant, and here are the highlights:<br />
* wpa_supplicant does not interfere with systemd-networkd, as systemd-networkd handles IP and routing, whereas wpa_supplicant handles with authentication and association/connection. Technically, the two operates on different layers on the [[wikipedia:OSI_model|OSI model]].<br />
* wpa_supplicant, like systemd-networkd, does not have a graphical interface/front-end. This can be especially useful when one does not need to worry about the memory/bandwidth overhead for needing to interface it graphically and/or remotely.<br />
* wpa_supplicant can store Pre-Shared Key (PSK) in encrypted format. Some network managers stores these in plain text, thus could lead to other security implications in the event of machine compromise, and that it contains keys/passwords stored in plain text.<br />
Naturally, the use of such a setup does also have certain caveats, and with complicating the issues being one of them.<br />
<br />
These leads me to my suggestion. Considering that there has been discussions on how to make the two daemons work together on [https://bbs.archlinux.org/viewtopic.php?id=178625 Arch Linux Forums], and that it is a link under the See Also section of this (Systemd-networkd wiki) page. Is it possible instead, to expand this as a sub-page (to this page of course) or at least as a sub-section? Unfortunately, <br />
* Some of the links detailed on the forums are dead (but Wayback machine still has records of these), <br />
* The forum thread does not offer much explanation/insights, and, <br />
* There's no reference from [[Wpa_supplicant|wpa_supplicant]] page to either that forum thread, or this (Systemd-networkd) page. <br />
With that said, I could help contribute if there's an/enough interest. Addressing this could also see the following be added once it is complete; [[Talk:Systemd-networkd#Static_IP_example_for_Wireless_adapter]]<br />
<br />
[[User:Tuxsavvy|Tuxsavvy]] ([[User talk:Tuxsavvy|talk]]) 09:17, 22 December 2020 (UTC)<br />
<br />
:What is there to describe on the "subpage"? As you said, systemd-networkd and wpa_supplicant operate on different layers, so you configure both as usual, there is nothing special needed to make them work together. There are already multiple references to both [[wpa_supplicant]] and [[iwd]] so it is obvious that the other thing is needed too. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 09:43, 22 December 2020 (UTC)<br />
<br />
::Indeed, there is nothing special about the process. However, the information currently provided as-is, are rudimentary at best, almost like as if considerations to such options are of an afterthought. My point was to:<br />
* Adding page/section visibility (as a related article, as opposed to a link in the see also section),<br />
* Flesh out the information by adding (reference) links, even if they might be dead or archived, and,<br />
* Allow the viability of expansion for the said article. <br />
Potential expansions include (but are not limited to) incorporating that other topic on static IP with wireless, as it is relevant. -- [[User:Tuxsavvy|Tuxsavvy]] ([[User talk:Tuxsavvy|talk]]) 03:43, 24 December 2020 (UTC)<br />
<br />
:* Pages on the wiki are created based on the content, not for artificial visibility. I don't think there is enough content for a separate page.<br />
:* What references are you talking about? Adding dead or archived links does not make sense.<br />
:* You can expand this very page if something is missing, you don't need a new page for that. But I don't see how you imagine the ''new'' content yet...<br />
:-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 09:37, 24 December 2020 (UTC)<br />
<br />
::* The intention was to create a stub page that explains lightly the process, provide a crude example of how to make it all work, along with a few archived links as reference points. This was with hopes to have more related content (e.g. more examples) added to it, as this (existing) page primarily focuses on wired networking aspect, and I was hoping to structure it based on how [[Network_configuration]] and [[Network_configuration/Wireless]] were made respectively.<br />
::* The references are as per outlined before; making systemd-networkd and wpa_supplicant work together. Anyway, here are the links to it:<br />
::** [https://web.archive.org/web/20161116061329/https://beaveris.me/systemd-networkd-with-roaming/ https://web.archive.org/web/20161116061329/https://beaveris.me/systemd-networkd-with-roaming/]<br />
::** [https://web.archive.org/web/20160417055209/http://blog.volcanis.me/2014/06/01/systemd-networkd/ https://web.archive.org/web/20160417055209/http://blog.volcanis.me/2014/06/01/systemd-networkd/]<br />
::** [https://web.archive.org/web/20190524075834/https://dabase.com/blog/Good_riddance_netctl/ https://web.archive.org/web/20190524075834/https://dabase.com/blog/Good_riddance_netctl/]<br />
::The alternative would then be to simply copy and paste the contents of the archived links on here instead, as I do not wish to necro-bump/necro-post an old BBS/forum thread. Posting a new thread in continuation on that old thread instead could potentially be counter-intuitive.<br />
::* I could expand on this existing page. However after discussing it, noticing the recent change on this talk page, it made sense, and my interest with it waned. Initially, I did not want to "pollute" the page with wireless content, as it is also hypothetically possible to make iwd, instead of wpa_supplicant to work with systemd-networkd for instance. Besides, it is boiling down to the end users needing to exercise some ingenuity, as opposed to having a wiki thoroughly explaining these. <nowiki>:)</nowiki><br />
::-- [[User:Tuxsavvy|Tuxsavvy]] ([[User talk:Tuxsavvy|talk]]) 09:17, 2 January 2021 (UTC)</div>Tuxsavvyhttps://wiki.archlinux.org/index.php?title=Talk:Systemd-networkd&diff=647975Talk:Systemd-networkd2021-01-02T09:16:16Z<p>Tuxsavvy: Undo revision 647974 by Tuxsavvy (talk) -- I screwed up with my summary, undoing and redoing it with a proper edit summary on replying my own topic</p>
<hr />
<div>== Static IP example for single host ==<br />
<br />
(moved from [[Talk:Network_configuration#Systemd-networkd]])<br />
<br />
Now that networkd is maturing and much simpler to configure for VMs, containers, etc should we include a section with an example?<br />
{{unsigned|21:42, 1 January 2015|Chetwisniewski}}<br />
<br />
:There is a whole page on [[systemd-networkd]] already, and it is linked from [[Network_configuration#Configure_the_IP_address]]. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 21:52, 1 January 2015 (UTC)<br />
<br />
:It doesn't include any decent static examples. Perhaps I should post these points to that page? Something with example config, like:<br />
<br />
{{hc|/etc/systemd/network/enp3s0.network|<nowiki><br />
[Match]<br />
Name=enp3s0<br />
[Network]<br />
DNS=fe80:a3c1::1<br />
DNS=192.168.0.1<br />
Address=192.168.0.10/24<br />
Address=2001:DB8::1/64<br />
Gateway=192.168.0.1<br />
</nowiki>}}<br />
<br />
[[User:Chetwisniewski|Chetwisniewski]] ([[User talk:Chetwisniewski|talk]]) 21:59, 1 January 2015 (UTC)<br />
<br />
::Re-opening. That would make sense imo. But we need to take care not to break the existing [[Systemd-networkd#Static IP network]] instructions. Maybe it is just necessary to clarify which steps are required to set up static for a single host before leading over to the bridge/container setup (analoguous to the first example in [[Systemd-networkd#Basic DHCP network]]). Ok?--[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 23:57, 1 January 2015 (UTC)<br />
::Comparing your example config again to what we have, the only major difference is the IPv6 which is not covered in this article yet. Still the basic instructions for a single host could be made clearer in this article. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 18:11, 9 February 2015 (UTC)<br />
<br />
== standalone vs containers ==<br />
<br />
Yes, I agree with the discussion and the style warning on the main page: we should break this out into two parts to make it clear which are for standalone systems and which are for containers which are likely foreign to some users.<br />
[[User:Graysky|Graysky]] ([[User talk:Graysky|talk]]) 12:06, 27 March 2015 (UTC)<br />
<br />
: There, I made a pretty major edit to the main article in an attempt to break out "basic" from "complex" usage cases. I don't have inclination or knowledge to comb through the original article targeted mainly at container usage. [[User:Graysky|Graysky]] ([[User talk:Graysky|talk]]) 19:49, 27 March 2015 (UTC)<br />
<br />
::Thanks. How about moving the whole container section to a subpage. Relevant parts can be merged back to the main article; as of now, the container section is not very usable anyway. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 19:53, 27 March 2015 (UTC)<br />
<br />
::: Feel free to do it. I'm out of time for now. [[User:Graysky|Graysky]] ([[User talk:Graysky|talk]]) 20:03, 27 March 2015 (UTC)<br />
<br />
:::: Neat edit that was! Good to have the basic examples on top. As for moving the container section to a subpage, sure why not. Yet, I would vote for keeping [[Systemd-networkd#Configuration files]] on the main page (to see how it works I moved it like it is now). It would be a strange article ending with a section like that though.? The container section uses some configuration files content as practical examples on the other hand. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 20:39, 27 March 2015 (UTC)<br />
<br />
== Usage with containers -- Static IP network ==<br />
<br />
Not having worked with systemd-networkd before (moving over from the custom systemd script method) this section looks like it has a typo, an omission, or a missing explanation. The list of configuration files uses a .netdev extension on MyBridge, and the example uses a .network extension on MyBridge.<br />
<br />
Again, being new to systemd-networkd, I think there is supposed to be both a MyBridge.netdev file with "[NetDev] Name=br0 Kind=bridge" and a MyBridge.bridge file with "[Match] Name=br0 [Network] DNS= Address= Gateway=". Or, maybe I'm using more files than I needed and just one of the extensions needs to be changed. Or maybe I'm totally off, and a clarification would prevent someone else from making the same mistake. [[User:Jamespharvey20|Jamespharvey20]] ([[User talk:Jamespharvey20|talk]]) 06:44, 20 July 2015 (UTC)<br />
<br />
:My guess is that you need MyBridge.netdev from [[Systemd-networkd#Bridge_interface]], MyEth.network from [[Systemd-networkd#Bind_ethernet_to_bridge]] and MyBridge.network from [[Systemd-networkd#Static_IP_network]] (this is the change against [[Systemd-networkd#Bridge_network]], hence the only file actually shown in that section). If you manage to get it working, please fix the listing of necessary files accordingly. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 07:39, 20 July 2015 (UTC)<br />
<br />
::This is correct. The MyBridge.netdev file is needed to create the virtual device br0 first. This way the device now exists when MyEth.network refers to it with Bridge=br0 and MyBridge.network refers to it with Name=br0. Note: In a DHCP setup, I think it may be important to use file names to specify the order, since in theory a physical adapter needs to be bound to the bridge first before the bridge can request an IP address. Perhaps naming the files 10-MyBridge.netdev, 20-MyEth.network, and 30-MyBridge.network would help clarify the meaning behind these files better? This setup worked well for me. [[User:Xerion567|Xerion567]] ([[User talk:Xerion567|talk]]) 09:31, 30 January 2016 (UTC)<br />
<br />
== I couldn't find /run/systemd/resolve/resolv.conf ==<br />
<br />
I had read this line and I couldn't find the file<br />
# ln -s /run/systemd/resolve/resolv.conf /etc/resolv.conf<br />
But I can see /etc/systemd/resolved.conf. should I just do not link anything?<br />
<br />
Answer: you need to run systemd-resolved, which will create it.<br />
:This symlink should not be needed since systemd-226. In a typical setup, you should simply remove /etc/resolv.conf. Posted here, rather than edit wiki directly, in the event that this is not good for more advanced setups. [[User:DJ L|DJ L]] ([[User talk:DJ L|talk]]) 04:51, 4 February 2016 (UTC)<br />
:: Oops, good thing I didn't edit. This is not covered in systemd documentation. I don't see any issue with this, but I'll reach out to the devs on it. Should probably be addressed in systemd-resolved manpage (even if not supported). [[User:DJ L|DJ L]] ([[User talk:DJ L|talk]]) 05:48, 4 February 2016 (UTC)<br />
<br />
== Note about systemd-resolved.service ==<br />
<br />
In my today's contribution (https://wiki.archlinux.org/index.php?title=Systemd-networkd&oldid=408408) I've added a note about the systemd-resolved service. I never needed that service in a wired/static-ip/single user environment, checking the LFS doc http://www.linuxfromscratch.org/lfs/view/systemd/chapter07/network.html seems to confirm that in that scenario you don't actually need it. Please double check.<br />
<br />
{{unsigned|12:51, 7 November 2015|Matt3o}}<br />
<br />
:I have no idea what you mean by "single user environment", but the official documentation is [http://www.freedesktop.org/software/systemd/man/systemd-resolved.html here]. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 13:14, 7 November 2015 (UTC)<br />
<br />
::The previous comment (by Matt3o) is incorrect. I'm not sure where exactly we differ (I only comment because I was actually the one who rewrote that part of BLFS page linked above), but the systemd-networkd service does not seem to be enabled by default in Arch's systemd package (I'm sure there is a reason, since it is enabled by default in a fresh build of systemd, I'm just not familiar with the decision to exclude it). As to where "single user environment" came from, I've no idea. That concept is pretty much dead, no more runlevel 2 since systemd has arrived, and networking wouldn't have been present in any case. Maybe he was referring to a single PC (very small network) where static networking is acceptable? :-/ [[User:DJ L|DJ L]] ([[User talk:DJ L|talk]]) 05:34, 4 February 2016 (UTC)<br />
<br />
== More static/DHCP examples ==<br />
<br />
The Wiki mentions as a note "The Metric option is for static routes while the RouteMetric option is for setups not using static routes."<br />
While not clear why two different keywords are needed (but let's leave that for upstream to discuss), the Wiki has no example of how "Metric" is used in a static configuration.<br />
<br />
I think the reader is left somewhat in a trial&error loop here (at least I am as I intend to keep my configuration I used in another distro: static for wired, DHCP for wireless). While I'll figure it out eventually, I think at least some clues here would have been helpful as I do not think that config is so exotic. (use static wired in home office, DHCP wireless abroad) Unfortunately, I'm still lacking sufficient systemd experience to make the amendments myself [[User:Archer666|Archer666]] ([[User talk:Archer666|talk]]) 20:48, 2 November 2016 (UTC)<br />
<br />
== Systemd-networkd dhcp configuration ==<br />
<br />
I'm getting confused with dhcp configuration parameters for ipv4. While SYSTEMD.NETWORK(5) suggests setting DHCP=ipv4 under the [Network] section, systemd-networkd refuses to start and logs a unknown parameter error. Setting DHCP=v4 resolves the issue, as the german Arch wiki article suggests: https://wiki.archlinux.de/title/Systemd/systemd-networkd<br />
Does anyone else see this with systemd 232? [[User:anarki|anarki]] ([[User talk:anarki|talk]]) 22:40, 2016-12-06 UTC<br />
<br />
== nsswitch.conf ==<br />
<br />
I removed the recommended nsswitch.conf configuration; it was misleading and out-of-date. The latest filesystem package configures nsswitch.conf correctly to use nss-resolve and fall back in the proper way to nss-dns. The recommended setup breaks glibc DNS resolution in several situations, notably with GPG. [[User:Tad|Tad]] ([[User talk:Tad|talk]]) 20:25, 21 February 2017 (UTC)<br />
<br />
== Why link /run/systemd/resolve/resolv.conf instead of /usr/lib/systemd/resolv.conf ? ==<br />
<br />
{{man|8|systemd-resolved}} says linking from {{ic|/etc/resolv.conf}} to {{ic|/usr/lib/systemd/resolv.conf}} is preferred over linking to {{ic|/run/systemd/resolve/resolv.conf}}.<br />
<br />
{{unsigned| 15:50, 15 November 2017|Mearon}}<br />
<br />
:Could you provide a literal quote of the confusing part? -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 16:58, 15 November 2017 (UTC)<br />
<br />
::Sorry for being unspecific. It's the first codeblock here [[Systemd-networkd#Required_services_and_setup]], immediately after the sentence "For compatibility with resolv.conf, delete or rename the existing file and create the following symbolic link when using systemd-resolved:" [[User:Mearon|Mearon]] ([[User talk:Mearon|talk]]) 18:22, 15 November 2017 (UTC)<br />
<br />
:::So it's not from the {{man|8|systemd-resolved}} man page. Maybe it's a relatively new feature? -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 18:51, 15 November 2017 (UTC)<br />
<br />
::::"•A static file /usr/lib/systemd/resolv.conf is provided that lists the 127.0.0.53 DNS stub (see above) as only DNS server. This file may be symlinked from /etc/resolv.conf in order to connect all local clients that bypass local DNS APIs to systemd-resolved. This mode of operation is recommended."<br />
::::Considering this seems to be in perpetual flux as most systemd things, I'd say we delete that sentence and just refer to the man page. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 19:29, 15 November 2017 (UTC)<br />
<br />
::::{{man|8|systemd-resolved}} lists three alternatives for dealing with /etc/resolv.conf: [http://jlk.fjfi.cvut.cz/arch/manpages/man/systemd-resolved.8#/ETC/RESOLV.CONF]<br />
::::The Arch Wiki currently only mentions option 2 ({{ic|ln -s /run/systemd/resolve/resolv.conf /etc/resolv.conf}}) while {{man|8|systemd-resolved}} recommends option 1 ({{ic|ln -s /usr/lib/systemd/resolv.conf /etc/resolv.conf}}) as quoted by [[User:Alad|Alad]]. [[User:Mearon|Mearon]] ([[User talk:Mearon|talk]]) 20:49, 15 November 2017 (UTC)<br />
<br />
:::::It seems that in systemd 236 the recommended option is changing. As per [https://lists.freedesktop.org/archives/systemd-devel/2017-December/039996.html]: ''"systemd-resolved now maintains a new dynamic /run/systemd/resolve/stub-resolv.conf compatibility file. It is recommended to make /etc/resolv.conf a symlink to it. This file points at the systemd-resolved stub DNS 127.0.0.53 resolver and includes dynamically acquired search domains, achieving more correct DNS resolution by software that bypasses local DNS APIs such as NSS."''<br />
:::::It seems the best of both worlds since this way programs that directly read {{ic|resolv.conf}} don't bypass ''systemd-resolved'''s per-interface DNS server configuration (very problematic in the case of VPN's, for example) but search domains are still accessible for them.<br />
:::::When {{pkg|systemd}} 236 is finally available in ''core'', I think we should update this page to recommend using the new {{ic|stub-resolv.conf}}. --[[User:Icycat|Icycat]] ([[User talk:Icycat|talk]]) 16:30, 16 December 2017 (UTC)<br />
::::::Now that {{pkg|systemd}} 236 is in ''core'', I have updated the page with this new recommendation. --[[User:Icycat|Icycat]] ([[User talk:Icycat|talk]]) 08:50, 22 December 2017 (UTC)<br />
<br />
== <s>Static IP example for Wireless adapter</s> ==<br />
<br />
Simply create /etc/systemd/network/25-wireless.network <br />
with, e.g.<br />
[Match]<br />
Name=wlan0<br />
<br />
[Network]<br />
Address=192.168.0.12/24<br />
Gateway=192.168.0.254<br />
<br />
needs no other file to work<br />
<br />
{{Unsigned|06:19, 18 July 2019 (UTC)|Waitnsea}}<br />
<br />
:There is already an example in [[systemd-networkd#Wired adapter using a static IP]]. Changing {{ic|1=Name=wlan0}} or whatever is trivial, no other example is needed. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 09:32, 24 December 2020 (UTC)<br />
<br />
== systemd-networkd + Dm-crypt/Swap = system not booting ==<br />
<br />
:See also [[Talk:Dm-crypt/Swap encryption#Dm-crypt/Swap + systemd-networkd = system not booting]]<br />
<br />
I encountered issue on fresh install on small VPS (1Gb RAM, 1vCPU) that if I have systemd-networkd and crypt-swap then boot process hangs while waiting for crypt-swap device. Posted workaround here: https://bbs.archlinux.org/viewtopic.php?pid=1882917#p1882917<br />
<br />
[[User:Gregosky|Gregosky]] ([[User talk:Gregosky|talk]]) 06:31, 16 January 2020 (UTC)<br />
<br />
== Setting up and connecting to wireless networks using systemd-networkd via wpa_supplicant ==<br />
<br />
systemd-networkd is great for configuring wired networks, but it lacks the ability to authenticate or associate (connect) with/to a wireless network. This leaves the user wondering and looking for alternatives. There is a clever trick, and that is to use something like [[Wpa_supplicant|wpa_supplicant]]. There are advantages to use systemd-networkd with wpa_supplicant, and here are the highlights:<br />
* wpa_supplicant does not interfere with systemd-networkd, as systemd-networkd handles IP and routing, whereas wpa_supplicant handles with authentication and association/connection. Technically, the two operates on different layers on the [[wikipedia:OSI_model|OSI model]].<br />
* wpa_supplicant, like systemd-networkd, does not have a graphical interface/front-end. This can be especially useful when one does not need to worry about the memory/bandwidth overhead for needing to interface it graphically and/or remotely.<br />
* wpa_supplicant can store Pre-Shared Key (PSK) in encrypted format. Some network managers stores these in plain text, thus could lead to other security implications in the event of machine compromise, and that it contains keys/passwords stored in plain text.<br />
Naturally, the use of such a setup does also have certain caveats, and with complicating the issues being one of them.<br />
<br />
These leads me to my suggestion. Considering that there has been discussions on how to make the two daemons work together on [https://bbs.archlinux.org/viewtopic.php?id=178625 Arch Linux Forums], and that it is a link under the See Also section of this (Systemd-networkd wiki) page. Is it possible instead, to expand this as a sub-page (to this page of course) or at least as a sub-section? Unfortunately, <br />
* Some of the links detailed on the forums are dead (but Wayback machine still has records of these), <br />
* The forum thread does not offer much explanation/insights, and, <br />
* There's no reference from [[Wpa_supplicant|wpa_supplicant]] page to either that forum thread, or this (Systemd-networkd) page. <br />
With that said, I could help contribute if there's an/enough interest. Addressing this could also see the following be added once it is complete; [[Talk:Systemd-networkd#Static_IP_example_for_Wireless_adapter]]<br />
<br />
[[User:Tuxsavvy|Tuxsavvy]] ([[User talk:Tuxsavvy|talk]]) 09:17, 22 December 2020 (UTC)<br />
<br />
:What is there to describe on the "subpage"? As you said, systemd-networkd and wpa_supplicant operate on different layers, so you configure both as usual, there is nothing special needed to make them work together. There are already multiple references to both [[wpa_supplicant]] and [[iwd]] so it is obvious that the other thing is needed too. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 09:43, 22 December 2020 (UTC)<br />
<br />
::Indeed, there is nothing special about the process. However, the information currently provided as-is, are rudimentary at best, almost like as if considerations to such options are of an afterthought. My point was to:<br />
* Adding page/section visibility (as a related article, as opposed to a link in the see also section),<br />
* Flesh out the information by adding (reference) links, even if they might be dead or archived, and,<br />
* Allow the viability of expansion for the said article. <br />
Potential expansions include (but are not limited to) incorporating that other topic on static IP with wireless, as it is relevant. -- [[User:Tuxsavvy|Tuxsavvy]] ([[User talk:Tuxsavvy|talk]]) 03:43, 24 December 2020 (UTC)<br />
<br />
:* Pages on the wiki are created based on the content, not for artificial visibility. I don't think there is enough content for a separate page.<br />
:* What references are you talking about? Adding dead or archived links does not make sense.<br />
:* You can expand this very page if something is missing, you don't need a new page for that. But I don't see how you imagine the ''new'' content yet...<br />
:-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 09:37, 24 December 2020 (UTC)</div>Tuxsavvyhttps://wiki.archlinux.org/index.php?title=Talk:Systemd-networkd&diff=647974Talk:Systemd-networkd2021-01-02T09:13:01Z<p>Tuxsavvy: /</p>
<hr />
<div>== Static IP example for single host ==<br />
<br />
(moved from [[Talk:Network_configuration#Systemd-networkd]])<br />
<br />
Now that networkd is maturing and much simpler to configure for VMs, containers, etc should we include a section with an example?<br />
{{unsigned|21:42, 1 January 2015|Chetwisniewski}}<br />
<br />
:There is a whole page on [[systemd-networkd]] already, and it is linked from [[Network_configuration#Configure_the_IP_address]]. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 21:52, 1 January 2015 (UTC)<br />
<br />
:It doesn't include any decent static examples. Perhaps I should post these points to that page? Something with example config, like:<br />
<br />
{{hc|/etc/systemd/network/enp3s0.network|<nowiki><br />
[Match]<br />
Name=enp3s0<br />
[Network]<br />
DNS=fe80:a3c1::1<br />
DNS=192.168.0.1<br />
Address=192.168.0.10/24<br />
Address=2001:DB8::1/64<br />
Gateway=192.168.0.1<br />
</nowiki>}}<br />
<br />
[[User:Chetwisniewski|Chetwisniewski]] ([[User talk:Chetwisniewski|talk]]) 21:59, 1 January 2015 (UTC)<br />
<br />
::Re-opening. That would make sense imo. But we need to take care not to break the existing [[Systemd-networkd#Static IP network]] instructions. Maybe it is just necessary to clarify which steps are required to set up static for a single host before leading over to the bridge/container setup (analoguous to the first example in [[Systemd-networkd#Basic DHCP network]]). Ok?--[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 23:57, 1 January 2015 (UTC)<br />
::Comparing your example config again to what we have, the only major difference is the IPv6 which is not covered in this article yet. Still the basic instructions for a single host could be made clearer in this article. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 18:11, 9 February 2015 (UTC)<br />
<br />
== standalone vs containers ==<br />
<br />
Yes, I agree with the discussion and the style warning on the main page: we should break this out into two parts to make it clear which are for standalone systems and which are for containers which are likely foreign to some users.<br />
[[User:Graysky|Graysky]] ([[User talk:Graysky|talk]]) 12:06, 27 March 2015 (UTC)<br />
<br />
: There, I made a pretty major edit to the main article in an attempt to break out "basic" from "complex" usage cases. I don't have inclination or knowledge to comb through the original article targeted mainly at container usage. [[User:Graysky|Graysky]] ([[User talk:Graysky|talk]]) 19:49, 27 March 2015 (UTC)<br />
<br />
::Thanks. How about moving the whole container section to a subpage. Relevant parts can be merged back to the main article; as of now, the container section is not very usable anyway. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 19:53, 27 March 2015 (UTC)<br />
<br />
::: Feel free to do it. I'm out of time for now. [[User:Graysky|Graysky]] ([[User talk:Graysky|talk]]) 20:03, 27 March 2015 (UTC)<br />
<br />
:::: Neat edit that was! Good to have the basic examples on top. As for moving the container section to a subpage, sure why not. Yet, I would vote for keeping [[Systemd-networkd#Configuration files]] on the main page (to see how it works I moved it like it is now). It would be a strange article ending with a section like that though.? The container section uses some configuration files content as practical examples on the other hand. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 20:39, 27 March 2015 (UTC)<br />
<br />
== Usage with containers -- Static IP network ==<br />
<br />
Not having worked with systemd-networkd before (moving over from the custom systemd script method) this section looks like it has a typo, an omission, or a missing explanation. The list of configuration files uses a .netdev extension on MyBridge, and the example uses a .network extension on MyBridge.<br />
<br />
Again, being new to systemd-networkd, I think there is supposed to be both a MyBridge.netdev file with "[NetDev] Name=br0 Kind=bridge" and a MyBridge.bridge file with "[Match] Name=br0 [Network] DNS= Address= Gateway=". Or, maybe I'm using more files than I needed and just one of the extensions needs to be changed. Or maybe I'm totally off, and a clarification would prevent someone else from making the same mistake. [[User:Jamespharvey20|Jamespharvey20]] ([[User talk:Jamespharvey20|talk]]) 06:44, 20 July 2015 (UTC)<br />
<br />
:My guess is that you need MyBridge.netdev from [[Systemd-networkd#Bridge_interface]], MyEth.network from [[Systemd-networkd#Bind_ethernet_to_bridge]] and MyBridge.network from [[Systemd-networkd#Static_IP_network]] (this is the change against [[Systemd-networkd#Bridge_network]], hence the only file actually shown in that section). If you manage to get it working, please fix the listing of necessary files accordingly. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 07:39, 20 July 2015 (UTC)<br />
<br />
::This is correct. The MyBridge.netdev file is needed to create the virtual device br0 first. This way the device now exists when MyEth.network refers to it with Bridge=br0 and MyBridge.network refers to it with Name=br0. Note: In a DHCP setup, I think it may be important to use file names to specify the order, since in theory a physical adapter needs to be bound to the bridge first before the bridge can request an IP address. Perhaps naming the files 10-MyBridge.netdev, 20-MyEth.network, and 30-MyBridge.network would help clarify the meaning behind these files better? This setup worked well for me. [[User:Xerion567|Xerion567]] ([[User talk:Xerion567|talk]]) 09:31, 30 January 2016 (UTC)<br />
<br />
== I couldn't find /run/systemd/resolve/resolv.conf ==<br />
<br />
I had read this line and I couldn't find the file<br />
# ln -s /run/systemd/resolve/resolv.conf /etc/resolv.conf<br />
But I can see /etc/systemd/resolved.conf. should I just do not link anything?<br />
<br />
Answer: you need to run systemd-resolved, which will create it.<br />
:This symlink should not be needed since systemd-226. In a typical setup, you should simply remove /etc/resolv.conf. Posted here, rather than edit wiki directly, in the event that this is not good for more advanced setups. [[User:DJ L|DJ L]] ([[User talk:DJ L|talk]]) 04:51, 4 February 2016 (UTC)<br />
:: Oops, good thing I didn't edit. This is not covered in systemd documentation. I don't see any issue with this, but I'll reach out to the devs on it. Should probably be addressed in systemd-resolved manpage (even if not supported). [[User:DJ L|DJ L]] ([[User talk:DJ L|talk]]) 05:48, 4 February 2016 (UTC)<br />
<br />
== Note about systemd-resolved.service ==<br />
<br />
In my today's contribution (https://wiki.archlinux.org/index.php?title=Systemd-networkd&oldid=408408) I've added a note about the systemd-resolved service. I never needed that service in a wired/static-ip/single user environment, checking the LFS doc http://www.linuxfromscratch.org/lfs/view/systemd/chapter07/network.html seems to confirm that in that scenario you don't actually need it. Please double check.<br />
<br />
{{unsigned|12:51, 7 November 2015|Matt3o}}<br />
<br />
:I have no idea what you mean by "single user environment", but the official documentation is [http://www.freedesktop.org/software/systemd/man/systemd-resolved.html here]. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 13:14, 7 November 2015 (UTC)<br />
<br />
::The previous comment (by Matt3o) is incorrect. I'm not sure where exactly we differ (I only comment because I was actually the one who rewrote that part of BLFS page linked above), but the systemd-networkd service does not seem to be enabled by default in Arch's systemd package (I'm sure there is a reason, since it is enabled by default in a fresh build of systemd, I'm just not familiar with the decision to exclude it). As to where "single user environment" came from, I've no idea. That concept is pretty much dead, no more runlevel 2 since systemd has arrived, and networking wouldn't have been present in any case. Maybe he was referring to a single PC (very small network) where static networking is acceptable? :-/ [[User:DJ L|DJ L]] ([[User talk:DJ L|talk]]) 05:34, 4 February 2016 (UTC)<br />
<br />
== More static/DHCP examples ==<br />
<br />
The Wiki mentions as a note "The Metric option is for static routes while the RouteMetric option is for setups not using static routes."<br />
While not clear why two different keywords are needed (but let's leave that for upstream to discuss), the Wiki has no example of how "Metric" is used in a static configuration.<br />
<br />
I think the reader is left somewhat in a trial&error loop here (at least I am as I intend to keep my configuration I used in another distro: static for wired, DHCP for wireless). While I'll figure it out eventually, I think at least some clues here would have been helpful as I do not think that config is so exotic. (use static wired in home office, DHCP wireless abroad) Unfortunately, I'm still lacking sufficient systemd experience to make the amendments myself [[User:Archer666|Archer666]] ([[User talk:Archer666|talk]]) 20:48, 2 November 2016 (UTC)<br />
<br />
== Systemd-networkd dhcp configuration ==<br />
<br />
I'm getting confused with dhcp configuration parameters for ipv4. While SYSTEMD.NETWORK(5) suggests setting DHCP=ipv4 under the [Network] section, systemd-networkd refuses to start and logs a unknown parameter error. Setting DHCP=v4 resolves the issue, as the german Arch wiki article suggests: https://wiki.archlinux.de/title/Systemd/systemd-networkd<br />
Does anyone else see this with systemd 232? [[User:anarki|anarki]] ([[User talk:anarki|talk]]) 22:40, 2016-12-06 UTC<br />
<br />
== nsswitch.conf ==<br />
<br />
I removed the recommended nsswitch.conf configuration; it was misleading and out-of-date. The latest filesystem package configures nsswitch.conf correctly to use nss-resolve and fall back in the proper way to nss-dns. The recommended setup breaks glibc DNS resolution in several situations, notably with GPG. [[User:Tad|Tad]] ([[User talk:Tad|talk]]) 20:25, 21 February 2017 (UTC)<br />
<br />
== Why link /run/systemd/resolve/resolv.conf instead of /usr/lib/systemd/resolv.conf ? ==<br />
<br />
{{man|8|systemd-resolved}} says linking from {{ic|/etc/resolv.conf}} to {{ic|/usr/lib/systemd/resolv.conf}} is preferred over linking to {{ic|/run/systemd/resolve/resolv.conf}}.<br />
<br />
{{unsigned| 15:50, 15 November 2017|Mearon}}<br />
<br />
:Could you provide a literal quote of the confusing part? -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 16:58, 15 November 2017 (UTC)<br />
<br />
::Sorry for being unspecific. It's the first codeblock here [[Systemd-networkd#Required_services_and_setup]], immediately after the sentence "For compatibility with resolv.conf, delete or rename the existing file and create the following symbolic link when using systemd-resolved:" [[User:Mearon|Mearon]] ([[User talk:Mearon|talk]]) 18:22, 15 November 2017 (UTC)<br />
<br />
:::So it's not from the {{man|8|systemd-resolved}} man page. Maybe it's a relatively new feature? -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 18:51, 15 November 2017 (UTC)<br />
<br />
::::"•A static file /usr/lib/systemd/resolv.conf is provided that lists the 127.0.0.53 DNS stub (see above) as only DNS server. This file may be symlinked from /etc/resolv.conf in order to connect all local clients that bypass local DNS APIs to systemd-resolved. This mode of operation is recommended."<br />
::::Considering this seems to be in perpetual flux as most systemd things, I'd say we delete that sentence and just refer to the man page. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 19:29, 15 November 2017 (UTC)<br />
<br />
::::{{man|8|systemd-resolved}} lists three alternatives for dealing with /etc/resolv.conf: [http://jlk.fjfi.cvut.cz/arch/manpages/man/systemd-resolved.8#/ETC/RESOLV.CONF]<br />
::::The Arch Wiki currently only mentions option 2 ({{ic|ln -s /run/systemd/resolve/resolv.conf /etc/resolv.conf}}) while {{man|8|systemd-resolved}} recommends option 1 ({{ic|ln -s /usr/lib/systemd/resolv.conf /etc/resolv.conf}}) as quoted by [[User:Alad|Alad]]. [[User:Mearon|Mearon]] ([[User talk:Mearon|talk]]) 20:49, 15 November 2017 (UTC)<br />
<br />
:::::It seems that in systemd 236 the recommended option is changing. As per [https://lists.freedesktop.org/archives/systemd-devel/2017-December/039996.html]: ''"systemd-resolved now maintains a new dynamic /run/systemd/resolve/stub-resolv.conf compatibility file. It is recommended to make /etc/resolv.conf a symlink to it. This file points at the systemd-resolved stub DNS 127.0.0.53 resolver and includes dynamically acquired search domains, achieving more correct DNS resolution by software that bypasses local DNS APIs such as NSS."''<br />
:::::It seems the best of both worlds since this way programs that directly read {{ic|resolv.conf}} don't bypass ''systemd-resolved'''s per-interface DNS server configuration (very problematic in the case of VPN's, for example) but search domains are still accessible for them.<br />
:::::When {{pkg|systemd}} 236 is finally available in ''core'', I think we should update this page to recommend using the new {{ic|stub-resolv.conf}}. --[[User:Icycat|Icycat]] ([[User talk:Icycat|talk]]) 16:30, 16 December 2017 (UTC)<br />
::::::Now that {{pkg|systemd}} 236 is in ''core'', I have updated the page with this new recommendation. --[[User:Icycat|Icycat]] ([[User talk:Icycat|talk]]) 08:50, 22 December 2017 (UTC)<br />
<br />
== <s>Static IP example for Wireless adapter</s> ==<br />
<br />
Simply create /etc/systemd/network/25-wireless.network <br />
with, e.g.<br />
[Match]<br />
Name=wlan0<br />
<br />
[Network]<br />
Address=192.168.0.12/24<br />
Gateway=192.168.0.254<br />
<br />
needs no other file to work<br />
<br />
{{Unsigned|06:19, 18 July 2019 (UTC)|Waitnsea}}<br />
<br />
:There is already an example in [[systemd-networkd#Wired adapter using a static IP]]. Changing {{ic|1=Name=wlan0}} or whatever is trivial, no other example is needed. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 09:32, 24 December 2020 (UTC)<br />
<br />
== systemd-networkd + Dm-crypt/Swap = system not booting ==<br />
<br />
:See also [[Talk:Dm-crypt/Swap encryption#Dm-crypt/Swap + systemd-networkd = system not booting]]<br />
<br />
I encountered issue on fresh install on small VPS (1Gb RAM, 1vCPU) that if I have systemd-networkd and crypt-swap then boot process hangs while waiting for crypt-swap device. Posted workaround here: https://bbs.archlinux.org/viewtopic.php?pid=1882917#p1882917<br />
<br />
[[User:Gregosky|Gregosky]] ([[User talk:Gregosky|talk]]) 06:31, 16 January 2020 (UTC)<br />
<br />
== Setting up and connecting to wireless networks using systemd-networkd via wpa_supplicant ==<br />
<br />
systemd-networkd is great for configuring wired networks, but it lacks the ability to authenticate or associate (connect) with/to a wireless network. This leaves the user wondering and looking for alternatives. There is a clever trick, and that is to use something like [[Wpa_supplicant|wpa_supplicant]]. There are advantages to use systemd-networkd with wpa_supplicant, and here are the highlights:<br />
* wpa_supplicant does not interfere with systemd-networkd, as systemd-networkd handles IP and routing, whereas wpa_supplicant handles with authentication and association/connection. Technically, the two operates on different layers on the [[wikipedia:OSI_model|OSI model]].<br />
* wpa_supplicant, like systemd-networkd, does not have a graphical interface/front-end. This can be especially useful when one does not need to worry about the memory/bandwidth overhead for needing to interface it graphically and/or remotely.<br />
* wpa_supplicant can store Pre-Shared Key (PSK) in encrypted format. Some network managers stores these in plain text, thus could lead to other security implications in the event of machine compromise, and that it contains keys/passwords stored in plain text.<br />
Naturally, the use of such a setup does also have certain caveats, and with complicating the issues being one of them.<br />
<br />
These leads me to my suggestion. Considering that there has been discussions on how to make the two daemons work together on [https://bbs.archlinux.org/viewtopic.php?id=178625 Arch Linux Forums], and that it is a link under the See Also section of this (Systemd-networkd wiki) page. Is it possible instead, to expand this as a sub-page (to this page of course) or at least as a sub-section? Unfortunately, <br />
* Some of the links detailed on the forums are dead (but Wayback machine still has records of these), <br />
* The forum thread does not offer much explanation/insights, and, <br />
* There's no reference from [[Wpa_supplicant|wpa_supplicant]] page to either that forum thread, or this (Systemd-networkd) page. <br />
With that said, I could help contribute if there's an/enough interest. Addressing this could also see the following be added once it is complete; [[Talk:Systemd-networkd#Static_IP_example_for_Wireless_adapter]]<br />
<br />
[[User:Tuxsavvy|Tuxsavvy]] ([[User talk:Tuxsavvy|talk]]) 09:17, 22 December 2020 (UTC)<br />
<br />
:What is there to describe on the "subpage"? As you said, systemd-networkd and wpa_supplicant operate on different layers, so you configure both as usual, there is nothing special needed to make them work together. There are already multiple references to both [[wpa_supplicant]] and [[iwd]] so it is obvious that the other thing is needed too. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 09:43, 22 December 2020 (UTC)<br />
<br />
::Indeed, there is nothing special about the process. However, the information currently provided as-is, are rudimentary at best, almost like as if considerations to such options are of an afterthought. My point was to:<br />
* Adding page/section visibility (as a related article, as opposed to a link in the see also section),<br />
* Flesh out the information by adding (reference) links, even if they might be dead or archived, and,<br />
* Allow the viability of expansion for the said article. <br />
Potential expansions include (but are not limited to) incorporating that other topic on static IP with wireless, as it is relevant. -- [[User:Tuxsavvy|Tuxsavvy]] ([[User talk:Tuxsavvy|talk]]) 03:43, 24 December 2020 (UTC)<br />
<br />
:* Pages on the wiki are created based on the content, not for artificial visibility. I don't think there is enough content for a separate page.<br />
:* What references are you talking about? Adding dead or archived links does not make sense.<br />
:* You can expand this very page if something is missing, you don't need a new page for that. But I don't see how you imagine the ''new'' content yet...<br />
:-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 09:37, 24 December 2020 (UTC)<br />
<br />
::* The intention was to create a stub page that explains lightly the process, provide a crude example of how to make it all work, along with a few archived links as reference points. This was with hopes to have more related content (e.g. more examples) added to it, as this (existing) page primarily focuses on wired networking aspect, and I was hoping to structure it based on how [[Network_configuration]] and [[Network_configuration/Wireless]] were made respectively.<br />
::* The references are as per outlined before; making systemd-networkd and wpa_supplicant work together. Anyway, here are the links to it:<br />
::** [https://web.archive.org/web/20161116061329/https://beaveris.me/systemd-networkd-with-roaming/ https://web.archive.org/web/20161116061329/https://beaveris.me/systemd-networkd-with-roaming/]<br />
::** [https://web.archive.org/web/20160417055209/http://blog.volcanis.me/2014/06/01/systemd-networkd/ https://web.archive.org/web/20160417055209/http://blog.volcanis.me/2014/06/01/systemd-networkd/]<br />
::** [https://web.archive.org/web/20190524075834/https://dabase.com/blog/Good_riddance_netctl/ https://web.archive.org/web/20190524075834/https://dabase.com/blog/Good_riddance_netctl/]<br />
::The alternative would then be to simply copy and paste the contents of the archived links on here instead, as I do not wish to necro-bump/necro-post an old BBS/forum thread. Posting a new thread in continuation on that old thread instead could potentially be counter-intuitive.<br />
::* I could expand on this existing page. However after discussing it, noticing the recent change on this talk page, it made sense, and my interest with it waned. Initially, I did not want to "pollute" the page with wireless content, as it is also hypothetically possible to make iwd, instead of wpa_supplicant to work with systemd-networkd for instance. Besides, it is boiling down to the end users needing to exercise some ingenuity, as opposed to having a wiki thoroughly explaining these. <nowiki>:)</nowiki><br />
::-- [[User:Tuxsavvy|Tuxsavvy]] ([[User talk:Tuxsavvy|talk]]) 09:13, 2 January 2021 (UTC)</div>Tuxsavvyhttps://wiki.archlinux.org/index.php?title=Talk:Systemd-networkd&diff=646447Talk:Systemd-networkd2020-12-24T03:43:48Z<p>Tuxsavvy: /* Setting up and connecting to wireless networks using systemd-networkd via wpa_supplicant */ Provided my response in regards to a feedback that I received. Editing as it is my own topic.</p>
<hr />
<div>== Static IP example for single host ==<br />
<br />
(moved from [[Talk:Network_configuration#Systemd-networkd]])<br />
<br />
Now that networkd is maturing and much simpler to configure for VMs, containers, etc should we include a section with an example?<br />
{{unsigned|21:42, 1 January 2015|Chetwisniewski}}<br />
<br />
:There is a whole page on [[systemd-networkd]] already, and it is linked from [[Network_configuration#Configure_the_IP_address]]. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 21:52, 1 January 2015 (UTC)<br />
<br />
:It doesn't include any decent static examples. Perhaps I should post these points to that page? Something with example config, like:<br />
<br />
{{hc|/etc/systemd/network/enp3s0.network|<nowiki><br />
[Match]<br />
Name=enp3s0<br />
[Network]<br />
DNS=fe80:a3c1::1<br />
DNS=192.168.0.1<br />
Address=192.168.0.10/24<br />
Address=2001:DB8::1/64<br />
Gateway=192.168.0.1<br />
</nowiki>}}<br />
<br />
[[User:Chetwisniewski|Chetwisniewski]] ([[User talk:Chetwisniewski|talk]]) 21:59, 1 January 2015 (UTC)<br />
<br />
::Re-opening. That would make sense imo. But we need to take care not to break the existing [[Systemd-networkd#Static IP network]] instructions. Maybe it is just necessary to clarify which steps are required to set up static for a single host before leading over to the bridge/container setup (analoguous to the first example in [[Systemd-networkd#Basic DHCP network]]). Ok?--[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 23:57, 1 January 2015 (UTC)<br />
::Comparing your example config again to what we have, the only major difference is the IPv6 which is not covered in this article yet. Still the basic instructions for a single host could be made clearer in this article. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 18:11, 9 February 2015 (UTC)<br />
<br />
== standalone vs containers ==<br />
<br />
Yes, I agree with the discussion and the style warning on the main page: we should break this out into two parts to make it clear which are for standalone systems and which are for containers which are likely foreign to some users.<br />
[[User:Graysky|Graysky]] ([[User talk:Graysky|talk]]) 12:06, 27 March 2015 (UTC)<br />
<br />
: There, I made a pretty major edit to the main article in an attempt to break out "basic" from "complex" usage cases. I don't have inclination or knowledge to comb through the original article targeted mainly at container usage. [[User:Graysky|Graysky]] ([[User talk:Graysky|talk]]) 19:49, 27 March 2015 (UTC)<br />
<br />
::Thanks. How about moving the whole container section to a subpage. Relevant parts can be merged back to the main article; as of now, the container section is not very usable anyway. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 19:53, 27 March 2015 (UTC)<br />
<br />
::: Feel free to do it. I'm out of time for now. [[User:Graysky|Graysky]] ([[User talk:Graysky|talk]]) 20:03, 27 March 2015 (UTC)<br />
<br />
:::: Neat edit that was! Good to have the basic examples on top. As for moving the container section to a subpage, sure why not. Yet, I would vote for keeping [[Systemd-networkd#Configuration files]] on the main page (to see how it works I moved it like it is now). It would be a strange article ending with a section like that though.? The container section uses some configuration files content as practical examples on the other hand. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 20:39, 27 March 2015 (UTC)<br />
<br />
== Usage with containers -- Static IP network ==<br />
<br />
Not having worked with systemd-networkd before (moving over from the custom systemd script method) this section looks like it has a typo, an omission, or a missing explanation. The list of configuration files uses a .netdev extension on MyBridge, and the example uses a .network extension on MyBridge.<br />
<br />
Again, being new to systemd-networkd, I think there is supposed to be both a MyBridge.netdev file with "[NetDev] Name=br0 Kind=bridge" and a MyBridge.bridge file with "[Match] Name=br0 [Network] DNS= Address= Gateway=". Or, maybe I'm using more files than I needed and just one of the extensions needs to be changed. Or maybe I'm totally off, and a clarification would prevent someone else from making the same mistake. [[User:Jamespharvey20|Jamespharvey20]] ([[User talk:Jamespharvey20|talk]]) 06:44, 20 July 2015 (UTC)<br />
<br />
:My guess is that you need MyBridge.netdev from [[Systemd-networkd#Bridge_interface]], MyEth.network from [[Systemd-networkd#Bind_ethernet_to_bridge]] and MyBridge.network from [[Systemd-networkd#Static_IP_network]] (this is the change against [[Systemd-networkd#Bridge_network]], hence the only file actually shown in that section). If you manage to get it working, please fix the listing of necessary files accordingly. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 07:39, 20 July 2015 (UTC)<br />
<br />
::This is correct. The MyBridge.netdev file is needed to create the virtual device br0 first. This way the device now exists when MyEth.network refers to it with Bridge=br0 and MyBridge.network refers to it with Name=br0. Note: In a DHCP setup, I think it may be important to use file names to specify the order, since in theory a physical adapter needs to be bound to the bridge first before the bridge can request an IP address. Perhaps naming the files 10-MyBridge.netdev, 20-MyEth.network, and 30-MyBridge.network would help clarify the meaning behind these files better? This setup worked well for me. [[User:Xerion567|Xerion567]] ([[User talk:Xerion567|talk]]) 09:31, 30 January 2016 (UTC)<br />
<br />
== I couldn't find /run/systemd/resolve/resolv.conf ==<br />
<br />
I had read this line and I couldn't find the file<br />
# ln -s /run/systemd/resolve/resolv.conf /etc/resolv.conf<br />
But I can see /etc/systemd/resolved.conf. should I just do not link anything?<br />
<br />
Answer: you need to run systemd-resolved, which will create it.<br />
:This symlink should not be needed since systemd-226. In a typical setup, you should simply remove /etc/resolv.conf. Posted here, rather than edit wiki directly, in the event that this is not good for more advanced setups. [[User:DJ L|DJ L]] ([[User talk:DJ L|talk]]) 04:51, 4 February 2016 (UTC)<br />
:: Oops, good thing I didn't edit. This is not covered in systemd documentation. I don't see any issue with this, but I'll reach out to the devs on it. Should probably be addressed in systemd-resolved manpage (even if not supported). [[User:DJ L|DJ L]] ([[User talk:DJ L|talk]]) 05:48, 4 February 2016 (UTC)<br />
<br />
== Note about systemd-resolved.service ==<br />
<br />
In my today's contribution (https://wiki.archlinux.org/index.php?title=Systemd-networkd&oldid=408408) I've added a note about the systemd-resolved service. I never needed that service in a wired/static-ip/single user environment, checking the LFS doc http://www.linuxfromscratch.org/lfs/view/systemd/chapter07/network.html seems to confirm that in that scenario you don't actually need it. Please double check.<br />
<br />
{{unsigned|12:51, 7 November 2015|Matt3o}}<br />
<br />
:I have no idea what you mean by "single user environment", but the official documentation is [http://www.freedesktop.org/software/systemd/man/systemd-resolved.html here]. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 13:14, 7 November 2015 (UTC)<br />
<br />
::The previous comment (by Matt3o) is incorrect. I'm not sure where exactly we differ (I only comment because I was actually the one who rewrote that part of BLFS page linked above), but the systemd-networkd service does not seem to be enabled by default in Arch's systemd package (I'm sure there is a reason, since it is enabled by default in a fresh build of systemd, I'm just not familiar with the decision to exclude it). As to where "single user environment" came from, I've no idea. That concept is pretty much dead, no more runlevel 2 since systemd has arrived, and networking wouldn't have been present in any case. Maybe he was referring to a single PC (very small network) where static networking is acceptable? :-/ [[User:DJ L|DJ L]] ([[User talk:DJ L|talk]]) 05:34, 4 February 2016 (UTC)<br />
<br />
== More static/DHCP examples ==<br />
<br />
The Wiki mentions as a note "The Metric option is for static routes while the RouteMetric option is for setups not using static routes."<br />
While not clear why two different keywords are needed (but let's leave that for upstream to discuss), the Wiki has no example of how "Metric" is used in a static configuration.<br />
<br />
I think the reader is left somewhat in a trial&error loop here (at least I am as I intend to keep my configuration I used in another distro: static for wired, DHCP for wireless). While I'll figure it out eventually, I think at least some clues here would have been helpful as I do not think that config is so exotic. (use static wired in home office, DHCP wireless abroad) Unfortunately, I'm still lacking sufficient systemd experience to make the amendments myself [[User:Archer666|Archer666]] ([[User talk:Archer666|talk]]) 20:48, 2 November 2016 (UTC)<br />
<br />
== Systemd-networkd dhcp configuration ==<br />
<br />
I'm getting confused with dhcp configuration parameters for ipv4. While SYSTEMD.NETWORK(5) suggests setting DHCP=ipv4 under the [Network] section, systemd-networkd refuses to start and logs a unknown parameter error. Setting DHCP=v4 resolves the issue, as the german Arch wiki article suggests: https://wiki.archlinux.de/title/Systemd/systemd-networkd<br />
Does anyone else see this with systemd 232? [[User:anarki|anarki]] ([[User talk:anarki|talk]]) 22:40, 2016-12-06 UTC<br />
<br />
== nsswitch.conf ==<br />
<br />
I removed the recommended nsswitch.conf configuration; it was misleading and out-of-date. The latest filesystem package configures nsswitch.conf correctly to use nss-resolve and fall back in the proper way to nss-dns. The recommended setup breaks glibc DNS resolution in several situations, notably with GPG. [[User:Tad|Tad]] ([[User talk:Tad|talk]]) 20:25, 21 February 2017 (UTC)<br />
<br />
== Why link /run/systemd/resolve/resolv.conf instead of /usr/lib/systemd/resolv.conf ? ==<br />
<br />
{{man|8|systemd-resolved}} says linking from {{ic|/etc/resolv.conf}} to {{ic|/usr/lib/systemd/resolv.conf}} is preferred over linking to {{ic|/run/systemd/resolve/resolv.conf}}.<br />
<br />
{{unsigned| 15:50, 15 November 2017|Mearon}}<br />
<br />
:Could you provide a literal quote of the confusing part? -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 16:58, 15 November 2017 (UTC)<br />
<br />
::Sorry for being unspecific. It's the first codeblock here [[Systemd-networkd#Required_services_and_setup]], immediately after the sentence "For compatibility with resolv.conf, delete or rename the existing file and create the following symbolic link when using systemd-resolved:" [[User:Mearon|Mearon]] ([[User talk:Mearon|talk]]) 18:22, 15 November 2017 (UTC)<br />
<br />
:::So it's not from the {{man|8|systemd-resolved}} man page. Maybe it's a relatively new feature? -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 18:51, 15 November 2017 (UTC)<br />
<br />
::::"•A static file /usr/lib/systemd/resolv.conf is provided that lists the 127.0.0.53 DNS stub (see above) as only DNS server. This file may be symlinked from /etc/resolv.conf in order to connect all local clients that bypass local DNS APIs to systemd-resolved. This mode of operation is recommended."<br />
::::Considering this seems to be in perpetual flux as most systemd things, I'd say we delete that sentence and just refer to the man page. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 19:29, 15 November 2017 (UTC)<br />
<br />
::::{{man|8|systemd-resolved}} lists three alternatives for dealing with /etc/resolv.conf: [http://jlk.fjfi.cvut.cz/arch/manpages/man/systemd-resolved.8#/ETC/RESOLV.CONF]<br />
::::The Arch Wiki currently only mentions option 2 ({{ic|ln -s /run/systemd/resolve/resolv.conf /etc/resolv.conf}}) while {{man|8|systemd-resolved}} recommends option 1 ({{ic|ln -s /usr/lib/systemd/resolv.conf /etc/resolv.conf}}) as quoted by [[User:Alad|Alad]]. [[User:Mearon|Mearon]] ([[User talk:Mearon|talk]]) 20:49, 15 November 2017 (UTC)<br />
<br />
:::::It seems that in systemd 236 the recommended option is changing. As per [https://lists.freedesktop.org/archives/systemd-devel/2017-December/039996.html]: ''"systemd-resolved now maintains a new dynamic /run/systemd/resolve/stub-resolv.conf compatibility file. It is recommended to make /etc/resolv.conf a symlink to it. This file points at the systemd-resolved stub DNS 127.0.0.53 resolver and includes dynamically acquired search domains, achieving more correct DNS resolution by software that bypasses local DNS APIs such as NSS."''<br />
:::::It seems the best of both worlds since this way programs that directly read {{ic|resolv.conf}} don't bypass ''systemd-resolved'''s per-interface DNS server configuration (very problematic in the case of VPN's, for example) but search domains are still accessible for them.<br />
:::::When {{pkg|systemd}} 236 is finally available in ''core'', I think we should update this page to recommend using the new {{ic|stub-resolv.conf}}. --[[User:Icycat|Icycat]] ([[User talk:Icycat|talk]]) 16:30, 16 December 2017 (UTC)<br />
::::::Now that {{pkg|systemd}} 236 is in ''core'', I have updated the page with this new recommendation. --[[User:Icycat|Icycat]] ([[User talk:Icycat|talk]]) 08:50, 22 December 2017 (UTC)<br />
<br />
== Static IP example for Wireless adapter ==<br />
<br />
Simply create /etc/systemd/network/25-wireless.network <br />
with, e.g.<br />
[Match]<br />
Name=wlan0<br />
<br />
[Network]<br />
Address=192.168.0.12/24<br />
Gateway=192.168.0.254<br />
<br />
needs no other file to work<br />
<br />
{{Unsigned|06:19, 18 July 2019 (UTC)|Waitnsea}}<br />
<br />
== systemd-networkd + Dm-crypt/Swap = system not booting ==<br />
<br />
:See also [[Talk:Dm-crypt/Swap encryption#Dm-crypt/Swap + systemd-networkd = system not booting]]<br />
<br />
I encountered issue on fresh install on small VPS (1Gb RAM, 1vCPU) that if I have systemd-networkd and crypt-swap then boot process hangs while waiting for crypt-swap device. Posted workaround here: https://bbs.archlinux.org/viewtopic.php?pid=1882917#p1882917<br />
<br />
[[User:Gregosky|Gregosky]] ([[User talk:Gregosky|talk]]) 06:31, 16 January 2020 (UTC)<br />
<br />
== Setting up and connecting to wireless networks using systemd-networkd via wpa_supplicant ==<br />
<br />
systemd-networkd is great for configuring wired networks, but it lacks the ability to authenticate or associate (connect) with/to a wireless network. This leaves the user wondering and looking for alternatives. There is a clever trick, and that is to use something like [[Wpa_supplicant|wpa_supplicant]]. There are advantages to use systemd-networkd with wpa_supplicant, and here are the highlights:<br />
* wpa_supplicant does not interfere with systemd-networkd, as systemd-networkd handles IP and routing, whereas wpa_supplicant handles with authentication and association/connection. Technically, the two operates on different layers on the [[wikipedia:OSI_model|OSI model]].<br />
* wpa_supplicant, like systemd-networkd, does not have a graphical interface/front-end. This can be especially useful when one does not need to worry about the memory/bandwidth overhead for needing to interface it graphically and/or remotely.<br />
* wpa_supplicant can store Pre-Shared Key (PSK) in encrypted format. Some network managers stores these in plain text, thus could lead to other security implications in the event of machine compromise, and that it contains keys/passwords stored in plain text.<br />
Naturally, the use of such a setup does also have certain caveats, and with complicating the issues being one of them.<br />
<br />
These leads me to my suggestion. Considering that there has been discussions on how to make the two daemons work together on [https://bbs.archlinux.org/viewtopic.php?id=178625 Arch Linux Forums], and that it is a link under the See Also section of this (Systemd-networkd wiki) page. Is it possible instead, to expand this as a sub-page (to this page of course) or at least as a sub-section? Unfortunately, <br />
* Some of the links detailed on the forums are dead (but Wayback machine still has records of these), <br />
* The forum thread does not offer much explanation/insights, and, <br />
* There's no reference from [[Wpa_supplicant|wpa_supplicant]] page to either that forum thread, or this (Systemd-networkd) page. <br />
With that said, I could help contribute if there's an/enough interest. Addressing this could also see the following be added once it is complete; [[Talk:Systemd-networkd#Static_IP_example_for_Wireless_adapter]]<br />
<br />
[[User:Tuxsavvy|Tuxsavvy]] ([[User talk:Tuxsavvy|talk]]) 09:17, 22 December 2020 (UTC)<br />
<br />
:What is there to describe on the "subpage"? As you said, systemd-networkd and wpa_supplicant operate on different layers, so you configure both as usual, there is nothing special needed to make them work together. There are already multiple references to both [[wpa_supplicant]] and [[iwd]] so it is obvious that the other thing is needed too. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 09:43, 22 December 2020 (UTC)<br />
<br />
::Indeed, there is nothing special about the process. However, the information currently provided as-is, are rudimentary at best, almost like as if considerations to such options are of an afterthought. My point was to:<br />
* Adding page/section visibility (as a related article, as opposed to a link in the see also section),<br />
* Flesh out the information by adding (reference) links, even if they might be dead or archived, and,<br />
* Allow the viability of expansion for the said article. <br />
Potential expansions include (but are not limited to) incorporating that other topic on static IP with wireless, as it is relevant. -- [[User:Tuxsavvy|Tuxsavvy]] ([[User talk:Tuxsavvy|talk]]) 03:43, 24 December 2020 (UTC)</div>Tuxsavvyhttps://wiki.archlinux.org/index.php?title=Talk:Systemd-networkd&diff=646325Talk:Systemd-networkd2020-12-22T09:17:42Z<p>Tuxsavvy: /* Setting up and connecting to wireless networks using systemd-networkd via wpa_supplicant */ new section</p>
<hr />
<div>== Static IP example for single host ==<br />
<br />
(moved from [[Talk:Network_configuration#Systemd-networkd]])<br />
<br />
Now that networkd is maturing and much simpler to configure for VMs, containers, etc should we include a section with an example?<br />
{{unsigned|21:42, 1 January 2015|Chetwisniewski}}<br />
<br />
:There is a whole page on [[systemd-networkd]] already, and it is linked from [[Network_configuration#Configure_the_IP_address]]. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 21:52, 1 January 2015 (UTC)<br />
<br />
:It doesn't include any decent static examples. Perhaps I should post these points to that page? Something with example config, like:<br />
<br />
{{hc|/etc/systemd/network/enp3s0.network|<nowiki><br />
[Match]<br />
Name=enp3s0<br />
[Network]<br />
DNS=fe80:a3c1::1<br />
DNS=192.168.0.1<br />
Address=192.168.0.10/24<br />
Address=2001:DB8::1/64<br />
Gateway=192.168.0.1<br />
</nowiki>}}<br />
<br />
[[User:Chetwisniewski|Chetwisniewski]] ([[User talk:Chetwisniewski|talk]]) 21:59, 1 January 2015 (UTC)<br />
<br />
::Re-opening. That would make sense imo. But we need to take care not to break the existing [[Systemd-networkd#Static IP network]] instructions. Maybe it is just necessary to clarify which steps are required to set up static for a single host before leading over to the bridge/container setup (analoguous to the first example in [[Systemd-networkd#Basic DHCP network]]). Ok?--[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 23:57, 1 January 2015 (UTC)<br />
::Comparing your example config again to what we have, the only major difference is the IPv6 which is not covered in this article yet. Still the basic instructions for a single host could be made clearer in this article. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 18:11, 9 February 2015 (UTC)<br />
<br />
== standalone vs containers ==<br />
<br />
Yes, I agree with the discussion and the style warning on the main page: we should break this out into two parts to make it clear which are for standalone systems and which are for containers which are likely foreign to some users.<br />
[[User:Graysky|Graysky]] ([[User talk:Graysky|talk]]) 12:06, 27 March 2015 (UTC)<br />
<br />
: There, I made a pretty major edit to the main article in an attempt to break out "basic" from "complex" usage cases. I don't have inclination or knowledge to comb through the original article targeted mainly at container usage. [[User:Graysky|Graysky]] ([[User talk:Graysky|talk]]) 19:49, 27 March 2015 (UTC)<br />
<br />
::Thanks. How about moving the whole container section to a subpage. Relevant parts can be merged back to the main article; as of now, the container section is not very usable anyway. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 19:53, 27 March 2015 (UTC)<br />
<br />
::: Feel free to do it. I'm out of time for now. [[User:Graysky|Graysky]] ([[User talk:Graysky|talk]]) 20:03, 27 March 2015 (UTC)<br />
<br />
:::: Neat edit that was! Good to have the basic examples on top. As for moving the container section to a subpage, sure why not. Yet, I would vote for keeping [[Systemd-networkd#Configuration files]] on the main page (to see how it works I moved it like it is now). It would be a strange article ending with a section like that though.? The container section uses some configuration files content as practical examples on the other hand. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 20:39, 27 March 2015 (UTC)<br />
<br />
== Usage with containers -- Static IP network ==<br />
<br />
Not having worked with systemd-networkd before (moving over from the custom systemd script method) this section looks like it has a typo, an omission, or a missing explanation. The list of configuration files uses a .netdev extension on MyBridge, and the example uses a .network extension on MyBridge.<br />
<br />
Again, being new to systemd-networkd, I think there is supposed to be both a MyBridge.netdev file with "[NetDev] Name=br0 Kind=bridge" and a MyBridge.bridge file with "[Match] Name=br0 [Network] DNS= Address= Gateway=". Or, maybe I'm using more files than I needed and just one of the extensions needs to be changed. Or maybe I'm totally off, and a clarification would prevent someone else from making the same mistake. [[User:Jamespharvey20|Jamespharvey20]] ([[User talk:Jamespharvey20|talk]]) 06:44, 20 July 2015 (UTC)<br />
<br />
:My guess is that you need MyBridge.netdev from [[Systemd-networkd#Bridge_interface]], MyEth.network from [[Systemd-networkd#Bind_ethernet_to_bridge]] and MyBridge.network from [[Systemd-networkd#Static_IP_network]] (this is the change against [[Systemd-networkd#Bridge_network]], hence the only file actually shown in that section). If you manage to get it working, please fix the listing of necessary files accordingly. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 07:39, 20 July 2015 (UTC)<br />
<br />
::This is correct. The MyBridge.netdev file is needed to create the virtual device br0 first. This way the device now exists when MyEth.network refers to it with Bridge=br0 and MyBridge.network refers to it with Name=br0. Note: In a DHCP setup, I think it may be important to use file names to specify the order, since in theory a physical adapter needs to be bound to the bridge first before the bridge can request an IP address. Perhaps naming the files 10-MyBridge.netdev, 20-MyEth.network, and 30-MyBridge.network would help clarify the meaning behind these files better? This setup worked well for me. [[User:Xerion567|Xerion567]] ([[User talk:Xerion567|talk]]) 09:31, 30 January 2016 (UTC)<br />
<br />
== I couldn't find /run/systemd/resolve/resolv.conf ==<br />
<br />
I had read this line and I couldn't find the file<br />
# ln -s /run/systemd/resolve/resolv.conf /etc/resolv.conf<br />
But I can see /etc/systemd/resolved.conf. should I just do not link anything?<br />
<br />
Answer: you need to run systemd-resolved, which will create it.<br />
:This symlink should not be needed since systemd-226. In a typical setup, you should simply remove /etc/resolv.conf. Posted here, rather than edit wiki directly, in the event that this is not good for more advanced setups. [[User:DJ L|DJ L]] ([[User talk:DJ L|talk]]) 04:51, 4 February 2016 (UTC)<br />
:: Oops, good thing I didn't edit. This is not covered in systemd documentation. I don't see any issue with this, but I'll reach out to the devs on it. Should probably be addressed in systemd-resolved manpage (even if not supported). [[User:DJ L|DJ L]] ([[User talk:DJ L|talk]]) 05:48, 4 February 2016 (UTC)<br />
<br />
== Note about systemd-resolved.service ==<br />
<br />
In my today's contribution (https://wiki.archlinux.org/index.php?title=Systemd-networkd&oldid=408408) I've added a note about the systemd-resolved service. I never needed that service in a wired/static-ip/single user environment, checking the LFS doc http://www.linuxfromscratch.org/lfs/view/systemd/chapter07/network.html seems to confirm that in that scenario you don't actually need it. Please double check.<br />
<br />
{{unsigned|12:51, 7 November 2015|Matt3o}}<br />
<br />
:I have no idea what you mean by "single user environment", but the official documentation is [http://www.freedesktop.org/software/systemd/man/systemd-resolved.html here]. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 13:14, 7 November 2015 (UTC)<br />
<br />
::The previous comment (by Matt3o) is incorrect. I'm not sure where exactly we differ (I only comment because I was actually the one who rewrote that part of BLFS page linked above), but the systemd-networkd service does not seem to be enabled by default in Arch's systemd package (I'm sure there is a reason, since it is enabled by default in a fresh build of systemd, I'm just not familiar with the decision to exclude it). As to where "single user environment" came from, I've no idea. That concept is pretty much dead, no more runlevel 2 since systemd has arrived, and networking wouldn't have been present in any case. Maybe he was referring to a single PC (very small network) where static networking is acceptable? :-/ [[User:DJ L|DJ L]] ([[User talk:DJ L|talk]]) 05:34, 4 February 2016 (UTC)<br />
<br />
== More static/DHCP examples ==<br />
<br />
The Wiki mentions as a note "The Metric option is for static routes while the RouteMetric option is for setups not using static routes."<br />
While not clear why two different keywords are needed (but let's leave that for upstream to discuss), the Wiki has no example of how "Metric" is used in a static configuration.<br />
<br />
I think the reader is left somewhat in a trial&error loop here (at least I am as I intend to keep my configuration I used in another distro: static for wired, DHCP for wireless). While I'll figure it out eventually, I think at least some clues here would have been helpful as I do not think that config is so exotic. (use static wired in home office, DHCP wireless abroad) Unfortunately, I'm still lacking sufficient systemd experience to make the amendments myself [[User:Archer666|Archer666]] ([[User talk:Archer666|talk]]) 20:48, 2 November 2016 (UTC)<br />
<br />
== Systemd-networkd dhcp configuration ==<br />
<br />
I'm getting confused with dhcp configuration parameters for ipv4. While SYSTEMD.NETWORK(5) suggests setting DHCP=ipv4 under the [Network] section, systemd-networkd refuses to start and logs a unknown parameter error. Setting DHCP=v4 resolves the issue, as the german Arch wiki article suggests: https://wiki.archlinux.de/title/Systemd/systemd-networkd<br />
Does anyone else see this with systemd 232? [[User:anarki|anarki]] ([[User talk:anarki|talk]]) 22:40, 2016-12-06 UTC<br />
<br />
== nsswitch.conf ==<br />
<br />
I removed the recommended nsswitch.conf configuration; it was misleading and out-of-date. The latest filesystem package configures nsswitch.conf correctly to use nss-resolve and fall back in the proper way to nss-dns. The recommended setup breaks glibc DNS resolution in several situations, notably with GPG. [[User:Tad|Tad]] ([[User talk:Tad|talk]]) 20:25, 21 February 2017 (UTC)<br />
<br />
== Why link /run/systemd/resolve/resolv.conf instead of /usr/lib/systemd/resolv.conf ? ==<br />
<br />
{{man|8|systemd-resolved}} says linking from {{ic|/etc/resolv.conf}} to {{ic|/usr/lib/systemd/resolv.conf}} is preferred over linking to {{ic|/run/systemd/resolve/resolv.conf}}.<br />
<br />
{{unsigned| 15:50, 15 November 2017|Mearon}}<br />
<br />
:Could you provide a literal quote of the confusing part? -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 16:58, 15 November 2017 (UTC)<br />
<br />
::Sorry for being unspecific. It's the first codeblock here [[Systemd-networkd#Required_services_and_setup]], immediately after the sentence "For compatibility with resolv.conf, delete or rename the existing file and create the following symbolic link when using systemd-resolved:" [[User:Mearon|Mearon]] ([[User talk:Mearon|talk]]) 18:22, 15 November 2017 (UTC)<br />
<br />
:::So it's not from the {{man|8|systemd-resolved}} man page. Maybe it's a relatively new feature? -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 18:51, 15 November 2017 (UTC)<br />
<br />
::::"•A static file /usr/lib/systemd/resolv.conf is provided that lists the 127.0.0.53 DNS stub (see above) as only DNS server. This file may be symlinked from /etc/resolv.conf in order to connect all local clients that bypass local DNS APIs to systemd-resolved. This mode of operation is recommended."<br />
::::Considering this seems to be in perpetual flux as most systemd things, I'd say we delete that sentence and just refer to the man page. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 19:29, 15 November 2017 (UTC)<br />
<br />
::::{{man|8|systemd-resolved}} lists three alternatives for dealing with /etc/resolv.conf: [http://jlk.fjfi.cvut.cz/arch/manpages/man/systemd-resolved.8#/ETC/RESOLV.CONF]<br />
::::The Arch Wiki currently only mentions option 2 ({{ic|ln -s /run/systemd/resolve/resolv.conf /etc/resolv.conf}}) while {{man|8|systemd-resolved}} recommends option 1 ({{ic|ln -s /usr/lib/systemd/resolv.conf /etc/resolv.conf}}) as quoted by [[User:Alad|Alad]]. [[User:Mearon|Mearon]] ([[User talk:Mearon|talk]]) 20:49, 15 November 2017 (UTC)<br />
<br />
:::::It seems that in systemd 236 the recommended option is changing. As per [https://lists.freedesktop.org/archives/systemd-devel/2017-December/039996.html]: ''"systemd-resolved now maintains a new dynamic /run/systemd/resolve/stub-resolv.conf compatibility file. It is recommended to make /etc/resolv.conf a symlink to it. This file points at the systemd-resolved stub DNS 127.0.0.53 resolver and includes dynamically acquired search domains, achieving more correct DNS resolution by software that bypasses local DNS APIs such as NSS."''<br />
:::::It seems the best of both worlds since this way programs that directly read {{ic|resolv.conf}} don't bypass ''systemd-resolved'''s per-interface DNS server configuration (very problematic in the case of VPN's, for example) but search domains are still accessible for them.<br />
:::::When {{pkg|systemd}} 236 is finally available in ''core'', I think we should update this page to recommend using the new {{ic|stub-resolv.conf}}. --[[User:Icycat|Icycat]] ([[User talk:Icycat|talk]]) 16:30, 16 December 2017 (UTC)<br />
::::::Now that {{pkg|systemd}} 236 is in ''core'', I have updated the page with this new recommendation. --[[User:Icycat|Icycat]] ([[User talk:Icycat|talk]]) 08:50, 22 December 2017 (UTC)<br />
<br />
== Static IP example for Wireless adapter ==<br />
<br />
Simply create /etc/systemd/network/25-wireless.network <br />
with, e.g.<br />
[Match]<br />
Name=wlan0<br />
<br />
[Network]<br />
Address=192.168.0.12/24<br />
Gateway=192.168.0.254<br />
<br />
needs no other file to work<br />
<br />
{{Unsigned|06:19, 18 July 2019 (UTC)|Waitnsea}}<br />
<br />
== systemd-networkd + Dm-crypt/Swap = system not booting ==<br />
<br />
:See also [[Talk:Dm-crypt/Swap encryption#Dm-crypt/Swap + systemd-networkd = system not booting]]<br />
<br />
I encountered issue on fresh install on small VPS (1Gb RAM, 1vCPU) that if I have systemd-networkd and crypt-swap then boot process hangs while waiting for crypt-swap device. Posted workaround here: https://bbs.archlinux.org/viewtopic.php?pid=1882917#p1882917<br />
<br />
[[User:Gregosky|Gregosky]] ([[User talk:Gregosky|talk]]) 06:31, 16 January 2020 (UTC)<br />
<br />
== <s>netctl vs systemd-networkd</s> ==<br />
<br />
With the rise of systemd I thought that netctl got obsolete. Do you think including the following info is worthwhile?<br />
<br />
https://wiki.archlinux.org/index.php/Network_configuration#Network_managers<br />
https://bbs.archlinux.org/viewtopic.php?id=251815<br />
<br />
{{unsigned|02:50, 21 July 2020|Leuko}}<br />
<br />
:It's not "obsolete" until its developers say so. As said in the forum thread, Arch does not have a preferred method of networking. As systemd-networkd and netctl are completely unrelated, there is no reason to mention netctl at all. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 17:35, 21 July 2020 (UTC)<br />
<br />
:Thank you Lahwaacz for the feedback. (Actually I wanted to post this in Talk:netctl. Mentioning netctl here does not make sense at all.) [[User:Leuko|Leuko]] ([[User talk:Leuko|talk]]) 19:26, 21 July 2020 (UTC)<br />
<br />
== Setting up and connecting to wireless networks using systemd-networkd via wpa_supplicant ==<br />
<br />
systemd-networkd is great for configuring wired networks, but it lacks the ability to authenticate or associate (connect) with/to a wireless network. This leaves the user wondering and looking for alternatives. There is a clever trick, and that is to use something like [[Wpa_supplicant|wpa_supplicant]]. There are advantages to use systemd-networkd with wpa_supplicant, and here are the highlights:<br />
* wpa_supplicant does not interfere with systemd-networkd, as systemd-networkd handles IP and routing, whereas wpa_supplicant handles with authentication and association/connection. Technically, the two operates on different layers on the [[wikipedia:OSI_model|OSI model]].<br />
* wpa_supplicant, like systemd-networkd, does not have a graphical interface/front-end. This can be especially useful when one does not need to worry about the memory/bandwidth overhead for needing to interface it graphically and/or remotely.<br />
* wpa_supplicant can store Pre-Shared Key (PSK) in encrypted format. Some network managers stores these in plain text, thus could lead to other security implications in the event of machine compromise, and that it contains keys/passwords stored in plain text.<br />
Naturally, the use of such a setup does also have certain caveats, and with complicating the issues being one of them.<br />
<br />
These leads me to my suggestion. Considering that there has been discussions on how to make the two daemons work together on [https://bbs.archlinux.org/viewtopic.php?id=178625 Arch Linux Forums], and that it is a link under the See Also section of this (Systemd-networkd wiki) page. Is it possible instead, to expand this as a sub-page (to this page of course) or at least as a sub-section? Unfortunately, <br />
* Some of the links detailed on the forums are dead (but Wayback machine still has records of these), <br />
* The forum thread does not offer much explanation/insights, and, <br />
* There's no reference from [[Wpa_supplicant|wpa_supplicant]] page to either that forum thread, or this (Systemd-networkd) page. <br />
With that said, I could help contribute if there's an/enough interest. Addressing this could also see the following be added once it is complete; [[Talk:Systemd-networkd#Static_IP_example_for_Wireless_adapter]]<br />
<br />
[[User:Tuxsavvy|Tuxsavvy]] ([[User talk:Tuxsavvy|talk]]) 09:17, 22 December 2020 (UTC)</div>Tuxsavvyhttps://wiki.archlinux.org/index.php?title=GNU_Compiler_Collection&diff=642243GNU Compiler Collection2020-11-24T14:20:33Z<p>Tuxsavvy: /* Old versions */ GCC v8 and v9 has been dropped from community repository, and are now in AUR.</p>
<hr />
<div>[[Category:Development]]<br />
[[Category:GNU]]<br />
[[es:GNU Compiler Collection]]<br />
[[ja:GNU Compiler Collection]]<br />
[[pt:GNU Compiler Collection]]<br />
[[zh-hans:GNU Compiler Collection]]<br />
{{Related articles start}}<br />
{{Related|LLVM}}<br />
{{Related articles end}}<br />
<br />
The [[Wikipedia:GNU Compiler Collection|GNU Compiler Collection]] ('''GCC''') is part of the [[GNU toolchain]] and includes front ends for [[C]] and [[C++]].<br />
<br />
== Installation ==<br />
<br />
[[Install]] the {{Pkg|gcc}} package.<br />
<br />
Other available front-ends are:<br />
<br />
* {{Pkg|gcc-ada}} for [[Ada]]<br />
* {{Pkg|gcc-d}} for [[D]]<br />
* {{Pkg|gcc-fortran}} for [[Wikipedia:Fortran|Fortran]]<br />
* {{Pkg|gcc-go}} for [[Go]]<br />
* {{Pkg|gcc-objc}} for [[Wikipedia:Objective-C|Objective-C]]<br />
<br />
=== Old versions ===<br />
<br />
Old versions of GCC are available via the [[official repositories]] and the [[AUR]] and may be useful for historical curiosity, old projects that cannot be compiled on the current versions, or for testing the compatibility of projects:<br />
<br />
* GCC 4.3: {{AUR|gcc43}}<br />
* GCC 4.4: {{AUR|gcc44}}<br />
* GCC 4.5: {{AUR|gcc45}}<br />
* GCC 4.6: {{AUR|gcc46}}<br />
* GCC 4.7: {{AUR|gcc47}}<br />
* GCC 4.8: {{AUR|gcc48}}<br />
* GCC 4.9: {{AUR|gcc49}}<br />
* GCC 5: {{AUR|gcc5}}<br />
* GCC 6: {{AUR|gcc6}}<br />
* GCC 7: {{AUR|gcc7}}<br />
* GCC 8: {{AUR|gcc8}}<br />
* GCC 9: {{AUR|gcc9}}<br />
<br />
Other front-ends for old versions of GCC may be found on the official repositories and the AUR by searching for {{ic|gcc<''version without period''>}}, e.g. searching for {{ic|gcc9}} for GCC 9 front-ends.<br />
<br />
== See also ==<br />
<br />
* [https://gcc.gnu.org/onlinedocs/gcc/ Info manual]<br />
* [https://gcc.gnu.org/ Official website]<br />
* {{man|1|gcc}}</div>Tuxsavvyhttps://wiki.archlinux.org/index.php?title=TOMOYO_Linux&diff=621731TOMOYO Linux2020-06-24T10:05:12Z<p>Tuxsavvy: "It was launched in March 2003 and had been sponsored by NTT DATA Corporation, Japan until March 2012." -- http://tomoyo.osdn.jp/</p>
<hr />
<div>[[Category:Access control]]<br />
[[Category:Kernel]]<br />
[[ja:TOMOYO Linux]]<br />
[http://tomoyo.sourceforge.jp/ TOMOYO Linux] is a [[Mandatory Access Control]] (MAC) implementation for Linux. It was launched in March 2003 and was sponsored by [http://www.nttdata.co.jp/en/ NTT Data Corporation]. TOMOYO Linux focuses on the behaviour of a system, allowing each process to declare behaviours and resources needed to achieve its purpose. It can be used as a system analysis tool as well as an access restriction tool.<br />
<br />
The security goal of TOMOYO Linux is to provide "MAC that covers practical requirements for most users and keeps usable for most administrators". TOMOYO Linux is not a tool for just security professionals, but also for average users and administrators.<br />
{{Note|This article does not aim to be an exhaustive guide and should be used as a supplement to the extensive [http://tomoyo.sourceforge.jp/documentation.html user documentation] provided by the project.}}<br />
{{Tip|The [[#TOMOYO Linux 2.x|TOMOYO Linux 2.x]] will eventually come closer to reaching feature parity with the 1.x branch, but for those wanting an easy start the 2.x branch is easy to install. The [[#TOMOYO Linux 1.x|TOMOYO Linux 1.x]] branch is for those wanting the greatest security, while [[#AKARI|AKARI]] is somewhere in between.}}<br />
<br />
==Introduction==<br />
TOMOYO Linux attempts to make the system where everything is prearranged in an easy to understand way:<br />
* Make all access requests that will occur at least once during the lifetime of the kernel known in advance<br />
* Allow the administrator to write a policy that only allows expected and desirable access requests<br />
Unlike AppArmor, TOMOYO Linux is intended to protect the whole system from attackers exploiting vulnerabilities in applications. TOMOYO Linux addresses this threat by recording the behaviour of all applications in the test environment and then forcing all applications to act within these recorded behaviours in the production environment.<br />
<br />
TOMOYO Linux is not for users wanting ready-made policy files supplied by others. It involves creating policy from scratch, aided by the "learning mode" which can automatically generate policy files with necessary and sufficient permissions for a specific system. TOMOYO Linux reports what is happening within the Linux system and can therefore be used as a system analysis tool. It resembles strace and reports what is being executed by each program and what files/networks are accessed.<br />
<br />
This [http://tomoyo.sourceforge.jp/wiki-e/?WhatIs#comparison table] provides a comprehensive comparison of TOMOYO Linux with [[AppArmor]], [[SELinux]] and [http://schaufler-ca.com/ SMACK].<br />
<br />
==Branches of development==<br />
[http://tomoyo.sourceforge.jp/1.8/index.html.en TOMOYO Linux 1.x] is the original branch of development. TOMOYO Linux was first released on 11th November 2005. It was implemented as a patch that can be applied to the Linux kernel and is still in active development. It can coexist with other security modules such as SELinux, SMACK and AppArmor.<br />
<br />
[http://tomoyo.sourceforge.jp/2.3/index.html.en TOMOYO Linux 2.x] is the Linux mainline kernel branch of development. In June 2009, TOMOYO was merged into the Linux kernel version 2.6.30 and it uses standard Linux Security Module (LSM) hooks. However, the LSM hooks must be extended further in order to port the full MAC functionality of TOMOYO Linux into the Linux kernel. Thus, it does not yet provide equal functionality with the 1.x branch of development. This [http://tomoyo.sourceforge.jp/comparison.html.en chart] compares the differences between each branch.<br />
<br />
[http://akari.sourceforge.jp/ AKARI] is based on the TOMOYO Linux 1.x branch and is implemented as a Loadable Kernel Module (LKM). It therefore has the advantage of not requiring the user to patch and recompile the kernel. This [http://akari.sourceforge.jp/comparison.html table] provides a comprehensive comparison of AKARI with the TOMOYO Linux 1.x and 2.x branches.<br />
<br />
==TOMOYO Linux 1.x==<br />
Implementing TOMOYO Linux 1.x using a kernel patched with ccs-patch provides the full functionality obtainable from the TOMOYO Linux project. However, implementation of this branch requires the most hurdles to be overcome, as the kernel must be patched with [http://sourceforge.jp/projects/tomoyo/ ccs-patch] and subsequently recompiled.<br />
<br />
Both a patched kernel and the userspace tools must be installed. A package for {{AUR|ccs-tools}} is available on the AUR.<br />
<br />
===Initializing configuration===<br />
The policy must first be initialized:<br />
# /usr/lib/ccs/init_policy<br />
The policy files are saved in the {{ic|/etc/css/}} directory and can be edited by running:<br />
# ccs-editpolicy<br />
<br />
==AKARI==<br />
===Limitations of AKARI===<br />
If using the TOMOYO Linux project purely for system analysis, then AKARI is the easiest method of achieving this. If using the TOMOYO Linux project for system restriction, it is a minimal effort way to gain most of the functionality of the TOMOYO Linux 1.x branch. However, there are a few limitations that must be considered:<br />
* It depends on the kernel version and configuration provided by the distribution:<br />
<pre><br />
CONFIG_SECURITY=y [required]<br />
CONFIG_KALLSYMS=y [required]<br />
CONFIG_PROC_FS=y [required]<br />
CONFIG_MODULES=y [required]<br />
CONFIG_SECURITY_PATH=y [optional: for using absolute pathnames]<br />
CONFIG_SECURITY_NETWORK=y [optional: for providing network restriction]<br />
</pre><br />
* The restriction of a few advanced networking operations are limited or unavailable due to the absence of required LSM hooks<br />
* Restricting use of [[wikipedia:Capability-based_security|capabilities]] is not possible<br />
* Looking up per-task variables is slower as they are managed outside "struct task_struct" in order to keep KABI unchanged. However, this should not be noticeable for the typical end-user as performance decrease by pathname based permission checking is dominant<br />
This [http://akari.sourceforge.jp/comparison.html table] provides a comprehensive comparison of AKARI with the TOMOYO Linux 1.x and 2.x branches.<br />
<br />
===Installation===<br />
Both AKARI and the userspace tools must be installed. A package for {{AUR|akari}} and a package for {{AUR|ccs-tools}} are available on the AUR.<br />
<br />
The bootloader configuration must be changed in order to activate AKARI:<br />
title Arch Linux<br />
root (hd0,0)<br />
kernel /boot/vmlinuz-linux root=/dev/sda1 ro init=/sbin/ccs-init<br />
initrd /boot/initramfs-linux.img<br />
<br />
===Initializing configuration===<br />
The policy must first be initialized:<br />
# /usr/lib/ccs/init_policy --module_name=akari<br />
The policy files are saved in the {{ic|/etc/css/}} directory and can be edited by running:<br />
# ccs-editpolicy<br />
<br />
==TOMOYO Linux 2.x==<br />
===Limitations of TOMOYO Linux 2.x===<br />
The implementation of TOMOYO Linux 2.x into the Linux mainline kernel is not yet complete but is very close to 1.x since 2.5.x. There are a few features that still need to be implemented as compared to the 1.x branch. This [http://tomoyo.sourceforge.jp/comparison.html.en chart] has a comprehensive comparison of the differences between each branch of development.<br />
<br />
===Installation===<br />
<br />
{{note| TOMOYO support in the official {{pkg|linux}} package has been reintroduced as of version 5.0.7-arch1.}}<br />
<br />
For custom kernels make sure that the following kernel options are set:<br />
<pre><br />
CONFIG_SECURITY=y<br />
CONFIG_SECURITYFS=y<br />
CONFIG_SECURITY_NETWORK=y<br />
CONFIG_SECURITY_PATH=y<br />
CONFIG_SECURITY_TOMOYO=y<br />
</pre><br />
<br />
; For kernels 5.1 and above: TOMOYO requires the 2.6 branch of the userspace tools to be installed (from AUR {{AUR|tomoyo-tools}}).<br />
<br />
; For kernels 3.4 to 5.0: TOMOYO requires the 2.5 branch of the userspace tools to be installed (from AUR {{AUR|tomoyo-tools-25}}).<br />
<br />
{{note| The 2.5.x and 2.6.x branches of tomoyo-tools are not compatible. Using the wrong version may render your system unbootable.}}<br />
<br />
===Activation===<br />
<br />
TOMOYO Linux supports "TOMOYO_trigger" kernel boot option.<br />
<br />
Edit GRUB_CMDLINE_LINUX_DEFAULT in {{ic|/etc/default/grub}}:<br />
* For kernels 5.1 and above, append '''TOMOYO_trigger=/usr/lib/systemd/systemd''':<br />
<pre><br />
GRUB_CMDLINE_LINUX_DEFAULT="quiet TOMOYO_trigger=/usr/lib/systemd/systemd"<br />
</pre><br />
<br />
* For kernels 3.2 to 5.0, append '''security=tomoyo TOMOYO_trigger=/usr/lib/systemd/systemd''':<br />
<pre><br />
GRUB_CMDLINE_LINUX_DEFAULT="quiet security=tomoyo TOMOYO_trigger=/usr/lib/systemd/systemd"<br />
</pre><br />
<br />
After, recompile {{ic|grub.cfg}}:<br />
# grub-mkconfig -o /boot/grub/grub.cfg<br />
so, TOMOYO will load all saved policies from {{ic|/etc/tomoyo/policy/current}} when {{ic|/usr/lib/systemd/systemd}} executes.<br />
<br />
Next, check whether the activation was successful.<br />
<br />
* For kernels 5.1 and above, check the content of {{ic|/sys/kernel/security/lsm}}.<br />
If the output contains ''tomoyo'', the kernel was booted with TOMOYO Linux enabled.<br />
<br />
$ cat /sys/kernel/security/lsm<br />
capability,yama,loadpin,safesetid,selinux,tomoyo<br />
<br />
If the output does not contain ''tomoyo'', the kernel was booted with TOMOYO Linux disabled.<br />
If this is the case, reboot the kernel with ''lsm'' kernel boot option (with ''tomoyo'' appended to the content of {{ic|/sys/kernel/security/lsm}}).<br />
<pre><br />
GRUB_CMDLINE_LINUX_DEFAULT="quiet lsm=capability,yama,loadpin,safesetid,selinux,tomoyo TOMOYO_trigger=/usr/lib/systemd/systemd"<br />
</pre><br />
<br />
* For kernels 3.2 to 5.0, you should have the following lines (or similar) in your dmesg output: <br />
$ dmesg |grep -A 1 -B 1 TOMOYO<br />
[ 0.003375] Security Framework initialized<br />
[ 0.003387] TOMOYO Linux initialized<br />
[ 0.003396] AppArmor: AppArmor disabled by boot time parameter<br />
--<br />
[ 6.829798] Calling /usr/bin/tomoyo-init to load policy. Please wait.<br />
[ 6.833709] TOMOYO: 2.5.0<br />
[ 6.833712] Mandatory Access Control activated.<br />
<br />
<br />
For first time, you may want to auto-save in-memory policies to filesystem when computer goes to shutdown/reboot. If yes, write {{ic|/usr/lib/systemd/system/tomoyo-savepolicy.service}} script:<br />
<br />
{{hc|/usr/lib/systemd/system/tomoyo-savepolicy.service|<nowiki><br />
[Unit] <br />
Description=Tomoyo savepolicy<br />
<br />
[Service]<br />
Type=oneshot<br />
ExecStart=/bin/true<br />
ExecStop=/usr/bin/tomoyo-savepolicy<br />
StandardInput=tty<br />
RemainAfterExit=yes<br />
<br />
[Install]<br />
WantedBy=multi-user.target</nowiki>}}<br />
<br />
You can enable/disable it with systemctl:<br />
# systemctl enable tomoyo-savepolicy.service<br />
<br />
===Disabling===<br />
<br />
* For kernels 5.1 and above use the ''lsm'' kernel boot option (with ''tomoyo'' removed from the content of {{ic|/sys/kernel/security/lsm}}):<br />
<pre><br />
GRUB_CMDLINE_LINUX_DEFAULT="quiet lsm=capability,yama,loadpin,safesetid,selinux"<br />
</pre><br />
* For kernels 3.2 to 5.0 change '''security=tomoyo''' to '''security=none''':<br />
<pre><br />
GRUB_CMDLINE_LINUX_DEFAULT="quiet security=none"<br />
</pre><br />
<br />
===Initializing configuration===<br />
The policy must first be initialized:<br />
# /usr/lib/tomoyo/init_policy<br />
The policy files are saved in the {{ic|/etc/tomoyo/}} directory and can be edited by running:<br />
# tomoyo-editpolicy<br />
<br />
By default, tomoyo will start with "Disabled" profile (see profile-table below). You may want to enable learning mode for everybody right now. Just switch profile for {{ic|<kernel>}} namespace in {{ic|/etc/tomoyo/policy/current/domain_policy.conf}}:<br />
<pre><kernel><br />
use_profile 1<br />
use_group 0</pre><br />
If unsure if such wide learning is needed, just ignore this step. You can switch profiles later using '''tomoyo-editpolicy''' in "Domain transition editor" by pressing '''S''' on any selected domain (domains).<br />
<br />
Now, the computer should be restarted.<br />
<br />
===Log daemon===<br />
For tomoyo exists the log-daemon {{ic|/usr/sbin/tomoyo-auditd}}. It is useful for monitoring the behavior of closed-source applications. The initial configuration file is well explained and can be found in {{ic|/etc/tomoyo/tools/auditd.conf}} whereas the log files can be found in {{ic|/var/log/tomoyo}}.<br />
<br />
To use it with systemd create the file {{ic|/lib/systemd/system/tomoyo-auditd.service}} with the content described in chapter 4.6 in the official [http://tomoyo.sourceforge.jp/2.5/chapter-4.html.en documentation].<br />
<br />
==Usage==<br />
It is important to consult the relevant documentation in order to use TOMOYO Linux or AKARI effectively:<br />
* [http://tomoyo.sourceforge.jp/documentation.html.en TOMOYO Linux documentation]<br />
* [http://akari.sourceforge.jp/index.html.en AKARI documentation]<br />
Run the policy editor to begin editing. If using TOMOYO Linux 1.x or AKARI, then ''ccs-tools'' should be used:<br />
# /usr/sbin/ccs-editpolicy<br />
If using TOMOYO Linux 2.x, then ''tomoyo-tools'' should be used:<br />
# /usr/sbin/tomoyo-editpolicy<br />
As the system runs, TOMOYO Linux will create domains and add them to the tree. The access analysis/restriction in TOMOYO Linux is applied via domains. Every process belongs to a single domain and the process will transit to a different domain whenever it executes a program. The name of a domain is a concatenated string expression for the process execution history. For example, the name of the domain which the kernel belongs to is "<kernel>"; the name of domain which {{ic|/sbin/init}} invoked by the kernel belongs to is "<kernel> /sbin/init"; if {{ic|/sbin/init}} invokes {{ic|/etc/rc.d/rc}} then the domain it belongs to is "<kernel> /sbin/init /etc/rc.d/rc". You can suppress or initialize domain transitions as needed.<br />
<br />
Profiles can be assigned to each domain. There are four default profiles:<br />
<br />
{| class="wikitable"<br />
| Disabled || Works as if regular kernel.<br />
|-<br />
| Learning || Do not reject an access request if it violates policy. Append the request to policy.<br />
|-<br />
| Permissive || Do not reject an access request if it violates policy. Do not append the request to policy.<br />
|-<br />
| Enforcing || Reject an access request if it violates policy. Do not append the request to policy.<br />
|}<br />
The learning profile can be used to analyse the system or a specific application. Once all of the desired access requests of a domain have been identified, the policy for that domain can be edited as required before selecting the enforcing profile. This can be done for any and all domains from the start of system boot.<br />
<br />
==References==<br />
* [http://tomoyo.osdn.jp/ TOMOYO Linux Home Page]<br />
* [http://tomoyo.osdn.jp/wiki-e/ TOMOYO Linux Wiki]<br />
* [http://akari.osdn.jp/index.html.en AKARI Home Page]<br />
* [http://akari.osdn.jp/documentation.html.en AKARI Ddocumentation]<br />
* [http://akari.osdn.jp/comparison.html AKARI/TOMOYO functionality comparison table]<br />
* [http://tomoyo.osdn.jp/1.8/index.html.en TOMOYO Linux 1.8.x : The Official Guide]<br />
* [http://tomoyo.osdn.jp/2.5/index.html.en TOMOYO Linux 2.5.x : The Official Guide]<br />
* [http://lwn.net/Articles/263179/ TOMOYO Linux Security Goal]<br />
* [http://tomoyo.sourceforge.jp/cgi-bin/lxr/source/centos5.5/domain_policy.conf?v=policy-sample Policy sample]<br />
* [http://elinux.org/TomoyoLinux TOMOYO Linux on the Embedded Linux Wiki]<br />
* [https://osdn.net/projects/tomoyo/docs/PacSec2007-en-demo.pdf Presentation slides from PacSec 2007]<br />
<br />
==See also==<br />
* [[AppArmor]]<br />
* [[SELinux]]</div>Tuxsavvyhttps://wiki.archlinux.org/index.php?title=Talk:VMware&diff=315764Talk:VMware2014-05-20T02:33:00Z<p>Tuxsavvy: Created separate section for own minor suggestions. May be this may help improve this wiki page.</p>
<hr />
<div>== DKMS ==<br />
<br />
Is the section about using DKMS to compile the kernel modules still valid? There is [https://www.archlinux.org/packages/community/i686/open-vm-tools-dkms/ open-vm-tools-dkms] in the community repository which seems to be the same thing. I don't know how to use DKMS yet so it would be nice if someone with experience on using DKMS could update the corresponding section. --[[User:BertiBoeller|BertiBoeller]] ([[User talk:BertiBoeller|talk]]) 11:33, 2 October 2012 (UTC)<br />
<br />
:Yeah, but that's Open Virtual Machine Tools, not VMware Virtual Machine Tools (see the [https://superuser.com/questions/270112/open-vm-tools-vs-vmware-tools Stack Overflow thread] for differences.)<br />
:Also, it looks like it's been [https://aur.archlinux.org/packages/open-vm-tools-dkms/ moved] to the [[AUR]] less than a week ago. --'''<span style="text-shadow:grey 0.1em 0.1em 0.1em; font-size:110%">[[User:Det|<span style="color:gold">D</span><span style="color:orange">e</span><span style="color:red">t</span>]][[User talk:Det|<sup><font color="white">talk</font></sup>]]</span>''' 21:36, 5 April 2014 (UTC)<br />
<br />
== Some minor suggestions to wiki page ==<br />
<br />
Hi, thanks for the wiki page. It is somewhat comprehensive even though I was a little confused and didn't get what some of the details on the wiki page meant initially. Anyway, I thought I would like to drop some stuff on possible suggestions to some of the stuff. <br />
<br />
=== Alternative VMware kernel modules patch ===<br />
I found another patch which also works for 10.0.2 - it is by the same author but this patch seems to be bigger: [https://communities.vmware.com/thread/477701 VMware Community: Vmware Workstation 10.0.2 build-1744117 patch for Linux kernel 3.14.2]. This definitely works fine with 3.14.3-2 as well but I have not found an easier way to patch the necessary files that needs to be patched using the aforementioned patch.<br />
<br />
=== vmware-modconfig requiring /etc/systemd/user/vmware even though it does not exist ===<br />
This seems to be an issue when systemd is in use. The [https://wiki.archlinux.org/index.php/VMware#Systemd_service Archwiki: Systemd service script for VMware] does somewhat work in conjunction with vmware-modconfig but I did it via nasty symlink:<br />
ln -s /etc/systemd/system/vmware.service /etc/systemd/user/vmware<br />
<br />
Then again I think ideally it should probably be symlinked to the init.d script in /etc/init.d instead as the systemd script produces some bizarre entries. Though it works nonetheless (or perhaps not, I had to manually run /etc/init.d/vmware stop to make it work).<br />
<br />
=== Patch file for /etc/init.d/vmware (workaround for vmci/vsock issue) ===<br />
I noticed this: [https://wiki.archlinux.org/index.php/VMware#vmci.2Fvsock_modules_not_loading_automatically Archwiki: VMware: vmci/vsock modules not loading automatically] - whilst the manual patching does work I thought it would be a little nice(r) to make a patch and then somehow automate it. Anyhow it is just an idea:<br />
{{hc|init.d_vmware_script.patch|2=<br />
--- /etc/init.d/vmware 2014-05-15 13:45:03.359475803 +1000<br />
+++ /etc/init.d/vmware-new 2014-05-15 13:43:45.470838553 +1000<br />
@@ -181,7 +181,8 @@<br />
<br />
# only load vmci if it's not already loaded<br />
if [ "`isLoaded "$mod"`" = 'no' ]; then<br />
- vmwareLoadModule "$mod"<br />
+# vmwareLoadModule "$mod"<br />
+ vmwareLoadModule "$vmci"<br />
fi<br />
vmware_rm_stale_node "$vmciNode"<br />
if [ ! -e "/dev/$vmciNode" ]; then<br />
@@ -231,7 +232,8 @@<br />
<br />
# only unload vmci if it's already loaded<br />
if [ "`isLoaded "${mod}"`" = 'yes' ]; then<br />
- vmwareUnloadModule "${mod}"<br />
+# vmwareUnloadModule "${mod}"<br />
+ vmwareUnloadModule "$vmci"<br />
fi<br />
rm -f "/dev/$vmciNode"<br />
}<br />
@@ -249,7 +251,8 @@<br />
mod=$(vmwareRealModName $vsock $vsock_alias)<br />
# only load vsock if it's not already loaded<br />
if [ "`isLoaded "$mod"`" = 'no' ]; then<br />
- vmwareLoadModule "$mod"<br />
+# vmwareLoadModule "$mod"<br />
+ vmwareLoadModule "vsock"<br />
fi<br />
vmware_rm_stale_node "$vsockNode"<br />
# Give udev 5 seconds to create our node<br />
@@ -269,7 +272,8 @@<br />
mod=$(vmwareRealModName $vsock $vsock_alias)<br />
# only unload vsock if it's already loaded<br />
if [ "`isLoaded "$mod"`" = 'yes' ]; then<br />
- vmwareUnloadModule "$mod"<br />
+# vmwareUnloadModule "$mod"<br />
+ vmwareUnloadModule "vsock"<br />
fi<br />
rm -f /dev/vsock<br />
}<br />
}}<br />
This patch has not been tested but it may work.<br />
--[[User:Tuxsavvy|Tuxsavvy]] ([[User talk:Tuxsavvy|talk]]) 02:32, 20 May 2014 (UTC)</div>Tuxsavvyhttps://wiki.archlinux.org/index.php?title=KDE&diff=303117KDE2014-03-04T03:07:59Z<p>Tuxsavvy: /* Yakuake */ Yakuake now has its own wiki page and is linked to it.</p>
<hr />
<div>[[Category:KDE]]<br />
[[cs:KDE]]<br />
[[de:KDE]]<br />
[[es:KDE]]<br />
[[fr:KDE]]<br />
[[it:KDE]]<br />
[[ja:KDE]]<br />
[[pl:KDE]]<br />
[[ru:KDE]]<br />
[[tr:KDE_Masaüstü_Ortamı]]<br />
[[zh-CN:KDE]]<br />
[[zh-TW:KDE]]<br />
{{Related articles start}}<br />
{{Related|Desktop environment}}<br />
{{Related|Display manager}}<br />
{{Related|Window manager}}<br />
{{Related|Plasma}}<br />
{{Related|Qt}}<br />
{{Related|KDM}}<br />
{{Related|KDevelop 4}}<br />
{{Related|Uniform Look for Qt and GTK Applications}}<br />
{{Related articles end}}<br />
<br />
From [http://www.kde.org/community/whatiskde/softwarecompilation.php KDE Software Compilation] and [http://www.kde.org/download/ Getting KDE Software]:<br />
<br />
:''The KDE Software Compilation is the set of frameworks, workspaces, and applications produced by KDE to create a beautiful, functional and free desktop computing environment for Linux and similar operating systems. It consists of a large number of individual applications and a desktop workspace as a shell to run these applications. ''<br />
<br />
The KDE upstream has a well maintained [http://userbase.kde.org/ UserBase wiki]. Users can get detailed information about most KDE applications there.<br />
<br />
== Installation ==<br />
<br />
Before installing KDE, make sure you have a working [[Xorg]] installation on your system.<br />
<br />
KDE 4.x is ''modular''. You can install an entire set of packages or only install your preferred KDE applications.<br />
<br />
=== Full install ===<br />
<br />
[[pacman|Install]] {{Grp|kde}} or {{Grp|kde-meta}} available in the [[official repositories]]. For differences between {{Grp|kde}} and {{Grp|kde-meta}} see the [[KDE Packages]] article.<br />
<br />
=== Minimal install ===<br />
<br />
If you want to have a minimal installation of the KDE Software Compilation, install {{Grp|kdebase}}.<br />
<br />
=== Language pack ===<br />
<br />
If you need language files, install {{ic|kde-l10n-yourlanguagehere}} (e.g. {{Pkg|kde-l10n-de}} for the German language).<br />
<br />
For a full list of available languages see [https://www.archlinux.org/packages/extra/any/kde-l10n/ this link].<br />
<br />
== Upgrading ==<br />
<br />
'''KDE 4.12''' Software Compilation is the current major [http://kde.org/announcements/ release of KDE]. Important hints for upgraders:<br />
* Always check if your mirror is '''up to date'''.<br />
* '''Do not force an update using {{ic|# pacman --force}}'''. If pacman complains about conflicts please '''file a bug report'''.<br />
* You can remove the meta packages and the sub packages you do not need after the update.<br />
* If you do not like split packages just keep using the kde-meta packages.<br />
<br />
== Starting KDE ==<br />
<br />
Starting KDE depends on your preferences. Basically there are two ways of starting KDE. Using '''KDM''' or '''xinitrc'''.<br />
<br />
=== Using a Display Manager ===<br />
A [[display manager]], or login manager, is typically a graphical user interface that is displayed at the end of the boot process in place of the default shell. It allows easily logging in straight to KDE. KDE has its own display manager, KDM.<br />
<br />
==== KDM (KDE Display Manager) ====<br />
<br />
''See the [[KDM]] page for more information.''<br />
<br />
[[systemd#Using units|Enable/start]] {{ic|kdm.service}} to start the display manager.<br />
<br />
=== Using xinitrc ===<br />
<br />
''See the [[xinitrc]] page for more information.''<br />
<br />
{{hc|~/.xinitrc|<br />
exec startkde<br />
}}<br />
<br />
Execute {{ic|startx}} or {{ic|xinit}} to start KDE.<br />
<br />
{{Note|If you want to start Xorg at boot, please read the [[Start X at Login]] article.}}<br />
<br />
== Configuration ==<br />
<br />
All KDE configuration is saved in the {{ic|~/.kde4}} folder. If KDE is giving you a lot of trouble or if you ever want a fresh installation of KDE, just backup and rename this folder and restart your X session. KDE will re-create it with all the default configuration files. If you want very fine-grained control over KDE programs, you may want to edit the files in this folder.<br />
<br />
However, configuring KDE is primarily done in '''System Settings'''. A few other options for the desktop are available in '''Default Desktop Settings''' in the desktop's context menu.<br />
<br />
For other personalization options not covered below such as activities, different wallpapers on one cube, etc., please refer to the [[Plasma]] wiki page.<br />
<br />
=== Personalization ===<br />
<br />
How to set up the KDE desktop to your personal style: use different Plasma themes, window decorations and icon themes.<br />
<br />
==== Plasma desktop ====<br />
<br />
[[Plasma]] is a desktop integration technology that provides many functions like displaying the wallpaper, adding widgets to the desktop, and handling the panel(s), or "taskbar(s)".<br />
<br />
===== Themes =====<br />
<br />
[http://kde-look.org/index.php?xcontentmode=76 Plasma themes] can be installed through the Desktop Settings control panel. Plasma themes define the look of panels and plasmoids. For easy system-wide installation, some such themes are available in both the official repositories and the [https://aur.archlinux.org/packages.php?O=0&K=plasmatheme&do_Search=Go AUR].<br />
<br />
===== Widgets =====<br />
<br />
Plasmoids are little scripted (plasmoid scripts) or coded (plasmoid binaries) KDE applications designed to enhance the functionality of your desktop.<br />
<br />
Plasmoid binaries can be installed using PKGBUILDs from [https://aur.archlinux.org/packages.php?O=0&K=plasmoid&do_Search=Go&PP=25&SO=d&SB=v AUR], or you can write your own PKGBUILD.<br />
<br />
The easiest way to install plasmoid scripts is by right-clicking onto a panel or the desktop:<br />
<br />
Add Widgets > Get new Widgets > Download Widgets<br />
<br />
This will present a nice frontend for [http://www.kde-look.org/ kde-look.org] that allows you to install, uninstall, or update third-party plasmoid scripts with literally just one click.<br />
<br />
Most plasmoids are not created officially by KDE developers. You can also try installing Mac OS X widgets, Microsoft Windows Vista/7 widgets, Google Widgets, and even SuperKaramba widgets.<br />
<br />
===== Sound applet in the system tray =====<br />
<br />
Install Kmix ({{Pkg|kdemultimedia-kmix}}) from the official repositories and start it from the application launcher. Since KDE, by default, autostarts programs from the previous session, it does not need to be started manually upon every login.<br />
<br />
{{Note|1=To adjust the [https://bugs.kde.org/show_bug.cgi?id=313579#c28 step size of volume increments/decrements], add e.g. {{ic|1=VolumePercentageStep=1}} in the {{ic|[Global]}} section of {{ic|~/.kde4/share/config/kmixrc}}}}<br />
<br />
===== Adding a Global Menu to the desktop =====<br />
<br />
Install {{Pkg|appmenu-qt}} from the official repositories and {{aur|appmenu-gtk}} and {{aur|appmenu-qt5}} from the AUR in order to complete the preliminaries for a Mac OS X style always-on global menu. To get Firefox and LibreOffice to use the global menu as well, install {{aur|firefox-extension-globalmenu}} and {{aur|libreoffice-extension-menubar}} from the AUR.<br />
<br />
{{Warning|{{aur|firefox-extension-globalmenu}} has been deprecated as of Firefox 25 and there is no other recommended method for getting the global menu. However, there is a patched package, {{aur|firefox-ubuntu}} available in the AUR which has Canonical's patch for getting the global menu to work with the current version of Firefox (as of this writing).}}<br />
<br />
To actually get the global menu, install {{aur|kdeplasma-applets-menubar}} from the AUR. Create a plasma-panel on top of your screen and add the window menubar applet to the panel. To export the menus to your global menu, go to ''System Settings > Application Appearance > Style''. Now click the fine-tuning tab and use the drop-down list to select ''only export'' as your menubar style.<br />
<br />
==== Window decorations ====<br />
<br />
[http://kde-look.org/index.php?xcontentmode=75 Window decorations] can be changed in:<br />
System Settings > Workspace Appearance > Window Decorations<br />
There you can also directly download and install more themes with one click, and some are available in the [https://aur.archlinux.org/packages.php?O=0&K=kdestyle&do_Search=Go&PP=25&SO=d&SB=v AUR].<br />
<br />
==== Icon themes ====<br />
<br />
Not many full system icons themes are available for KDE 4. You can open up ''System Settings > Application Appearance > Icons'' and browse for new ones or install them manually. Many of them can be found on [http://www.kde-look.org/ kde-look.org].<br />
<br />
Official logos, icons, CD labels and other artwork for Arch Linux are provided in the {{AUR|archlinux-artwork}} package. After installing you can find such artwork at {{ic|/usr/share/archlinux/}}.<br />
<br />
==== Fonts ====<br />
<br />
===== Fonts in KDE look poor =====<br />
<br />
Try installing the {{Pkg|ttf-dejavu}} and {{Pkg|ttf-liberation}} packages.<br />
<br />
After the installation, be sure to log out and back in. You should not have to modify anything in ''System Settings > Fonts''.<br />
<br />
If you have personally set up how your [[Fonts]] render, be aware that System Settings may alter their appearance. When you go ''System Settings > Appearance > Fonts'', System Settings will likely alter your font configuration file ({{ic|fonts.conf}}).<br />
<br />
There is no way to prevent this, but, if you set the values to match your {{ic|fonts.conf}} file, the expected font rendering will return (it will require you to restart your application or in a few cases restart your desktop). Note that Gnome's Font Preferences also does this.<br />
<br />
===== Fonts are huge or seem disproportional =====<br />
<br />
Try to force font DPI to '''96''' in ''System Settings > Application Appearance > Fonts''.<br />
<br />
If that does not work, try setting the DPI directly in your Xorg configuration as documented [[Xorg#Setting_DPI_manually|here]].<br />
<br />
==== Space efficiency ====<br />
<br />
Users with small screens (e.g. netbooks) can change some setting to make KDE more space efficient. See the [http://userbase.kde.org/KWin#Using_with_small_screens_(eg_Netbooks) upstream wiki] for more information. Also, you can use [http://www.kde.org/workspaces/plasmanetbook/ KDE's Plasma Netbook] which is a workspace made specifically for small, lightweight netbook devices.<br />
<br />
=== Networking ===<br />
<br />
You can choose from the following tools:<br />
* NetworkManager. See [[NetworkManager#KDE4|NetworkManager]] for more information.<br />
* Wicd. See [[Wicd]] for more information.<br />
<br />
=== Printing ===<br />
<br />
{{Tip|Use the [[CUPS]] web interface for faster configuration. Printers configured in this way can be used in KDE applications. }}<br />
<br />
You can also configure printers in ''System Settings > Printer Configuration''. To use this method, you must first install {{Pkg|kdeutils-print-manager}} and {{Pkg|cups}}.<br />
<br />
The {{ic|avahi-daemon}} and {{ic|cupsd}} daemons must be started first; otherwise, you will get the following error:<br />
The service 'Printer Configuration' does not provide an interface 'KCModule'<br />
with keyword 'system-config- printer-kde/system-config-printer-kde.py'<br />
The factory does not support creating components of the specified type.<br />
<br />
If you are getting the following error, you need to give your user the right to manage printers.<br />
There was an error during CUPS operation: 'cups-authorization-canceled'<br />
<br />
For CUPS, this is set in {{ic|/etc/cups/cups-files.conf}}.<br />
<br />
Adding {{ic|lp}} to {{ic|SystemGroup}} allows anyone who can print to configure printers. You can, of course, add another group instead of {{ic|lp}}.<br />
{{hc|/etc/cups/cups-files.conf|# Administrator user group...<br />
SystemGroup sys root lp}}<br />
<br />
{{Tip|Read the [[CUPS#CUPS_administration]] Article to get more details on how to configure CUPS. }}<br />
<br />
=== Samba/Windows support ===<br />
<br />
If you want to have access to Windows services, install [[Samba]] (package {{Pkg|samba}}).<br />
<br />
You can then configure Samba shares through:<br />
<br />
System Settings > Sharing > Samba<br />
<br />
=== KDE Desktop activities ===<br />
<br />
KDE Desktop Activities are Plasma-based virtual-desktop-like sets of Plasma Widgets where you can independently configure widgets as if you have more than one screen or desktop.<br />
<br />
On your desktop, click the Cashew Plasmoid and, on the pop-up window, press "Activities".<br />
<br />
A plasma bar presenting you the current existing Plasma Desktop Activities will appear at the bottom of the screen. You can navigate between them by pressing the correspondent icons.<br />
<br />
=== Power saving ===<br />
<br />
KDE has an integrated power saving service called "'''Powerdevil Power Management'''" that may adjust the power saving profile of the system and/or the brightness of the screen (if supported).<br />
<br />
Since KDE 4.6, CPU frequency scaling is no longer managed by KDE. Instead it is assumed to be handled automatically by the the hardware and/or kernel. Arch has used {{ic|ondemand}} as the default CPU frequency governor since kernel version 3.3, so no additional configuration in needed in most cases. For details on fine-tuning the governor, see [[CPU Frequency Scaling]].<br />
<br />
=== Monitoring changes on local files and directories ===<br />
<br />
KDE now uses '''inotify''' directly from the kernel with '''kdirwatch''' (included in kdelibs), so Gamin or FAM are no longer needed. You may want to install this {{AUR|kdirwatch}} from AUR which is a GUI frontend for kdirwatch.<br />
<br />
== System administration ==<br />
<br />
=== Set keyboard ===<br />
<br />
Navigate to:<br />
System Settings > Hardware > Input Devices > Keyboard<br />
In the first tab, you can choose your keyboard model.<br />
<br />
In the "'''Layouts'''" tab, you can choose the languages you may want to use by pressing the "Add Layout" button and subsequently choosing the variant and the language.<br />
<br />
In the "'''Advanced'''" tab, you can choose the keyboard combination you want in order to change the layouts in the "Key(s) to change layout" sub-menu.<br />
<br />
=== Terminate Xorg server through KDE system settings ===<br />
<br />
Navigate to the submenu:<br />
System Settings > Input Devices > Keyboard > Advanced (tab) > "Key Sequence to kill the X server"<br />
and tick the checkbox.<br />
<br />
=== KCM ===<br />
<br />
KCM stands for '''KC'''onfig '''M'''odule. KCMs can help you configure your system by providing interfaces in System Settings.<br />
<br />
'''Configuration for look and feel of GTK applications.'''<br />
* {{Pkg|kde-gtk-config}}<br />
* {{AUR|kcm-gtk}}<br />
* {{AUR|kcm-qt-graphicssystem}}<br />
<br />
'''Configuration for the GRUB bootloader.'''<br />
* {{AUR|grub2-editor}}<br />
* {{AUR|kcm-grub2}}<br />
<br />
'''Configuration for Synaptics touchpads.'''<br />
* {{AUR|synaptiks}}<br />
* {{AUR|kcm_touchpad}}<br />
<br />
'''Configuration for the [[Uncomplicated Firewall]] (UFW)'''<br />
* {{AUR|kcm-ufw}}<br />
<br />
'''Configuration for [[PolicyKit]]'''<br />
* {{AUR|kcm-polkit-kde-git}}<br />
<br />
'''Configuration for Wacom tablets'''<br />
* {{AUR|kcm-wacomtablet}}<br />
<br />
More KCMs can be found at [http://kde-apps.org/index.php?xcontentmode=273 kde-apps.org].<br />
<br />
== Desktop search and semantic desktop ==<br />
<br />
According to [[wikipedia:Semantic_desktop|Wikipedia]], ''"the Semantic Desktop is a collective term for ideas related to changing a computer's user interface and data handling capabilities so that data is more easily shared between different applications or tasks and so that data that once could not be automatically processed by a computer can be (automatically processed)."''<br />
<br />
The KDE implementation of this concept is tied to (as of KDE 4.10) two major pieces of software, Akonadi and Nepomuk. Between the two of them, these programs look at your data and make an easily searchable index of it. The idea behind these pieces of software is to make your system "aware" of your data and give it context using meta-data and user-supplied tags.<br />
<br />
Soprano and Virtuoso are two dependencies of the Nepomuk Semantic Desktop. Since the relationship between the two major components and their dependencies is not very clear, the following sections try to shed some light on their inner workings.<br />
<br />
=== Virtuoso and Soprano ===<br />
<br />
The database used to store all the metadata used by the semantic desktop is a ''[[wikipedia:Resource_Description_Framework|Resource Description Framework (RDF)]]'' database called Virtuoso. Internally, Virtuoso may be looked as a relational database. (A [[wikipedia:Relational_model|relational database]] is different from a traditional single-table based database in the sense that it uses multiple tables related by a single key in order to store data.) It is currently controlled by OpenLink and is available under a commercial and an open source license.<br />
<br />
From the [http://techbase.kde.org/Projects/Nepomuk/ComponentOverview#Soprano KDE Techbase], ''Soprano is a Qt abstraction over databases. It provides a friendly Qt-based API for accessing different RDF stores. It currently supports 3 database backends - Sesame, Redland and Virtuoso. The KDE Semantic Stack only works with Virtuoso. Soprano also provides additional features such as serializing, parsing RDF data, and a client server architecture that is heavily used in Nepomuk.''<br />
<br />
=== Nepomuk ===<br />
<br />
Nepomuk stands for "Networked Environment for Personal, Ontology-based Management of Unified Knowledge". It is what allows all the tagging and labeling of files as well to take place and also serves as the way to actually read the Virtuoso databases. It provides an API to application developers which allows them to read the data collected by it.<br />
<br />
In the past, the "Strigi" service was used to collect data about the various files present on the system. However, due to many reasons, the most important of them being CPU and Memory usage, Strigi was replaced by a homegrown indexing service which is integrated with Nepomuk-Core.<br />
<br />
For further information about Nepomuk, [http://techbase.kde.org/Projects/Nepomuk/ComponentOverview#Nepomuk_Components this page] is a good resource. However, some of the information in the previous page has been rendered outdated according to [http://vhanda.in/blog/2012/11/nepomuk-without-strigi/ this blog post].<br />
<br />
==== Using and configuring Nepomuk ====<br />
<br />
In order to search using Nepouk on the KDE desktop, press {{ic|ALT+F2}} and type in your query. Nepomuk is enabled by default. It can be turned on and off in:<br />
System Settings > Desktop Search<br />
<br />
Nepomuk has to keep track of a lot of files. It is for this reason that it is recommended to increase the number of files that can be watched with inotify. In order to do that this command is a good option.<br />
# sysctl fs.inotify.max_user_watches=524288<br />
<br />
To do it persistently:<br />
# echo "fs.inotify.max_user_watches = 524288" >> /etc/sysctl.d/99-inotify.conf<br />
<br />
Restart Nepomuk to see the changes.<br />
<br />
==== KDE without Nepomuk ====<br />
<br />
If you wish to run KDE without Nepomuk, there exists a {{AUR|nepomuk-core-fake}} package in the AUR.<br />
{{Warning|As of now, Dolphin depends on {{Pkg|nepomuk-widgets}} and hence will break if used with the fake Nepomuk package.}}<br />
<br />
=== Akonadi ===<br />
<br />
Akonadi is a system meant to act as a local cache for PIM data, regardless of its origin, which can be then used by other applications. This includes the user's emails, contacts, calendars, events, journals, alarms, notes, and so on. It interfaces with the Nepomuk libraries to provide searching capabilities.<br />
<br />
Akonadi does not store any data by itself: the storage format depends on the nature of the data (for example, contacts may be stored in vCard format).<br />
<br />
For more information on Akonadi and its relationship with Nepomuk, see [http://blogs.kde.org/node/4503] and [http://cmollekopf.wordpress.com/2013/02/13/kontact-nepomuk-integration-why-data-from-akonadi-is-indexed-in-nepomuk/].<br />
<br />
==== Disabling Akonadi ====<br />
<br />
See this [http://userbase.kde.org/Akonadi#Disabling_the_Akonadi_subsystem section in the KDE userbase].<br />
<br />
==== Database configuration ====<br />
<br />
Start {{ic|akonaditray}} from package {{Pkg|kdepim-runtime}}. Right click on it and select '''configure'''. In the Akonadi server configure tab, you can:<br />
* Configuring Akonadi to use MySQL/MariaDB Server<br />
* Configuring Akonadi to use PostgreSQL Server<br />
* Configuring Akonadi to use SQLite<br />
<br />
==== Running KDE without Akonadi ====<br />
<br />
The package {{AUR|akonadi-fake}} is a good option for those who wish to run KDE without Akonadi.<br />
<br />
== Phonon ==<br />
<br />
=== What is Phonon? ===<br />
<br />
From [[Wikipedia:Phonon|Wikipedia]]:<br />
''Phonon is the multimedia API for KDE 4. Phonon was created to allow KDE 4 to be independent of any single multimedia framework such as GStreamer or xine and to provide a stable API for KDE 4's lifetime. It was done for various reasons: to create a simple KDE/Qt style multimedia API, to better support native multimedia frameworks on Windows and Mac OS X, and to fix problems of frameworks becoming unmaintained or having API or ABI instability.<br />
''<br />
<br />
'''Phonon''' is being widely used within KDE, for both audio (e.g., the System notifications or KDE audio apps) and video (e.g., the Dolphin video thumbnails).<br />
<br />
=== Which backend should I choose? ===<br />
<br />
You can choose between various backends like [[GStreamer]] ({{Pkg|phonon-gstreamer}}) or [[VLC]] ({{Pkg|phonon-vlc}}), available in the [[official repositories]], and [[MPlayer]] ({{AUR|phonon-mplayer-git}}), QuickTime ({{AUR|phonon-quicktime-git}}) or [http://martinsandsmark.wordpress.com/2012/07/07/akademy/ AVKode] ({{AUR|phonon-avkode-git}}), available in the [[AUR]].<br />
<br />
Most users will want GStreamer or VLC which have the best upstream support. Note that multiple backends can be installed at once and chosen at ''System Settings > Multimedia > Phonon > Backend''.<br />
<br />
{{Note|<br />
* According to the [http://community.kde.org/Phonon/FeatureMatrix Feature Matrix], the GStreamer backend has some more features that the VLC backend.<br />
* According to the [http://userbase.kde.org/Phonon#Backend_libraries KDE UserBase], Phonon-MPlayer is currently unmaintained.}}<br />
<br />
== Useful applications ==<br />
<br />
The official set of KDE applications may be found [http://www.kde.org/applications/ here].<br />
<br />
=== Yakuake ===<br />
<br />
[[Yakuake]] provides a Quake-like terminal emulator whose visibility is toggled by the F12 key. It also has support for multiple tabs. Yakuake is available in the package {{Pkg|yakuake}}.<br />
<br />
=== KDE Telepathy ===<br />
<br />
[http://community.kde.org/KTp KDE Telepathy] is a project with the goal to closely integrate Instant Messaging with the KDE desktop. It utilizes the Telepathy framework as a backend and is intended to replace Kopete.<br />
<br />
To install all Telepathy protocols, install the {{Grp|telepathy}} group.<br />
To use the KDE Telepathy client, install the {{Pkg|kde-telepathy-meta}} package that includes all the packages contained in the {{Grp|kde-telepathy}} group .<br />
<br />
== Tips and tricks ==<br />
<br />
=== Using Openbox in KDE ===<br />
{{tip|The native window manager for KDE is {{ic|kwin}}.}}<br />
<br />
The [[Openbox]] window manager works very well within KDE, combined with a noticable improvement in performance and responsiveness. By default, a {{ic|KDE/Openbox}} session will be made automatically available upon installing Openbox, even if the KDE environment itself has not been installed. Most popular display managers will therefore allow KDE with Openbox as the window manager to be selected as a session.<br />
<br />
To manually start KDE with Openbox as the window manager - as a default session for [[SLiM]], or where not using a display manager at all - add the following command to the [[Xinitrc]] file:<br />
<br />
exec openbox-kde-session<br />
<br />
==== When using KDM ====<br />
<br />
To use [[Openbox]] as a default windows manager when logging in with [[KDM]] just go to Default Applications -> Window Manager -> Use a different windows manager then select Openbox within the dropdown box.<br />
<br />
<br />
==== Re-enabling compositing effects ====<br />
Where replacing the native {{ic|kwin}} window manager with Openbox, any desktop compositing effects - such a transparency - provided will also be lost. This is because Openbox itself does not provide any compositing functionality. However, it is easily possible to use a seperate compositing program to [[Openbox#Compositing_effects|re-enable compositing]].<br />
<br />
=== Integrate Android with the KDE Desktop ===<br />
<br />
Install {{Pkg|kdeconnect}} and [https://play.google.com/store/apps/details?id=org.kde.kdeconnect_tp&hl=en KDE Connect] from the Google Play store for great Android-KDE integration.<br />
<br />
=== Get notifications for software updates ===<br />
<br />
Install {{Pkg|apper}} to get notifications about package updates in your KDE system tray and a basic package manager GUI. See the [http://www.packagekit.org/index.html PackageKit website] for more information.<br />
<br />
=== Configure KWin to use OpenGL ES ===<br />
<br />
Beginning with KWin version 4.8 it is possible to use the separately built binary '''kwin_gles''' as a replacement for kwin. It behaves almost the same as the kwin executable in OpenGL2 mode with the slight difference that it uses ''egl'' instead of ''glx'' as the native platform interface. To test kwin_gles you just have to run {{ic|kwin_gles --replace}} in Konsole.<br />
If you want to make this change permanent you have to create a script in {{ic|$(kde4-config --localprefix)/env/}} which exports {{ic|1=KDEWM=kwin_gles}}.<br />
<br />
=== Enabling audio thumbnails under Konqueror/Dolphin file managers ===<br />
<br />
For thumbnails of audio files in Konqueror and Dolphin install {{AUR|audiothumbs}} from AUR.<br />
<br />
=== Enabling video thumbnails under Konqueror/Dolphin file managers ===<br />
<br />
For thumbnails of videos in konqueror and dolphin install {{Pkg|kdemultimedia-mplayerthumbs}} or {{Pkg|kdemultimedia-ffmpegthumbs}}.<br />
<br />
=== Speed up application startup ===<br />
<br />
User Rob wrote on his blog this "[http://kdemonkey.blogspot.nl/2008/04/magic-trick.html magic trick]" to improve application start-up time by 50-150ms.<br />
To enable it, create this folder in your home:<br />
$ mkdir -p ~/.compose-cache/<br />
<br />
{{Note|For those curious about what is going on here, this enables an optimization which Lubos (of general KDE speediness fame) came up with some time ago and was then rewritten and integrated into libx11. Ordinarily, on startup, applications read input method information from {{ic|/usr/share/X11/locale/''your locale''/Compose}}. This file is quite long (>5000 lines for the en_US.UTF-8 one) and takes some time to process. libX11 can create a cache of the parsed information which is much quicker to read subsequently, but it will only re-use an existing cache or create a new one in {{ic|~/.compose-cache}} if the directory already exists.}}<br />
<br />
=== Hiding partitions ===<br />
<br />
In Dolphin, it is as simple as right-clicking on the partition in the {{ic|Places}} sidebar and selecting {{ic|Hide ''partition''}}. Otherwise...<br />
<br />
If you wish to prevent your internal partitions from appearing in your file manager, you can create an udev rule, e.g:<br />
<br />
{{hc|/etc/udev/rules.d/10-local.rules|2=<br />
KERNEL=="sda[0-9]", ENV{UDISKS_IGNORE}="1"<br />
}}<br />
<br />
The same thing for a certain partition:<br />
<br />
KERNEL=="sda1", ENV{UDISKS_IGNORE}="1"<br />
KERNEL=="sda2", ENV{UDISKS_IGNORE}="1"<br />
<br />
=== Konqueror tips ===<br />
<br />
==== Disabling smart key tooltips (browser) ====<br />
<br />
To disable those smart key tooltips in Konqueror (pressing {{ic|Ctrl}} on a web page), use ''Settings > Configure Konqueror > Web Browsing'' and uncheck ''Enable Access Key activation with Ctrl key'' o<br />
<br />
{{hc|~/.kde4/share/config/konquerorrc|2=<br />
[Access Keys]<br />
Enabled=false<br />
}}<br />
<br />
==== Using WebKit ====<br />
<br />
WebKit is an open source browser engine developed by Apple Inc. It is a derivative from the KHTML and KJS libraries and contains many improvements. WebKit is used by Safari, Google Chrome and rekonq.<br />
<br />
It is possible to use WebKit in Konqueror instead of KHTML. First install the {{Pkg|kwebkitpart}} package.<br />
<br />
Then, after executing Konqueror, navigate to ''Settings > Configure Konqueror > General > Default web browser engine'' and set it as {{ic|WebKit}}.<br />
<br />
=== Firefox integration ===<br />
<br />
See [[Firefox#KDE_integration|Firefox]].<br />
<br />
=== Setting the screensaver background to the same as the current one ===<br />
<br />
Kscreensaver's background can be changed from the default.<br />
<br />
KDE by default is [https://bugs.kde.org/show_bug.cgi?id=312828 not able] to change this for the 'Simple Lock', but a [http://lists.opensuse.org/opensuse-kde/2013-02/msg00082.html workaround] [http://forum.kde.org/viewtopic.php?f=66&t=110039 exists]:<br />
<br />
{{hc|/usr/share/apps/ksmserver/screenlocker/org.kde.passworddialog/contents/ui/|<br />
[...]<br />
''#source: theme.wallpaperPathForSize(parent.width, parent.height)''<br />
source: "1920x1080.jpg"<br />
[...]<br />
}}<br />
<br />
Now you copy your current background image to {{ic|"1920x1080.jpg"}}.<br />
<br />
Note you have to redo this for each update of the package {{Pkg|kdebase-workspace}}.<br />
<br />
=== Setting lockscreen wallpaper to arbitrary image ===<br />
<br />
Copy an existing wallpaper profile as a template:<br />
$ cp -r /usr/share/wallpapers/''ExistingWallpaper'' ~/.kde4/share/wallpapers/<br />
<br />
Change the name of the directory, and edit {{ic|metadata.desktop}}:<br />
<br />
{{hc|~/.kde4/share/wallpapers/''MyWallpaper''/metadata.desktop|2=<br />
[Desktop Entry]<br />
Name=MyWallpaper<br />
X-KDE-PluginInfo-Name=MyWallpaper<br />
}}<br />
<br />
Remove existing images ({{ic|contents/screenshot.png}} and {{ic|images/*}}):<br />
$ rm ~/.kde4/share/wallpapers/MyWallpaper/contents/screenshot.png<br />
$ rm ~/.kde4/share/wallpapers/MyWallpaper/contents/images/*<br />
<br />
Copy new image in:<br />
$ cp ''path/to/MyWallpaper.png'' MyWallpaper/contents/images/1920x1080.png<br />
<br />
Edit the metadata profile for the current theme:<br />
{{hc|~/.kde4/share/apps/desktoptheme/MyTheme/metadata.desktop|2=<br />
[Wallpaper]<br />
defaultWallpaperTheme=MyWallpaper<br />
defaultFileSuffix=.png<br />
defaultWidth=1920<br />
defaultHeight=1080<br />
}}<br />
<br />
Lock the screen to check that it worked.<br />
<br />
{{Note|This method sets the lockscreen background without changing any system-wide settings. For a system-wide change, create the new wallpaper profile in {{ic|/usr/share/wallpapers}}.}}<br />
<br />
== Troubleshooting ==<br />
<br />
=== Configuration related ===<br />
<br />
Many problems in KDE are related to configuration. One way to resolve upgrade problems is to start over with a fresh KDE config.<br />
<br />
==== Reset all KDE configuration ====<br />
<br />
To test whether your config is the problem try quitting your KDE session by logging out and, in a tty, run<br />
$ cp ~/.kde4 ~/.kde4.safekeeping<br />
$ rm .kde4/{cache,socket,tmp}-$(hostname)<br />
<br />
The ''rm'' command just removes symbolic links which will be recreated by KDE automatically. Now start a new KDE session to see the results.<br />
<br />
If the problem is resolved, you will have a fresh, problem-free {{ic|~/.kde4/}}. You can gradually move parts of your saved configuration back, restarting your session regularly to test, to identify the problematic parts of your config. Some files here are named after applications so you will probably be able to test these without needing to restart KDE.<br />
<br />
==== File Indexer Service not working even after enabling everything properly ====<br />
<br />
This is caused due to a corrupted Nepomuk database. It may be remedied by moving the database or deleting it all together. Log out of KDE and issue this command from a virtual console:<br />
<br />
$ mv ~/.kde4/share/apps/nepomuk ~/.kde4/share/apps/nepomuk_backup<br />
<br />
to move your existing (and corrupt) nepomuk database. It will be recreated when you log in again.<br />
<br />
==== Plasma desktop behaves strangely ====<br />
<br />
Plasma problems are usually caused by unstable '''plasmoids''' or '''plasma themes'''. First, find which was the last plasmoid or plasma theme you had installed and disable it or uninstall it.<br />
<br />
So, if your desktop suddenly exhibits "locking up", this is likely caused by a faulty installed widget. If you cannot remember which widget you installed before the problem began (sometimes it can be an irregular problem), try to track it down by removing each widget until the problem ceases. Then you can uninstall the widget, and file a bug report (bugs.kde.org) '''only if it is an official widget'''. If it is not, it is recommended you find the entry on kde-look.org and inform the developer of that widget about the problem (detailing steps to reproduce, etc).<br />
<br />
If you cannot find the problem, but you do not want ''all'' the KDE settings to be lost, do:<br />
<br />
$ rm -r ~/.kde4/share/config/plasma*<br />
<br />
This command will '''delete all plasma related configs''' of your user and when you will relogin into KDE, you will have the '''default''' settings back. You should know that this action '''cannot be undone'''. You should create a backup folder and copy all the plasma related configs in it.<br />
<br />
==== Clean cache to resolve upgrade problems ====<br />
<br />
The [https://bbs.archlinux.org/viewtopic.php?id=135301 problem] may be caused by old cache. Sometimes after an upgrade, the old cache might introduce strange, hard to debug behaviour such as unkillable shells, hangs when changing various settings and several other problems such as ark being unable to unrar or unzip or amarok not recognizing any of your musics. This solution can also resolve problems with KDE and QT programmes looking bad following upgrade.<br />
<br />
Rebuild your cache with the following commands:<br />
<br />
$ rm ~/.config/Trolltech.conf<br />
$ kbuildsycoca4 --noincremental<br />
<br />
Hopefully, your problems are now fixed.<br />
<br />
=== Clean akonadi configuration to fix KMail ===<br />
<br />
First, make sure that KMail is not running. Then backup configuration:<br />
$ mv ~/.local/share/akonadi ~/.local/share/akonadi-old<br />
$ mv ~/.config/akonadi ~/.config/akonadi-old<br />
<br />
Start ''SystemSettings > Personal'' and remove all the resources. Go back to Dolphin and remove the original {{ic|~/.local/share/akonadi}} and<br />
{{ic|~/.config/akonadi}} - the copies you made ensure that you can back-track if necessary.<br />
<br />
Now go back to the System Settings page and carefully add the necessary resources. You should see the resource reading in your mail folders. Then start Kontact/KMail to see if it work properly.<br />
<br />
=== Getting current state of KWin for support and debug purposes ===<br />
<br />
This command prints out a wonderful summary of the current state of KWin including used options, used compositing backend and relevant OpenGL driver capabilities. See more on [http://blog.martin-graesslin.com/blog/2012/03/on-getting-help-for-kwin-and-helping-kwin/ Martin's blog].<br />
<br />
$ qdbus org.kde.kwin /KWin supportInformation<br />
<br />
=== KDE4 does not finish loading ===<br />
<br />
There might be a situation in which the graphic driver might create a conflict when starting KDE4. This situation happens after the login but before finishing loading the desktop, making the user wait indefinitely at the loading screen. Until now the only users confirmed to be affected by this are the ones that use [[NVIDIA|Nvidia drivers]] and KDE4.<br />
<br />
A solution for Nvidia users:<br />
<br />
{{hc|~/.kde4/share/config/kwinrc|2=<br />
[Compositing]<br />
Enabled=false<br />
}}<br />
For more information, see [https://bbs.archlinux.org/viewtopic.php?pid=932598 this] thread.<br />
<br />
If a minimal install was done, make sure you installed the required font by your phonon backend listed here: [[#Minimal install]]<br />
<br />
=== KDE and Qt programs look bad when in a different window manager ===<br />
<br />
If you are using KDE or Qt programs but not in a full KDE session (specifically, you did not run {{ic|startkde}}), then as of KDE 4.6.1 you will need to tell Qt how to find KDE's styles (Oxygen, QtCurve etc.)<br />
<br />
You just need to set the environment variable {{ic|QT_PLUGIN_PATH}}. E.g. put:<br />
<br />
export QT_PLUGIN_PATH=$HOME/.kde4/lib/kde4/plugins/:/usr/lib/kde4/plugins/<br />
<br />
into your {{ic|/etc/profile}} (or {{ic|~/.profile}} if you do not have root access). qtconfig should then be able to find your KDE styles and everything should look nice again!<br />
<br />
Alternatively, you can symlink the Qt styles directory to the KDE styles one:<br />
# ln -s /usr/lib/kde4/plugins/styles/ /usr/lib/qt/plugins/styles<br />
<br />
Under Gnome you can try to install the package libgnomeui.<br />
<br />
=== Graphical related problems ===<br />
<br />
==== Low 2D desktop performance (or) artifacts appear when on 2D ====<br />
<br />
===== GPU driver problem =====<br />
<br />
Make sure you have the proper driver for your card installed, so that your desktop is at least 2D accelerated. Follow these articles for more information: [[ATI]], [[NVIDIA]], [[Intel]] for more information, in order to make sure that everything is all right.<br />
The open-source ATI and Intel drivers and the proprietary (binary) Nvidia driver should theoretically provide the best 2D and 3D acceleration.<br />
<br />
===== The Raster engine workaround =====<br />
<br />
If this does not solve your problems, your driver may not provide a good '''XRender''' acceleration which the current Qt painter engine relies on by default.<br />
<br />
You can change the painter engine to software based only by invoking the application with the {{ic|-graphicssystem raster}} command line. This rendering engine can be set as the default one by recompiling Qt with the same as configure option, {{ic|-graphicssystem raster}}.<br />
<br />
The raster paint engine enables the CPU to do the majority of the painting, as opposed to the GPU. You may get better performance, depending on your system. This is basically a work-around for the terrible Linux driver stack, since the CPU should obviously not be doing graphical computations since it is designed for fewer threads of greater complexity, as opposed to the GPU which is many threads but lesser computational strength. So, only use Raster engine if you are having problems or your GPU is much slower than you CPU, otherwise is better to use XRender.<br />
<br />
Since Qt 4.7+, recompiling Qt is not needed. Simply export {{ic|1=QT_GRAPHICSSYSTEM=raster}}, or {{ic|opengl}}, or {{ic|native}} (for the default). Raster depends on the CPU, OpenGL depends on the GPU and high driver support, and Native is just using the X11 rendering (mixture, usually).<br />
<br />
'''The best and automatic way to do that''' is to install {{AUR|kcm-qt-graphicssystem}} from AUR and configure this particular Qt setting through:<br />
<br />
System Settings > Qt Graphics System<br />
<br />
For more information, consult this [http://apachelog.wordpress.com/2010/09/05/qt-graphics-system-kcm/ KDE Developer blog entry] and/or this [http://labs.trolltech.com/blogs/2009/12/18/qt-graphics-and-performance-the-raster-engine/ Qt Developer blog entry].<br />
<br />
==== Low 3D desktop performance====<br />
<br />
KDE begins with desktop effects enabled. Older cards may be insufficient for 3D desktop acceleration. You can disable desktop effects in:<br />
System Settings > Desktop Effects<br />
and you can toggle desktop effects with {{ic|Alt+Shift+F12}}.<br />
<br />
{{Note| You may encounter such problems with 3D desktop performance even when using a more powerful graphics card, especially the catalyst proprietary driver ({{ic|fglrx}}). This driver is known for having problems with 3D acceleration. Visit [[ATI|the ATI Wiki page]] for more troubleshooting.}}<br />
<br />
==== Desktop compositing is disabled on my system with a modern Nvidia GPU ====<br />
<br />
Sometimes, KWin may have settings in its configuration file ({{ic|kwinrc}}) that ''may'' cause a problem on re-activating the 3D desktop {{ic|OpenGL}} compositing. That could be caused randomly (for example, due to a sudden Xorg crash or restart, and it gets corrupted), so, in case that happens, delete your {{ic|~/.kde4/share/config/kwinrc}} file and relogin. The KWin settings will turn to the KDE default ones and the problem should be probably gone.<br />
<br />
==== Flickering in fullscreen when compositing is enabled ====<br />
<br />
As of KDE SC 4.6.0, there is an option in ''Sytem Settings > Desktop Effect > Advanced > Suspend desktop effects for fullscreen windows''. Uncheck it would tell kwin to disable unredirect fullscren.<br />
<br />
==== Screen Tearing with desktop compositing enabled ====<br />
<br />
{{Note|With the release of KDE 4.11, several new Vsync options have been added, which may help with screen tearing.}}<br />
<br />
KWin may suffer from screen tearing while desktop effects are enabled. Uncheck the VSync option under ''System Settings > Desktop Effects > Advanced > Use Vsync''.<br />
<br />
For proprietary driver users, ensure that the driver's VSync option is enabled ({{ic|amdccle}} for [[Catalyst]] users, and nvidia-settings for [[NVIDIA]] users).<br />
<br />
==== Display settings lost on reboot (multiple monitors) ====<br />
Installing {{Pkg|kscreen}} might fix the problem unless your screens share the same EDID. Kscreen is the improved screen management software for KDE, more information can be found [https://fedoraproject.org/wiki/Changes/KScreen?rd=Features/KScreen here].<br />
<br />
=== Sound problems under KDE ===<br />
<br />
==== ALSA related problems ====<br />
<br />
{{Note|First make sure you have {{Pkg|alsa-lib}} and {{Pkg|alsa-utils}} installed.}}<br />
<br />
===== "Falling back to default" messages when trying to listen to any sound in KDE =====<br />
<br />
When you encounter such messages:<br />
The audio playback device ''name_of_the_sound_device'' does not work.<br />
Falling back to default<br />
Go to:<br />
System Settings > Multimedia > Phonon<br />
and set the device named {{ic|default}} above all the other devices in each box you see.<br />
<br />
===== MP3 files cannot be played when using the GStreamer Phonon backend =====<br />
<br />
This can be solved by installing the GStreamer plugins (package group {{Grp|gstreamer0.10-plugins}}). If you still encounter problems, you can try changing the Phonon backend used by installing another such as {{Pkg|phonon-vlc}}.<br />
Then, make sure the backend is preferred via:<br />
<br />
System Settings > Multimedia > Phonon > Backend (tab)<br />
<br />
=== Konsole does not save commands' history ===<br />
<br />
By default console command history is saved only when you type 'exit' in console. When you close Konsole with 'x' in the corner it does not happen.<br />
To enable autosaving after every command execution:<br />
<br />
{{hc|~/.bashrc|<nowiki><br />
shopt -s histappend<br />
[[ "${PROMPT_COMMAND}" ]] && PROMPT_COMMAND="$PROMPT_COMMAND;history -a" || PROMPT_COMMAND="history -a"<br />
</nowiki>}}<br />
<br />
=== KDE password prompts display three bullets per char ===<br />
<br />
This setting can be changed at ''System Settings > Account Details > Password & User Account'':<br />
* Show one bullet for each letter<br />
* Show three bullets for each letter<br />
* Show nothing<br />
<br />
=== Nepomukserver process still autostarts even with semantic desktop disabled ===<br />
<br />
Go to ''System Settings > Startup and Shutdown > Service Manager > Startup Services'' and uncheck the Nepomuk Search Module.<br />
<br />
=== Dolphin and File Dialogs are extremely slow to start ===<br />
<br />
This may be caused by the upower service. If the upower service is not needed on your system, it can be disabled:<br />
<br />
# systemctl disable upower<br />
# systemctl mask upower<br />
<br />
Obviously this will not have any side effect on a desktop system.<br />
<br />
=== Default PDF viewer in GTK applications under KDE ===<br />
<br />
In some cases when you have installed [[Inkscape]], [[Gimp]] or other graphic programs, GTK applications ([[Firefox]] among all) might not select Okular as the default PDF application, and they are not going to follow the KDE settings on default applications. You can use the following user command to make Okular the default application again.<br />
<br />
$ xdg-mime default kde4-okularApplication_pdf.desktop application/pdf<br />
<br />
If you are using a different PDF viewer application, or a different mime-type is misbehaving, you should change {{ic|kde4-okularApplication_pdf.desktop}} and {{ic|application/pdf}} respectively according to your needs.<br />
<br />
For more information, consult [[Default applications]] wiki page.<br />
<br />
== Unstable releases ==<br />
<br />
When KDE is reaching beta or RC milestone, KDE "unstable" packages are uploaded to the [kde-unstable] repository. They stay there until KDE is declared stable and passes to [extra].<br />
<br />
You can add [kde-unstable] with:<br />
<br />
{{hc|/etc/pacman.conf|2=<br />
[kde-unstable]<br />
Include = /etc/pacman.d/mirrorlist<br />
}}<br />
<br />
# [kde-unstable] is based upon testing. Therefore, you need to enable the repositories in the following order: [kde-unstable], [testing], [core], [extra], [community-testing], [community].<br />
# To update from a previous KDE installation, run: {{ic|# pacman -Syu}} or {{ic|# pacman -S kde-unstable/kde}}<br />
# If you do not have KDE installed, you might have difficulties to install it by using groups (limitation of pacman)<br />
# '''Subscribe and read the [https://mailman.archlinux.org/pipermail/arch-dev-public/ arch-dev-public] mailing list'''<br />
# Make sure [[#Distro_and_Upstream_bug_report|you make bug reports]] if you find any problems.<br />
<br />
== Other KDE projects ==<br />
<br />
=== Trinity ===<br />
<br />
From the release of KDE 4.x, the developers dropped support for KDE 3.5.x. Trinity Desktop Environment is a fork of KDE3 developed by Timothy Pearson ([http://trinitydesktop.org/ trinitydesktop.org]). This project aims to keep the KDE3.5 computing style alive, as well as polish off any rough edges that were present as of KDE 3.5.10. See [[Trinity]] for more info.<br />
<br />
{{Warning|KDE 3 is no longer maintained and supported by the KDE developers. The "Trinity KDE" is maintained by the Trinity project commmunity. Use KDE 3 on your own risk, regarding any bugs, performance problems or security risks.}}<br />
<br />
== Bugs ==<br />
<br />
It is preferrable that if you find a minor or serious bug, you should visit [https://bugs.archlinux.org the Arch Bug Tracker] or/and [http://bugs.kde.org KDE Bug Tracker] in order to report that. Make sure that you are clear about what you want to report.<br />
<br />
If you have any problem and you write about in on the Arch forums, first make sure that you have '''fully''' updated your system using a good sync mirror (check [https://www.archlinux.de/?page=MirrorStatus here]) or try [[Reflector]].<br />
<br />
== See also ==<br />
<br />
* [http://www.kde.org] - KDE homepage<br />
* [https://bugs.kde.org] - KDE bug tracker<br />
* [https://bugs.archlinux.org] - Arch Linux bug tracker<br />
* [https://projects.kde.org] - KDE Projects</div>Tuxsavvyhttps://wiki.archlinux.org/index.php?title=Yakuake&diff=303116Yakuake2014-03-04T03:06:26Z<p>Tuxsavvy: Correction on Yakuake link. Forgot to point to Yakuake link to Yakuake KDE page and not Guake of Gnome. Oops.</p>
<hr />
<div>[[Category:Terminal emulators]]<br />
{{Article summary start}}<br />
{{Article summary text|This article demonstrates the installation of Yakuake}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|KDE}}<br />
{{Article summary end}}<br />
[http://yakuake.kde.org/ Yakuake] is a top-down terminal for [[KDE]] (in the style of [[Guake]] for [[Gnome]], [[Tilda]] or the terminal used in Quake).<br />
<br />
== Installation ==<br />
<br />
[[pacman|Install]] {{Pkg|yakuake}}, available in the [[official repositories]].<br />
<br />
== Usage ==<br />
<br />
Once installed, you can start Yakuake from the terminal with:<br />
<br />
$ yakuake<br />
<br />
After yakuake has started you can click on configure yakuake by clicking on the "Open Menu" button (middle button on the bottom right hand side of the interface) and select "Configure Shortcuts" to change the hotkey to drop/retract the terminal automatically, by default it is set to F12.<br />
<br />
== Starting Yakuake with user defined sessions ==<br />
Like [[Guake]] Yakuake allows the user to invoke a shell script for instance to load Yakuake with user's defined sessions. In a nutshell, Yakuake can be launched and for instance when the hotkey to drop the terminal down will start showing all the individual tab(s) and their programs as the user defined in their own respective tab(s). Furthermore, like [[Guake]] Yakuake also allows one to define the name for each and every specific name of their tab(s).<br />
<br />
However, Yakuake relies on Qt framework and therefore the syntaxes for invoking the spawning/renaming/executing tab(s) are not the same as [[Guake]]. Below is a rough guide on setting up Yakuake to spawn user defined sessions (as tested working with 2.9.9-1).<br />
{{hc|~/editme.sh<br />
|#!/bin/bash<br />
|2=<nowiki># Starting yakuake based on user preferences. Information based on http://forums.gentoo.org/viewtopic-t-873915-start-0.html<br />
# Adding sessions from previous website is broken, use this: http://pawelkoston.pl/blog/sublime-text-3-cheatsheet-modules-web-develpment/<br />
# This line is needed in case yakuake does not accept fcitx inputs.<br />
/usr/bin/yakuake --im /usr/bin/fcitx --inputstyle onthespot<br />
<br />
# Start iotop in its own tab.<br />
qdbus-qt4 org.kde.yakuake /yakuake/sessions org.kde.yakuake.addSession<br />
qdbus-qt4 org.kde.yakuake /yakuake/tabs setTabTitle 0 "iotop" <br />
qdbus-qt4 org.kde.yakuake /yakuake/sessions runCommandInTerminal 0 "iotop"<br />
<br />
# Start htop in its own tab.<br />
qdbus-qt4 org.kde.yakuake /yakuake/sessions org.kde.yakuake.addSession<br />
qdbus-qt4 org.kde.yakuake /yakuake/tabs setTabTitle 1 "htop"<br />
qdbus-qt4 org.kde.yakuake /yakuake/sessions runCommandInTerminal 1 "htop"<br />
<br />
# Start atop in its own tab.<br />
qdbus-qt4 org.kde.yakuake /yakuake/sessions org.kde.yakuake.addSession<br />
qdbus-qt4 org.kde.yakuake /yakuake/tabs setTabTitle 2 "atop"<br />
qdbus-qt4 org.kde.yakuake /yakuake/sessions runCommandInTerminal 2 "atop"<br />
<br />
# Start (watching) iptables in its own tab.<br />
qdbus-qt4 org.kde.yakuake /yakuake/sessions org.kde.yakuake.addSession<br />
qdbus-qt4 org.kde.yakuake /yakuake/tabs setTabTitle 3 "iptables -nvL"<br />
qdbus-qt4 org.kde.yakuake /yakuake/sessions runCommandInTerminal 3 "~/.iptables.sh"<br />
<br />
# Start journalctl --follow --full in its own tab.<br />
qdbus-qt4 org.kde.yakuake /yakuake/sessions org.kde.yakuake.addSession<br />
qdbus-qt4 org.kde.yakuake /yakuake/tabs setTabTitle 4 "journalctl"<br />
qdbus-qt4 org.kde.yakuake /yakuake/sessions runCommandInTerminal 4 "journalctl --follow --full"<br />
<br />
# Start irssi in its own tab.<br />
qdbus-qt4 org.kde.yakuake /yakuake/sessions org.kde.yakuake.addSession<br />
qdbus-qt4 org.kde.yakuake /yakuake/tabs setTabTitle 5 "irssi"<br />
qdbus-qt4 org.kde.yakuake /yakuake/sessions runCommandInTerminal 5 "irssi"<br />
<br />
# Start root shell 1 in its own tab.<br />
qdbus-qt4 org.kde.yakuake /yakuake/sessions org.kde.yakuake.addSession<br />
qdbus-qt4 org.kde.yakuake /yakuake/tabs setTabTitle 6 "rootshell0"<br />
qdbus-qt4 org.kde.yakuake /yakuake/sessions runCommandInTerminal 6 "sudo -i"<br />
<br />
# Start root shell 2 in its own tab.<br />
qdbus-qt4 org.kde.yakuake /yakuake/sessions org.kde.yakuake.addSession<br />
qdbus-qt4 org.kde.yakuake /yakuake/tabs setTabTitle 7 "rootshell1"<br />
qdbus-qt4 org.kde.yakuake /yakuake/sessions runCommandInTerminal 7 "sudo -i"<br />
<br />
# Start shell 1 in its own tab.<br />
qdbus-qt4 org.kde.yakuake /yakuake/sessions org.kde.yakuake.addSession<br />
qdbus-qt4 org.kde.yakuake /yakuake/tabs setTabTitle 8 "shell0"<br />
<br />
# Start shell 2 in its own tab.<br />
qdbus-qt4 org.kde.yakuake /yakuake/sessions org.kde.yakuake.addSession<br />
qdbus-qt4 org.kde.yakuake /yakuake/tabs setTabTitle 9 "shell1"<br />
<br />
# Kill default (and now redundant) new shell tab. Already there are two shells each opened for both root and user.<br />
qdbus-qt4 org.kde.yakuake /yakuake/sessions org.kde.yakuake.removeSession 10</nowiki>}}</div>Tuxsavvyhttps://wiki.archlinux.org/index.php?title=Talk:Guake&diff=303115Talk:Guake2014-03-04T03:03:50Z<p>Tuxsavvy: Yakuake wiki page has been created and similiar BASH shell script is used to show example.</p>
<hr />
<div>: Autostarting up guake with user defined session (multiple tabs)<br />
:: I found some guides on making guake autostart with user defined session. What I meant by that is if I were to start guake via some shell script, it will start guake with all the tabs and programs in each specific tabs that I want.<br />
:: The two sites below refers to what I am referring to:<br />
::* http://askubuntu.com/a/364731 (Although this only provides a skeletal setup of what is needed.)<br />
::* https://github.com/Guake/guake/issues/198#issuecomment-21340679 (This gives a clearer setup but it still does not work well with guake 0.4.4.)<br />
:: Based on these two links I have furthermore modified their setup into my own (this is only a rough guide):<br />
:: #!/bin/bash<br />
:: /usr/bin/guake &<br />
:: sleep 5<br />
::<br />
:: guake --rename-tab="iotop" --execute="/usr/bin/iotop"<br />
::<br />
:: guake --new-tab --execute="/usr/bin/bash"<br />
:: guake --execute="/usr/bin/htop" --rename-tab="htop"<br />
::<br />
:: guake --new-tab --execute="/usr/bin/bash"<br />
:: guake --execute="/usr/bin/atop" --rename-tab="atop"<br />
::<br />
:: guake --new-tab --execute="/usr/bin/bash"<br />
:: guake --execute="~/.iptables.sh" --rename-tab="iptables -nvL"<br />
::<br />
:: guake --new-tab --execute="/usr/bin/bash"<br />
:: guake --execute="/usr/bin/journalctl --follow --full" --rename-tab="journalctl"<br />
::<br />
:: guake --new-tab --execute="/usr/bin/bash"<br />
:: guake --execute="/usr/bin/irssi" --rename-tab="irssi"<br />
::<br />
:: guake --new-tab --execute="/usr/bin/bash"<br />
:: guake --execute="/usr/bin/sudo -i" --rename-tab="rootshell0"<br />
::<br />
:: guake --new-tab --execute="/usr/bin/bash"<br />
:: guake --execute="/usr/bin/sudo -i" --rename-tab="rootshell1"<br />
::<br />
:: guake --new-tab --execute="/usr/bin/bash" <br />
:: guake --rename-tab="shell0"<br />
::<br />
:: guake --new-tab --execute="/usr/bin/bash"<br />
:: guake --rename-tab="shell1"<br />
::<br />
:: Based on this setup, it worked flawlessly on guake 0.4.4 with the settings that I desired. A similar sort of setup (albeit obviously with different commands, syntaxes, etc) appears on the [[Yakuake]] wiki page.<br />
: Disabling autorenaming of tabs from guake.<br />
:: This was something that I like when I was using yakuake and especially on KDE. The following link provides insight on how to disable autorenaming and yet combined with my suggestion above (for autostarting guake with user defined tabs) it works great:<br />
:: http://askubuntu.com/a/255958<br />
: Final remarks.<br />
::* I believe these two suggestions once approved should be moved into the main page of guake on Archwiki as they may help others.<br />
::* My BASH script above is not a direct representation of my setup as exactly as worded, however with one adjusting to their own preferences the script should work with guake 0.4.4.<br />
::* These suggestions were somewhat based on my desires for guake to mimick my setup in yakuake. As such yakuake wiki page has been created along with some basic guides for starters. <br />
[[User:Tuxsavvy|Tuxsavvy]] ([[User talk:Tuxsavvy|talk]]) 03:03, 4 March 2014 (UTC)Tuxsavvy</div>Tuxsavvyhttps://wiki.archlinux.org/index.php?title=Tilda&diff=303114Tilda2014-03-04T02:59:35Z<p>Tuxsavvy: Yakuake has a wiki page now and as such is linked.</p>
<hr />
<div>[[Category:Terminal emulators]]<br />
{{Article summary start}}<br />
{{Article summary text|This article describes installation and configuration of Tilda}}<br />
{{Article summary end}}<br />
[http://tilda.sourceforge.net Tilda] is a "pop-up virtual terminal" for X, just like [[Yakuake]] ([[KDE]]) or [[Guake]] ([[GNOME]]), but a little more lightweight and a little more maintained than sjterm.<br />
<br />
== Why Tilda ==<br />
<br />
You may find it very convenient to drop into a shell quickly without wasting screen estate. Tilda allows you to do that, as it is already open and therefore can be accessed very quickly, while staying unobtrusively in the "background" when you do not need it.<br />
<br />
== Installation ==<br />
<br />
{{pkg|tilda}} is available in the [community] repository.<br />
<br />
== Using with dwm ==<br />
<br />
[[dwm]] is a tiling [[Window manager|window manager]], which manages placement of windows automatically, so it takes some configuration to make Tilda work properly.<br />
<br />
You have to edit dwm's {{ic|config.h}} and recompile/reinstall dwm to properly account for Tilda.<br />
<br />
Get the latest [[PKGBUILD]] for dwm:<br />
# abs community/dwm<br />
<br />
Copy newest sources to your working directory, I am using {{ic|~/sources}}:<br />
$ cp -r /var/abs/community/dwm ~/sources<br />
<br />
Get into working directory to start config:<br />
$ cd ~/sources/dwm<br />
<br />
Edit config.h:<br />
<pre>static const Rule rules[] = {<br />
/* class instance title tags mask isfloating monitor */<br />
{ "Gimp", NULL, NULL, 0, True, -1 },<br />
{ "Firefox", NULL, NULL, 1 << 8, False, -1 },<br />
//add the line below<br />
{ "Tilda", NULL, NULL, 0, True, -1 },<br />
{ "Volumeicon", NULL, NULL, 0, True, -1 },<br />
};</pre><br />
<br />
The above makes all windows with the WM_CLASS "Tilda" floating. The word "Tilda" has to be uppercase, as shown by<br />
$ xprop |grep WM_CLASS<br />
<br />
Save {{ic|config.h}}, then compile and install dwm:<br />
$ makepkg -g >> PKGBUILD && makepkg -efi<br />
<br />
Start dwm or restart dwm if it is already active, either by MOD+SHIFT+Q or killing dwm and restarting it.<br />
<br />
Launch tilda with -C option:<br />
$ tilda -C<br />
<br />
Now you can configure Tilda, I recommend the following options:<br />
<pre>Font: Clean 9<br />
Appearance: Height: 50%, Width: 70%, Centered Horizontally<br />
Extras: Enable Transparency Level 15<br />
Animated Pulldown: 1500 usec, Orientation: Top<br />
Colors: Built-in Scheme "Green on Black"<br />
Scrolling: Scrollbar is on the left, 2000 lines scrollback<br />
Key Binding: F9<br />
</pre><br />
<br />
Here is what my config looks like after those settings in {{ic|~/.tilda/config_0}}:<br />
<pre><br />
tilda_config_version = "0.9.6"<br />
# image = ""<br />
# command = ""<br />
font = "Clean 9"<br />
key = "F9"<br />
title = "Tilda"<br />
background_color = "white"<br />
# working_dir = ""<br />
web_browser = "firefox"<br />
lines = 2000<br />
max_width = 956<br />
max_height = 384<br />
min_width = 1<br />
min_height = 1<br />
transparency = 15<br />
x_pos = 205<br />
y_pos = 1<br />
tab_pos = 0<br />
backspace_key = 0<br />
delete_key = 1<br />
d_set_title = 3<br />
command_exit = 2<br />
scheme = 1<br />
slide_sleep_usec = 1500<br />
animation_orientation = 0<br />
scrollbar_pos = 0<br />
back_red = 0<br />
back_green = 0<br />
back_blue = 0<br />
text_red = 0<br />
text_green = 65535<br />
text_blue = 0<br />
scroll_background = true<br />
scroll_on_output = false<br />
notebook_border = false<br />
antialias = true<br />
scrollbar = false<br />
use_image = false<br />
grab_focus = true<br />
above = true<br />
notaskbar = true<br />
bold = true<br />
blinks = true<br />
scroll_on_key = true<br />
bell = false<br />
run_command = false<br />
pinned = true<br />
animation = true<br />
hidden = true<br />
centered_horizontally = true<br />
centered_vertically = false<br />
enable_transparency = true<br />
double_buffer = false<br />
</pre><br />
<br />
It is important you enable the pulldown-animation, otherwise Tilda will keep jumping down each time you unhide it, must be a dwm issue.</div>Tuxsavvyhttps://wiki.archlinux.org/index.php?title=Guake&diff=303113Guake2014-03-04T02:58:56Z<p>Tuxsavvy: Yakuake has a wiki page now and as such is linked.</p>
<hr />
<div>[[Category:Terminal emulators]]<br />
[[de:Guake]]<br />
[[ru:Guake]]<br />
{{Article summary start}}<br />
{{Article summary text|This article demonstrates the installation of Guake}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|GNOME}}<br />
{{Article summary end}}<br />
[http://guake.org Guake] is a top-down terminal for [[GNOME]] (in the style of [[Yakuake]] for [[KDE]], [[Tilda]] or the terminal used in Quake).<br />
<br />
== Installation ==<br />
<br />
[[pacman|Install]] {{Pkg|guake}}, available in the [[official repositories]].<br />
<br />
== Usage ==<br />
<br />
Once installed, you can start Guake from the terminal with:<br />
<br />
$ guake<br />
<br />
After guake has started you can right click on the interface and select Preferences to change the hotkey to drop the terminal automatically, by default it is set to F12.<br />
<br />
== Autostartup ==<br />
<br />
You may want Guake to load on starting up Desktop Environment. To do this, you need to<br />
{{bc|# cp /usr/share/applications/guake.desktop /etc/xdg/autostart/}}<br />
<br />
See [[Autostarting]] for more info.<br />
<br />
== Window width ==<br />
<br />
Guake takes all the width of your display by default and there's no such option in "Preferences". To change width you can edit the program itself ({{ic|/usr/bin/guake}}) which is [[Python|python]] script.<br />
Find that string:<br />
<br />
width &#61; 100<br />
<br />
It is width value in percents, change it to whatever you like.<br />
<br />
If you want to align new "narrowed" window left or right find string (just below the 'width' line above).<br />
<br />
halignment &#61; self.client.get_int(KEY('/general/window_halignment'))<br />
<br />
and replace the part after the '&#61;' sign with "ALIGN_LEFT" or "ALIGN_RIGHT".<br />
<br />
To avoid overwrites on update, save it as /usr/local/bin/guake and remember to make it executable.<br />
<br />
Window alignment can also be set in gconf, under apps > guake > general > halignment. 0 sets it to center, 1 to right, 2 to left. (However, the width setting in gconf seems to have no effect and still requires editing the python script as explained above.)<br />
<br />
== Dual monitor workaround ==<br />
<br />
The traditional patch for dual monitors is no longer available, but a workaround is to define the start points for the window.<br />
Edit {{ic|/usr/bin/guake}}.<br />
Find that string<br />
<br />
window_rect.y &#61; 0<br />
<br />
is the default point in Y coordinate if you need change for the width of top desktop bar (or the long from the top of the bar to below), if you use it, <br />
and add the default x coordinate in the line below, for positioned the window I use:<br />
<br />
window_rect.x &#61; total_width - window_rect.width<br />
window_rect.y &#61; 24 <br />
window_rect.x &#61; 1024 <br />
return window_rect<br />
<br />
My first window is 1024 pixels and my second window is 1280 pixels, so guake get size of the first window from left to right which is why I must increase the width by a percentage<br />
<br />
Find that string<br />
<br />
width &#61; 100<br />
<br />
Change de value 100 for a more greater, in my case 125 (1280 divided by 1024 and multiplicated by 100.<br />
<br />
If the window width identified wrong, try to change the display number in<br />
<br />
window_rect = screen.get_monitor_geometry(0)<br />
<br />
== 'Ctrl' Keybind Problem ==<br />
<br />
As of {{Pkg|guake}} 0.4.2-7, there has been a noted bug affecting multiple users concerning the use of the 'Ctrl' key on the Keyboard Shortcuts to toggle guake visibility in the "Keyboard shortcuts" tab of guake-prefs (i.e. Users that setup 'Ctrl+Shift+z' to open the guake console can open it by pressing 'Shift+z', hence having the Ctrl key-bind irrelevant.<br />
•••••••••••<br />
There is a bug in the program that stores the settings in Toggle Guake Visibility that places the Ctrl string as "<Primary>" instead of "<Control>".<br />
<br />
The workaround is to use the command-line gconftool-2 from {{Pkg|gconf}} package, get the current string shortcut string from {{ic|/apps/guake/keybindings/global/show_hide}}, and replace all instances of "<Primary>" to "<Control>".<br />
<br />
To get what the current keyboard shortcut string is:<br />
# gconftool-2 -g /apps/guake/keybindings/global/show_hide<br />
<br />
To activate the guake console with Ctrl+Shift+z for example:<br />
# gconftool-2 -t string -s /apps/guake/keybindings/global/show_hide "<Control><Shift>z"<br />
<br />
It would be easier to use the graphical gconftool equivalent {{Pkg|gconf-editor}} to browse for and edit the {{ic|/apps/guake/keybindings/global/show_hide}} string. Replace "<Primary>" in the string with "<Control>".<br />
<br />
Alternatively you can use this script to replace instances of <Primary> with <Control> in the {{ic|/apps/guake/keybindings/global/show_hide}} string:<br />
{{hc|~/replaceit.sh<br />
|#!/bin/bash<br />
|2=<nowiki>if which gconftool-2 &> /dev/null<br />
then<br />
val=$(printf "%s" $(gconftool-2 -g /apps/guake/keybindings/global/show_hide))<br />
newval=${val/"<Primary>"/"<Control>"}<br />
if [ "$newval" = "$val" ]<br />
then echo "No changes made. Could not find or replace <Primary> in your settings."<br />
else<br />
echo "Replacing old string $val with new string:$newval"<br />
gconftool-2 -t string -s /apps/guake/keybindings/global/show_hide "$newval"<br />
fi<br />
else<br />
echo "gconftool-2 not found. Please install gconf. Exiting..."<br />
fi</nowiki>}}</div>Tuxsavvyhttps://wiki.archlinux.org/index.php?title=Yakuake&diff=303112Yakuake2014-03-04T02:56:54Z<p>Tuxsavvy: Started Yakuake page loosely based on Guake page as template.</p>
<hr />
<div>[[Category:Terminal emulators]]<br />
{{Article summary start}}<br />
{{Article summary text|This article demonstrates the installation of Yakuake}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|KDE}}<br />
{{Article summary end}}<br />
[http://guake.org Yakuake] is a top-down terminal for [[KDE]] (in the style of [[Guake]] for [[Gnome]], [[Tilda]] or the terminal used in Quake).<br />
<br />
== Installation ==<br />
<br />
[[pacman|Install]] {{Pkg|yakuake}}, available in the [[official repositories]].<br />
<br />
== Usage ==<br />
<br />
Once installed, you can start Yakuake from the terminal with:<br />
<br />
$ yakuake<br />
<br />
After yakuake has started you can click on configure yakuake by clicking on the "Open Menu" button (middle button on the bottom right hand side of the interface) and select "Configure Shortcuts" to change the hotkey to drop/retract the terminal automatically, by default it is set to F12.<br />
<br />
== Starting Yakuake with user defined sessions ==<br />
Like [[Guake]] Yakuake allows the user to invoke a shell script for instance to load Yakuake with user's defined sessions. In a nutshell, Yakuake can be launched and for instance when the hotkey to drop the terminal down will start showing all the individual tab(s) and their programs as the user defined in their own respective tab(s). Furthermore, like [[Guake]] Yakuake also allows one to define the name for each and every specific name of their tab(s).<br />
<br />
However, Yakuake relies on Qt framework and therefore the syntaxes for invoking the spawning/renaming/executing tab(s) are not the same as [[Guake]]. Below is a rough guide on setting up Yakuake to spawn user defined sessions (as tested working with 2.9.9-1).<br />
{{hc|~/editme.sh<br />
|#!/bin/bash<br />
|2=<nowiki># Starting yakuake based on user preferences. Information based on http://forums.gentoo.org/viewtopic-t-873915-start-0.html<br />
# Adding sessions from previous website is broken, use this: http://pawelkoston.pl/blog/sublime-text-3-cheatsheet-modules-web-develpment/<br />
# This line is needed in case yakuake does not accept fcitx inputs.<br />
/usr/bin/yakuake --im /usr/bin/fcitx --inputstyle onthespot<br />
<br />
# Start iotop in its own tab.<br />
qdbus-qt4 org.kde.yakuake /yakuake/sessions org.kde.yakuake.addSession<br />
qdbus-qt4 org.kde.yakuake /yakuake/tabs setTabTitle 0 "iotop" <br />
qdbus-qt4 org.kde.yakuake /yakuake/sessions runCommandInTerminal 0 "iotop"<br />
<br />
# Start htop in its own tab.<br />
qdbus-qt4 org.kde.yakuake /yakuake/sessions org.kde.yakuake.addSession<br />
qdbus-qt4 org.kde.yakuake /yakuake/tabs setTabTitle 1 "htop"<br />
qdbus-qt4 org.kde.yakuake /yakuake/sessions runCommandInTerminal 1 "htop"<br />
<br />
# Start atop in its own tab.<br />
qdbus-qt4 org.kde.yakuake /yakuake/sessions org.kde.yakuake.addSession<br />
qdbus-qt4 org.kde.yakuake /yakuake/tabs setTabTitle 2 "atop"<br />
qdbus-qt4 org.kde.yakuake /yakuake/sessions runCommandInTerminal 2 "atop"<br />
<br />
# Start (watching) iptables in its own tab.<br />
qdbus-qt4 org.kde.yakuake /yakuake/sessions org.kde.yakuake.addSession<br />
qdbus-qt4 org.kde.yakuake /yakuake/tabs setTabTitle 3 "iptables -nvL"<br />
qdbus-qt4 org.kde.yakuake /yakuake/sessions runCommandInTerminal 3 "~/.iptables.sh"<br />
<br />
# Start journalctl --follow --full in its own tab.<br />
qdbus-qt4 org.kde.yakuake /yakuake/sessions org.kde.yakuake.addSession<br />
qdbus-qt4 org.kde.yakuake /yakuake/tabs setTabTitle 4 "journalctl"<br />
qdbus-qt4 org.kde.yakuake /yakuake/sessions runCommandInTerminal 4 "journalctl --follow --full"<br />
<br />
# Start irssi in its own tab.<br />
qdbus-qt4 org.kde.yakuake /yakuake/sessions org.kde.yakuake.addSession<br />
qdbus-qt4 org.kde.yakuake /yakuake/tabs setTabTitle 5 "irssi"<br />
qdbus-qt4 org.kde.yakuake /yakuake/sessions runCommandInTerminal 5 "irssi"<br />
<br />
# Start root shell 1 in its own tab.<br />
qdbus-qt4 org.kde.yakuake /yakuake/sessions org.kde.yakuake.addSession<br />
qdbus-qt4 org.kde.yakuake /yakuake/tabs setTabTitle 6 "rootshell0"<br />
qdbus-qt4 org.kde.yakuake /yakuake/sessions runCommandInTerminal 6 "sudo -i"<br />
<br />
# Start root shell 2 in its own tab.<br />
qdbus-qt4 org.kde.yakuake /yakuake/sessions org.kde.yakuake.addSession<br />
qdbus-qt4 org.kde.yakuake /yakuake/tabs setTabTitle 7 "rootshell1"<br />
qdbus-qt4 org.kde.yakuake /yakuake/sessions runCommandInTerminal 7 "sudo -i"<br />
<br />
# Start shell 1 in its own tab.<br />
qdbus-qt4 org.kde.yakuake /yakuake/sessions org.kde.yakuake.addSession<br />
qdbus-qt4 org.kde.yakuake /yakuake/tabs setTabTitle 8 "shell0"<br />
<br />
# Start shell 2 in its own tab.<br />
qdbus-qt4 org.kde.yakuake /yakuake/sessions org.kde.yakuake.addSession<br />
qdbus-qt4 org.kde.yakuake /yakuake/tabs setTabTitle 9 "shell1"<br />
<br />
# Kill default (and now redundant) new shell tab. Already there are two shells each opened for both root and user.<br />
qdbus-qt4 org.kde.yakuake /yakuake/sessions org.kde.yakuake.removeSession 10</nowiki>}}</div>Tuxsavvyhttps://wiki.archlinux.org/index.php?title=Talk:Guake&diff=303111Talk:Guake2014-03-04T02:13:16Z<p>Tuxsavvy: Added suggestions based on Fengchao's summary comments on the guake (main) page.</p>
<hr />
<div>: Autostarting up guake with user defined session (multiple tabs)<br />
:: I found some guides on making guake autostart with user defined session. What I meant by that is if I were to start guake via some shell script, it will start guake with all the tabs and programs in each specific tabs that I want.<br />
:: The two sites below refers to what I am referring to:<br />
::* http://askubuntu.com/a/364731 (Although this only provides a skeletal setup of what is needed.)<br />
::* https://github.com/Guake/guake/issues/198#issuecomment-21340679 (This gives a clearer setup but it still does not work well with guake 0.4.4.)<br />
:: Based on these two links I have furthermore modified their setup into my own (this is only a rough guide):<br />
:: #!/bin/bash<br />
:: /usr/bin/guake &<br />
:: sleep 5<br />
::<br />
:: guake --rename-tab="iotop" --execute="/usr/bin/iotop"<br />
::<br />
:: guake --new-tab --execute="/usr/bin/bash"<br />
:: guake --execute="/usr/bin/htop" --rename-tab="htop"<br />
::<br />
:: guake --new-tab --execute="/usr/bin/bash"<br />
:: guake --execute="/usr/bin/atop" --rename-tab="atop"<br />
::<br />
:: guake --new-tab --execute="/usr/bin/bash"<br />
:: guake --execute="~/.iptables.sh" --rename-tab="iptables -nvL"<br />
::<br />
:: guake --new-tab --execute="/usr/bin/bash"<br />
:: guake --execute="/usr/bin/journalctl --follow --full" --rename-tab="journalctl"<br />
::<br />
:: guake --new-tab --execute="/usr/bin/bash"<br />
:: guake --execute="/usr/bin/irssi" --rename-tab="irssi"<br />
::<br />
:: guake --new-tab --execute="/usr/bin/bash"<br />
:: guake --execute="/usr/bin/sudo -i" --rename-tab="rootshell0"<br />
::<br />
:: guake --new-tab --execute="/usr/bin/bash"<br />
:: guake --execute="/usr/bin/sudo -i" --rename-tab="rootshell1"<br />
::<br />
:: guake --new-tab --execute="/usr/bin/bash" <br />
:: guake --rename-tab="shell0"<br />
::<br />
:: guake --new-tab --execute="/usr/bin/bash"<br />
:: guake --rename-tab="shell1"<br />
::<br />
:: Based on this setup, it worked flawlessly on guake 0.4.4 with the settings that I desired. <br />
: Disabling autorenaming of tabs from guake.<br />
:: This was something that I like when I was using yakuake and especially on KDE. The following link provides insight on how to disable autorenaming and yet combined with my suggestion above (for autostarting guake with user defined tabs) it works great:<br />
:: http://askubuntu.com/a/255958<br />
: Final remarks.<br />
::* I believe these two suggestions once approved should be moved into the main page of guake on Archwiki as they may help others.<br />
::* My BASH script above is not a direct representation of my setup as exactly as worded, however with one adjusting to their own preferences the script should work with guake 0.4.4.<br />
::* These suggestions were somewhat based on my desires for guake to mimick my setup in yakuake. <br />
[[User:Tuxsavvy|Tuxsavvy]] ([[User talk:Tuxsavvy|talk]]) 02:13, 4 March 2014 (UTC)Tuxsavvy</div>Tuxsavvy