Unable to check for updates from dashboard

callinectes

@stephenw10 Output, in order:

pkg-static info pkg
pkg-1.20.2
Name           : pkg
Version        : 1.20.2
Installed on   : Tue Jul 11 22:53:08 2023 EDT
Origin         : ports-mgmt/pkg
Architecture   : FreeBSD:14:amd64
Prefix         : /usr/local
Categories     : ports-mgmt
Licenses       : BSD2CLAUSE
Maintainer     : pkg@FreeBSD.org
WWW            : https://github.com/freebsd/pkg
Comment        : Package manager
Options        :
        DOCS           : off
Shared Libs provided:
        libpkg.so.4
Annotations    :
        FreeBSD_version: 1400093
        build_timestamp: 2023-07-11T22:24:13+0000
        built_by       : poudriere-git-3.3.99.20220831
        port_checkout_unclean: no
        port_git_hash  : 09a785875a27
        ports_top_checkout_unclean: yes
        ports_top_git_hash: c959ae811528
        repo_type      : binary
        repository     : pfSense
Flat size      : 38.8MiB
Description    :
Package management tool

WWW: https://github.com/freebsd/pkg

ls /var/cache/pkg/pkg*
/var/cache/pkg/pkg-1.17.5_3.pkg
/var/cache/pkg/pkg-1.17.5_3~b8e15d34b2.pkg
/var/cache/pkg/pkg-1.19.1_1.pkg
/var/cache/pkg/pkg-1.19.1_1~d54ac0ca75.pkg
/var/cache/pkg/pkg-1.20.2.pkg
/var/cache/pkg/pkg-1.20.2~269d0c3235.pkg

stephenw10

Ok, good. Make sure the update branch is set to Latest stable (2.7) again. Then force the pkg downgrade at the command line with:

pkg-static add -f /var/cache/pkg/pkg-1.19.1_1.pkg

Then recheck for upgrades.

callinectes

@stephenw10 Awesome - appears that worked:
"

"
I can't run the upgrade right now but I believe you've helped me across the only hurdle. Greatly appreciated!

stephenw10

Nice

Nibblet

Any updates for me.. ?

stephenw10

You're still seeing the dash report 'unable to check' but everything working at the CLI?

Have you tried setting IPv4 as preferred?

Nibblet

@stephenw10 That is correct. Upgrade from 2.6.0 to 2.7.0 worked fine from the CLI, but the dashboard and the update (system -> update) menu item are still showing "Unable to check for updates"

Sadly I cannot change to IPv4 as preferred as - due to the need to resolve items internally, and the complete lack of 'internal' IPv4 - this is why I need to perform 'smoke and mirrors' tricks to emulate the netgate update system in order to then point to proxies in areas of our network that DO have IPv4 connectivity out.

If there is a way to tell the update check widget to ignore system resolvers and use an internet based system (similar to squids dns_nameservers directive) then I could do this.

This is why I was wanting to know the underlying mechanism that the update widget is employing to check - as, whatever it is seems different from the pkg/pkg-static command line utilities as these are working fine.
This is a diagram of the setup - the DNS server has a 'dummy' version of the netgate SVC records that return a DNS name for the pkg servers, and the proxy is used to reach these. The proxy is squid and has the afor-mentioned DNS directive such that the proxy can resolve internet entries and reach them, yet still be part of the internal domain.

This used to work for the widget, but broke somewhere during 2.6.0 and after the transition from files00 and files01 to the new domain name

alt text

SteveITS

@Nibblet re DNS for pfSense: https://docs.netgate.com/pfsense/en/latest/config/general.html#dns-resolution-behavior

Re: IPv4: https://docs.netgate.com/pfsense/en/latest/config/advanced-networking.html#prefer-ipv4-over-ipv6
“ this option causes the firewall itself to prefer sending traffic to IPv4 hosts instead of IPv6 hosts when a DNS query returns results for both.” Doesn’t affect LAN devices.

Nibblet

@SteveITS I guess the point here is - that the firewall should never actually get an IPv4 A record response.
The DNS server in this example is not recursive and doesn't actually have A records to return.

stephenw10

@Nibblet said in Unable to check for updates from dashboard:

this is why I need to perform 'smoke and mirrors' tricks to emulate the netgate update system in order to then point to proxies in areas of our network that DO have IPv4 connectivity out.

Ha well that seems likely to be involved in this error situation!

We are digging into a problem internally though, specifically when using external proxies. Do you have a proxy configured in pfSense?

If you run pkg-static -d update via Diag > Command Prompt does it fail there when it succeeds at the real command line?

Steve

Nibblet

@stephenw10 Really weirdly, it has all started working again. Nothing changed from the perspective of DNS/proxy settings - very strange.

Also, running the update -d command would have worked, except of course that these servers were already updated..

Of note - these are in production with around 40-50 people actively connecting through them so I REALLY don't like running arbitrary commands that update packages. Hopefully this will put to bed that whatever pkg (and pkg-static) and the 'check of updates' widget are doing is different, and the widget is not calling the pkg (or pkg-static) command but rather doing its own thing - do you know where the source code for this widget would be? is there a specific package I can look the sources up for?

DBG(1)[33734]> pkg initialized
Updating pfSense-core repository catalogue...
DBG(1)[33734]> PkgRepo: verifying update for pfSense-core
DBG(1)[33734]> Pkgrepo, begin update of '/var/db/pkg/repo-pfSense-core.sqlite'
DBG(1)[33734]> Request to fetch pkg+https://pkg.pfsense.org/pfSense_v2_7_0_amd64-core/meta.conf
DBG(1)[33734]> opening libfetch fetcher
DBG(1)[33734]> Fetch > libfetch: connecting
DBG(1)[33734]> Fetch: fetching from: https://pkg01-atx.netgate.com/pfSense_v2_7_0_amd64-core/meta.conf with opts "i"
DBG(1)[33734]> Fetch: fetcher chosen: https
DBG(1)[33734]> Request to fetch pkg+https://pkg.pfsense.org/pfSense_v2_7_0_amd64-core/packagesite.pkg
DBG(1)[33734]> opening libfetch fetcher
DBG(1)[33734]> Fetch > libfetch: connecting
DBG(1)[33734]> Fetch: fetching from: https://pkg01-atx.netgate.com/pfSense_v2_7_0_amd64-core/packagesite.pkg with opts "i"
DBG(1)[33734]> Fetch: fetcher chosen: https
DBG(1)[33734]> Request to fetch pkg+https://pkg.pfsense.org/pfSense_v2_7_0_amd64-core/packagesite.txz
DBG(1)[33734]> opening libfetch fetcher
DBG(1)[33734]> Fetch > libfetch: connecting
DBG(1)[33734]> Fetch: fetching from: https://pkg01-atx.netgate.com/pfSense_v2_7_0_amd64-core/packagesite.txz with opts "i"
DBG(1)[33734]> Fetch: fetcher chosen: https
pfSense-core repository is up to date.
Updating pfSense repository catalogue...
DBG(1)[33734]> PkgRepo: verifying update for pfSense
DBG(1)[33734]> Pkgrepo, begin update of '/var/db/pkg/repo-pfSense.sqlite'
DBG(1)[33734]> Request to fetch pkg+https://pkg.pfsense.org/pfSense_v2_7_0_amd64-pfSense_v2_7_0/meta.conf
DBG(1)[33734]> opening libfetch fetcher
DBG(1)[33734]> Fetch > libfetch: connecting
DBG(1)[33734]> Fetch: fetching from: https://pkg00-atx.netgate.com/pfSense_v2_7_0_amd64-pfSense_v2_7_0/meta.conf with opts "i"
DBG(1)[33734]> Fetch: fetcher chosen: https
DBG(1)[33734]> Request to fetch pkg+https://pkg.pfsense.org/pfSense_v2_7_0_amd64-pfSense_v2_7_0/packagesite.pkg
DBG(1)[33734]> opening libfetch fetcher
DBG(1)[33734]> Fetch > libfetch: connecting
DBG(1)[33734]> Fetch: fetching from: https://pkg00-atx.netgate.com/pfSense_v2_7_0_amd64-pfSense_v2_7_0/packagesite.pkg with opts "i"
DBG(1)[33734]> Fetch: fetcher chosen: https
DBG(1)[33734]> Request to fetch pkg+https://pkg.pfsense.org/pfSense_v2_7_0_amd64-pfSense_v2_7_0/packagesite.txz
DBG(1)[33734]> opening libfetch fetcher
DBG(1)[33734]> Fetch > libfetch: connecting
DBG(1)[33734]> Fetch: fetching from: https://pkg00-atx.netgate.com/pfSense_v2_7_0_amd64-pfSense_v2_7_0/packagesite.txz with opts "i"
DBG(1)[33734]> Fetch: fetcher chosen: https
pfSense repository is up to date.
All repositories are up to date.

stephenw10

Huh, weird.

The pkg update command only updates the local cached list against the repo. pkg upgrade is required to actually upgrade anything. pkg update gets run every time it checks so everytime you visit the dashboard for example. It is generally safe to run.

Anyway glad you're back up and running.

walidbz

i run pfsense 2.7.0 and i want to upgrade pkg from 1.19.1 to 1.20.6 but an error occurs :
ld-elf.so.1: Shared object "libssl.so.30" not found, required by "pkg"
if anyone knows how can i fix this please help me .
thank you

stephenw10

You have to use pkg-static if you are already using a newer version of pkg. But in 2.7 you should be running 1.19.1_2 unless you had the dev branch set at some point.

Steve

walidbz

@stephenw10 thank you
But i did not undrestand what i am supposed to do !!

stephenw10

If you have a newer version of pkg installed than the base you have to use pkg-static instead of pkg.

So for example:

[2.7.0-RELEASE][admin@pfsense.fire.box]/root: pkg-static info -x pkg
pfSense-pkg-Shellcmd-1.0.5_3
pfSense-pkg-Status_Traffic_Totals-2.3.2_3
pfSense-pkg-System_Patches-2.2.4
pfSense-pkg-iperf-3.0.3
pfSense-pkg-nmap-1.4.4_7
pfSense-pkg-openvpn-client-export-1.9
pkg-1.19.1_2

But as you can see there you should have pkg version 1.19.1_2 in 2.7. Why are you trying to install 1.20.6? What version do you have now?

walidbz

@stephenw10 you are right i have pkg 1.19.1_2 .
i want to install wazuh-agent 4.5.0 and when i run pkg-static install wazuh-agent-4.5.0 , this is what i have :
Sans titre.png
Sans titre2.png

stephenw10

Where are you installing that from? That's not the CE pkg repo so it;s pulling in some unknown version of pkg.

walidbz

@stephenw10 i want to install wazuh-agent on my psfense VMware virtual machine
pfsense 2.7.0 release
freeBSD 14

walidbz

@stephenw10 now i got this
Sans titre3.png