Cannot upgrade packages on 10.3 update

Oldrancher

Oldrancher

Yesterday, I set out to upgrade my FreeBSD 10.3 system. I was able to complete the basic update and do a subversion update of /usr/ports.

To make what is a very long story short, pkg will not download anything from
http://pkg.FreeBSD.org/FreeBSD:10:amd64/quarterly/All/.

Here is an attempt to install firefox
Code: 
# pkg install firefox
Updating FreeBSD repository catalogue...
FreeBSD repository is up to date.
All repositories are up to date.
The following 32 package(s) will be affected (of 0 checked):

Installed packages to be REMOVED:
        cups-client-2.0.3_2
        cups-image-2.0.3_2

New packages to be INSTALLED:
        firefox: 53.0.3,1
        trousers: 0.3.14_1
        tpm-emulator: 0.7.4_1
        libunistring: 0.9.7
        gtk2: 2.24.29_3
        cups: 2.2.2_1
        webp: 0.5.2_1
        giflib: 5.1.4
        libav: 11.8
        libvdpau: 1.1.1
        libva: 1.7.3
        opencv2-core: 2.4.13.1_1
        opencv2: 2.4.13.1_6
        vo-aacenc: 0.1.3_1
        x265: 2.3
        ghostscript9-agpl-base: 9.16_5

Installed packages to be UPGRADED:
        gnutls: 3.3.17.1 -> 3.5.9
        nettle: 2.7.1 -> 3.3
        ghostscript9-base: 9.06_11 -> 9.06_13
        gtk3: 3.16.7_2 -> 3.18.8_4
        gnupg: 2.1.8 -> 2.1.21
        texlive-base: 20150521_6 -> 20150521_15
        libgd: 2.1.0_7,1 -> 2.2.4,1
        libvpx: 1.5.0 -> 1.6.1_1
        ffmpeg: 2.8.6,1 -> 3.2.4_7,1
        libgphoto2: 2.5.9 -> 2.5.12
        glib-networking: 2.44.0 -> 2.46.1_1
        hunspell: 1.3.3 -> 1.6.1
        libx264: 0.144.2533_1 -> 0.148.2728_1

Installed packages to be DOWNGRADED:
        vte3: 0.48.3 -> 0.42.4_2

Number of packages to be removed: 2
Number of packages to be installed: 16
Number of packages to be upgraded: 13
Number of packages to be downgraded: 1

The process will require 308 MiB more space.
54 MiB to be downloaded.

Proceed with this action? [y/N]: y
pkg: http://pkg.FreeBSD.org/FreeBSD:10:amd64/quarterly/All/gtk3-3.18.8_4.txz: Operation timed out
#

I have tried building ports, but too much is broken with basic needs, and I cannot install the needed packages, either.

Hank
 
tingo said:
Then you have a connectivity issue. can you ping pkg.freebsd.org?
Click to expand...
Yes, I can ping the site. Actually, I have connected to it, gone to the http://pkg.freebsd.org/FreeBSD:10:amd64/quarterly/All/ directory, found the gtk3-3.18.8_4.txz and downloaded it. I put it in the FreeBSD /var/cache/pkg directory, but that doesn't satisfy the requirement.
The other files in that directory are symbolic links to files with a checksum in the name, but the download is the filename alone.

I am using a Solaris system that is another node on the same network as the FreeBSD system to do this administration. However, I see nothing wrong in the
FreeBSD installation configuration and routing tables, and can download from other sites.

If there is a way to do a workaround download, I need to know what it is.
 
Since your post mentions the Solaris machine, and I'm unclear on what you answered: can you ping pkg.freebsd.org from the FreeBSD machine that you are trying to run the pkg command from?
I still think your FreeBSD machine has a connectivity issue.
 
tingo said:
Since your post mentions the Solaris machine, and I'm unclear on what you answered: can you ping pkg.freebsd.org from the FreeBSD machine that you are trying to run the pkg command from?
I still think your FreeBSD machine has a connectivity issue.
Click to expand...

To be specific, all of my connectivity tests have been from the FreeBSD system I am trying to upgrade. That includes ping.
Code: 
# ping pkg.freebsd.org
PING pkgmir.geo.freebsd.org (149.20.1.201): 56 data bytes
64 bytes from 149.20.1.201: icmp_seq=0 ttl=54 time=47.237 ms
64 bytes from 149.20.1.201: icmp_seq=1 ttl=54 time=57.386 ms
64 bytes from 149.20.1.201: icmp_seq=2 ttl=54 time=43.750 ms
64 bytes from 149.20.1.201: icmp_seq=3 ttl=54 time=40.747 ms
64 bytes from 149.20.1.201: icmp_seq=4 ttl=54 time=42.057 ms
64 bytes from 149.20.1.201: icmp_seq=5 ttl=54 time=46.259 ms
64 bytes from 149.20.1.201: icmp_seq=6 ttl=54 time=40.670 ms
64 bytes from 149.20.1.201: icmp_seq=7 ttl=54 time=42.059 ms
64 bytes from 149.20.1.201: icmp_seq=8 ttl=54 time=38.046 ms
64 bytes from 149.20.1.201: icmp_seq=9 ttl=54 time=40.734 ms
64 bytes from 149.20.1.201: icmp_seq=10 ttl=54 time=44.094 ms
^C
--- pkgmir.geo.freebsd.org ping statistics ---
11 packets transmitted, 11 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 38.046/43.913/57.386/4.955 ms
#
 
Does fetch http://pkg.FreeBSD.org/FreeBSD:10:amd64/quarterly/All/gtk3-3.18.8_4.txz work?

Is there perhaps a (transparent) proxy in between?
 
SirDice said:
Does fetch http://[FILE]pkg.FreeBSD.org[/FILE]/FreeBSD:10:amd64/quarterly/All/gtk3-3.18.8_4.txz work?

Is there perhaps a (transparent) proxy in between?
Click to expand...

There shouldn't be. The topology here is pretty simple. Both the Solaris and FreeBSD machines connect through a Fortigate 30D firewall to my upstream feed through a radio link.
All IP's are static, and I do not have wifi. I programmed the FG 30D over a year ago, and was able to install packages on the FreeBSD box afterward (May '16). I also ssh
outside my system, and have gotten no checksum squawks over the past year.

I also noted that (recently) I was able to download fresh distfile files and pkg files, and the only block seems to be when trying to download from pkg.FreeBSD.org
 
It could be the Fortigate, some models have IPS features. That could be triggering on a false positive.
Oldrancher said:
I programmed the FG 30D over a year ago, and was able to install packages on the FreeBSD box afterward (May '16).
Click to expand...
Are you able to check its logs? Perhaps there's something automatic being triggered. Won't hurt to look, even if it's only to rule it out as a possible cause.
 
SirDice said:
It could be the Fortigate, some models have IPS features. That could be triggering on a false positive.
Click to expand...

"Some models have IPS features." ???!!! Fortinet firewalls are tops for IPS features, when run with the UTM (Universal Threat Management) subscription.
Two years ago I went through a real siege of script kiddie probes to my systems, denial of service, etc., so that Fortigate (which was a replacement for a failing unit) is programmed to the hilt. And, quite by coincidence, Fedex delivered a Fortigate 60D with UTM this afternoon, which will replace an old FG-60, which is long since EOL, though it's better than most consumer units, even without UTM.

For a quick test on the FreeBSD box, I switched over to the old FG-60 route to the outside, and it appears that I can download without blocking. I am going to investigate whether the firewall or upstream of the IP is doing the blocking.
 
Wild guess: the subscription service (who is crazy enough to run a service on his / her firewall that is outside of your control? That's just asking for a denial-of-service to happen) has downloaded and installed new rules, which now is responsible for blocking your pkg downloads.
 
tingo said:
Wild guess: the subscription service (who is crazy enough to run a service on his / her firewall that is outside of your control? That's just asking for a denial-of-service to happen) has downloaded and installed new rules, which now is responsible for blocking your pkg downloads.
Click to expand...

I'd have to ask: just what are you trying to contribute here? Sir Dice has suggested I consider the Fortigate's IPS as a possible cause of my inability to download packages.
I am putting a plan in place to pinpoint the problem. My initial post was to determine whether the pkg.freebsd.org was up or down, before trying to troubleshoot further.

While I consider any detailed discussion of Fortinet products here to be wildly off topic, let me be specific that I have used Fortigate firewalls since 2005, and recommend them highly to those who can benefit from a top-quality security product. Also let me specific that what firewall is programmed to block, both intrinsically and through the UTM service, is both visible to the user and can be switched off under user control. If I run through a sequence of tests that identifies a false positive block, I can bring that up with Fortinet support.

Right now, any idea that the FG-30D and/or UTM are responsible for the problems I've had is strictly hypothetical, and will remain so until proven. That is a low priority task at the moment.
As to site security and configuration, I have responsibilties not only for my site, but others as well. Crazy? As the French say, "Folle comme un renard." I don't work alone on security management.
 
You must log in or register to reply here.
Back
Top