Talk:Network configuration

From ArchWiki
Revision as of 00:15, 11 February 2015 by Kynikos (talk | contribs) (leave a temporary reference to the destination after moving a discussion, so that interested users don't have to look at the history to understand what happened)
Jump to: navigation, search

IP address aliasing with netctl

Configuration presented here isn't working. —This unsigned comment is by Xcfw (talk) 13:33, 17 September 2013‎. Please sign your posts with ~~~~!

Static network service

I've found the current service convoluted, so tried to improve it. [1]:

  • EnvironmentFile= passes all arguments to ExecStart= and ExecStop=, so single bash scripts can be used instead of multiple Exec lines and sh -c (see man systemd.service and man systemd.exec). This makes it easier to change the ip logic, if needed.
  • The IP addresses were made consistent throughout Network configuration#Static IP address.
  • The configuration file was renamed to net-conf-interface, as the special character @ has no meaning there (avoiding unnecessary escaping).

Tested on my current install and it works without issue. -- Alad (talk) 01:04, 25 August 2014 (UTC)

I think it's a matter of preference to use scripts or not. Surely is easier when you expect to change logic, test commands, run other commands right after, etc. Ive renamed the section; think "udev rules" was a relict. Then I've added crosslinks between the wireless example unit and this section, good to have both methods and spell them out because net connectivity is crucial. Sidenote: Your approach made me wonder, if we should not have a basic section about sourcing scripts in Systemd#Writing_custom_.service_files. This talk indicates that as well. --Indigo (talk) 19:59, 25 August 2014 (UTC)
Good work, and I agree to expand on sourcing scripts. This may also help users familiar with bash scripts for the boot process. -- Alad (talk) 01:36, 1 September 2014 (UTC)
There is something strange about the current service file - the service will execute at boot, but the network may stay down; see [2]. Adapting [Unit] from systemd-networkd.service seems to make it work properly (bold parts are additions):
[Unit]
Description=Network connectivity (%i)
ConditionCapability=CAP_NET_ADMIN
DefaultDependencies=no
BindsTo=sys-subsystem-net-devices-%i.device
After=network-pre.target sys-subsystem-net-devices-%i.device
Before=network.target multi-user.target shutdown.target
Conflicts=shutdown.target
Wants=network.target
Maybe someone could confirm this... -- Alad (talk) 01:36, 1 September 2014 (UTC)

Hostname resolution

I feel that there is more to this edit: the linked Debian documentation mentions that aliasing 127.0.1.1 to the hostname is "a workaround for some software (e.g., GNOME)". I have also found this post, which says "In the long run the UNIX hostname should not be put in /etc/hosts at all."

So, is aliasing 127.0.1.1 (or the permanent IP address) really necessary on Arch, and in which cases?

-- Lahwaacz (talk) 08:48, 8 November 2014 (UTC)

I've also found https://lists.debian.org/debian-devel/2013/07/msg00809.html
I vote for reverting that edit (and the same on the Beginners' guide). I don't use a line like that in my /etc/hosts and have no problems at all, and if it's a workaround for bugs in some applications, it should be mentioned in their wiki articles, with a link to the upstream bug report.
-- Kynikos (talk) 02:25, 9 November 2014 (UTC)
I undid the BG edit with [3] and the one in this article with [4] for now. Then added the work-around again with [5]. Please add to it, e.g. the bug report or also [6] (quoted in the edit) may be helpful.
Yet, I think it was a good edit/suggestion, even if it is a work-around for some environments only, and don't know how it could be problematic for users to add the alias. I suggest we keep this open to get more feedback. --Indigo (talk) 10:36, 9 November 2014 (UTC)
I just remembered this edit, which (re-)introduced setting the hostname in /etc/hosts. The edit summary leads to [7] which then leads to some real world examples. Anyway, the wiki should say why this is important (more verbosely than "to avoid slowdowns of some programs"), possibly using the bbs post as a reference.
It also removed a note saying "You no longer need to edit /etc/hosts, systemd will provide host name resolution. ...", which could still be relevant in the complementary cases. How does systemd fit in here? Is hostnamectl more than just a tool to "query and change the system hostname"?
I have not set the hostname in /etc/hosts and never experienced any slowdowns (most likely because I have not used any of the affected programs), which is why I think that setting hostname in /etc/hosts is just a (common) workaround for the programs that I don't use. And yes, more feedback would definitely be welcome.
-- Lahwaacz (talk) 11:56, 9 November 2014 (UTC)
There's another recent forum thread about this [8]. Edit: [9]. -- Alad (talk) 17:29, 22 November 2014 (UTC)
This is handled by nss_myhostname these days. It's likely that the users with problems didn't merge an nss pacnew file or are using an unsupported setup without systemd. -- thestinger 01:31, 25 December 2014 (UTC)
I replaced these instructions with a note because it's the official stance of the distribution. The myhostname module is included in /etc/nsswitch.conf which is provided by the filesystem package. A system without this library installed is not supported. It's possible that the library is buggy, but bugs should be reported on our tracker or upstream. -- thestinger 01:39, 25 December 2014 (UTC)
I am happy with the current version, as long as we keep the link down to Network configuration#Local network hostname resolution and keep the workaround with /etc/hosts, added with [10].
See one of now removed BBS links is about Firefox/Thunderbird. These are exactly the kind of applications that might create the problem with slowdown/not resolving, and there is a reason for it as well: They need to control hostname resolution very tight, but might also have proprietary dns-cache to speed resolution. On top some apps/services have their own online/offline network switches and the logic must work for localhost as well. All this is considered in this mozilla bug, which took them 12 years to resolve (in 2013; and of course there is no single mention of systemd/nsswitch in there). Now when they resolved, you can read ".. That is, we can't restrict a lookup to only the hosts file (where localhost and other locally defined names are configured). An attempted lookup that doesn't resolve in the hosts file would try to hit the network." (comment 55), which (a) indeed indicates they still do rely on the hosts file and (b) the efforts to keep their (important) offline feature clean.
The above long para to explain why we should keep mentioning the hosts workaround in Network configuration#Local network hostname resolution (and add particularly relevant bug reports/bbs threads there; edit: [11]). Close this? Other opinions/ideas how to handle it? --Indigo (talk) 08:43, 25 December 2014 (UTC)
I've recently had the same issue with Thunderbird and Firefox, with systemd installed. Restored the workaround in the BG [12], closing. -- Alad (talk) 13:40, 7 January 2015 (UTC)

Systemd-networkd

[Moved to Talk:Systemd-networkd#Static_IP_example_for_single_host]