Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.debian.user > #255289 > unrolled thread
| Started by | davenull@tuxfamily.org |
|---|---|
| First post | 2023-02-22 18:20 +0100 |
| Last post | 2023-03-03 06:20 +0100 |
| Articles | 20 on this page of 60 — 16 participants |
Back to article view | Back to linux.debian.user
Debugging what is deleting/recreating /etc/resolv.conf with wrong configuration, on debian stable davenull@tuxfamily.org - 2023-02-22 18:20 +0100
Re: Debugging what is deleting/recreating /etc/resolv.conf with wrong configuration, on debian stable Roberto C. Sánchez <roberto@debian.org> - 2023-02-22 18:30 +0100
Re: Debugging what is deleting/recreating /etc/resolv.conf with wrong configuration, on debian stable Christoph Brinkhaus <c.brinkhaus@t-online.de> - 2023-02-22 18:40 +0100
Re: Debugging what is deleting/recreating /etc/resolv.conf with wrong configuration, on debian stable davenull@tuxfamily.org - 2023-02-23 11:40 +0100
Re: Debugging what is deleting/recreating /etc/resolv.conf with wrong configuration, on debian stable Reco <recoverym4n@enotuniq.net> - 2023-02-23 18:20 +0100
Re: Debugging what is deleting/recreating /etc/resolv.conf with wrong configuration, on debian stable Greg Wooledge <greg@wooledge.org> - 2023-02-22 19:30 +0100
Re: Debugging what is deleting/recreating /etc/resolv.conf with wrong configuration, on debian stable David Wright <deblis@lionunicorn.co.uk> - 2023-02-22 22:10 +0100
Re: Debugging what is deleting/recreating /etc/resolv.conf with wrong configuration, on debian stable davenull@tuxfamily.org - 2023-02-23 10:50 +0100
Re: Debugging what is deleting/recreating /etc/resolv.conf with wrong configuration, on debian stable <tomas@tuxteam.de> - 2023-02-23 11:00 +0100
Re: Debugging what is deleting/recreating /etc/resolv.conf with wrong configuration, on debian stable davenull@tuxfamily.org - 2023-02-23 11:40 +0100
Re: Debugging what is deleting/recreating /etc/resolv.conf with wrong configuration, on debian stable David Wright <deblis@lionunicorn.co.uk> - 2023-02-24 06:40 +0100
Re: Debugging what is deleting/recreating /etc/resolv.conf with wrong configuration, on debian stable <tomas@tuxteam.de> - 2023-02-24 06:50 +0100
Re: Debugging what is deleting/recreating /etc/resolv.conf with wrong configuration, on debian stable davenull@tuxfamily.org - 2023-02-24 10:30 +0100
Re: Debugging what is deleting/recreating /etc/resolv.conf with wrong configuration, on debian stable <tomas@tuxteam.de> - 2023-02-24 10:30 +0100
Re: Debugging what is deleting/recreating /etc/resolv.conf with wrong configuration, on debian stable davenull@tuxfamily.org - 2023-02-24 11:30 +0100
Re: Debugging what is deleting/recreating /etc/resolv.conf with wrong configuration, on debian stable tomas@tuxteam.de - 2023-02-24 11:50 +0100
Re: Debugging what is deleting/recreating /etc/resolv.conf with wrong configuration, on debian stable davenull@tuxfamily.org - 2023-02-27 15:20 +0100
Re: Debugging what is deleting/recreating /etc/resolv.conf with wrong configuration, on debian stable Greg Wooledge <greg@wooledge.org> - 2023-02-27 15:40 +0100
Re: Debugging what is deleting/recreating /etc/resolv.conf with wrong configuration, on debian stable Greg Wooledge <greg@wooledge.org> - 2023-02-24 13:30 +0100
Re: Debugging what is deleting/recreating /etc/resolv.conf with wrong configuration, on debian stable David Wright <deblis@lionunicorn.co.uk> - 2023-02-25 01:30 +0100
Forcing dhclient to not ignore tun0 interface when it's available davenull@tuxfamily.org - 2023-03-02 11:50 +0100
Re: Forcing dhclient to not ignore tun0 interface when it's available Tim Woodall <debianuser@woodall.me.uk> - 2023-03-03 04:10 +0100
Re: Forcing dhclient to not ignore tun0 interface when it's available Max Nikulin <manikulin@gmail.com> - 2023-03-03 06:30 +0100
Re: Forcing dhclient to not ignore tun0 interface when it's available Tim Woodall <debianuser@woodall.me.uk> - 2023-03-03 07:40 +0100
Re: Forcing dhclient to not ignore tun0 interface when it's available Max Nikulin <manikulin@gmail.com> - 2023-03-03 16:10 +0100
Re: Forcing dhclient to not ignore tun0 interface when it's available David Wright <deblis@lionunicorn.co.uk> - 2023-03-03 16:20 +0100
Re: Forcing dhclient to not ignore tun0 interface when it's available davenull@tuxfamily.org - 2023-03-06 13:40 +0100
Re: Forcing dhclient to not ignore tun0 interface when it's available David Wright <deblis@lionunicorn.co.uk> - 2023-03-07 05:10 +0100
Re: Forcing dhclient to not ignore tun0 interface when it's available davenull@tuxfamily.org - 2023-03-07 17:20 +0100
Re: Forcing dhclient to not ignore tun0 interface when it's available David Wright <deblis@lionunicorn.co.uk> - 2023-03-10 02:00 +0100
Re: Forcing dhclient to not ignore tun0 interface when it's available davenull@tuxfamily.org - 2023-03-06 13:20 +0100
Re: Forcing dhclient to not ignore tun0 interface when it's available David Wright <deblis@lionunicorn.co.uk> - 2023-03-07 05:10 +0100
Re: Forcing dhclient to not ignore tun0 interface when it's available davenull@tuxfamily.org - 2023-03-07 17:00 +0100
Re: Forcing dhclient to not ignore tun0 interface when it's available Max Nikulin <manikulin@gmail.com> - 2023-03-07 16:30 +0100
Re: Forcing dhclient to not ignore tun0 interface when it's available davenull@tuxfamily.org - 2023-03-07 18:00 +0100
Re: Forcing dhclient to not ignore tun0 interface when it's available David Wright <deblis@lionunicorn.co.uk> - 2023-03-10 02:00 +0100
Re: Forcing dhclient to not ignore tun0 interface when it's available davenull@tuxfamily.org - 2023-03-10 09:50 +0100
Re: Forcing dhclient to not ignore tun0 interface when it's available David Wright <deblis@lionunicorn.co.uk> - 2023-03-03 06:30 +0100
Re: Forcing dhclient to not ignore tun0 interface when it's available davenull@tuxfamily.org - 2023-03-03 18:10 +0100
Re: Forcing dhclient to not ignore tun0 interface when it's available David Wright <deblis@lionunicorn.co.uk> - 2023-03-04 18:40 +0100
Re: Debugging what is deleting/recreating /etc/resolv.conf with wrong configuration, on debian stable Cindy Sue Causey <butterflybytes@gmail.com> - 2023-02-23 02:30 +0100
Re: Debugging what is deleting/recreating /etc/resolv.conf with wrong configuration, on debian stable conover@panix.com (John Conover) - 2023-02-23 03:20 +0100
Re: Debugging what is deleting/recreating /etc/resolv.conf with wrong configuration, on debian stable davenull@tuxfamily.org - 2023-02-23 11:30 +0100
Re: Debugging what is deleting/recreating /etc/resolv.conf with wrong configuration, on debian stable Jeremy Ardley <jeremy@ardley.org> - 2023-02-23 11:40 +0100
Re: Debugging what is deleting/recreating /etc/resolv.conf with wrong configuration, on debian stable David Wright <deblis@lionunicorn.co.uk> - 2023-02-28 05:30 +0100
Re: Debugging what is deleting/recreating /etc/resolv.conf with wrong configuration, on debian stable davenull@tuxfamily.org - 2023-02-28 16:10 +0100
Re: Debugging what is deleting/recreating /etc/resolv.conf with wrong configuration, on debian stable Tixy <tixy@yxit.co.uk> - 2023-02-28 17:00 +0100
Re: Debugging what is deleting/recreating /etc/resolv.conf with wrong configuration, on debian stable David Wright <deblis@lionunicorn.co.uk> - 2023-03-02 00:30 +0100
Re: Debugging what is deleting/recreating /etc/resolv.conf with wrong configuration, on debian stable davenull@tuxfamily.org - 2023-03-02 10:40 +0100
Re: Debugging what is deleting/recreating /etc/resolv.conf with wrong configuration, on debian stable Greg Wooledge <greg@wooledge.org> - 2023-03-02 13:40 +0100
Re: Debugging what is deleting/recreating /etc/resolv.conf with wrong configuration, on debian stable davenull@tuxfamily.org - 2023-03-02 13:50 +0100
Re: Debugging what is deleting/recreating /etc/resolv.conf with wrong configuration, on debian stable davenull@tuxfamily.org - 2023-03-02 14:10 +0100
Re: Debugging what is deleting/recreating /etc/resolv.conf with wrong configuration, on debian stable Greg Wooledge <greg@wooledge.org> - 2023-03-02 14:20 +0100
Re: Debugging what is deleting/recreating /etc/resolv.conf with wrong configuration, on debian stable davenull@tuxfamily.org - 2023-03-02 16:20 +0100
Re: Debugging what is deleting/recreating /etc/resolv.conf with wrong configuration, on debian stable David <bouncingcats@gmail.com> - 2023-03-02 16:40 +0100
Re: Debugging what is deleting/recreating /etc/resolv.conf with wrong configuration, on debian stable David <bouncingcats@gmail.com> - 2023-03-02 16:20 +0100
Re: Debugging what is deleting/recreating /etc/resolv.conf with wrong configuration, on debian stable Curt <curty@free.fr> - 2023-03-02 18:30 +0100
Re: Debugging what is deleting/recreating /etc/resolv.conf with wrong configuration, on debian stable David Wright <deblis@lionunicorn.co.uk> - 2023-03-02 19:20 +0100
Re: Debugging what is deleting/recreating /etc/resolv.conf with wrong configuration, on debian stable <tomas@tuxteam.de> - 2023-03-02 20:30 +0100
Re: Debugging what is deleting/recreating /etc/resolv.conf with wrong configuration, on debian stable David Wright <deblis@lionunicorn.co.uk> - 2023-03-03 06:20 +0100
Page 1 of 3 [1] 2 3 Next page →
| From | davenull@tuxfamily.org |
|---|---|
| Date | 2023-02-22 18:20 +0100 |
| Subject | Debugging what is deleting/recreating /etc/resolv.conf with wrong configuration, on debian stable |
| Message-ID | <G20WC-7JT0-5@gated-at.bofh.it> |
Hello, ========= context ========= For the context, I use a Debian 11 laptop for work. When I work remotely from home, I have to use a cisco VPN. Good thing is there is openconnect, which does work, and in teh case of ym work's VPN, it does wor. cisco's spyware/downloaded binry, namely using the --csd-wrapper /usr/libexec/openconnect/" When I start openconnect, it usses some vpnc sript to write a porper, working, /etc/resolv.conf, with the right (work's) DNS resolver IP in it. And it works. That worked flawlessly for months. But some months ago, probably after an upgrade or something (because I definitely didn't change anything), something started to screw up with /etc/resolv.conf. So issue is not openconnect-related, at was just for the context. And to make it clear that totally disabling DHCP and writing the whole network config manually is not reasonably doable in my context. Because it's a laptop, sometime used with VPN, sometimes without it (even from home, occasionally, like during training on which I need to access external VMs that are not withelisted workplace's firewalls) so network context varies sometimes. ===== end of context ===== There is an unidentified process that decides it's ok to delete and recreate /etc/resolv.conf without asking user/admin, The problem is, the problematic process is not work's VPN related and creates the file with wrong resolver's IP. The IP corresponds to my home router IP, which does has a DNS resolver and it works as it should. BUT my home's router DNS obviously don't know jack about work internal servers, on which I work… and work's proxy as well, which when it cannot be resolved… breaks everything using HTTP. What I want is: setting up /etc/resolv.conf ONLY - at system startup/initial network connexion. - when openconnect is executed and connects to work's VPN - when openconnect is ^C-ed and disconnects from the works VPN (cleaning it's mess in the routing table, interfaces, /etc/resolv's and other netwwork stuff it might have modified, makes sense) Here's what I know: - Whatever process does that seems does what I highly suspect to be DHCP [1] requests every now and then. Home's router answers giving it's own address as both gateway and DNS resolver. And said process thinks it's OK to delete and recreate resolv.conf with the wrong content… breaking everything work's related while the VPN is still active - Such requests which varies a lot and inst consistent, can be twice or tree time in 10 minutes or 3-5 times during one afternoon…). sometimes it happens the minute after I restart the VPN client to recreate a working resolv.conf file, sometimes it leaves the file alone for 15, minutes or even 2-3 hours… - I never configured anything that to do repetitive/time-random DHCP requests. Except of course the initial DHCP request the system is first started and connected in the morning when I satrt my work day, wich is configurerd by default when you install debian for desktop/laptop/with DEs and network managers and all the fancy stuff. - I don't use systemd-resolvd. My OS image (Debian stable, LXDE, connmann as the default network manager) ships with systemd-resolvd disabled and I'm totally OK with it - I do use connmann and didn't replace it with anything else - The process that deletes and recreates /etc/resolv.conf runs as root. I used auditd to detect when changes that file… but I can't a get any process name. I can just see it's root Here's what tail -f audit.log | grep --color resolv.conf shown what it happens ------ type=PATH msg=audit(1677072201.558:572): item=3 name="/etc/resolv.conf" inode=786763 dev=fd:01 mode=0100644 ouid=0 ogid=0 rdev=00:00 nametype=DELETE cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 cap_frootid=0OUID="root" OGID="root" type=PATH msg=audit(1677072201.558:572): item=4 name="/etc/resolv.conf" inode=784351 dev=fd:01 mode=0100644 ouid=0 ogid=0 rdev=00:00 nametype=CREATE cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 cap_frootid=0OUID="root" OGID="root" ------ I was expecting to see a process name it the audit.log file BUT it didn't happened so I'm still stuck. so my question is: How to debug that further, and identify the exact process that screw up with /etc/resolv.conf file… So from there I could search for a way to prevent that by modifying the rights config file or whatever… 1. But didn't sniff network packets to confirma or infirm that, because I might wait for long time for it to happen, making extremely huge pcap files… Unless I know exactly what to filter out from input to have compact dumps… If it's not DHCP, aned I filter anything but DHCP, I'll end up with nothing. If I don't filter anything and it doesn't happen before 2 or 3 hours, it will take a shitload too much space form my home partition and would be PITA to use wireshark's search functions and display filters, and search for specific stuff, that will probably need several attempts with different search pattern and display filters to MAYBE find out something. Because I wouldn't know for sure what I'm looking for… Plus, it obviously would only confirm whether or not it's DHCP requests without additional nfo I actually need. I prefer to put my efforts and to time to look for the actual culprit process, not just the protocol.
[toc] | [next] | [standalone]
| From | Roberto C. Sánchez <roberto@debian.org> |
|---|---|
| Date | 2023-02-22 18:30 +0100 |
| Subject | Re: Debugging what is deleting/recreating /etc/resolv.conf with wrong configuration, on debian stable |
| Message-ID | <G216h-7JXc-13@gated-at.bofh.it> |
| In reply to | #255289 |
On Wed, Feb 22, 2023 at 06:12:29PM +0100, davenull@tuxfamily.org wrote: > > There is an unidentified process that decides it's ok to delete and recreate > /etc/resolv.conf without asking user/admin, I will admit up front that I did not read your message in great detail. However, overall it seems like you are experiencing something similar to what I experienced in the past. Here was what I found and how I solved the problem: https://lists.debian.org/debian-user/2017/10/msg00896.html The entire thread is rather large, so I didn't just point you to the beginning of it, but you might find other parts of the discussion illuminating as well. Regards, -Roberto -- Roberto C. Sánchez
[toc] | [prev] | [next] | [standalone]
| From | Christoph Brinkhaus <c.brinkhaus@t-online.de> |
|---|---|
| Date | 2023-02-22 18:40 +0100 |
| Subject | Re: Debugging what is deleting/recreating /etc/resolv.conf with wrong configuration, on debian stable |
| Message-ID | <G21fX-7K0v-1@gated-at.bofh.it> |
| In reply to | #255289 |
Am Wed, Feb 22, 2023 at 06:12:29PM +0100 schrieb davenull@tuxfamily.org:
>
> ========= context =========
> For the context, I use a Debian 11 laptop for work. When I work remotely
> from home, I have to use a cisco VPN. Good thing is there is openconnect,
> which does work, and in teh case of ym work's VPN, it does wor. cisco's
> spyware/downloaded binry, namely using the --csd-wrapper
> /usr/libexec/openconnect/"
[snip]
> ===== end of context =====
> What I want is: setting up /etc/resolv.conf ONLY
> - at system startup/initial network connexion.
> - when openconnect is executed and connects to work's VPN
> - when openconnect is ^C-ed and disconnects from the works VPN (cleaning
> it's mess in the routing table, interfaces, /etc/resolv's and other netwwork
> stuff it might have modified, makes sense)
>
> Here's what I know:
> - Whatever process does that seems does what I highly suspect to be DHCP [1]
> requests every now and then. Home's router answers giving it's own address
> as both gateway and DNS resolver. And said process thinks it's OK to delete
> and recreate resolv.conf with the wrong content… breaking everything work's
> related while the VPN is still active
If it is DHCP: You might do a countermeasure in
/etc/dhcp/dhclient.conf. On my system I have an entry as below.
interface "wlp4s0" {
supersede domain-name-servers 127.0.0.1;
}
I run unbound as a resolver. The entry in dhcclient.conf prevents that
the entry in /etc/resolv.conf is overwritten.
[snip]
My setup is stoneage like compared to your context.
Anyhow, I hope this is at least useful as a pointer :-).
Kind regards,
Christoph
--
Ist die Katze gesund
schmeckt sie dem Hund.
[toc] | [prev] | [next] | [standalone]
| From | davenull@tuxfamily.org |
|---|---|
| Date | 2023-02-23 11:40 +0100 |
| Message-ID | <G2hb3-7UiR-3@gated-at.bofh.it> |
| In reply to | #255291 |
Hi
On 2023-02-22 18:30, Christoph Brinkhaus wrote:
> Am Wed, Feb 22, 2023 at 06:12:29PM +0100 schrieb
> davenull@tuxfamily.org:
>>
>> ========= context =========
>> For the context, I use a Debian 11 laptop for work. When I work
>> remotely
>> from home, I have to use a cisco VPN. Good thing is there is
>> openconnect,
>> which does work, and in teh case of ym work's VPN, it does wor.
>> cisco's
>> spyware/downloaded binry, namely using the --csd-wrapper
>> /usr/libexec/openconnect/"
> [snip]
>> ===== end of context =====
>> What I want is: setting up /etc/resolv.conf ONLY
>> - at system startup/initial network connexion.
>> - when openconnect is executed and connects to work's VPN
>> - when openconnect is ^C-ed and disconnects from the works VPN
>> (cleaning
>> it's mess in the routing table, interfaces, /etc/resolv's and other
>> netwwork
>> stuff it might have modified, makes sense)
>>
>> Here's what I know:
>> - Whatever process does that seems does what I highly suspect to be
>> DHCP [1]
>> requests every now and then. Home's router answers giving it's own
>> address
>> as both gateway and DNS resolver. And said process thinks it's OK to
>> delete
>> and recreate resolv.conf with the wrong content… breaking everything
>> work's
>> related while the VPN is still active
>
> If it is DHCP: You might do a countermeasure in
> /etc/dhcp/dhclient.conf. On my system I have an entry as below.
>
> interface "wlp4s0" {
> supersede domain-name-servers 127.0.0.1;
Unfortunately, I can't use supersede parameter because I need to use
different resolvers at different times/in different contexts.
I would need something more… conditional
IF openconnect is running and has modified resolv.conf, leave that file
alone unless you are openconnect
Otherwise, when there's no VPN active, you can do normal DHCP requests
and accept whatever currently-active network's router/DHCP tells you and
update resolve conf accordingly
> }
>
> I run unbound as a resolver. The entry in dhcclient.conf prevents that
> the entry in /etc/resolv.conf is overwritten.
>
> [snip]
>
> My setup is stoneage like compared to your context.
> Anyhow, I hope this is at least useful as a pointer :-).
>
> Kind regards,
> Christoph
[toc] | [prev] | [next] | [standalone]
| From | Reco <recoverym4n@enotuniq.net> |
|---|---|
| Date | 2023-02-23 18:20 +0100 |
| Subject | Re: Debugging what is deleting/recreating /etc/resolv.conf with wrong configuration, on debian stable |
| Message-ID | <G2nq9-7YrY-7@gated-at.bofh.it> |
| In reply to | #255321 |
Hi.
On Thu, Feb 23, 2023 at 11:31:44AM +0100, davenull@tuxfamily.org wrote:
> > If it is DHCP: You might do a countermeasure in
> > /etc/dhcp/dhclient.conf. On my system I have an entry as below.
> >
> > interface "wlp4s0" {
> > supersede domain-name-servers 127.0.0.1;
>
> Unfortunately, I can't use supersede parameter because I need to use
> different resolvers at different times/in different contexts.
>
> I would need something more… conditional
>
> IF openconnect is running and has modified resolv.conf, leave that
> file alone unless you are openconnect Otherwise, when there's no VPN
> active, you can do normal DHCP requests and accept whatever
> currently-active network's router/DHCP tells you and update resolve
> conf accordingly
openconnect has that helpful --script option, which calls
/usr/share/vpnc-scripts/vpnc-script by default.
All you need is to make a copy of that script, modify dhclient.conf
at "connect" and "disconnect" phases accordingly, and then call your
modified script from openconnect.
Reco
[toc] | [prev] | [next] | [standalone]
| From | Greg Wooledge <greg@wooledge.org> |
|---|---|
| Date | 2023-02-22 19:30 +0100 |
| Subject | Re: Debugging what is deleting/recreating /etc/resolv.conf with wrong configuration, on debian stable |
| Message-ID | <G222l-7Kxa-9@gated-at.bofh.it> |
| In reply to | #255289 |
On Wed, Feb 22, 2023 at 06:12:29PM +0100, davenull@tuxfamily.org wrote: > There is an unidentified process that decides it's ok to delete and recreate > /etc/resolv.conf without asking user/admin, > The problem is, the problematic process is not work's VPN related and > creates the file with wrong resolver's IP. The IP corresponds to my home > router IP, [...] Then it's probably the Debian DHCP client, rewriting resolv.conf according to what your router's DHCP server told it to use. <https://wiki.debian.org/resolv.conf> has several different strategies for working around this sort of issue. Good luck.
[toc] | [prev] | [next] | [standalone]
| From | David Wright <deblis@lionunicorn.co.uk> |
|---|---|
| Date | 2023-02-22 22:10 +0100 |
| Subject | Re: Debugging what is deleting/recreating /etc/resolv.conf with wrong configuration, on debian stable |
| Message-ID | <G24xb-7M9K-17@gated-at.bofh.it> |
| In reply to | #255289 |
On Wed 22 Feb 2023 at 18:12:29 (+0100), davenull@tuxfamily.org wrote: > What I want is: setting up /etc/resolv.conf ONLY > - at system startup/initial network connexion. > - when openconnect is executed and connects to work's VPN > - when openconnect is ^C-ed and disconnects from the works VPN > (cleaning it's mess in the routing table, interfaces, /etc/resolv's > and other netwwork stuff it might have modified, makes sense) What's the output from ls -l /etc/resolv.conf What's responsible for restoring the previous contents of /etc/resolv.conf to your normal network connection when you finish "work" and tear down the VPN. > - I don't use systemd-resolvd. My OS image (Debian stable, LXDE, > connmann as the default network manager) ships with systemd-resolvd > disabled and I'm totally OK with it > - I do use connmann and didn't replace it with anything else > - The process that deletes and recreates /etc/resolv.conf runs as > root. I used auditd to detect when changes that file… but I can't a > get any process name. I can just see it's root One way of finding the process is to # chattr +i /etc/resolv.conf while you're "at work", so that you get permission errors in the logs when it happens. (Remember to chattr -i before you "stop work".) But how do you manage /etc/resolv.conf with connman. I don't use it, but I read there's a plug-in for that. Is openconnect correctly informing connman when it finishes. > I was expecting to see a process name it the audit.log file BUT it > didn't happened so I'm still stuck. so my question is: How to debug > that further, and identify the exact process that screw up with > /etc/resolv.conf file… So from there I could search for a way to > prevent that by modifying the rights config file or whatever… Whatever the "rogue process" is should be informing whatever the "/etc/resolv.conf controller" is, shouldn't it, rather than being blocked. (It might be legitimate rather than "rogue".) Cheers, David.
[toc] | [prev] | [next] | [standalone]
| From | davenull@tuxfamily.org |
|---|---|
| Date | 2023-02-23 10:50 +0100 |
| Message-ID | <G2goF-7TM7-1@gated-at.bofh.it> |
| In reply to | #255302 |
Hello On 2023-02-22 22:08, David Wright wrote: > On Wed 22 Feb 2023 at 18:12:29 (+0100), davenull@tuxfamily.org wrote: > >> What I want is: setting up /etc/resolv.conf ONLY >> - at system startup/initial network connexion. >> - when openconnect is executed and connects to work's VPN >> - when openconnect is ^C-ed and disconnects from the works VPN >> (cleaning it's mess in the routing table, interfaces, /etc/resolv's >> and other netwwork stuff it might have modified, makes sense) > > What's the output from ls -l /etc/resolv.conf > -rw-r--r-- 1 root root 104 23 févr. 09:35 /etc/resolv.conf With the ctime changing more or less often, since it is deleted/recreated by what I suspect to do DHCP requests (see audit.log) > What's responsible for restoring the previous contents of > /etc/resolv.conf to your normal network connection when you > finish "work" and tear down the VPN. openconnect does. When it's CTRL-C-ed to disconnect from the workplace VPN, resolv.conf is reverted back to my home network resolver Not sure whether vpnc_script just calls the DHCP client (probably dhclient since it's the only dhcp client preinstalled, at least I'm aware of) > >> - I don't use systemd-resolvd. My OS image (Debian stable, LXDE, >> connmann as the default network manager) ships with systemd-resolvd >> disabled and I'm totally OK with it >> - I do use connmann and didn't replace it with anything else >> - The process that deletes and recreates /etc/resolv.conf runs as >> root. I used auditd to detect when changes that file… but I can't a >> get any process name. I can just see it's root > > One way of finding the process is to # chattr +i /etc/resolv.conf > while you're "at work", so that you get permission errors in the > logs when it happens. (Remember to chattr -i before you "stop work".) Thank you. I'll give it a try, But I won't be on remote work before next week Which log file is used for that? So instead of grepping /var/log/ recursively when the problem occurs. I'd tail -f the right file to find the "rogue" process right away > > But how do you manage /etc/resolv.conf with connman. I don't use it, openconnect uses something called vpnc_script. When openconnects is exc, resolv.conf contains the appropriate info as well a comment including "VPNC_GENERATED" > but I read there's a plug-in for that. Is openconnect correctly > informing connman when it finishes. Whether it informs connmann or cleans after itself without involving connmann, I don't know and I'm not sure how to check that out. I'm not familiar with how vpnc_script works and what it does _exactly_ But it does clean up the config and network config is left in working state when openconnect disconnects > >> I was expecting to see a process name it the audit.log file BUT it >> didn't happened so I'm still stuck. so my question is: How to debug >> that further, and identify the exact process that screw up with >> /etc/resolv.conf file… So from there I could search for a way to >> prevent that by modifying the rights config file or whatever… > > Whatever the "rogue process" is should be informing whatever the > "/etc/resolv.conf controller" is, shouldn't it, rather than being > blocked. (It might be legitimate rather than "rogue".) Yes, I certainly don't want to block the process entirely, I just want to find some mechanism that works in the following way "Leave /etc/resolv.conf alone, ONLY IF you're not openconnect/a vpnc_script AND WHEN openconnect is running" Otherwise, when VPN is disconnected, I DO want /etc/resolv.conf to be generated according to my home router's DHCP tells the computer Thank you for your help either way. It gives me some interesting pointers :) > > Cheers, > David.
[toc] | [prev] | [next] | [standalone]
| From | <tomas@tuxteam.de> |
|---|---|
| Date | 2023-02-23 11:00 +0100 |
| Subject | Re: Debugging what is deleting/recreating /etc/resolv.conf with wrong configuration, on debian stable |
| Message-ID | <G2gyl-7TPv-1@gated-at.bofh.it> |
| In reply to | #255318 |
[Multipart message — attachments visible in raw view] — view raw
On Thu, Feb 23, 2023 at 10:44:35AM +0100, davenull@tuxfamily.org wrote: [...] > Thank you. I'll give it a try, But I won't be on remote work before next > week > Which log file is used for that? That depends: it's the perpetrator's choice where to log (or whether to log at all, sadly). > So instead of grepping /var/log/ recursively when the problem occurs. I'd > tail -f the right file to find the "rogue" process right away You know that you can tail -f more than one file, do you? I just learnt that from a colleague. Enormously handy. Cheers -- t
[toc] | [prev] | [next] | [standalone]
| From | davenull@tuxfamily.org |
|---|---|
| Date | 2023-02-23 11:40 +0100 |
| Message-ID | <G2hb3-7UiR-9@gated-at.bofh.it> |
| In reply to | #255319 |
On 2023-02-23 10:54, tomas@tuxteam.de wrote: > On Thu, Feb 23, 2023 at 10:44:35AM +0100, davenull@tuxfamily.org wrote: > > [...] > >> Thank you. I'll give it a try, But I won't be on remote work before >> next >> week >> Which log file is used for that? > > That depends: it's the perpetrator's choice where to log (or whether > to log at all, sadly). > >> So instead of grepping /var/log/ recursively when the problem occurs. >> I'd >> tail -f the right file to find the "rogue" process right away > > You know that you can tail -f more than one file, do you? > > I just learnt that from a colleague. Enormously handy. > > Cheers Interesting! I didn't knew that. Thanks for the tip. I knew about and I just remembered multitail, which I never used that much, cause can be too noisy… But I guess I'm going to use "grep resolv.conf"… But if the "rogue" process doesn't log anything… I'll be stuck… worth trying either way. Thanks
[toc] | [prev] | [next] | [standalone]
| From | David Wright <deblis@lionunicorn.co.uk> |
|---|---|
| Date | 2023-02-24 06:40 +0100 |
| Subject | Re: Debugging what is deleting/recreating /etc/resolv.conf with wrong configuration, on debian stable |
| Message-ID | <G2yYh-85Ai-5@gated-at.bofh.it> |
| In reply to | #255318 |
On Thu 23 Feb 2023 at 10:44:35 (+0100), davenull@tuxfamily.org wrote: > On 2023-02-22 22:08, David Wright wrote: > > On Wed 22 Feb 2023 at 18:12:29 (+0100), davenull@tuxfamily.org wrote: > > > > > What I want is: setting up /etc/resolv.conf ONLY > > > - at system startup/initial network connexion. > > > - when openconnect is executed and connects to work's VPN > > > - when openconnect is ^C-ed and disconnects from the works VPN > > > (cleaning it's mess in the routing table, interfaces, /etc/resolv's > > > and other netwwork stuff it might have modified, makes sense) > > > > What's the output from ls -l /etc/resolv.conf > > -rw-r--r-- 1 root root 104 23 févr. 09:35 /etc/resolv.conf > > With the ctime changing more or less often, since it is > deleted/recreated by what I suspect to do DHCP requests (see > audit.log) Being a real file, it's not protected from being modified by any process that wants to. A resolv.conf manager will set up resolv.conf as a symlink to a file that it controls, so that it can manage contention between different processes. > > What's responsible for restoring the previous contents of > > /etc/resolv.conf to your normal network connection when you > > finish "work" and tear down the VPN. > > openconnect does. When it's CTRL-C-ed to disconnect from the workplace > VPN, resolv.conf is reverted back to my home network resolver > Not sure whether vpnc_script just calls the DHCP client (probably > dhclient since it's the only dhcp client preinstalled, at least I'm > aware of) [ … ] > > One way of finding the process is to # chattr +i /etc/resolv.conf > > while you're "at work", so that you get permission errors in the > > logs when it happens. (Remember to chattr -i before you "stop work".) > > Thank you. I'll give it a try, But I won't be on remote work before > next week > Which log file is used for that? > So instead of grepping /var/log/ recursively when the problem occurs. > I'd tail -f the right file to find the "rogue" process right away I don't know. I thought the destination was chosen more by the program than the error type. Perhaps daemon.log and syslog might be good candidates. Of course, after the event you can check them all. > openconnect uses something called vpnc_script. > When openconnects is exc, resolv.conf contains the appropriate info as > well a comment including "VPNC_GENERATED" > > > but I read there's a plug-in for that. Is openconnect correctly > > informing connman when it finishes. > > Whether it informs connmann or cleans after itself without involving > connmann, I don't know and I'm not sure how to check that out. > I'm not familiar with how vpnc_script works and what it does _exactly_ > But it does clean up the config and network config is left in working > state when openconnect disconnects vpnc_script has about eight methods available for setting up and reverting resolv.conf. Which is used depends on the presence of a binary, checked in turn from this list: /etc/openwrt_release modify_resolvconf_openwrt /usr/bin/resolvectl modify_resolved_manager /usr/bin/busctl modify_resolved_manager_old /sbin/resolvconf modify_resolvconf_manager /sbin/netconfig modify_resolvconf_suse_netconfig /sbin/modify_resolvconf modify_resolvconf_suse /usr/sbin/unbound-control modify_resolvconf_unbound otherwise modify_resolvconf_generic Perhaps you could check which of those binaries you have. > > But how do you manage /etc/resolv.conf with connman. I don't use it, Actually I was interested in what sets up your ordinary networking, the one that uses your ISP, when you're not "at work" … > Otherwise, when VPN is disconnected, I DO want /etc/resolv.conf to be > generated according to my home router's DHCP tells the computer … yes, that one. Cheers, David.
[toc] | [prev] | [next] | [standalone]
| From | <tomas@tuxteam.de> |
|---|---|
| Date | 2023-02-24 06:50 +0100 |
| Subject | Re: Debugging what is deleting/recreating /etc/resolv.conf with wrong configuration, on debian stable |
| Message-ID | <G2z7X-85Eg-1@gated-at.bofh.it> |
| In reply to | #255333 |
[Multipart message — attachments visible in raw view] — view raw
On Thu, Feb 23, 2023 at 11:39:03PM -0600, David Wright wrote: [...] > vpnc_script has about eight methods available for setting up and > reverting resolv.conf. Which is used depends on the presence of > a binary, checked in turn from this list: > > /etc/openwrt_release modify_resolvconf_openwrt > /usr/bin/resolvectl modify_resolved_manager > /usr/bin/busctl modify_resolved_manager_old > /sbin/resolvconf modify_resolvconf_manager > /sbin/netconfig modify_resolvconf_suse_netconfig > /sbin/modify_resolvconf modify_resolvconf_suse > /usr/sbin/unbound-control modify_resolvconf_unbound > otherwise modify_resolvconf_generic > > Perhaps you could check which of those binaries you have. Thanks for this one. I think this is the most constructive contribution to this thread. Cheers -- t
[toc] | [prev] | [next] | [standalone]
| From | davenull@tuxfamily.org |
|---|---|
| Date | 2023-02-24 10:30 +0100 |
| Message-ID | <G2CyR-87VI-3@gated-at.bofh.it> |
| In reply to | #255333 |
Hello, > […] > vpnc_script has about eight methods available for setting up and > reverting resolv.conf. Which is used depends on the presence of > a binary, checked in turn from this list: > > /etc/openwrt_release modify_resolvconf_openwrt > /usr/bin/resolvectl modify_resolved_manager > /usr/bin/busctl modify_resolved_manager_old > /sbin/resolvconf modify_resolvconf_manager > /sbin/netconfig modify_resolvconf_suse_netconfig > /sbin/modify_resolvconf modify_resolvconf_suse > /usr/sbin/unbound-control modify_resolvconf_unbound > otherwise modify_resolvconf_generic > > Perhaps you could check which of those binaries you have. I have they two resolved_manager binaries, but since systemd-resolvd service is disabled and stopped on my system, I highly doubt these are used. It's more likely modify_resolvconf_generic However, I didn't notice any vnpc_script malfunction. It does what it is expected to do. I'm like 99% sure the problem is dhclient deleting and recreating /etc/resolv.conf as it sees fit, multiple times a day, and deleting whatever vpnc_script has put in that file. > >> > But how do you manage /etc/resolv.conf with connman. I don't use it, > > Actually I was interested in what sets up your ordinary networking, > the one that uses your ISP, when you're not "at work" … - ConnMan is used to manually connect to/disconnect from wired, and much less often wireless (wifi, bluetooth) networks - dhclient is used for DHCP request - My OpenWRT router with DHCP is used as gateway for my subnet, answers to DHCP requests - Then there's is toward my ISP's all-in-one router/modem + TV set top box + telephony bullshit (I don't use anything but Interne, but ISP enforces their "triple play bullshit so I have to do with that all in one device… There's no alternatives for DOCSIS, Since I can't get FTTH yet, which my current router doesn't support yet, either way I'm dependant on ISP router) > >> Otherwise, when VPN is disconnected, I DO want /etc/resolv.conf to be >> generated according to my home router's DHCP tells the computer > > … yes, that one. > > Cheers, > David.
[toc] | [prev] | [next] | [standalone]
| From | <tomas@tuxteam.de> |
|---|---|
| Date | 2023-02-24 10:30 +0100 |
| Subject | Re: Debugging what is deleting/recreating /etc/resolv.conf with wrong configuration, on debian stable |
| Message-ID | <G2CyR-87VI-9@gated-at.bofh.it> |
| In reply to | #255338 |
[Multipart message — attachments visible in raw view] — view raw
On Fri, Feb 24, 2023 at 10:19:38AM +0100, davenull@tuxfamily.org wrote: [...] > However, I didn't notice any vnpc_script malfunction. It does what it is > expected to do. I'm like 99% sure the problem is dhclient deleting and > recreating /etc/resolv.conf as it sees fit, multiple times a day, and > deleting whatever vpnc_script has put in that file. Instead of 99% suspicions you could just look into your /var/log/syslog: dhclient does leave enough traces there. Bonus point if you correlate these timestamps with your resolv.conf mod time :-) Cheers -- t
[toc] | [prev] | [next] | [standalone]
| From | davenull@tuxfamily.org |
|---|---|
| Date | 2023-02-24 11:30 +0100 |
| Message-ID | <G2DuV-88Bn-1@gated-at.bofh.it> |
| In reply to | #255339 |
On 2023-02-24 10:27, tomas@tuxteam.de wrote: > On Fri, Feb 24, 2023 at 10:19:38AM +0100, davenull@tuxfamily.org wrote: > > [...] > >> However, I didn't notice any vnpc_script malfunction. It does what it >> is >> expected to do. I'm like 99% sure the problem is dhclient deleting and >> recreating /etc/resolv.conf as it sees fit, multiple times a day, and >> deleting whatever vpnc_script has put in that file. > > Instead of 99% suspicions you could just look into your > /var/log/syslog: > dhclient does leave enough traces there. Bonus point if you correlate > these timestamps with your resolv.conf mod time :-) > > Cheers Goode point. Thank you for the reminder :) I do only partial week remote work, been in the office the last days. So in order for the problem to happen again, I need to wait monday, only then I might dig into the log files. The thing is: at first, I didn't suspect dhclient until recently (after I started this thread) so I need to wait for the next remote work day. During my last days of remote work, I just used auditd to see if I can see process name when the file is deleted/recreated. The event was captured by auditd but the process name was missing from the audit.log file, so I had no idea what's to look for., in which log file(s). I'm still sure it isn't vpnc_script. vpnc_script leaves identification comments on the file And dhclient is more like to know only about what my home's DHCP tells it, than my work's place DNS resolver, that's why I suspect dhclient. BUT I will make sure to take some time to dig into the logs monday. Now that I have an idea what I'm looking for, totally agree logs are better than suspicion
[toc] | [prev] | [next] | [standalone]
| From | tomas@tuxteam.de |
|---|---|
| Date | 2023-02-24 11:50 +0100 |
| Subject | Re: Debugging what is deleting/recreating /etc/resolv.conf with wrong configuration, on debian stable |
| Message-ID | <G2DOh-88Kq-1@gated-at.bofh.it> |
| In reply to | #255340 |
[Multipart message — attachments visible in raw view] — view raw
On Fri, Feb 24, 2023 at 11:27:40AM +0100, davenull@tuxfamily.org wrote: > [...] totally agree logs are better than suspicion But please, don't take my snark all too seriously. On reread I realize it might have sounded harsher than it was meant. Cheers -- t
[toc] | [prev] | [next] | [standalone]
| From | davenull@tuxfamily.org |
|---|---|
| Date | 2023-02-27 15:20 +0100 |
| Message-ID | <G3Mw9-8S11-1@gated-at.bofh.it> |
| In reply to | #255340 |
Hello On 2023-02-24 11:27, davenull@tuxfamily.org wrote: > On 2023-02-24 10:27, tomas@tuxteam.de wrote: >> On Fri, Feb 24, 2023 at 10:19:38AM +0100, davenull@tuxfamily.org >> wrote: >> >> [...] > BUT I will make sure to take some time to dig into the logs monday. > Now that I have an idea what I'm looking for, totally agree logs are > better than suspicion I did - chattr +i /etc/revolv.conf And when auditd showed a (failed) delete event on /etc/resolv.conf I grepped "resolv.conf" recursively on /var/log/, and All I've found are entries in - /var/log/installer from more than 1 year ago, since the log file is small, I guess it has never been rotated - audit.log, since write and append to "/etc/resolv.conf" are audited - auth.log : authentication related to commands I've used this morning, which are "auditctl -w /etc/resolv.conf -p wa" and "chattr +i /etc/revolv.conf" But whatever process tried to delete "/etc/resolv.conf" whidle it was immutable, didn't leave traces. Not even a log for permission error because of the immutable flag. At least not in /var/log anyway.
[toc] | [prev] | [next] | [standalone]
| From | Greg Wooledge <greg@wooledge.org> |
|---|---|
| Date | 2023-02-27 15:40 +0100 |
| Subject | Re: Debugging what is deleting/recreating /etc/resolv.conf with wrong configuration, on debian stable |
| Message-ID | <G3MPw-8S8i-25@gated-at.bofh.it> |
| In reply to | #255415 |
On Mon, Feb 27, 2023 at 03:14:40PM +0100, davenull@tuxfamily.org wrote: > I did > > - chattr +i /etc/revolv.conf > > And when auditd showed a (failed) delete event on /etc/resolv.conf > > I grepped "resolv.conf" recursively on /var/log/, and All I've found are > entries in > > - /var/log/installer from more than 1 year ago, since the log file is small, > I guess it has never been rotated > - audit.log, since write and append to "/etc/resolv.conf" are audited > - auth.log : authentication related to commands I've used this morning, > which are "auditctl -w /etc/resolv.conf -p wa" and "chattr +i > /etc/revolv.conf" > > But whatever process tried to delete "/etc/resolv.conf" whidle it was > immutable, didn't leave traces. > Not even a log for permission error because of the immutable flag. At least > not in /var/log anyway. I can't say I'm shocked. But you *did* find an entry from auditd, which presumably has a timestamp. Check to see what was happening right at that moment in other log files. In particular, check whether a DHCP client daemon renewed its DHCP lease at that time.
[toc] | [prev] | [next] | [standalone]
| From | Greg Wooledge <greg@wooledge.org> |
|---|---|
| Date | 2023-02-24 13:30 +0100 |
| Subject | Re: Debugging what is deleting/recreating /etc/resolv.conf with wrong configuration, on debian stable |
| Message-ID | <G2Fn3-89Ol-5@gated-at.bofh.it> |
| In reply to | #255338 |
On Fri, Feb 24, 2023 at 10:19:38AM +0100, davenull@tuxfamily.org wrote:
> However, I didn't notice any vnpc_script malfunction. It does what it is
> expected to do. I'm like 99% sure the problem is dhclient deleting and
> recreating /etc/resolv.conf as it sees fit, multiple times a day, and
> deleting whatever vpnc_script has put in that file.
Then use one of the methods listed at <https://wiki.debian.org/resolv.conf>
to address that, and see if it fixes the problem.
The simplest one to test would be
<https://wiki.debian.org/resolv.conf#Configuring_dhclient>. It doesn't
involve installing any new packages.
If your testing is successful (e.g. a whole day goes by and the
resolv.conf file is not unexpectedly altered), then things get a little
bit trickier. If I understand correctly, you're working on a laptop,
and your desired configuration is:
* At boot time, allow the DHCP client to set up resolv.conf.
* Once that has been done, disallow all further modifications of
resolv.conf by the DHCP client.
* Allow modifications of resolv.conf by vpnc_script at any time.
The tricky part here is how to write a function that determines whether
dhclient should be allowed to modify the file ("is it boot time") or not.
Perhaps you could use something awful like "if the system uptime is less
than 5 minutes, allow it".
Another hack that comes to mind would be writing something that removes
the resolv.conf file at shutdown time. Then, the dhclient hook function
would allow dhclient to write the file if and only if it doesn't exist.
Or... the reverse of this. Keep a second file which serves as a flag
indicating that the resolv.conf file has already been configured once.
Remove this flag at boot time (make sure that happens *early*, before
dhclient is started), and then write your dhclient hook function to
allow the modification if and only if the flag file doesn't exist. Then
create the flag file after doing the modification.
I'm not sure which of those is the least bad. Maybe you can come up
with some other ideas.
[toc] | [prev] | [next] | [standalone]
| From | David Wright <deblis@lionunicorn.co.uk> |
|---|---|
| Date | 2023-02-25 01:30 +0100 |
| Subject | Re: Debugging what is deleting/recreating /etc/resolv.conf with wrong configuration, on debian stable |
| Message-ID | <G2QBP-8h5B-7@gated-at.bofh.it> |
| In reply to | #255338 |
On Fri 24 Feb 2023 at 10:19:38 (+0100), davenull@tuxfamily.org wrote: > > […] > > vpnc_script has about eight methods available for setting up and > > reverting resolv.conf. Which is used depends on the presence of > > a binary, checked in turn from this list: > > > > /etc/openwrt_release modify_resolvconf_openwrt > > /usr/bin/resolvectl modify_resolved_manager > > /usr/bin/busctl modify_resolved_manager_old > > /sbin/resolvconf modify_resolvconf_manager > > /sbin/netconfig modify_resolvconf_suse_netconfig > > /sbin/modify_resolvconf modify_resolvconf_suse > > /usr/sbin/unbound-control modify_resolvconf_unbound > > otherwise modify_resolvconf_generic > > > > Perhaps you could check which of those binaries you have. > > I have they two resolved_manager binaries, but since systemd-resolvd > service is disabled and stopped on my system, I highly doubt these are > used. > It's more likely modify_resolvconf_generic > > However, I didn't notice any vnpc_script malfunction. It does what it > is expected to do. I'm like 99% sure the problem is dhclient deleting > and recreating /etc/resolv.conf as it sees fit, multiple times a day, > and deleting whatever vpnc_script has put in that file. If that's the case, then unfortunately the vnpc_script gives you no protection against that happening. All it appears to do, when you connect, is to write: #@VPNC_GENERATED@ -- this file is generated by vpnc # and will be overwritten by vpnc # as long as the above mark is intact" at the start of resolv.conf, so that when you disconnect, it can check if that first string is still there and, if it is, restore the previous contents of the file. Meanwhile, anything else might overwrite the file, and if it does, it's likely that the vnpc_script won't even be able to restore the previous version of the file when you disconnect. You'll notice that none of the other functions actually reference resolv.conf itself, but will store the real file elsewhere, and publish it through a symlink. > > > > But how do you manage /etc/resolv.conf with connman. I don't use it, > > > > Actually I was interested in what sets up your ordinary networking, > > the one that uses your ISP, when you're not "at work" … > > - ConnMan is used to manually connect to/disconnect from wired, and > much less often wireless (wifi, bluetooth) networks > - dhclient is used for DHCP request They should work with either of the resolvconf packages that Debian supplies, resolvconf and openresolv. I use the latter, as iwd documents that it supports it. I know there are people on this list who use connman. > - My OpenWRT router with DHCP is used as gateway for my subnet, > answers to DHCP requests I do much the same, with my router (two, actually) connected to the ISP's ethernet connector. > - Then there's is toward my ISP's all-in-one router/modem + TV set top > box + telephony bullshit (I don't use anything but Interne, but ISP > enforces their "triple play bullshit so I have to do with that all in > one device… There's no alternatives for DOCSIS, Since I can't get FTTH > yet, which my current router doesn't support yet, either way I'm > dependant on ISP router) Everything of ours runs from my router, so the ISP's is just a glorified modem. Cheers, David.
[toc] | [prev] | [next] | [standalone]
Page 1 of 3 [1] 2 3 Next page →
Back to top | Article view | linux.debian.user
csiph-web