| View previous topic :: View next topic |
| Author |
Message |
Skirmitch
Apprentice
Joined: 15 Jun 2013
Posts: 207
|
 Posted: Sat Feb 11, 2017 12:32 am Post subject: [SOLVED] Resolv.conf being blank written |
 |
|
Hey guys, after an update some months ago, I got a problem with my net:
As soon as I connect, everything is fine, perfect and the resolv.conf gets written by who knows who but with the correct DNS servers but after 1 min or so, NetworkManager replaces it with a blank one, I know its NetworkManager cuz it leaves its signature and I have to replace the blank resolv.conf with the one that it was before. That goes EVERY time I connect or disconnect and on every network, first it gets it perfectly and after a minute it ereases it. Does anybody know whats going on and how to fix it? Maybe a temporary fix would be to not allow Networkmanager to write it in the first place but dunno how to do that and it wont work in other networks.
///////////////////////////////////////////// EDIT /////////////////////////////////////////
As the topic is getting too long and technical for some users, if you r having this issue and want a solution but dont understand that much about Linux, the solutions exposed here (that anyone could understand) were basically 2:
1.- Prevent dhcpcd from touching your resolv.conf file by adding a line with to the file
1.b.- Alternatively, you could just create the file | Code: | | /etc/resolv.conf.head |
and/or | Code: | | /etc/resolv.conf.tail |
with the desired configuration and dhcpcd will place the .head file's contents at the beginning of your resolv.conf file and the .tail contents at the end of your resolv.conf file
2.- Using resolvconf to manage the DNS servers. The easiest way to accomplish this is to add the USE variable resolvconf to your | Code: | | /etc/portage/make.conf |
file and then | Code: | | emerge -NDuqa world --backtrack=90 system --deep --newuse --with-bdeps=y --keep-going |
Last edited by Skirmitch on Sun Feb 19, 2017 7:38 pm; edited 3 times in total |
|
| Back to top |
|
 |
Skirmitch
Apprentice
Joined: 15 Jun 2013
Posts: 207
|
| Posted: Sat Feb 11, 2017 12:50 am Post subject: |
|
|
this is the blank file I get, its just that: (Sorry, its not networkmanager the generator, its dhcpcd)
# Generated by dhcpcd
# /etc/resolv.conf.head can replace this line
# /etc/resolv.conf.tail can replace this line |
|
| Back to top |
|
|
The Doctor
Moderator
Joined: 27 Jul 2010
Posts: 2678
|
| Posted: Sat Feb 11, 2017 12:57 am Post subject: |
|
|
Sometimes dhcpcd can be a bit of a pain. However, you file tells you the solution: | Quote: | | # /etc/resolv.conf.head can replace this line |
put the correct nameserver here. Often the path of least resistance is the best one.
_________________
First things first, but not necessarily in that order.
Apologies if I take a while to respond. I'm currently working on the dematerialization circuit for my blue box. |
|
| Back to top |
|
|
Skirmitch
Apprentice
Joined: 15 Jun 2013
Posts: 207
|
| Posted: Sat Feb 11, 2017 4:04 am Post subject: |
|
|
| The Doctor wrote: | Sometimes dhcpcd can be a bit of a pain. However, you file tells you the solution: | Quote: | | # /etc/resolv.conf.head can replace this line |
put the correct nameserver here. Often the path of least resistance is the best one. |
Shame on me, how is it possible that I didnt see that.... In all my raging I just didnt see it.... shame on me. I used this in the .head file and working flawlessly now:
| Code: | # Generated by NetworkManager
nameserver 200.30.192.14
nameserver 200.83.1.4
nameserver 190.160.0.11
# Google
nameserver 8.8.4.4
nameserver 8.8.8.8
# Named
#nameserver 127.0.0.1
# OpenDNS
nameserver 208.67.222.222
nameserver 208.67.222.220
options rotate
#options single-request
#options timeout:1
|
If u have any suggestion on modifications I would happily receive them. Thanks again and well, lets see if someone comes with an answer to actually stop the problem |
|
| Back to top |
|
|
Ant P.
Watchman
Joined: 18 Apr 2009
Posts: 6920
|
| Posted: Sat Feb 11, 2017 10:08 pm Post subject: |
|
|
| man 8 dhcpcd wrote: | | Code: |
-C, --nohook script
Don't run this hook script. Matches full name, or prefixed with
2 numbers optionally ending with .sh.
So to stop dhcpcd from touching your DNS settings you would do:-
dhcpcd -C resolv.conf eth0
|
|
|
|
| Back to top |
|
|
Skirmitch
Apprentice
Joined: 15 Jun 2013
Posts: 207
|
| Posted: Sun Feb 12, 2017 12:17 am Post subject: |
|
|
| Ant P. wrote: | | man 8 dhcpcd wrote: | | Code: |
-C, --nohook script
Don't run this hook script. Matches full name, or prefixed with
2 numbers optionally ending with .sh.
So to stop dhcpcd from touching your DNS settings you would do:-
dhcpcd -C resolv.conf eth0
|
|
|
Oh, nice one, in order to do that I would have to append that to every call of dhcpcd? Means I would have to edit the systemctl script? Is that correct? |
|
| Back to top |
|
|
Roman_Gruber
Advocate
Joined: 03 Oct 2006
Posts: 3846
Location: Austro Bavaria
|
| Posted: Sun Feb 12, 2017 12:57 pm Post subject: |
|
|
[Moderator note: although Roman acknowledges this to be a dirty hack, it should be noted that most of this advice is questionable. Readers are advised to read the counterarguments in subsequent posts before executing any of the changes in this post. -Hu]
A dirty hack is. And please do not comment after htis post, this is not recommended, bad practise, whatever. Just DO NOT!
Some network related scripts shipped by gentoo do not care for write protections. Which is just very evil! After my dirty hack, you will see the following but no more changes to resolv.conf
Root cause, evil dhcpcd package:
| Code: | ASUS-G75VW roman # /etc/init.d/dhcpcd restart
* Stopping DHCP Client Daemon ... [ ok ]
* Starting DHCP Client Daemon ...
/lib/dhcpcd/dhcpcd-run-hooks: line 144: /etc/resolv.conf: Operation not permitted
chmod: changing permissions of '/etc/resolv.conf': Operation not permitted |
set up
I recommend that you switch the order there
I recommend that you set trustworthy servers
I recommend that you set up a banlist there for known evil hosts and domains
Important!
| Code: | chattr +i /etc/resolv.conf
|
--
| Quote: | | Does anybody know whats going on and how to fix it? |
Fix above.
Root cause developers who think they are smarter as the administrator, or know it better for every use-case, who have set up config files in /etc
I do not want to patch dhcpcd.
I still remember the days where resolv.conf had to be set up by root the first time.
--
When you want a change, file a bug at bugs.gentoo.org. I expect it will be turned invalid for 90 percent. |
|
| Back to top |
|
|
khayyam
Watchman
Joined: 07 Jun 2012
Posts: 6227
Location: Room 101
|
| Posted: Sun Feb 12, 2017 2:07 pm Post subject: |
|
|
Roman_Gruber ...
and so having dhcpcd not alter /etc/reslov.conf isn't going to work? Practically every post you make is either incorrect, convoluted, or shows you're not reading the thread.
@Skirmitch ... the following should cover it:
| /etc/dhcpcd.conf: | | nohook resolv.conf |
best ... khay |
|
| Back to top |
|
|
Logicien
Veteran
Joined: 16 Sep 2005
Posts: 1555
Location: Montréal
|
| Posted: Sun Feb 12, 2017 4:50 pm Post subject: |
|
|
It can be a pain to change the permissions to allow a non root user to use NetworkManager. This have been seen a lot in several Linux distributions including intuitive ones.
NetworkManager erase in /etc/resolv.conf the Dns Ip addresses provided by the Dhcp server using Dhcpcd what Dhcpcd do not do by itself with it's default configuration. This should be resolv at the NetworkManager level by looking to the Dhcpcd options NetworkManager use to start Dhcpcd with help of the ps command and make the needed changes to NetworkManager configuration if possible. It would be better than a workaround.
It's just an idea, I do not use NetworkManager. I prefer non graphic but transparent network utilities.
_________________
Paul
Last edited by Logicien on Sun Feb 12, 2017 5:42 pm; edited 3 times in total |
|
| Back to top |
|
|
Hu
Moderator
Joined: 06 Mar 2007
Posts: 21631
|
| Posted: Sun Feb 12, 2017 5:32 pm Post subject: |
|
|
| Roman_Gruber wrote: | | A dirty hack is. And please do not comment after htis post, this is not recommended, bad practise, whatever. Just DO NOT! |
Very well. I will instead put that note at the top of your post, then use my post to debate the merits without specifically calling your advice bad practice. 
| Roman_Gruber wrote: | | Some network related scripts shipped by gentoo do not care for write protections. Which is just very evil! After my dirty hack, you will see the following but no more changes to resolv.conf |
What type of write protection did you try previously? Recall that standard Linux permissions allow root processes to ignore DAC write permissions: | Code: | # touch abc
# chmod 400 abc
# echo def > abc
# cat abc
def
# capsh --drop=cap_dac_override -- -c /bin/bash
# echo xyz > abc
bash: abc: Permission denied
|
| Code: | $ touch abc
$ chmod 400 abc
$ echo def > abc
-bash: abc: Permission denied
|
This is not specifically a failing of dhcpcd or any other package. Any root process that keeps CAP_DAC_OVERRIDE will do this. Any process that does not go out of its way to eliminate this capability will have it, unless the init system specifically strips it first.
| Roman_Gruber wrote: | set up
I recommend that you switch the order there
|
What order do you recommend be used? Why is that better than the default?
| Roman_Gruber wrote: | | I recommend that you set trustworthy servers |
What if OP normally gets DNS servers from his administrator, who may from time to time change the IPs of those servers and use DHCP to distribute the new IPs? What if OP has a habit of associating to other networks (such as wireless hotspots in businesses) that require use of their own name server?
| Roman_Gruber wrote: | | I recommend that you set up a banlist there for known evil hosts and domains |
This is a bad idea. Domains cannot be blocked here. There are too many bad hosts to list, and the list changes frequently. If a ban list is required at all, this is not the way to implement it.
| Roman_Gruber wrote: | Important! | Code: | | chattr +i /etc/resolv.conf |
|
I know what this does, but will users who read your advice know it and understand the consequences? If not, you should explain to them what this does. In my opinion, this should not be done at all. Instead, the solution proposed by khayyam should be tried. If for some reason khayyam's solution does not work, a similar solution based on that principle is still preferable to rendering the file immutable.
| Roman_Gruber wrote: | | Root cause developers who think they are smarter as the administrator, or know it better for every use-case, who have set up config files in /etc |
Citation needed, please. As above, ignoring the DAC is a (questionable) feature of being root, not an automatic decision deliberately made by the authors of dhcpcd. |
|
| Back to top |
|
|
Zucca
Moderator
Joined: 14 Jun 2007
Posts: 3343
Location: Rasi, Finland
|
| Posted: Sun Feb 12, 2017 6:04 pm Post subject: |
|
|
I created resolv.conf.head and added my server ip address as a nameserver.
Is the bug in dhcpcd or somewhere else (systemd)?
I do not want to stumble into this on my server too...
_________________
..: Zucca :..
Gentoo IRC channels reside on Libera.Chat.
--
| Quote: | | I am NaN! I am a man! |
|
|
| Back to top |
|
|
Ant P.
Watchman
Joined: 18 Apr 2009
Posts: 6920
|
| Posted: Sun Feb 12, 2017 7:50 pm Post subject: |
|
|
| Skirmitch wrote: | | Ant P. wrote: | | man 8 dhcpcd wrote: | | Code: |
-C, --nohook script
Don't run this hook script. Matches full name, or prefixed with
2 numbers optionally ending with .sh.
So to stop dhcpcd from touching your DNS settings you would do:-
dhcpcd -C resolv.conf eth0
|
|
|
Oh, nice one, in order to do that I would have to append that to every call of dhcpcd? Means I would have to edit the systemctl script? Is that correct? |
You can put it in dhcpcd.conf(5) too. |
|
| Back to top |
|
|
Skirmitch
Apprentice
Joined: 15 Jun 2013
Posts: 207
|
| Posted: Mon Feb 13, 2017 12:33 am Post subject: |
|
|
| Zucca wrote: | I created resolv.conf.head and added my server ip address as a nameserver.
Is the bug in dhcpcd or somewhere else (systemd)?
I do not want to stumble into this on my server too... |
I too added the config in the .head file although it would be awesome to know the root of this and how to fix the root itself. I just added the options in /etc/dhcpcd.conf as well just in case that solves the original issue but, again, since I created the .head file, my | Code: | | cat /home/skirmitch/resolv.conf >> /etc/resolv.conf |
routine every now and then has been terminated for good (I even thought on making a cron run this line of code every now and then rofl) |
|
| Back to top |
|
|
Skirmitch
Apprentice
Joined: 15 Jun 2013
Posts: 207
|
| Posted: Mon Feb 13, 2017 2:04 am Post subject: |
|
|
| Quote: | | What if OP normally gets DNS servers from his administrator, who may from time to time change the IPs of those servers and use DHCP to distribute the new IPs? What if OP has a habit of associating to other networks (such as wireless hotspots in businesses) that require use of their own name server? |
Thats exactly my case and its precisely why I insist on asking if anyone knows how to fix the issue without using the .head file. I already did the modification on /etc/dhcpcd.conf so we'll see if that fixes it (lets networkmanager write the correct nameservers and then not override it with a blank file) |
|
| Back to top |
|
|
UberLord
Retired Dev
Joined: 18 Sep 2003
Posts: 6835
Location: Blighty
|
| Posted: Fri Feb 17, 2017 8:37 pm Post subject: |
|
|
DISCLAIMER: I'm the dhcpcd author.
If dhcpcd writes a blank resolv.conf file, then it thinks there are no dhcp servers in the DHCP lease.
This can be perfectly normal - a blank resolv.conf means that the localhost is expected to run a recursive resolver.
To check the contents of the lease, do this
Replace eth0 with your interface name.
Look for domain_name and domain_name_servers - if you don't see them, there are none and dhcpcd did as it was instructed.
Anyway, I really do recommend installing a resolvconf based tool to manage this - dhcpcd will use it.
I recommend resolvconf.
You can then use resolvconf.conf(5) to tailor your specific needs.
Most network based programs should support resolvconf ..... even if a little badly.
_________________
Use dhcpcd for all your automated network configuration needs
Use dhcpcd-ui (GTK+/Qt) as your System Tray Network tool |
|
| Back to top |
|
|
Skirmitch
Apprentice
Joined: 15 Jun 2013
Posts: 207
|
| Posted: Sat Feb 18, 2017 12:21 am Post subject: |
|
|
Hey dude, thanks for replying. Well that's not the case (the network failure) since it happens on every network: Networkmanager generates a correct file and after a few seconds, dhcpcd overwrites it with a blank one.
Trying your solution of the resolveconf app, added the USE globally and will see what happens.
BTW, I did run the command you gave me anyway just in case (although I knew the problem was not related to a specific network) and got this error. Maybe it has to do with the problem itself?
| Code: | skirmitch # dhcpcd -U4 wlp3s0
wlp3s0: dhcp_dump: No such file or directory
|
|
|
| Back to top |
|
|
Skirmitch
Apprentice
Joined: 15 Jun 2013
Posts: 207
|
| Posted: Sun Feb 19, 2017 12:50 am Post subject: |
|
|
| Everything fixed with resolvconf, Greetings and thanks. |
|
| Back to top |
|
|
Roman_Gruber
Advocate
Joined: 03 Oct 2006
Posts: 3846
Location: Austro Bavaria
|
| Posted: Sun Feb 19, 2017 2:01 pm Post subject: |
|
|
| UberLord wrote: |
Anyway, I really do recommend installing a resolvconf based tool to manage this - dhcpcd will use it.
I recommend resolvconf.
|
Are you talking about this package or something else please?
| Code: | * net-dns/openresolv
Latest version available: 3.8.1
Latest version installed: [ Not Installed ]
Size of files: 18 KiB
Homepage: http://roy.marples.name/projects/openresolv
Description: A framework for managing DNS information
License: BSD-2
|
|
|
| Back to top |
|
|
Roman_Gruber
Advocate
Joined: 03 Oct 2006
Posts: 3846
Location: Austro Bavaria
|
| Posted: Sun Feb 19, 2017 2:26 pm Post subject: |
|
|
Feel free to provide me a working solution where DHCPCD do not use / overwrite resolv.conf
I have my reason why I need my own servers in that list (which I will not discuss here at all)
I do remember the "old" days where I had to set up resolv.conf and everythign worked. Was the case for any operating system in that era.
Why should I explain what it does. Man command tells it anyway! I think I explained it in detail what it does. I usually write 50 percent too much words in my posts. That should already state that it is more than sufficent.
I think i gave enough credit for:
a) dirty hack
b) I expect a gentoo user at least use man command (e.g. man chattr) will tell enough
c) I'm not the author of that dirty hack. I reused it from someone else because that person also had the same issues.
d) Overwriting config files is in general not a good behaviour. I'm forced to use chattr because the tool does not respect my will as owner of my box on how to set up dhcpcd. The root configured files should always have top priority before the will of some developers.
Rant: I do not think it is a good idea to let a tool just replace that config file in the first place. My solution: leave resolv.conf as is. when it does not exists, dhcpcd should generate another file which provides the contents of the overwritten resolv.conf wihtout touching resolv.conf. if resolv.conf exists, dhcpcd should not even dare to touch, change rules / contents / behaviour for resolv.conf
e) The developers speak with their code. / design of code / beahviour of that code
e.g. linux mint overwrites critical components so a box is rendered unbootable (coding fault)
windows does the same regarding critical components (I wonder why linux mint did that!)
dhcpcd is one of many "broken" tools in the portage tree. It may work for many, but not for everyone.
f) you are welcome to critize me. But i already stated
DIRTY hack (first warning)
and other warnings that this is not supposed to be used that way
when you critize me, than you have to show me a way to do things so it works in my use case.
AGAIN, i'll not discuss why I can't use those provided servers from my network node.
| Quote: |
What order do you recommend be used? Why is that better than the default? |
I gave more content / information so an intersted user can set up the hole thing, not only a part of it
When you want to use my way, you may have also to change those other files, like I did because of some odd behaviour of some "software". Sadly those tools do not only use one config file, no they use several config files and software components which makes things more complicated as they should be, or could be (again warning htis is my personal opinion).
There is not something better. There may be something better for a person, but there is no generic rule for beeing something better. So the question is just something to flame someone. wrong phrasing.
| Quote: | | What if OP normally gets DNS servers from his administrator, who may from time to time change the IPs of those servers and use DHCP to distribute the new IPs? What if OP has a habit of associating to other networks (such as wireless hotspots in businesses) that require use of their own name server? |
Not sure if you are trolling myself?
I do not wnat to explain the hole thing how it works. Therefore I want to refer to the corresponding IEEE standards. Anythign else is just interpredation.
| Quote: | | Thats totally off topic: that require use of their own name server? |
If so you can temporarily move resolv.conf and let dhcpcd do its job. Which is not recommended in my use case.
| Quote: | | change the IPs of those servers |
Thats exactly the point. Can you trust those new servers?
Dhcpcd changes it itself without hte user noticing it. ....
I hope you get my point.
My box, I want it to be as secure as possible. When the binding changes, I have to look up what happened and can check if there is a bad neighbour around by now.
| Quote: | | This is a bad idea. Domains cannot be blocked here. There are too many bad hosts to list, and the list changes frequently. If a ban list is required at all, this is not the way to implement it. |
Oh really?
And how comes that I do not see the nasty advertisments. those harmful servers?
I only see them once, than they have a new entry.
| Quote: | | too many bad hosts to list |
And thats the reason to say its impossible?
list anything which ends in *.eu *.online
| Quote: | | If a ban list is required at all, this is not the way to implement it. |
According to the standards it is.
And it works because I changed those files provided in that way so it is respeced and works as it should. E.g dowload SUSE 6.2 readhat 7.x and try it out when you doubt it
Old linux distro isos worked that way. No idea why guys do not stick to the standard, like FHS, network and such! Thats another topic.
| Quote: | | way to implement it. |
So may I ask how? What is the proper way? I also want to ask for full config files in this regard than on ~amd64 please for classical setup => openrc / eudev <= not that SYSTEMD + / or kde / gnome madness (that is some other fashion of linux in my eyes)
Even windows used the host file. Not sure on recent windows, as I do not use Wald Disneys Mickysoft anymore.
| Quote: | | I know what this does, but will users who read your advice know it and understand the consequences? If not, you should explain to them what this does. |
Or they could ask me what it does after they took their time understanding these advanced principles.
I expect that gentoo users, are not kids. Therefore i can expect the common knowledge of googling something, using a manpage.
I like to quote myself: I'm not the author. I understood what it does. I know how those scripts should have worked and because there is in my eyes a "bug" i fixed it the hard way. Refusing permissions to dhcpcd for that config file.
I would not have written that in an ubuntu forum because of the audience there! Gentoo needs some knowledge, and therefore I can expect the knowledge of CLI, using commands and such. And reading wiki / asking. When someone has a driver license for example I can expect some sort of behaviour. When a user uses gentoo, I can assume some knowledge. therefore this statement is just trolling, just picking a very rare case. Guys who can not argue, always pick the rare case. if things were designed for the rare case I would not have to fix anything. But things are designed for the common audience, not fore the single stone in a sandy beach. 1 in infinite! I do not know any technical device / software which consideres every rare case which can happen. if so show me and i am quite sure someone will find a flaw quite soon. do not put hamsters in a microwave
| Quote: | | Citation needed, please. As above, ignoring the DAC is a (questionable) feature of being root, not an automatic decision deliberately made by the authors of dhcpcd. |
Can you please explain me "not an automatic decision" ? When the software called dhcpcd overwrties a config file,
a) automated. it is a script. it does something. it overwrote my config file. so its automated.
b) decision to code dhcpcd by he author
c) i assume the author of that package is the author. If not I assume a human beeing has coded it and therefore there is an author anyway
what is a DAC? it is good practise to write the first time what it means and later just use the short version. thanks
I do not write a book so that i need a citation
And i gave above my statement why it is anyway.
That the software maybe not useful for every case is fact. But i do not ride that magical hat, the rare case in many cases.
I citated the behaviour of the gentoo packed package. No need to go any more in details. do i?
i gave also decent example what the consequences are. Why I changed it.
And big warning, note dirty hack. Some areas of the world need stickers, do not put hamsters in microwaves... (sarcasm) other parts of the world do not need that, I wonder why
| Quote: | | the list changes frequently |
nope. the list expands. no bad host will be ever considered a good host again. thats a paradoxon.
the list does also not care for duplicate entries, tehy are duplicates and all refer to the same localhost. |
|
| Back to top |
|
|
UberLord
Retired Dev
Joined: 18 Sep 2003
Posts: 6835
Location: Blighty
|
| Posted: Sun Feb 19, 2017 3:29 pm Post subject: |
|
|
| Roman_Gruber wrote: | | UberLord wrote: |
Anyway, I really do recommend installing a resolvconf based tool to manage this - dhcpcd will use it.
I recommend resolvconf.
|
Are you talking about this package or something else please?
| Code: | * net-dns/openresolv
Latest version available: 3.8.1
Latest version installed: [ Not Installed ]
Size of files: 18 KiB
Homepage: http://roy.marples.name/projects/openresolv
Description: A framework for managing DNS information
License: BSD-2
|
|
Yes, openresolv is a good resolvconf implementation I maintain.
_________________
Use dhcpcd for all your automated network configuration needs
Use dhcpcd-ui (GTK+/Qt) as your System Tray Network tool |
|
| Back to top |
|
|
UberLord
Retired Dev
Joined: 18 Sep 2003
Posts: 6835
Location: Blighty
|
| Posted: Sun Feb 19, 2017 3:53 pm Post subject: |
|
|
| Roman_Gruber wrote: | d) Overwriting config files is in general not a good behaviour. I'm forced to use chattr because the tool does not respect my will as owner of my box on how to set up dhcpcd. The root configured files should always have top priority before the will of some developers.
Rant: I do not think it is a good idea to let a tool just replace that config file in the first place. My solution: leave resolv.conf as is. when it does not exists, dhcpcd should generate another file which provides the contents of the overwritten resolv.conf wihtout touching resolv.conf. if resolv.conf exists, dhcpcd should not even dare to touch, change rules / contents / behaviour for resolv.conf
|
Generally, I agree that overwriting anything in /etc is a bad thing.
However, resolv.conf has always been an exception to this rule, and this predates my involvement with any open source projects.
It is expected for an automated network configuration client to configure address, routes and resolvers so the user has a fully working network.
Sadly, to configure resolvers we need to write to a file in /etc and if we don't do this by default then it's very likely new users won't have a working network which is bad.
Different products have different solutions, but the common ones are:
1) making resolv.conf immutable
2) disabling the products from writing to resolv.conf (this can be tricky)
3) using a middleman, such as resolvconf to manage this
| Quote: |
dhcpcd is one of many "broken" tools in the portage tree. It may work for many, but not for everyone.
|
dhcpcd is not broken at all.
The default dhcpcd.conf will request domain name servers and will run the default hook to write them.
If you don't like it, feel free to edit dhcpcd.conf NOT to do this.
| Quote: |
Dhcpcd changes it itself without hte user noticing it. ....
I hope you get my point.
My box, I want it to be as secure as possible. When the binding changes, I have to look up what happened and can check if there is a bad neighbour around by now.
|
dhcpcd is a DHCP client.
It negotiates with a DHCP server what it's address, routing and DNS should be.
A DHCP server can change these parameters at any point.
If there's a bad neighbor around and you're concerned by this then I suggest an either static confg (ie no DHCP at all) or employ DHCP authentication which dhcpcd supports.
If you want the user to notice, then please install dhcpcd-ui (gtk+ and qt front ends available) then you get a nice tooltip when the binding changes.
| Quote: |
I like to quote myself: I'm not the author. I understood what it does. I know how those scripts should have worked and because there is in my eyes a "bug" i fixed it the hard way. Refusing permissions to dhcpcd for that config file.
|
I am the author. I understand what it does very well and I also understand the needs of Grandma to plug in a usb network stick into her laptop and it just works.
Now, the typical Gentoo user isn't Grandma, but equally well I expect Gentoo users to read the comments in dhcpcd.conf and the fine documentation in dhcpcd( and dhcpcd.conf(5) which explains all of this.
_________________
Use dhcpcd for all your automated network configuration needs
Use dhcpcd-ui (GTK+/Qt) as your System Tray Network tool |
|
| Back to top |
|
|
Hu
Moderator
Joined: 06 Mar 2007
Posts: 21631
|
| Posted: Sun Feb 19, 2017 5:37 pm Post subject: |
|
|
| Roman_Gruber wrote: |
Feel free to provide me a working solution where DHCPCD do not use / overwrite resolv.conf |
Does using --nohook to suppress the resolv.conf update hook not satisfy your requirement?
| Roman_Gruber wrote: | | I have my reason why I need my own servers in that list (which I will not discuss here at all) |
Yes, and some users may have a similar requirement. Others will require that they use whatever their DHCP administrator tells them to use. I object to encouraging users to lock their configuration into one path without knowing that this is the best solution for their problem. Remember that this thread is not only for the benefit of the original poster, but also anyone who finds it, perhaps months or years later, via search engine and decides (whether rightly or not) that their problem is the same as the one described here.
| Roman_Gruber wrote: | | Why should I explain what it does. |
For good or ill, some users will trust that commands posted on the forum have no lasting negative side effects and will run them on faith. I object to giving users commands that change the system in unusual ways when there is a realistic chance the user will run the command, then later wonder why the system no longer works as desired.
| Roman_Gruber wrote: | | b) I expect a gentoo user at least use man command (e.g. man chattr) will tell enough |
Ideally, all users should always read the documentation in full before running any new command and should learn how to undo its effects before doing them in the first place. In practice, even experienced users may not do that, and you cannot assume that only experienced users will read your advice. In particular, when the advice comes from someone with a high post count and no other poster disputes the advice, readers might reasonably assume that the initial advice is good and safe.
| Roman_Gruber wrote: | | c) I'm not the author of that dirty hack. I reused it from someone else because that person also had the same issues. |
I am not concerned about who conceived it first. I am concerned that novices not run it without an understanding of what it does and what consequences they may bring upon themselves by running it.
| Roman_Gruber wrote: | | d) Overwriting config files is in general not a good behaviour. I'm forced to use chattr because the tool does not respect my will as owner of my box on how to set up dhcpcd. The root configured files should always have top priority before the will of some developers. |
I agree that tools ought not change the system administrator's settings. As UberLord described farther down, it is sometimes fuzzy trying to determine whether the administrator wanted the old value of resolv.conf, which is why dhcpcd defaults to changing it (because most people want that) and provides --nohook to disable this for those people who know better than the tool.
| Roman_Gruber wrote: | e) The developers speak with their code. / design of code / beahviour of that code
e.g. linux mint overwrites critical components so a box is rendered unbootable (coding fault) |
I do not see how that is relevant here.
| Roman_Gruber wrote: | f) you are welcome to critize me. But i already stated
DIRTY hack (first warning) |
Yes, but I take the very cautious view that warning users that something is ugly is not the same as warning them that it may cause unwanted side effects they do not understand how to fix.
| Roman_Gruber wrote: | | when you critize me, than you have to show me a way to do things so it works in my use case. |
No, I have to convince readers that they might not want to use your approach because it might be the wrong solution for them. For some people, particularly if they are in a hurry and can satisfy the other assumptions that hold true in your environment, this can be an acceptable workaround. My goal is that neither the original poster, nor users who read this thread later, end up a few months down the line wondering why they cannot modify /etc/resolv.conf by hand even though the permissions look fine. If they want to make it immutable, and they understand how to undo that if they ever find the immutability to be a problem, then they are welcome to do that. I do not want them to need to come back to the forum and have someone work out from the error messages that this happened, nor do I want them to give up and abandon Gentoo because they cannot solve the problem on their own and cannot or will not use the forums to get us to solve it for them.
| Roman_Gruber wrote: | | Quote: | | What order do you recommend be used? Why is that better than the default? |
I gave more content / information so an intersted user can set up the hole thing, not only a part of it
|
My queries were specifically in response to your statement: | Quote: | | I recommend that you switch the order there |
I see nothing around that in your prior post where you suggested what the user should change, only that something be changed. A text search in the page currently shows no other references to that file, so I have no idea what you wanted the user to do here. That is why I asked what you recommend.
| Roman_Gruber wrote: | | Not sure if you are trolling myself? |
No, that was a legitimate question. Some networks will only be fully usable if the client uses the DHCP administrator's choice of name servers. If the original poster uses such a network, and has locked /etc/resolv.conf to prevent accepting name servers from DHCP, then he will have problems. As an aside, yes, he will also have problems on such a network if he locks /etc/resolv.conf by using the supported --nohook option, since both paths prevent accepting the local name servers. My hope is that a user who uses the --nohook approach will more readily discover the origin of the problem if they one day find themselves on such a network.
| Roman_Gruber wrote: | | I do not wnat to explain the hole thing how it works. Therefore I want to refer to the corresponding IEEE standards. Anythign else is just interpredation. |
Omitting irrelevant detail is fine. Your post made no mention of suggested supplementary reading, though.
| Roman_Gruber wrote: | | Quote: | | Thats totally off topic: that require use of their own name server? |
If so you can temporarily move resolv.conf and let dhcpcd do its job. Which is not recommended in my use case. |
Immutability prevents move, too. Networks which require, or at least work much better with, their own name servers are not that uncommon. Readers should know the consequences of the changes we encourage them to make.
| Roman_Gruber wrote: | | Quote: | | change the IPs of those servers |
Thats exactly the point. Can you trust those new servers? |
They were set by the DHCP administrator, so they are presumed trusted. In this situation, I was worried about the case that the network administrator installs new DNS servers, configures them to his liking, changes his DHCP server to advertise the new DNS servers, then after a few days of concurrent operation, permanently halts the old DNS servers. Any clients which accepted DNS server addresses via DHCP seemlessly switch to the new servers. Any clients with locked settings continue to seek service from the old and now unresponsive servers.
If you do not trust your local network, you should backhaul all traffic to a trusted node somewhere else.
| Roman_Gruber wrote: | | My box, I want it to be as secure as possible. When the binding changes, I have to look up what happened and can check if there is a bad neighbour around by now. |
Your network is more hostile than mine. I believe, hopefully correctly, that the only peer which acts as a DHCP server is wholly controlled by someone who will not make intentionally adverse changes.
| Roman_Gruber wrote: | | Quote: | | This is a bad idea. Domains cannot be blocked here. There are too many bad hosts to list, and the list changes frequently. If a ban list is required at all, this is not the way to implement it. |
Oh really?
And how comes that I do not see the nasty advertisments. those harmful servers?
| Quote: | | too many bad hosts to list |
And thats the reason to say its impossible?
|
I did not say it is impossible. I said it is a bad idea because it is impractical.
| Roman_Gruber wrote: |
list anything which ends in *.eu *.online
| Quote: | | If a ban list is required at all, this is not the way to implement it. |
According to the standards it is. |
I am not aware of any standard which advocates banning hosts by causing their names to resolve to the wrong address. As I understand it, this file cannot be used for wildcards, so any advertiser that cared to defeat it could do so by configuring a DNS wildcard of *.annoying.ads.example.com, then arranging that every new ad is served from a new ephemeral subdomain under that glob.
| Roman_Gruber wrote: | | And it works because I changed those files provided in that way so it is respeced and works as it should. E.g dowload SUSE 6.2 readhat 7.x and try it out when you doubt it |
Sure, it works for your limited use case of mangling the resolution of specific blacklisted hosts. The only reason this is practical is that the adversary cannot be bothered to use existing technologies to make it impractical.
| Roman_Gruber wrote: |
So may I ask how? What is the proper way? I also want to ask for full config files in this regard than on ~amd64 please for classical setup => openrc / eudev <= not that SYSTEMD + / or kde / gnome madness (that is some other fashion of linux in my eyes)
Even windows used the host file. Not sure on recent windows, as I do not use Wald Disneys Mickysoft anymore. |
If you want to ban peers, do it at the right scope. For banning bad advertising, configure the browser not to fetch the bad domains. Even better, configure it to fetch only good domains. The Firefox extension Policeman can do this quite effectively.
| Roman_Gruber wrote: | | Quote: | | I know what this does, but will users who read your advice know it and understand the consequences? If not, you should explain to them what this does. |
Or they could ask me what it does after they took their time understanding these advanced principles.
I expect that gentoo users, are not kids. Therefore i can expect the common knowledge of googling something, using a manpage. |
As above, I am not willing to assume that the original poster and every future reader with a similar sounding problem will have the patience and presence of mind to fully research a solution proposed by someone with an old join date and a high post count, when no one else has disputed the wisdom of the idea. Whether wise or not, users tend to assume that long time users with no disputing posts are probably posting safe instructions.
| Roman_Gruber wrote: | | Quote: | | Citation needed, please. As above, ignoring the DAC is a (questionable) feature of being root, not an automatic decision deliberately made by the authors of dhcpcd. |
Can you please explain me "not an automatic decision" ? When the software called dhcpcd overwrties a config file,
a) automated. it is a script. it does something. it overwrote my config file. so its automated.
b) decision to code dhcpcd by he author
c) i assume the author of that package is the author. If not I assume a human beeing has coded it and therefore there is an author anyway
what is a DAC? it is good practise to write the first time what it means and later just use the short version. thanks |
Sorry, I assumed that as a long time user familiar with Gentoo you would Google this and see it is short for Discretionary Access Control, as hinted by the longer reference CAP_DAC_OVERRIDE.
As for "automated decision", I meant that dhcpcd runs with CAP_DAC_OVERRIDE, so if it tries to open the file for write, then the capability will bypass the file mode bits. As shown in my example, processes with CAP_DAC_OVERRIDE (which, by default, root processes almost always have) can overwrite a read-only file without changing its permissions first. The author does not need to specifically enable write permission first. Yes, the author wrote dhcpcd to write to that file, but no, he did not specifically write it to remove the read-only marker. Rather, since he did not drop CAP_DAC_OVERRIDE and did not include an explicit test to detect a read-only file, the kernel automatically bypassed read-only for him. Hence, it is not a deliberate decision by the dhcpcd author to ignore read-only. |
|
| Back to top |
|
|
Skirmitch
Apprentice
Joined: 15 Jun 2013
Posts: 207
|
| Posted: Sun Feb 19, 2017 7:40 pm Post subject: |
|
|
| I edited the first post so ppl who don't understand that much and just need the problem to be solved could find the easy answers that are mixed in here easily so you can keep with the more advanced topic's discussion without scaring newcomers. |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Networking & Security
