First upgrade - considerations

Hi All,

I’m preparing my machine for an upgrade from 10.3 to 11.1, this is the first time I’ll be doing it and I’ll most likely take the freebsd-update route. However, I do have a couple of questions which weren’t necessarily addressed by other posts and/or articles.

  1. Apart from tinkering with the system, what are the other advantages of rebuilding world? I’m particularly interested in understanding whether there are any performance benefits if I compile versus install binary packages? I’m guessing the performance difference, if any, would be minimal.

  2. The current system uses both ports and packages. I recently discovered that this is a sub-prime solution as pkg and ports try to install the same dependencies, in the same place and problems arise. My concern is that if I need to upgrade packages and ports in 11.1, it might blow up due to the fact that I’m using both. I’m thinking I could dump ports and go with pkg prior to upgrading the system. Worthwhile / necessary / not that important – please advise?

Thanks & regards,
Janusz
 
Regarding your second point, you might run into problems if you build ports using non-default configuration; for example, enabling features that disabled by default -- installing stock binary package after upgrade might exclude those particular features.

For example I have built www/nginx with OpenResty enabled. Installing binary nginx package will disable OpenResty (and will make nginx unable to start, as respective modules will be no more).

Is this a desktop or a server?
 
It's a server. I'm aware of the limited configurability of packages. I've not performed any analysis on that yet, but I think I should be fine with 99% of software using default options. Nginx is a good example of a package I'd like to modify in order to remove service identification (via config you can remove Nginx version but not the entire server signature).

The key question for now is whether the mixed pkg/ports environment would be problematic from a system upgrade perspective. If I need to rebuild/reinstall all software, then I can potentially see issues with either pkg or portmaster screaming that there are files installed already in a given directory... Other than that, is there anything else that comes to mind?
 
Apart from tinkering with the system, what are the other advantages of rebuilding world?
None.
My concern is that if I need to upgrade packages and ports in 11.1, it might blow up due to the fact that I’m using both. I’m thinking I could dump ports and go with pkg prior to upgrading the system. Worthwhile / necessary / not that important – please advise?
One of the first things you need to do after updating is to re-install everything. That's a good enough time to do it. Just run:
Code:
pkg-static install -f pkg
pkg upgrade -f

The key question for now is whether the mixed pkg/ports environment would be problematic from a system upgrade perspective.
You might want to consider setting up your own repository. That will give you the best of both worlds. It will allow you to modify options while keeping the ease of use of packages.
 
If I understand how ports/packages works correctly, ports collection is one way to allow you to customize specific packages. Meaning, to tune them, to toggle options that you need, that have other value in the binary packages (installed using pkg install <package-name> and fetched from FreeBSD package repository).

That aside, there is no difference between ports and packages. Both are tracked via pkg(8) and when you do make install on a port, it is also listed by pkg info and can be manipulated -- deleted or upgraded/reinstalled -- using pkg.

Please let me know if I'm (that fundamentally) wrong.
 
Thanks both. I'll keep it simple and stick with ports. Doubt a repository would be needed.
 
Hi All,

I’m preparing my machine for an upgrade from 10.3 to 11.1, this is the first time I’ll be doing it and I’ll most likely take the freebsd-update route. However, I do have a couple of questions which weren’t necessarily addressed by other posts and/or articles.

Interesting. My understanding was always that FreeBSD just like Red Hat doesn't support upgrade between major
version releases (mean from 9.xxx to 10.xxx to 11.xxx). If it did then it should be as easy as
Code:
freebsd-update fetch
freebsd-update install
pkg upgrade
I upgrade by exporting the ZFS pool, reinstalling OS in its own mirror and then importing pool again. I always keep the configuration files in version control system and use sysutils/ansible playbooks (also keep them in some kind version control system) to configure servers.


  1. A part from tinkering with the system, what are the other advantages of rebuilding world? I’m particularly interested in understanding whether there are any performance benefits if I compile versus install binary packages? I’m guessing the performance difference, if any, would be minimal.

None if you ask me. Speaking of packages the only "advantage" I personally see is that FreeBSD ports use non-reproducible builds and lacks the package flavors. Thus if you need a feature which is not compiled into the default package build you have no option but to use the port. My understanding is that package flavors are in works.

  1. The current system uses both ports and packages. I recently discovered that this is a sub-prime solution as pkg and ports try to install the same dependencies, in the same place and problems arise. My concern is that if I need to upgrade packages and ports in 11.1, it might blow up due to the fact that I’m using both. I’m thinking I could dump ports and go with pkg prior to upgrading the system. Worthwhile / necessary / not that important – please advise?

Thanks & regards,
Janusz
That is to be expected. On the systems which use reproducible builds like OpenBSD mixing ports and packages would not matter because every port (port flavor if you want to be more precise) has unique options and packages look always the same whether built locally or fetched from the build server. Unless you have to use ports (due to the lack of flavors) to include non-default feature I would not even bother to install ports tree. IMHO regular users (I consider myself a regular user) have no business compiling kernel and building ports.
 
I personally see is that FreeBSD ports use non-reproducible builds and lacks the package flavors.
You can do reproducible builds with ports-mgmt/poudriere, and yes FLAVORs are already a reality but incomplete yet.

About reproducible builds, you may want to take a look in HERE.

The current system uses both ports and packages. I recently discovered that this is a sub-prime solution as pkg and ports try to install the same dependencies, in the same place and problems arise. My concern is that if I need to upgrade packages and ports in 11.1, it might blow up due to the fact that I’m using both. I’m thinking I could dump ports and go with pkg prior to upgrading the system. Worthwhile / necessary / not that important – please advise?

I would like to kindly advise you to not mix pre-built and ports if you want to keep your system stable, but create you own repository using ports-mgmt/poudriere (or ports-mgmt/synth)

Info: POUDRIERE, POUDRIERE.

However, if you need/prefer to have more predicable/controlled updates, you may want to take a look on Ravenports too.

Cheers!
 
SirDice - thanks, I read it a bit too late but fortunately I was on p29 from what I recall. One odd thing that happened post upgrade is the fact that the system no longer accepts 'defaultrouter' from rc.conf. Added a default route manually but it won't persist post reboot. Any ideas how to quickly fix that? Must be something tiny... :)
 
Strange. The setting "defaultrouter" works excellently for me, and I'm on 11.1 (upgraded from 11.0).

Are you sure your /etc/rc.d/routing is undamaged? Here is its checksum: "# cksum /etc/rc.d/routing" gives 2244346791 7920 (this is for 11.1p9). And here is a small snippet from the function static_inet (which starts in line 146 of that file, this snippet starts in line 159), for you to compare:
Code:
    # Add default route.
        case ${defaultrouter} in
        [Nn][Oo] | '')
                ;;
        *)
                static_routes="${static_routes} _default"
                route__default="default ${defaultrouter}"
                ;;
    esac

P.S. Also make sure it is spelled correctly in /etc/rc.conf.
 
Thanks ralphbsz - I got the same checksum, static_inet function is exactly the same, and rc.conf's spelling is correct. I've not changed rc.conf for ages and from what I see the upgrade didn't modify the file either. The only thing that comes to mind is potentially different treatment of the following?
Code:
netwait_enable="YES"
netwait_ip="192.168.1.1"
netwait_if="bge1"

Although I highly doubt it. :)
 
Strange. I don't use any netwait_ on my machine, because the networks are all on the motherboard, and are all present right at boot. I looked at /etc/rc.d/netwait, and didn't see where it messes with the default router, so it is probably innocent (but it might still do it as a side effect, or I missed it).

Do you really need nitwait? It is intended for when the networking hardware shows up late or asynchronously during boot, and you have a bge ethernet, which should be PCI based.
 
Yup, sure:
Code:
hostname="..."
ifconfig_bge0="inet 192.168.1.220 netmask 255.255.255.0"
ifconfig_bge1="inet 192.168.1.2 netmask 255.255.255.0"
defaultrouter="192.168.1.1"
netwait_enable="YES"
netwait_ip="192.168.1.1"
netwait_if="bge1"
sshd_enable="YES"
sshblock_enable="YES"
moused_enable="YES"
powerd_enable="YES"
start_enable="YES"
dumpdev="NO"
zfs_enable="YES"
samba_enable="YES"
samba_server_enable="YES"
ntpd_enable="YES"
ntpd_sync_on_start="YES"
ntpd_config="/etc/ntp.conf"
kdc_enable="YES"
kadmind_enable="YES"
performance_cx_lowest="C2"
economy_cx_lowest="C2"
coretemp_load="yes"
clear_tmp_enable="YES"
syslogd_flags="-ss"
icmp_drop_redirect="YES"
inetd_enable="NO"
fuse_enable="YES"
dbus_enable="YES"
hald_enable="YES"
gateway_enable="YES"
openvpn_enable="YES"
openvpn_if="tun"
ddclient_enable="YES"
tcp_drop_synfin="YES"
pureftpd_enable="YES"
sendmail_enable="NO"
jail_enable="YES"
ejabberd_enable="YES"
 
bge0 and bge1 are on the same subnet with default metric 0. Can you try to specify the default interface for this subnet like this:
Code:
ifconfig_bge0="inet 192.168.1.220 netmask 255.255.255.0 metric 10"
ifconfig_bge1="inet 192.168.1.2 netmask 255.255.255.0"
 
2 nics on the same network is always going to be a bit of a problem one way or the other. You can't really expect this to work out of the box, you'll have to do some tuning yourself as well.

In general these scenario's are best avoided.
 
VladiBG - thanks, I tried that and it didn't help. Any other ideas?

ShelLuser - surprising. Why would that be a problem? All devices on the network don't care about bge0 since they use IP to talk to bge1. System services bind to a specific socket so again bge0 should not be a problem. Given that previously this worked out of the box, what tuning are you referring to?

lebarondemerde - thanks, moused removed and checking out the other pointers.
 
ShelLuser - surprising. Why would that be a problem?
It's a basic TCP/IP networking issue actually, you have a bad network setup which doesn't work and only breaks things.

Quite frankly I'm curious what netstat -4rn tells you, I wouldn't be surprised if only the network traffic gets routed through one single main NIC while both your IP addresses are routed through lo0, effectively undoing any advantages you might have hoped to gain by this because only 1 NIC gets effectively used.

FreeBSD allows you to shoot yourself in the foot, but it won't go as far as to actually break your entire network (which is what would have happened here otherwise).

The problem lies in routing and the whole concept of IP based networking. You can have only 1 default route which will use only 1 network interface. That's simply the way this works.

If you were to have 2 nics on the same physical network within the same subnet then it could be theoretically possible that if a host tried to contact 192.168.1.2 it would get a response from 192.168.1.220 which would make any basic firewall ring all alarmbells and plain out refuse the incoming data because the packet signatures nor the ARP addresses wouldn't match anymore.

Or to put this in simpler terms: it would expect return data from address 'A' and get it from address 'B', thus it would be refused. This is related to the concept of statefull filtering.

You may think that you're using 2 NIC's but trust me: you're only using 1 because your current network configuration is plain out broken.
 
OK, got it - I'll investigate further and share netstat -4rn when I'm working on the system. I was under the impression that the system would not autonomously respond via bge0 if communication was destined for bge1 - why would it if it's not load balancing and routing metrics are the same? If that's a TCP/IP rule that's a different story.

If the behaviour you describe takes place it is quite likely that the external security device would indeed complain about changing traffic destinations. I'm not really using bge0 at the moment, hence no problems were experienced. However, I'm building a jail with an externally facing web server and intend to route traffic to bge0 and that would likely blow up. Thanks for the heads-up. :)

I'll see whether this is also affecting default route acceptance...
 
Sorting out bge0 resolved the issue. Netstat output difference shown below:

# netstat -4rn
default 192.168.1.1 UGS bge1
(...)


Thanks all. You learn something new every day...
 
Back
Top