Problems after update to core 159

Getting Started with IPFire Updates Trouble
1

Hello all,
I’m not completely new, but unfortunately I don’t have access to my old account anymore. Hence a new account. I have used ipcop back in about 2004, moved to ipfire about 2009 I think… Usually I could solve my issues with the help of the forum and stayed silent.

However the last update I ran caused some issues…
I was behind with updating a bit due to not having the freedom to just randomly restart (work from home and so) and then forgetting again. So it was probably 2 or 3 updates combined.

After the update I could not access the gui anymore. I found a solution in the forum by chmod-ing several folders

chmod -v 755 /usr /usr/bin /usr/lib /usr/sbin /var /var/ipfire

That brought the gui back.
However I notice now some more issues. The strange thing is that it internet browsing in general seems to work. But when I noticed that the timeserver seems not being able to update I noticed that name resolving is not working properly.

If I run

[root@ipcoffin bin]# dig pool.ntp.org

; <<>> DiG 9.11.32 <<>> pool.ntp.org
;; global options: +cmd
;; connection timed out; no servers could be reached

however

[root@ipcoffin bin]# dig @8.8.8.8 pool.ntp.org

; <<>> DiG 9.11.32 <<>> @8.8.8.8 pool.ntp.org
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38101
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;pool.ntp.org.			IN	A

;; ANSWER SECTION:
pool.ntp.org.		14	IN	A	77.72.144.59
pool.ntp.org.		14	IN	A	37.252.127.156
pool.ntp.org.		14	IN	A	84.245.9.254
pool.ntp.org.		14	IN	A	194.5.96.24

;; Query time: 3 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Wed Aug 25 12:37:23 CEST 2021
;; MSG SIZE  rcvd: 105

seems to do just fine.
In my DNS settings I have 8.8.8.8 and 8.8.4.4 set as well. So dig should use them if nothing specified I assume.
But why is browsing the internet working just fine :confused:

I just noticed during writing this post, that the gui has some issues with graphs

Screenshot from 2021-08-25 12-49-26
Screenshot from 2021-08-25 12-49-26984×442 51.5 KB

Not sure what else is going wrong currently.

Due to the name resolving issue I can also not install updates etc.

[root@ipcoffin bin]# pakfire update

Giving up: There was no chance to get the file "2.27-x86_64/lists/server-list.db" from any available server.
There was an error on the way. Please fix it.

Giving up: There was no chance to get the file "lists/packages_list.db" from any available server.
There was an error on the way. Please fix it.

Giving up: There was no chance to get the file "lists/core-list.db" from any available server.
There was an error on the way. Please fix it.
[root@ipcoffin bin]#

Sorry if it seems a bit chaotic, as I am not sure what information will help solving the issue.

Cheers
Roger

2

find -type d -perm 700 gives me

./boot/lost+found
./root/.ssh
./opt/pakfire/etc/.gnupg
./lost+found
./etc
./etc/rc.d
./etc/rc.d/rc0.d
./etc/rc.d/rc6.d
./etc/rc.d/rc3.d
./usr/share
./var/net-snmp
./var/net-snmp/mib_indexes
./var/ipfire/ovpn/certs
./var/cache/ldconfig
./var/db/sudo/lectured
./var/lib/tor
./var/lib/tor/diff-cache
./var/lib/tor/stats
./var/lib/tor/keys
./var/lib/sasl
./var/lib/iptraf-ng

can that be right ?

3

Some of those are correct and some not. For instance the ovpn/certs should not be world readable so 700 is correct.

Read this forum post about permissions. It gives the command to only change the directories that need to be set to 755.

https://community.ipfire.org/t/trouble-when-upgrading-from-core-157-to-core-158/5842/56

1 Like
4

Thanks a lot for your message.
I did run the command mentioned

I now also changed the /etc folder as I assumed that can’t be right.

[root@ipcoffin etc]# chmod -v 755 /etc /etc/rc.d/ /etc/rc.d/rc0.d/ /etc/rc.d/rc6.d/ /etc/rc.d/rc3.d/ 
mode of '/etc' retained as 0755 (rwxr-xr-x)
mode of '/etc/rc.d/' changed from 0700 (rwx------) to 0755 (rwxr-xr-x)
mode of '/etc/rc.d/rc0.d/' changed from 0700 (rwx------) to 0755 (rwxr-xr-x)
mode of '/etc/rc.d/rc6.d/' changed from 0700 (rwx------) to 0755 (rwxr-xr-x)
mode of '/etc/rc.d/rc3.d/' changed from 0700 (rwx------) to 0755 (rwxr-xr-x)

Then I re-started unbound

[root@ipcoffin rc.d]# /etc/rc.d/init.d/unbound start

Now time is in sync again and I can resolve names. YAY

Still see other errors, but I think I will plan a reboot later and check what works afterwards (Girlfriend is working from home and won’t be happy if I reboot now :face_with_head_bandage:)

5

I just checked those directories on my system and yes, they are all 755.

Hopefully you can resolve the remaining issues successfully.

6

new day and new hope to get my firewall back in it’s normal working order.
So far it seems like the last remaining issue is with the generating of graphs.

I can see this in the httpd/error_log every time i access a page in the webui that contains graphs.

(process:1457): Pango-WARNING **: 08:07:23.371: failed to choose a font, expect ugly output. engine-type='PangoRenderFc', script='latin'

(process:1459): Pango-WARNING **: 08:07:23.427: failed to choose a font, expect ugly output. engine-type='PangoRenderFc', script='common'

(process:1459): Pango-WARNING **: 08:07:23.429: failed to choose a font, expect ugly output. engine-type='PangoRenderFc', script='latin'

I changed the permissions of /etc/pango/pango.modules to 755 (was 644), but that did not change anything, even after rebooting the system.

Hope any of the experts can tell me if there is another folder that needs it’s permission adjusted.

7

Hi @rogersbarn

That file is supposed to have 644 permissions. making it 755 has made it world executable. You need to be careful at just changing permissions on spec.

There are other people on the forum who are more familiar with the graphs system and should have more of a clue as to what is causing that error message to occur.

8

just found another thing… SNMP stopped working.

It turned out that /etc/init.d/netsnmpd disappeared.
Was however easy to fix by just un-install and re-install the addon.

But makes me wonder what else got screwed during those updates. Maybe a re-installing of the whole system would make sense. After all, it is supposed to be a security device.

Of course I learned a lesson. Do not trust updates and wait before installing them!

9

Do you know if there is somewhere a list available on where which permissions should be present.
If I have to go trough the whole system and try fixing things by trial and error it will obviously take forever and be potentially very unsafe.

10

Hi @rogersbarn

No there is no simple list like that. The git repository is laid out for building IPFire.

The permissions are all done as part of the installation so you would have to read through the code for the Upgrade or Install process to find that but you are right, that would take for ever to check the permissions of every directory/file.

It seems that you have additional issues than the people who reported the original permissions issue. I would suspect that the quickest solution would be to do a fresh installation, making sure that you have all required backups downloaded to another computer or usb key.

I am not sure I would agree with you on that point. If you wait and 5 people report an issue but a hundred people have upgraded and had no problem when do you decide to upgrade? You won’t know how many people have had no problem.

The Testing release is intended to help identify any potential issues before full release but there is never very much feedback on the testing releases except from a very few regular people.

I run the testing release on a vm setup that is used purely for testing and evaluation.
When the full release comes out I upgrade after making sure I have a copy of the previous iso on a usb key, together with all the mac addresses for the interfaces and the Interface IP addresses that I use, written down on paper. If anything goes wrong I do a re-install of the old version, which takes me about 15-20 minutes.

1 Like
11

Hi @bonnietwin

Thank you very much for your ongoing responses to my post. Much appreciated.

Of course I changed the permissions back you told me shouldn’t be changed.
Changing the permission of /usr/share to 755 brought then back life to the graph creation.

So far it looks like netsnmpd was the only package that disappeared during the update and the rest seems to work ok.
I will keep an eye on it, but for now I think my firewall is back in normal working order.

If I would have a vm setup at hand I could do that too, totally agree.
However IT is not that much of my ‘hobby’ anymore (it was my job and hobby for quite some time). therefore I like to use my devices just to perform their job and not invest to much time otherwise into it.
And yes, having proper and actual backups at hand is definitely a good idea. Currently I rsync my backup folder to my NAS on regular basis. However I still have to manually trigger backups, so I might see if there is a good backup script around to create them automatically.

Thanks again for your help.
Thread can be closed, crisis averted :slight_smile:

3 Likes