Hacker News Reader

Comment by iforgotpassword | Hacker News Reader

Or, if you're a lazy f, just recreate the file with your desired contents and then do

    chattr +i /etc/resolv.conf

To make it immutable.

View on HN

If you're lazy, never do this. It's not very visible and you or someone else will lose hours troubleshooting it later.

Add a comment in the file?

as well as a `etc/resolv.conf.README_IMPORTANT`-file.

...that says "Beware of the Leopard".

Isn't that the quintessential lazy programmer solution? A quick hack that is beautiful but will cause lots of wasted time later.

Troubleshooting what?

Maybe someone later has some legitimate edit they want to make to the file, which fails because it's immutable, which is in turn very hard to figure out. (E.g., I didn't know that there exists an "immutable" attribute.)

Put a comment in the file with the exact commands to turn on and off immutability. This is just good practice for most things. Having a maintenance text file with all the system stuff is a secondary good practice along with the comment.

For example why some daemon in the future takes lots of CPU spinning and logging errors about not being able to write to a file it's configured to manage.

I'll be grateful that it let me know it's stupid and can't fail gracefully.

Sound like exactly the kind of badly designed daemon I'd be trying to protect against by making the change in the first place

Let's be honest: Next to no service is designed to expect immutable files. At best they're handling a situation of read-only filesystems. If they document how configure not writing to a file and instead of doing that, the user is marking the file immutable, I wouldn't blame the app design.

Sometimes there's a point when you're just fed up with crap messing with your config and spending time hunting it down every other week to fix it and you just want it to stop.

so you'd rather spend time hunting down which config file you've mangled to be incompatible every month? this is not a good solution.

I can think of no other cases where so many different tools write to the same single configuration file.

Also I'm not necessarily saying it's a good or a bad solution. But it works, so there's that.

I'm lazy, and I've been doing this on my own computers for over a decade. I wouldn't do it on a box that anyone else uses. And I've had to do the normal fixes for some VPN software when the network blackholes any DNS traffic not going to their server IPs. Otherwise it's worked out fine for me

Hours? If you have problems modifying a file as root on a writable medium, checking for immutability is probably the first thing to do.

If you do it on every new system after OS install it's hard to forget.

That's why you leave yourself a comment reminding yourself what angry you did last week. :)

How long until SystemD and friends detect this and remove the immutable bit?

We'll use inotifywait then.

systemd-resolved explicitly (as in, it is documented behaviour) will not touch /etc/resolv.conf if it is a plain file.

It relies on /etc/resolv.conf being a symbolic link to it's generated version in /run/systemd/resolve/resolv.conf to do its thing. If it isn't linked, it assumes that is intentional and leaves your resolv.conf alone.

chattr (chflags on macos) - immutable files are a good defense against bad programs.

If you do that, do yourself a favor and put a comment line in resolv.conf telling your future self about it. :)

Won't that cause tons of errors in the services logs

Reply on news.ycombinator.com