On Mon, Feb 23, 2015 at 07:56:50AM -0800, Andrew Lutomirski wrote: > On Mon, Feb 23, 2015 at 7:43 AM, Lennart Poettering > <mzerqung@xxxxxxxxxxx> wrote: > > On Mon, 23.02.15 08:45, Nico Kadel-Garcia (nkadel@xxxxxxxxx) wrote: > > > >> > Hey! Come on. Everything that systemd does is create a symlink for > >> > /etc/resolv.conf if nothing else has created on for that. If something > >> > else created and owned that file, it leaves the thing alone. That's > >> > all. It's very defensively written. Anaconda's file copy routine > >> > tripped up on it though, since it follows symlinks on the destination > >> > (which is a really bad idea, and needs to be fixed). > >> > >> You do not know, and cannot know in advance without testing, how many > >> different systems might manipulate or rely on specific resolv.conf > >> changes. > > > > You know, that systemd creates a symlink if the file is missing is not > > going to change behaviour of anything, since it will only do something > > if the file is *missing*. And it won#t be missing if anaconda copies > > in its stuff as it currently does. I mean, the issue is really about > > this copy routine being broken, and not about systemd having a > > fallback logic to create /etc/resolv.conf if it is missing. > > > > If anaconda's file copy routine would not be confused by symlinks in > > the destination, the issue goes away entirely: it would create its > > file, and systemd's /etc/resolv.conf logic would never touch anything > > anymore. > > As a bystander, I'm lost here. > > Systemd made a change. I'm not sure what the change is. Previously all sources which could provide a list of dns server would fight over /etc/resolv.conf. This includes: explicit configuration by the admin, dhcplient, NetworkManager, systemd-resolved, local dns servers. Additional issue is that the list of dns servers is inherently dynamic, which conflicts with read-only root filesystem. The change: various provides of resolv.conf contents create files in temporary storage (under /run), and the administrator symlinks to the one he or she wants to be used. > Anaconda is supposedly confused by destination/etc/resolv.conf being a > symlink. What is anaconda *supposed* to do? Options seem to include: > > 1. Do nothing. > 2. Delete the symlink and replace it. > 3. Follow the symlink, delete the target, and replace it. > 4. Follow the symlink and overwrite the target. Anaconda should do 2. It can either provide a static file, or it can replace the symlink with a symlink of its own choosing. For example, it could symlink to the resolv.conf file provided by NetworkManager if NetworkManager is being installed in the system. It shouldn't do 1., because that would result in broken network, and it shouldn't do 3 or 4 because the target of the symlink is systemd-resolved territory. > Knowing little about what systemd is doing here, I would argue for > (1). If it's a symlink, then presumably something manages whatever > the symlink points to. > > OTOH, this is *anaconda* we're talking about. Maybe it should do > whatever it needs to do to make the installed Fedora system happy, > whatever that is. Yes, anaconda is installing the system, and knows how the network is supposed to set up. It should set /etc/resolv.conf accordingly. Zbyszek -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
