I recently upgraded from Xubuntu 20.04 to 22.04.1. The upgrade was very rocky, but no changes were made (by me!) to the inn2 installation. Inn
is the standard repository package version 2.6.4-2build4. The news
system is working generally. Ever since the upgrade, I'm getting a
steady stream of the error message (see subject line) but I cannot
determine why. The file exists where it always has. (Note that
/var/www is a symlink and the actual path is
/x/u/www/inn/inn_status.html)
% ls -l /var/www/inn/inn_status.html
-rw-rw-r-- 1 news news 1057 Sep 2 15:25 /var/www/inn/inn_status.html
Jeffery Small writes:
I recently upgraded from Xubuntu 20.04 to 22.04.1. The upgrade was very rocky, but no changes were made (by me!) to the inn2 installation. Inn
is the standard repository package version 2.6.4-2build4. The news
system is working generally. Ever since the upgrade, I'm getting a
steady stream of the error message (see subject line) but I cannot determine why. The file exists where it always has. (Note that
/var/www is a symlink and the actual path is
/x/u/www/inn/inn_status.html)
% ls -l /var/www/inn/inn_status.htmlCheck the permissions on the parent directories, maybe? I'm wondering if something changed the permissions in /var/www (/x/u/www) such that the
-rw-rw-r-- 1 news news 1057 Sep 2 15:25 /var/www/inn/inn_status.html
news user can't traverse it.
Yes that was my first thought. I checked all the paths and everything
is kosher. However I just sued into news and walked to the directory
without problem. But when I tried to manually edit the inn_status.html
file I get the message:
"Authorization requires, but no authorization protocol specified"
This is probably unrelated. What editor are you using? It sounds like
it's trying to open an X connection. (If Emacs, use emacs -nw instead.)
Is this file system mounted over the network, possibly?
Another possibility is that you have a corrupt file system.
I believe you are correct that this is an unrelated issue, and I will
look into it further. That brings us back to the original problem....
I believe you are correct that this is an unrelated issue, and I willOh, what does /lib/systemd/system/inn2.service look like? I bet that innd
look into it further. That brings us back to the original problem....
is now started with systemd following your upgrade and probably has
various security features enabled, and you're getting bitten by the fact that /var/www is a symlink off to some other file system and that file system probably isn't set up to be writable by the innd process.
If something like ProtectSystem=strict is set in that file, you may need
to create a directory named /etc/systemd/system/inn2.service.d and drop a file in there named something like www.conf and containing:
[Service]
ReadWritePaths=/var/www/inn
to whitelist an additional writable path. I think it will automatically resolve symlinks; if not, you may need:
[Service]
ReadWritePaths=/x/u/www
Just a quick follow-up. I tried your suggestions but unfortunately, it didn't work. Below I'll list the primary systemd inn2.service file as
well as my addition. I did add multiple directory paths and reloaded
the daemon and restarted inn2. Still I get a stream of errors.
ProtectSystem is set to full.
Ah, that's not it, then. ProtectSystem=full doesn't do anything with /var
or other file systems. It just does /usr, /boot, /efi, and /etc.
I'm still pretty confused! Definitely worth trying to write to the file after su to the news user, just to rule out all the normal UNIX permission things.
Just happened to still be at my desk. I did su to news and I am able to create a new file in the /var/www/inn directory and append to the inn_status.html file, so there is no Linux permission problem. If I can
do that, why can't the service programs?
I still have the xauth problem and, as news, cannot edit the file with
vim. I fixed the problem for root by removing the existing .Xauthority
file in my home directory and at /. I see root now has a new home
directory! I also found an .Xauthority file in the news home directory (/var/spool/news) and eliminated that, but that didn't fix the problem.
Still looking.....
Okay, then it's some sort of security control related to the service
startup. It's not immediately jumping out to me in the service unit,
though. Do you have SELinux or AppArmor or anything like that enabled? (Ubuntu, so AppArmor is probably more likely. I don't know if INN has AppArmor rules, though.)
In this case, I'm pretty sure the symlink to a different file system is
the root of the problem, I'm just not sure how.
For some reason all the editors you're using including vim are trying to connect to your X display, I think. One thing to try would be to unset
the DISPLAY environment variable before trying to edit the file, which
should hopefully clue in editors that support either using X or not that there's no X display they have access to.
It's possible that your vim actually ended up being vim-gtk3 or something during the upgrade.
On Wednesday, October 5, 2022 at 9:14:57 PM UTC-7, Russ Allbery wrote:
In this case, I'm pretty sure the symlink to a different file system is
the root of the problem, I'm just not sure how.
I see that apache2 doesn't have any access problems.
In /etc/news/inn.conf file there is only one entry that points to a symlink path:
pathhttp: /var/www/inn
I guess there are two things I could do. 1) change the path to eliminate symlinks:
pathhttp: /x/u/www/inn
or 2) completely change the location of the directory to somewhere on the root drive. For example:
pathhttp: /var/inn2
The only thing under the current /var/www/inn directory is the sole inn_status.html file. However, I'm not sure what making a change line
this would do to the overall inn2 operations.
You are correct. Unsetting the DISPLAY variable allowed the news user
to edit the file. I am going to have to look into what new things auth
is doing under the hood. One thought I had was that user news had a
home directory of /var/spool/news, but cannot login since the shell is
set to "nologin". Other users get a ~/.Xauthority file created when
they first login. (Copying my file to that location doesn't work.) Is
there a way to force non-login users to get an .Xauthority file? If
not, maybe I need to add a shell, login to create the auth file and then reset it to nologin.
Well, I still don't have a systemd solution or answer to the problem,
but I changed the /etc/news/inn.conf line to:
pathhttp: /x/u/www/inn
which is the original location on the mounted disk, but bypassing
the symlink. I restarted the inn2 service, but this also fails.
I then created a new directory, /var/inn, which is on the primary
drive and placed the inn_status.html file there. I changed the /etc/news/inn.conf line to:
pathhttp: /var/inn
and restarted the inn2 service. No more error messages and the
file is now updating. So the problem is with the file being on the
mounted disk and doesn't seem to be related to the symlink.
One thing you could do to work around the problem, although unsatisfying since it doesn't explain why, is symlink the other direction
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 430 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 122:55:13 |
| Calls: | 9,059 |
| Calls today: | 6 |
| Files: | 13,398 |
| Messages: | 6,017,142 |
| Posted today: | 1 |