How to use Git Large File Storage (git-lfs)

While working on updating my website recently I noticed this message when doing a “git push”.
> git push
Counting objects: 20, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (20/20), done.
Writing objects: 100% (20/20), 92.49 MiB | 1.10 MiB/s, done.
Total 20 (delta 6), reused 0 (delta 0)
remote: Resolving deltas: 100% (6/6), completed with 5 local objects.
remote: warning: GH001: Large files detected. You may want to try Git Large File Storage - https://git-lfs.github.com.
remote: warning: See http://git.io/iEPt8g for more information.
remote: warning: File includes/images/computers/builds/2004/VID_20170918_174906.mp4 is 67.53 MB; this is larger than GitHub's recommended maximum file size of 50.00 MB
To github.com:dsdickinson/codeuniversity.git
4c8f617..1f2b31a master -> master
 

I knew this would be a concern but hadn’t had to address it as of yet. So I decided to do some research on git-lfs to get familiar with it. These links were helpful:
https://git-lfs.github.com
https://www.youtube.com/watch?v=uLR1RNqJ1Mw
https://help.github.com/en/github/managing-large-files/versioning-large-files

Installation
> brew install git-lfs
...
Update your git config to finish installation:

# Update global git config
$ git lfs install

# Update system git config
$ git lfs install --system

Post Install
Make sure at this point you are in the repo you intend to use git-lfs in. This part you will have to do in all applicable repos it will be used in.
> git lfs install
Updated git hooks.
Git LFS initialized.

Specify file types to track.
> git lfs track "*.mp4"
Tracking "*.mp4"

Check file types being tracked.
> git lfs track
Listing tracked patterns
*.mp4 (.gitattributes)
Listing excluded patterns

Now at this point even though I had some *mp4 files added and committed to my repo already, it found these same files and changed them to use the new git-lfs module.

> git status
On branch master
Your branch is up-to-date with 'origin/master'.

Changes not staged for commit:
(use "git add ..." to update what will be committed)
(use "git checkout -- ..." to discard changes in working directory)

modified: includes/images/computers/builds/2004/VID_20170918_174906.mp4
modified: includes/images/computers/builds/2018/VID-20180201-WA0001.mp4
modified: includes/images/computers/builds/2018/VID_20180121_145056.mp4
modified: includes/images/computers/builds/2018/VID_20180125_204256.mp4

So I then added them, committed them and pushed them up again.
> git add includes/images/computers/builds/2004/VID_20170918_174906.mp4
> git add includes/images/computers/builds/2018/VID-20180201-WA0001.mp4
> git add includes/images/computers/builds/2018/VID_20180121_145056.mp4
> git add includes/images/computers/builds/2018/VID_20180125_204256.mp4

> git commit
[master 6fbfa4b] Added mp4 files to git lfs.
4 files changed, 0 insertions(+), 0 deletions(-)
rewrite includes/images/computers/builds/2004/VID_20170918_174906.mp4 (99%)
rewrite includes/images/computers/builds/2018/VID-20180201-WA0001.mp4 (100%)
rewrite includes/images/computers/builds/2018/VID_20180121_145056.mp4 (99%)
rewrite includes/images/computers/builds/2018/VID_20180125_204256.mp4 (99%)

> git push
Uploading LFS objects: 100% (4/4), 113 MB | 1.3 MB/s, done.
Counting objects: 12, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (12/12), done.
Writing objects: 100% (12/12), 1.29 KiB | 1.29 MiB/s, done.
Total 12 (delta 4), reused 0 (delta 0)
remote: Resolving deltas: 100% (4/4), completed with 4 local objects.
To github.com:dsdickinson/codeuniversity.git
1f2b31a..6fbfa4b master -> master

So the git-lfs module simply creates link references in my main repo on github.com to the new files in GitHub’s git-lfs server.

Here is how you can view the files that are being managed with git-lfs.

> git lfs ls-files
60c5be30ad * includes/images/computers/builds/2004/VID_20170918_174906.mp4
952f1a8feb * includes/images/computers/builds/2018/VID-20180201-WA0001.mp4
1a94475aa5 * includes/images/computers/builds/2018/VID_20180121_145056.mp4
4e3656ea95 * includes/images/computers/builds/2018/VID_20180125_204256.mp4

That’s pretty much all there is to it. Everything else in your GitHub workflow is the same.

Mercurial to Git Repo Conversion

Recently, I got the notice from Bitbucket that they are sunsetting Mercurial support. This means that any Mercurial repo I have hosted there needs to be converted to Git. (Yay) So here are the steps I took to do just that. A lengthier and a more detailed instruction set can be found at the following url, but I ran into a couple issues along the way that weren’t covered there, which I will describe.
https://git-scm.com/book/en/v2/Git-and-Other-Systems-Migrating-to-Git

We will be using hg-fast-export to do the conversion.
https://github.com/frej/fast-export

Setup the repos locally.

> cd /tmp/
> hg clone ssh://hg@bitbucket.org/dsdickinson/hg-repo
> git clone https://github.com/frej/fast-export.git
> git init git-repo
> cd git-repo

The following are some errors you may run into when running the hg-fast-export.sh script. Let’s fix those first:

ERROR 1:
ignoreCase

Error: The option core.ignoreCase is set to true in the git
repository. This will produce empty changesets for renames that just
change the case of the file name.
Use --force to skip this check or change the option with
git config core.ignoreCase false

FIX:
> git config core.ignoreCase false

ERROR 2:
Apparently, having hg installed is not enough, you also need the Python mercurial module installed.

Traceback (most recent call last):
File "../fast-export/hg-fast-export.py", line 6, in
from mercurial import node
ImportError: No module named mercurial

FIX:

> sudo pip install mercurial
Collecting mercurial
Downloading https://files.pythonhosted.org/packages/2b/f4/0d45d78c9f2c7a5f744a536109d22a75dcde31088a3b8651601b3c0c0cf6/mercurial-5.2.1.tar.gz (7.3MB)
|████████████████████████████████| 7.3MB 2.4MB/s
Building wheels for collected packages: mercurial
Building wheel for mercurial (setup.py) ... done
Created wheel for mercurial: filename=mercurial-5.2.1-cp27-cp27m-macosx_10_12_intel.whl size=2742327 sha256=62a2c2836a11f4d681af826ab6bca5840bfdb238dc2b66b0540f81bc784252eb
Stored in directory: /Users/steve/Library/Caches/pip/wheels/88/74/d5/bed76535d7c4d8c9ec04e34b038b5f2c5a3d88600699301c42
Successfully built mercurial
Installing collected packages: mercurial
Successfully installed mercurial-5.2.1

Now let’s do the conversion. Remember, we are running this from the new git-repo where the conversion will end up.

> ../fast-export/hg-fast-export.sh -r ../hg-repo
master: Exporting full revision 1/6 with 3/0/0 added/changed/removed files
master: Exporting simple delta revision 2/6 with 0/1/0 added/changed/removed files
master: Exporting simple delta revision 3/6 with 1/0/0 added/changed/removed files
master: Exporting simple delta revision 4/6 with 1/0/0 added/changed/removed files
master: Exporting thorough delta revision 5/6 with 2/0/0 added/changed/removed files
master: Exporting simple delta revision 6/6 with 0/1/0 added/changed/removed files
Issued 6 commands
Unpacking objects: 100% (19/19), done.
/Library/Developer/CommandLineTools/usr/libexec/git-core/git-fast-import statistics:
---------------------------------------------------------------------
Alloc'd objects: 5000
Total objects: 19 ( 2 duplicates )
blobs : 7 ( 2 duplicates 2 deltas of 7 attempts)
trees : 6 ( 0 duplicates 5 deltas of 6 attempts)
commits: 6 ( 0 duplicates 0 deltas of 0 attempts)
tags : 0 ( 0 duplicates 0 deltas of 0 attempts)
Total branches: 1 ( 1 loads )
marks: 1024 ( 6 unique )
atoms: 5
Memory total: 2344 KiB
pools: 2110 KiB
objects: 234 KiB
---------------------------------------------------------------------
pack_report: getpagesize() = 4096
pack_report: core.packedGitWindowSize = 1073741824
pack_report: core.packedGitLimit = 35184372088832
pack_report: pack_used_ctr = 2
pack_report: pack_mmap_calls = 1
pack_report: pack_open_windows = 0 / 1
pack_report: pack_mapped = 0 / 2907
---------------------------------------------------------------------

Make sure you checkout the HEAD to get to your newly imported files.

> git checkout HEAD

Let’s check the log to verify we have log bits converted.

> git log
commit 304a742c2eb8f657906fbaaadbc92acba6e08072 (HEAD -> master)
Author: Steve Dickinson 
Date:   Thu Jan 25 03:55:09 2018 +0000

 README.md edited online with Bitbucket

commit 50861d9a91287e82920f006bb7d40a8dec38be83
Merge: 84b4da3 13ffaee
Author: Steve Dickinson 
Date: Tue Aug 18 23:46:17 2015 -0400

 merge

commit 84b4da3a39e6c9c8a63bd390d07a3cb94fddec96
Author: Steve Dickinson 
Date: Tue Aug 18 23:44:44 2015 -0400

 Added license.

Finally, push your new repo up as you normally would to what ever git service you prefer. Here I’m using GitHub.

> git remote add origin git@github.com:dsdickinson/git-repo.git
> git push origin --all

All Done!

hponcfg

The hponcfg utility allows a sys-admin to configure a server’s HP iLO hardware straight from its host server via the command line. It does the magic by reading in a pre-configured XML file with the required settings. In this particular example we are going to be setting the iLO’s hostname.

First we create the XML file that hponcfg will use to set the hostname. Here we will call the XML file change_hostname.xml.

<RIBCL VERSION=”2.0″>
<LOGIN USER_LOGIN=”admin” PASSWORD=”somecoolpassword”>
<RIB_INFO MODE=”write”>
<MOD_NETWORK_SETTINGS>
<DHCP_DOMAIN_NAME value=”No”/>
<DNS_NAME value=”blackbox-con”/>
<DOMAIN_NAME value=”my.domain.net”/>
</MOD_NETWORK_SETTINGS>
</RIB_INFO>
</LOGIN>
</RIBCL>

In this example the admin user that is setup on the iLO has a password of somecoolpassword. This is the account that will actually login to the iLO and do the thing. We want to turn off getting a DHCP domain name so we give DHCP_DOMAIN_NAME a value of No. The DNS_NAME is the hostname and the DOMAIN_NAME is the domain name and tied together you get the fully qualified domain name i.e. blackbox-con.my.domain,net.

Our second step is to run the hponcfg command that reads in the XML config file and updates the hostname accordingly.

> hponcfg -f change_hostname.xml
HP Lights-Out Online Configuration utility
Version 4.3.0 Date 12/10/2013 (c) Hewlett-Packard Company, 2014
Firmware Revision = 1.13 Device type = iLO 4 Driver name = hpilo
<INFORM>Integrated Lights-Out will reset at the end of the script.</INFORM>

Please wait while the firmware is reset. This might take a minute
Script succeeded

By running this command, we have renamed our iLO hardware to blackbox-con.my.domain.net. Presumably the actual host’s hostname would be something blackbox.my.domain.net and we would want to make them both unique.

And there you have it. We have just renamed our iLO hostname.

DNS Zone Transfer

At times when working with DNS, it may be necessary to obtain a full listing of a particular zone file’s contents. We do this by performing a DNS zone transfer.

Let me first say that the term “zone transfer” is a little misleading and confused me in the beginning. To some it may imply that a transfer of files is taking place between systems. This is not the case. All that is happening is a query is made and a transfer of information is returned. That information we want to obtain is the contents of a given zone file. It may have been better termed a “zone query” but for all intents and purposes it is referred to as a zone transfer.

There are basically two steps involved in performing a zone transfer. In our example we will use the test domain of “zonetransfer.me” as the zone we want to query for our zone transfer. So the first thing we need to figure out are the authoritative DNS servers attached to that zone. To figure that out we type the following dig command:
dig -t NS <zone> (-t NS: specifies we want name server records returned)

> dig -t NS zonetransfer.me

; <<>> DiG 9.8.3-P1 <<>> NS zonetransfer.me
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40171
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;zonetransfer.me. IN NS

;; ANSWER SECTION:
zonetransfer.me. 7200 IN NS nsztm1.digi.ninja.
zonetransfer.me. 7200 IN NS nsztm2.digi.ninja.

;; Query time: 81 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)
;; WHEN: Mon Jun 11 22:59:50 2018
;; MSG SIZE  rcvd: 85

Here we can see there are two authoritative name servers for that zone: nsztm1.digi.ninja and nsztm2.digi.ninja. Now we have all the information we need to perform a zone transfer. We’ll perform our first zone transfer by using the nsztm1.digi.ninja name server and typing the following:
dig -t AXFR @<name server> <zone> (-t AXFR: specifies we want to do a zone transfer)

> dig -t AXFR @nsztm1.digi.ninja zonetransfer.me

<<>> DiG 9.8.3-P1 <<>> @nsztm1.digi.ninja zonetransfer.me axfr
; (1 server found)
;; global options: +cmd
zonetransfer.me. 7200 IN SOA nsztm1.digi.ninja. robin.digi.ninja. 2017042001 172800 900 1209600 3600
zonetransfer.me. 300 IN HINFO "Casio fx-700G" "Windows XP"
zonetransfer.me. 301 IN TXT "google-site-verification=tyP28J7JAUHA9fw2sHXMgcCC0I6XBmmoVi04VlMewxA"
zonetransfer.me. 7200 IN MX 0 ASPMX.L.GOOGLE.COM.
zonetransfer.me. 7200 IN MX 10 ALT1.ASPMX.L.GOOGLE.COM.
zonetransfer.me. 7200 IN MX 10 ALT2.ASPMX.L.GOOGLE.COM.
zonetransfer.me. 7200 IN MX 20 ASPMX2.GOOGLEMAIL.COM.
zonetransfer.me. 7200 IN MX 20 ASPMX3.GOOGLEMAIL.COM.
zonetransfer.me. 7200 IN MX 20 ASPMX4.GOOGLEMAIL.COM.
zonetransfer.me. 7200 IN MX 20 ASPMX5.GOOGLEMAIL.COM.
zonetransfer.me. 7200 IN A 5.196.105.14
zonetransfer.me. 7200 IN NS nsztm1.digi.ninja.
zonetransfer.me. 7200 IN NS nsztm2.digi.ninja.
_sip._tcp.zonetransfer.me. 14000 IN SRV 0 0 5060 www.zonetransfer.me.
14.105.196.5.IN-ADDR.ARPA.zonetransfer.me. 7200 IN PTR www.zonetransfer.me.
asfdbauthdns.zonetransfer.me. 7900 IN AFSDB 1 asfdbbox.zonetransfer.me.
asfdbbox.zonetransfer.me. 7200 IN A 127.0.0.1asfdbvolume.zonetransfer.me. 7800 IN AFSDB 1 asfdbbox.zonetransfer.me.
canberra-office.zonetransfer.me. 7200 IN A 202.14.81.230
cmdexec.zonetransfer.me. 300 IN TXT "\; ls"
contact.zonetransfer.me. 2592000 IN TXT "Remember to call or email Pippa on +44 123 4567890 or pippa@zonetransfer.me when making DNS changes"
dc-office.zonetransfer.me. 7200 IN A 143.228.181.132
deadbeef.zonetransfer.me. 7201 IN AAAA dead:beaf::
dr.zonetransfer.me. 300 IN LOC 53 20 56.558 N 1 38 33.526 W 0.00m 1m 10000m 10m
DZC.zonetransfer.me. 7200 IN TXT "AbCdEfG"
email.zonetransfer.me. 2222 IN NAPTR 1 1 "P" "E2U+email" "" email.zonetransfer.me.zonetransfer.me.
email.zonetransfer.me. 7200 IN A 74.125.206.26
home.zonetransfer.me. 7200 IN A 127.0.0.1
Info.zonetransfer.me. 7200 IN TXT "ZoneTransfer.me service provided by Robin Wood - robin@digi.ninja. See http://digi.ninja/projects/zonetransferme.php for more information."
internal.zonetransfer.me. 300 IN NS intns1.zonetransfer.me.
internal.zonetransfer.me. 300 IN NS intns2.zonetransfer.me.
intns1.zonetransfer.me. 300 IN A 81.4.108.41
intns2.zonetransfer.me. 300 IN A 167.88.42.94
office.zonetransfer.me. 7200 IN A 4.23.39.254
ipv6actnow.org.zonetransfer.me. 7200 IN AAAA 2001:67c:2e8:11::c100:1332
owa.zonetransfer.me. 7200 IN A 207.46.197.32
robinwood.zonetransfer.me. 302 IN TXT "Robin Wood"
rp.zonetransfer.me. 321 IN RP robin.zonetransfer.me. robinwood.zonetransfer.me.
sip.zonetransfer.me. 3333 IN NAPTR 2 3 "P" "E2U+sip" "!^.*$!sip:customer-service@zonetransfer.me!" .
sqli.zonetransfer.me. 300 IN TXT "' or 1=1 --"
sshock.zonetransfer.me. 7200 IN TXT "() { :]}\; echo ShellShocked"
staging.zonetransfer.me. 7200 IN CNAME www.sydneyoperahouse.com.
alltcpportsopen.firewall.test.zonetransfer.me. 301 IN A 127.0.0.1
testing.zonetransfer.me. 301 IN CNAME www.zonetransfer.me.
vpn.zonetransfer.me. 4000 IN A 174.36.59.154
www.zonetransfer.me. 7200 IN A 5.196.105.14
xss.zonetransfer.me. 300 IN TXT "'>"
zonetransfer.me. 7200 IN SOA nsztm1.digi.ninja. robin.digi.ninja. 2017042001 172800 900 1209600 3600
;; Query time: 112 msec
;; SERVER: 81.4.108.41#53(81.4.108.41)
;; WHEN: Mon Jun 11 23:11:07 2018
;; XFR size: 48 records (messages 1, bytes 1864)

All of that output is what is contained in that zone file (zonetransfer.me) on that name server (nsztm1.digi.ninja). If we wanted, we could perform the same command on the other name server, nsztm2.digi.ninja, and we would then have the contents of that same zone but from the other name server. The output should be relatively similar.

There you have it. We have now performed a complete set of zone transfers for a given domain.

 

Upgrading iocage jails from FreeBSD 10.3 to 11.0 (major upgrade)

Iocage makes upgrading jails quite simple. It can be a little more involved than the host upgrade but not by much.

First on the host server we need to fetch the right version of FreeBSD for iocage to use. This will create the iocage zfs file system structures for upgrading to and building 11.0 jails.

$ sudo iocage fetch 11.0-RELEASE

$ zfs list
NAME                                                              USED  AVAIL  REFER  MOUNTPOINT
pgdata                                                           7.63G   262G    19K  legacy
pgdata/pg94                                                      7.63G   262G  7.63G  /pg94
sys                                                               257G   580G    19K  legacy
sys/ROOT                                                         2.27G   580G    19K  legacy
sys/ROOT/default                                                 2.27G   580G  1.38G  /
sys/home                                                         4.62G   580G  4.60G  /home
sys/iocage                                                       94.2G   580G  24.9G  /iocage
sys/iocage/.defaults                                               28K   580G    19K  /iocage/.defaults
sys/iocage/base                                                  1.35G   580G    19K  /iocage/base
sys/iocage/base/10.3-RELEASE                                      655M   580G    19K  /iocage/base/10.3-RELEASE
sys/iocage/base/10.3-RELEASE/root                                 655M   580G  69.5M  /iocage/base/10.3-RELEASE/root
sys/iocage/base/10.3-RELEASE/root/bin                             804K   580G   790K  /iocage/base/10.3-RELEASE/root/bin
sys/iocage/base/10.3-RELEASE/root/boot                           1.24M   580G  1.23M  /iocage/base/10.3-RELEASE/root/boot
sys/iocage/base/10.3-RELEASE/root/lib                            5.35M   580G  5.34M  /iocage/base/10.3-RELEASE/root/lib
sys/iocage/base/10.3-RELEASE/root/libexec                         196K   580G   185K  /iocage/base/10.3-RELEASE/root/libexec
sys/iocage/base/10.3-RELEASE/root/rescue                         4.94M   580G  4.93M  /iocage/base/10.3-RELEASE/root/rescue
sys/iocage/base/10.3-RELEASE/root/sbin                           3.81M   580G  3.79M  /iocage/base/10.3-RELEASE/root/sbin
sys/iocage/base/10.3-RELEASE/root/usr                             569M   580G    21K  /iocage/base/10.3-RELEASE/root/usr
sys/iocage/base/10.3-RELEASE/root/usr/bin                        48.0M   580G  47.9M  /iocage/base/10.3-RELEASE/root/usr/bin
sys/iocage/base/10.3-RELEASE/root/usr/include                    8.11M   580G  7.94M  /iocage/base/10.3-RELEASE/root/usr/include
sys/iocage/base/10.3-RELEASE/root/usr/lib                        39.7M   580G  39.7M  /iocage/base/10.3-RELEASE/root/usr/lib
sys/iocage/base/10.3-RELEASE/root/usr/lib32                      39.0M   580G  38.9M  /iocage/base/10.3-RELEASE/root/usr/lib32
sys/iocage/base/10.3-RELEASE/root/usr/libdata                     139K   580G   127K  /iocage/base/10.3-RELEASE/root/usr/libdata
sys/iocage/base/10.3-RELEASE/root/usr/libexec                    1.80M   580G  1.75M  /iocage/base/10.3-RELEASE/root/usr/libexec
sys/iocage/base/10.3-RELEASE/root/usr/sbin                       8.08M   580G  8.07M  /iocage/base/10.3-RELEASE/root/usr/sbin
sys/iocage/base/10.3-RELEASE/root/usr/share                      29.9M   580G  29.5M  /iocage/base/10.3-RELEASE/root/usr/share
sys/iocage/base/10.3-RELEASE/root/usr/src                         394M   580G   389M  /iocage/base/10.3-RELEASE/root/usr/src
sys/iocage/base/11.0-RELEASE                                      724M   580G    19K  /iocage/base/11.0-RELEASE
sys/iocage/base/11.0-RELEASE/root                                 724M   580G  47.2M  /iocage/base/11.0-RELEASE/root
sys/iocage/base/11.0-RELEASE/root/bin                             824K   580G   824K  /iocage/base/11.0-RELEASE/root/bin
sys/iocage/base/11.0-RELEASE/root/boot                           1.48M   580G  1.48M  /iocage/base/11.0-RELEASE/root/boot
sys/iocage/base/11.0-RELEASE/root/lib                            5.96M   580G  5.96M  /iocage/base/11.0-RELEASE/root/lib
sys/iocage/base/11.0-RELEASE/root/libexec                         192K   580G   192K  /iocage/base/11.0-RELEASE/root/libexec
sys/iocage/base/11.0-RELEASE/root/rescue                         5.75M   580G  5.75M  /iocage/base/11.0-RELEASE/root/rescue
sys/iocage/base/11.0-RELEASE/root/sbin                           3.99M   580G  3.99M  /iocage/base/11.0-RELEASE/root/sbin
sys/iocage/base/11.0-RELEASE/root/usr                             658M   580G   120K  /iocage/base/11.0-RELEASE/root/usr
sys/iocage/base/11.0-RELEASE/root/usr/bin                        77.8M   580G  77.8M  /iocage/base/11.0-RELEASE/root/usr/bin
sys/iocage/base/11.0-RELEASE/root/usr/include                    8.08M   580G  8.08M  /iocage/base/11.0-RELEASE/root/usr/include
sys/iocage/base/11.0-RELEASE/root/usr/lib                        48.7M   580G  48.7M  /iocage/base/11.0-RELEASE/root/usr/lib
sys/iocage/base/11.0-RELEASE/root/usr/lib32                      40.8M   580G  40.8M  /iocage/base/11.0-RELEASE/root/usr/lib32
sys/iocage/base/11.0-RELEASE/root/usr/libdata                     129K   580G   129K  /iocage/base/11.0-RELEASE/root/usr/libdata
sys/iocage/base/11.0-RELEASE/root/usr/libexec                    1.91M   580G  1.91M  /iocage/base/11.0-RELEASE/root/usr/libexec
sys/iocage/base/11.0-RELEASE/root/usr/sbin                       8.57M   580G  8.57M  /iocage/base/11.0-RELEASE/root/usr/sbin
sys/iocage/base/11.0-RELEASE/root/usr/share                      38.4M   580G  38.4M  /iocage/base/11.0-RELEASE/root/usr/share
sys/iocage/base/11.0-RELEASE/root/usr/src                         434M   580G   434M  /iocage/base/11.0-RELEASE/root/usr/src

 

$ sudo iocage upgrade jail01 -r 11.0-RELEASE
* Creating back-out snapshot.
* Upgrading jail.
Looking up update.FreeBSD.org mirrors... 4 mirrors found.
Fetching metadata signature for 10.3-RELEASE from update4.freebsd.org... done.
Fetching metadata index... done.
Fetching 1 metadata patches. done.
Applying metadata patches... done.
Fetching 1 metadata files... done.
Inspecting system... done.

The following components of FreeBSD seem to be installed:
kernel/generic src/src world/base world/doc world/lib32

The following components of FreeBSD do not seem to be installed:
world/games

Does this look reasonable (y/n)? y

Fetching metadata signature for 11.0-RELEASE from update4.freebsd.org... done.
Fetching metadata index... done.
Fetching 1 metadata patches. done.
Applying metadata patches... done.
Fetching 1 metadata files... done.
Inspecting system... done.
Fetching files from 10.3-RELEASE for merging... done.
Preparing to download files... done.
Fetching 45107 patches.....10....20....30.  done.
Applying patches... done.
Fetching 12420 files...

Now we need to upgrade all the packages in the jail.

$ sudo iocage console jail01
$ pkg-static install -f pkg
$ pkg upgrade
Shared object "libssl.so.7" not found, required by "pkg"

Here we have an issue with the old pkg binary which is linking to a version of libssl that no longer exists. To fix this we need to reinstall the pkg binary.

$ pkg-static install -f pkg
pkg-static: Warning: Major OS version upgrade detected.  Running "pkg-static install -f pkg" recommended
Updating FreeBSD repository catalogue...
FreeBSD repository is up-to-date.
All repositories are up-to-date.
New version of pkg detected; it needs to be installed first.
The following 1 package(s) will be affected (of 0 checked):

Installed packages to be UPGRADED:
        pkg: 1.8.8 -> 1.9.4_1

Number of packages to be upgraded: 1

3 MiB to be downloaded.

Proceed with this action? [y/N]: y
[blackbox@mars.com] Fetching pkg-1.9.4_1.txz: 100%    3 MiB   2.9MB/s    00:01
Checking integrity... done (0 conflicting)
[blackbox@mars.com] [1/1] Upgrading pkg from 1.8.8 to 1.9.4_1...
[blackbox@mars.com] [1/1] Extracting pkg-1.9.4_1: 100%
Updating FreeBSD repository catalogue...
FreeBSD repository is up-to-date.
All repositories are up-to-date.
Checking integrity... done (0 conflicting)
The following 1 package(s) will be affected (of 0 checked):

Installed packages to be REINSTALLED:
        pkg-1.9.4_1

Number of packages to be reinstalled: 1

Proceed with this action? [y/N]: y
[1/1] Reinstalling pkg-1.9.4_1...
[1/1] Extracting pkg-1.9.4_1: 100%

Now let’s see if it works.

$ pkg info
alsa-lib-1.1.2                 ALSA compatibility library
ap24-mod_perl2-2.0.9,3         Embeds a Perl interpreter in the Apache server
apache24-2.4.23_1              Version 2.4.x of Apache web server
apr-1.5.2.1.5.4_1              Apache Portability Library
augeas-1.4.0                   Configuration editing tool
...

It works! Let’s continue upgrading the packages..

$ pkg upgrade
Updating FreeBSD repository catalogue...
FreeBSD repository is up-to-date.
All repositories are up-to-date.
Checking for upgrades (324 candidates): 100%
Processing candidates (324 candidates): 100%
The following 353 package(s) will be affected (of 0 checked):

New packages to be INSTALLED:
 readline: 6.3.8
 p5-Sub-Quote: 2.003001
 p5-List-UtilsBy: 0.10
 p5-Math-Random-Secure: 0.06_1
 p5-Any-Moose: 0.26
...

Installed packages to be UPGRADED:
 zsh: 5.2_3 -> 5.3.1
 xproto: 7.0.28 -> 7.0.31
 wget: 1.18 -> 1.18_2
 vim-lite: 8.0.0019_1 -> 8.0.0134_1
...

Installed packages to be REINSTALLED:
 zfs-stats-1.2.2_1 (ABI changed: 'freebsd:10:x86:64' -> 'freebsd:11:x86:64')
 xextproto-7.3.0 (ABI changed: 'freebsd:10:x86:64' -> 'freebsd:11:x86:64')
 unzip-6.0_7 (ABI changed: 'freebsd:10:x86:64' -> 'freebsd:11:x86:64')
 unixODBC-2.3.4 (ABI changed: 'freebsd:10:x86:64' -> 'freebsd:11:x86:64')
...

Number of packages to be installed: 29
Number of packages to be upgraded: 86
Number of packages to be reinstalled: 238

The process will require 46 MiB more space.
203 MiB to be downloaded.

Proceed with this action? [y/N]:
[blackbox@mars.com] Fetching zsh-5.3.1.txz: 100% 4 MiB 4.1MB/s 00:01
[blackbox@mars.com] Fetching zfs-stats-1.2.2_1.txz: 100% 9 KiB 9.5kB/s 00:01
[blackbox@mars.com] Fetching xproto-7.0.31.txz: 100% 59 KiB 60.2kB/s 00:01
[blackbox@mars.com] Fetching xextproto-7.3.0.txz: 100% 21 KiB 21.9kB/s 00:01
[blackbox@mars.com] Fetching wget-1.18_2.txz: 100% 578 KiB 592.2kB/s 00:01
[blackbox@mars.com] Fetching vim-lite-8.0.0134_1.txz: 100% 5 MiB 5.5MB/s 00:01
...

Number of packages to be installed: 29
Number of packages to be upgraded: 85
Number of packages to be reinstalled: 238

The process will require 46 MiB more space.

Proceed with this action? [y/N]:


[blackbox@mars.com] [1/354] Upgrading perl5 from 5.20.3_15 to 5.24.1.r4_1...
[blackbox@mars.com] [1/354] Extracting perl5-5.24.1.r4_1: 100%
[blackbox@mars.com] [2/354] Reinstalling p5-Sub-Install-0.928_1...
[blackbox@mars.com] [2/354] Extracting p5-Sub-Install-0.928_1: 100%
...
[blackbox@mars.com] [54/354] Installing libassuan-2.4.3...
[blackbox@mars.com] [54/354] Extracting libassuan-2.4.3: 100%
[blackbox@mars.com] [55/354] Installing libtasn1-4.9...
[blackbox@mars.com] [55/354] Extracting libtasn1-4.9: 100%
[blackbox@mars.com] [56/354] Installing tpm-emulator-0.7.4_1...
===> Creating groups.
Creating group '_tss' with gid '601'.
===> Creating users
Creating user '_tss' with uid '601'.
pw: user '_tss' disappeared during update
pkg: PRE-INSTALL script failed

Uh oh. Houston we have a problem. No biggie. Just run this to regenerate the passwd file which will fix it.

$ vipw
:w! (to save it)

Now lets finish up the pkg  upgrade.

$ pkg upgrade
Updating FreeBSD repository catalogue...
FreeBSD repository is up-to-date.
All repositories are up-to-date.
Checking for upgrades (273 candidates): 100%
Processing candidates (273 candidates): 100%
Checking integrity... done (1 conflicting)
 - p5-Sub-Quote-2.003001 conflicts with p5-Moo-2.002004 on /usr/local/lib/perl5/site_perl/Sub/Defer.pm
Checking integrity... done (0 conflicting)
The following 298 package(s) will be affected (of 0 checked):

New packages to be INSTALLED:
 readline: 6.3.8
 p5-Sub-Quote: 2.003001
 p5-Math-Random-Secure: 0.06_1
 p5-Any-Moose: 0.26
...

Installed packages to be UPGRADED:
 zsh: 5.2_3 -> 5.3.1
 wget: 1.18 -> 1.18_2
 vim-lite: 8.0.0019_1 -> 8.0.0134_1
...

Installed packages to be REINSTALLED:
 zfs-stats-1.2.2_1 (ABI changed: 'freebsd:10:x86:64' -> 'freebsd:11:x86:64')
 xextproto-7.3.0 (ABI changed: 'freebsd:10:x86:64' -> 'freebsd:11:x86:64')
 unzip-6.0_7 (ABI changed: 'freebsd:10:x86:64' -> 'freebsd:11:x86:64')
 unixODBC-2.3.4 (ABI changed: 'freebsd:10:x86:64' -> 'freebsd:11:x86:64')
 ttcp-1.12_1 (ABI changed: 'freebsd:10:x86:64' -> 'freebsd:11:x86:64')
 tmux-2.3 (ABI changed: 'freebsd:10:x86:64' -> 'freebsd:11:x86:64')
...

Number of packages to be installed: 25
Number of packages to be upgraded: 68
Number of packages to be reinstalled: 205

The process will require 40 MiB more space.

Proceed with this action? [y/N]: y
[eastern01.cello.com] [1/298] Installing tpm-emulator-0.7.4_1...
===> Creating groups.
Using existing group '_tss'.
===> Creating users
Using existing user '_tss'.
[blackbox@mars.com] [1/298] Extracting tpm-emulator-0.7.4_1: 100%
[blackbox@mars.com] [2/298] Deinstalling p5-Moo-2.002004...
[blackbox@mars.com] [2/298] Deleting files for p5-Moo-2.002004: 100%
[blackbox@mars.com] [3/298] Reinstalling xextproto-7.3.0...
...

Finally let’s upgrade any cpan modules we have installed in the jail.

$ cpan-outdated | cpanm
--> Working on I/IB/IBB/Acme-Damn-0.08.tar.gz
Fetching http://www.cpan.org/authors/id/I/IB/IBB/Acme-Damn-0.08.tar.gz ... OK
Configuring Acme-Damn-0.08 ... OK
Building and testing Acme-Damn-0.08 ... OK
Successfully installed Acme-Damn-0.08
--> Working on K/KA/KAZEBURO/Apache-LogFormat-Compiler-0.33.tar.gz
Fetching http://www.cpan.org/authors/id/K/KA/KAZEBURO/Apache-LogFormat-Compiler-0.33.tar.gz ... OK
Configuring Apache-LogFormat-Compiler-0.33 ... OK
Building and testing Apache-LogFormat-Compiler-0.33 ... OK
Successfully installed Apache-LogFormat-Compiler-0.33
--> Working on B/BI/BINGOS/Archive-Tar-2.24.tar.gz
Fetching http://www.cpan.org/authors/id/B/BI/BINGOS/Archive-Tar-2.24.tar.gz ... OK
Configuring Archive-Tar-2.24 ... OK
Building and testing Archive-Tar-2.24 ... OK
Successfully installed Archive-Tar-2.24
...

All done!

Upgrading from FreeBSD 10.3 to 11.0 (major upgrade)

Performing a major upgrade isn’t much different from doing a minor upgrade as far as ease goes. However more can go wrong. Here we’ll discuss the basic commands to get through it.

First we want to get to the latest and greatest minor version patch level of FreeBSD.

$ sudo freebsd-update fetch
Looking up update.FreeBSD.org mirrors... 4 mirrors found.
Fetching metadata signature for 10.3-RELEASE from update6.freebsd.org... done.
Fetching metadata index... done.
Fetching 2 metadata patches.. done.
Applying metadata patches... done.
Inspecting system... done.
Preparing to download files... done.
Fetching 324 patches.....10....20....30. done.
Applying patches... done.
Fetching 40 files... done.

The following files are affected by updates, but no changes have
been downloaded because the files have been modified locally:
/etc/mail/freebsd.cf
/etc/mail/freebsd.submit.cf
/etc/mail/sendmail.cf
...

The following files will be removed as part of updating to 10.3-RELEASE-p15:
/usr/share/zoneinfo/America/Santa_Isabel
/usr/share/zoneinfo/Asia/Rangoon

The following files will be added as part of updating to 10.3-RELEASE-p15:
/usr/share/zoneinfo/Asia/Barnaul
/usr/share/zoneinfo/Asia/Famagusta
/usr/share/zoneinfo/Asia/Tomsk
/usr/share/zoneinfo/Asia/Yangon
...

The following files will be updated as part of updating to 10.3-RELEASE-p15:
/bin/freebsd-version
/lib/libc.so.7
/rescue/[
/rescue/atmconfig
/rescue/badsect
...

$ sudo freebsd-update install
Installing updates... done.

Now let’s do the major upgrade:

$ sudo freebsd-update upgrade -r 11.0-RELEASE
Looking up update.FreeBSD.org mirrors... 4 mirrors found.
Fetching metadata signature for 10.3-RELEASE from update3.freebsd.org... done.
Fetching metadata index... done.
Fetching 1 metadata patches. done.
Applying metadata patches... done.
Inspecting system... done.

The following components of FreeBSD seem to be installed:
kernel/generic src/src world/base world/games world/lib32

The following components of FreeBSD do not seem to be installed:
world/doc

Does this look reasonable (y/n)? y

Fetching metadata signature for 11.0-RELEASE from update3.freebsd.org... done.
Fetching metadata index... done.
Fetching 1 metadata patches. done.
Applying metadata patches... done.
Fetching 1 metadata files... done.
Inspecting system... done.
Fetching files from 10.3-RELEASE for merging... done.
Preparing to download files... done.
Fetching 45032 patches.....10....20....30....40....50. done.
Applying patches... done.
Fetching 12099 files... done.
Attempting to automatically merge changes in files... done.

The following file could not be merged automatically: /etc/defaults/rc.conf
Press Enter to edit this file in /usr/bin/vi and resolve the conflicts
manually...

At this point you’ll be placed into various files that have merge conflicts. They will need to be resolved. In each file you will see the markers that designate the old files content vs the new files content such as:

<<<<<<< current version
# $FreeBSD: release/10.3.0/etc/syslog.conf 194005 2014-06-11 15:07:02Z avg $
=======
# $FreeBSD: release/11.0.0/etc/syslog.conf 238473 2016-07-15 10:55:43Z brueffer $
>>>>>>> 11.0-RELEASE

Basically you will choose which content wins (typically the new content) by removing the markers and the old content. So in this example you would end up with:

# $FreeBSD: release/11.0.0/etc/syslog.conf 238473 2016-07-15 10:55:43Z brueffer $

Now we will continue on. Next you will be asked if various merges that did not have conflicts look reasonable.

The following changes, which occurred between FreeBSD 10.3-RELEASE and
FreeBSD 11.0-RELEASE have been merged into /etc/defaults/periodic.conf:
Does this look reasonable (y/n)?

The following files are affected by updates, but no changes have
been downloaded because the files have been modified locally:
/.cshrc
/.profile
/root/.cshrc
/root/.k5login
/root/.login
/root/.profile
...
To install the downloaded upgrades, run "/usr/sbin/freebsd-update install".

$ sudo freebsd-update install
$ sudo shutdown -r now

$ hostver
FreeBSD 10.3 RELEASE-p15

$ sudo freebsd-update install
Installing updates...

Completing this upgrade requires removing old shared object files.
Please rebuild all installed 3rd party software (e.g., programs
installed from the ports tree) and then run "/usr/sbin/freebsd-update install"
again to finish installing updates.

$ hostver
FreeBSD 11.0 RELEASE-p6

$ uname -r
11.0-RELEASE-p2

$ sudo shutdown -r now

Now lets upgrade the packages on the system.

$ sudo pkg upgrade
pkg: Warning: Major OS version upgrade detected.  Running "pkg-static install -f pkg" recommended
Updating FreeBSD repository catalogue...
Repository FreeBSD has a wrong packagesite, need to re-create database
Fetching meta.txz: 100%    944 B   0.9kB/s    00:01
Fetching packagesite.txz: 100%    6 MiB   5.9MB/s    00:01
Processing entries: 100%
FreeBSD repository update completed. 25901 packages processed.
New version of pkg detected; it needs to be installed first.
The following 1 package(s) will be affected (of 0 checked):

Installed packages to be UPGRADED:
        pkg: 1.9.3 -> 1.9.4_1

Number of packages to be upgraded: 1

3 MiB to be downloaded.

Proceed with this action? [y/N]: y
Fetching pkg-1.9.4_1.txz: 100%    3 MiB   2.9MB/s    00:01
Checking integrity... done (0 conflicting)
[1/1] Upgrading pkg from 1.9.3 to 1.9.4_1...
[1/1] Extracting pkg-1.9.4_1: 100%
Updating FreeBSD repository catalogue...
FreeBSD repository is up-to-date.
All repositories are up-to-date.
Checking for upgrades (102 candidates): 100%
Processing candidates (102 candidates): 100%
The following 104 package(s) will be affected (of 0 checked):

New packages to be INSTALLED:
        readline: 6.3.8
        libnghttp2: 1.18.1

Installed packages to be UPGRADED:
        zsh: 5.2_4 -> 5.3.1
        vim-lite: 8.0.0063 -> 8.0.0134_1
        trousers: 0.3.13_1 -> 0.3.14_1
        sudo: 1.8.18p1 -> 1.8.19p1
        subversion: 1.9.4 -> 1.9.5
        sqlite3: 3.14.1_1 -> 3.15.1_1
        ruby: 2.2.5_1,1 -> 2.2.6_1,1
        rsync: 3.1.2_5 -> 3.1.2_6
        python27: 2.7.12 -> 2.7.13_1
        ...

Installed packages to be REINSTALLED:
        zfs-stats-1.2.2_1 (ABI changed: 'freebsd:10:x86:64' -> 'freebsd:11:x86:64')
        urlview-0.9.20131021_1 (ABI changed: 'freebsd:10:x86:64' -> 'freebsd:11:x86:64')
        unzip-6.0_7 (ABI changed: 'freebsd:10:x86:64' -> 'freebsd:11:x86:64')
        ttcp-1.12_1 (ABI changed: 'freebsd:10:x86:64' -> 'freebsd:11:x86:64')
        ...

Number of packages to be installed: 2
Number of packages to be upgraded: 38
Number of packages to be reinstalled: 64

The process will require 5 MiB more space.
110 MiB to be downloaded.

Proceed with this action? [y/N]: y
Fetching zsh-5.3.1.txz: 100%    4 MiB   4.1MB/s    00:01
Fetching zfs-stats-1.2.2_1.txz: 100%    9 KiB   9.5kB/s    00:01
Fetching vim-lite-8.0.0134_1.txz: 100%    5 MiB   5.5MB/s    00:01
...
Checking integrity... done (0 conflicting)
[1/104] Reinstalling indexinfo-0.2.6...
[1/104] Extracting indexinfo-0.2.6: 100%
[2/104] Reinstalling libffi-3.2.1...
[2/104] Extracting libffi-3.2.1: 100%
[3/104] Upgrading gettext-runtime from 0.19.8.1 to 0.19.8.1_1...
[3/104] Extracting gettext-runtime-0.19.8.1_1: 100%
...

Finally we’ll upgrade any perl modules on the system from cpan.

$ sudo cpan-outdated | sudo cpanm

So, to recap the commands are as follows and in this order:

$ sudo freebsd-update fetch
$ sudo freebsd-update install
$ sudo freebsd-update upgrade -r 11.0-RELEASE
$ sudo freebsd-update install
$ sudo shutdown -r now
$ sudo freebsd-update install
$ sudo pkg upgrade
$ sudo cpan-outdated | sudo cpanm

Display “real” FreeBSD version

Typically when you want to find the current version of FreeBSD you type the following:

$ uname -r
10.3-RELEASE-p4

That’s great but it doesn’t tell the full story. If updates were made that do not affect the kernel, than it will not be reflected here. For instance, if the system had been upgraded to patch 12 I would not know that from looking at this. It makes it look like its only been updated to patch 4. Enter the “/usr/src/sys/conf/newvers.sh” file. This file gives a more clear picture of the system’s current state of affairs. I wrote a quick script that grabs the relevant info from this file and displays it similarly to the uname output.

#!/usr/local/bin/perl

use strict;
use warnings;

my $file = "/usr/src/sys/conf/newvers.sh";
my $cnt = 0;
my ($type, $rev, $branch);

open (FILE, "$file") or die "File $file does not exist!";
while (<FILE>) {
 chomp ($_);
     if ($_ =~ /^TYPE="(.*)?"/) {
         $type = $1;
         $cnt++;
     }
    if ($_ =~ /^REVISION="(.*)?"/ && $cnt == 1) {
         $rev = $1;
         $cnt++;
     }
     if ($_ =~ /^BRANCH="(.*)?"/ && $cnt == 2) {
         $branch = $1;
     }
}
close (FILE);

print "$type $rev $branch\n";

I put this script in /usr/local/sbin/hostver on all the systems I administer.

$ hostver
FreeBSD 10.3 RELEASE-p12

Now I always know the current patch level of the system. There are other ways to get this info (freebsd-version) but this works fine for me.

Monit (fix /var/log/messages)

Recently I discovered monit for FreeBSD, a monitoring system that is highly configurable and can be used to monitor various system happenings including service checks, disk space usage and process health. I installed it on all of the systems we have that require such monitoring. It has been very helpful in letting us know when things go offline.

The one issue I have noticed with it has to do with monitoring PostgreSQL. The PostgreSQL part of our config is setup like so:

# POSTGRESQL
check host PostgreSQL with address 127.0.0.1
    if failed ping then alert
    if failed port 5432 protocol pgsql then alert

So when it can’t connect to PostgreSQL we will receive an email message about it. Great! However if you look in the /var/log/messages you will notice something like this every 30 seconds (since we have monit setup to check everything in 30 second intervals):

Nov  1 00:12:41 blackbox postgres[70271]: [2-1] FATAL:  role "root" does not exist

To fix this and start cleaning up our log its pretty straight forward. Create that role:

psql -U pgsql template1
create role root login nocreaterole nocreatedb nosuperuser noinherit;

After this we now start seeing this error in the log:

Nov  9 12:47:50 blackbox postgres[94875]: [2-1] FATAL:  database "root" does not exist

To fix this we simple create that database:

create database root;

I also added this to the pg_hba.conf:

# TYPE  DATABASE        USER            ADDRESS                 METHOD
...
host    root            root            127.0.0.1/32            trust
...

That fixed our issues and now we no longer see those /var/log/messages. Monit wants to always connect using the “root” user and there’s no way to configure it to use a different user. So I came up with this as the workaround.

FreeBSD minor version upgrading

Upgrading FreeBSD to a new minor version is relatively simple. Here are the commands that will get you there: [upgrading from 10.1-p16]


[steve@blackbox:/var/empty]%uname -a
FreeBSD blackbox.cello.com 10.1-RELEASE-p16 FreeBSD 10.1-RELEASE-p16 #0: Tue Jul 17 05:25:45 UTC 2015 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64

sudo freebsd-update upgrade -r 10.2-RELEASE
sudo freebsd-update install
sudo reboot now
sudo freebsd-update install
sudo reboot now
sudo pkg upgrade

I experienced a couple issues along the way, but they were easily correctable. During the upgrade (first command) the process hung while attempting to download the software it needs. I completely lost my connection so I logged back in and ran it again with no issues. Then during the second “freebsd-update install” the same thing happened. Again, log back in and run it again. No issues. Finally, while running the last command to upgrade the packages on the system I ran into one package it would not upgrade. Running “pkg upgrade” twice seemed to ignore the problem.

[steve@blackbox:/var/empty]%sudo pkg upgrade
Updating FreeBSD repository catalogue...
Fetching meta.txz: 100% 944 B 0.9kB/s 00:01
Fetching packagesite.txz: 100% 5 MiB 1.1MB/s 00:05
Processing entries: 100%
FreeBSD repository update completed. 24442 packages processed.
New version of pkg detected; it needs to be installed first.
The following 1 package(s) will be affected (of 0 checked):

Installed packages to be UPGRADED:
pkg: 1.5.5 -> 1.5.6

The process will require 319 B more space.
2 MiB to be downloaded.

Proceed with this action? [y/N]: y
Fetching pkg-1.5.6.txz: 100% 2 MiB 1.2MB/s 00:02
Checking integrity... done (0 conflicting)
[1/1] Upgrading pkg from 1.5.5 to 1.5.6...
[1/1] Extracting pkg-1.5.6: 100%
Message for pkg-1.5.6:
If you are upgrading from the old package format, first run:

# pkg2ng
Updating FreeBSD repository catalogue...
FreeBSD repository is up-to-date.
All repositories are up-to-date.
Checking for upgrades (32 candidates): 100%
Processing candidates (32 candidates): 100%
The following 32 package(s) will be affected (of 0 checked):

New packages to be INSTALLED:
postgresql93-client: 9.3.9

Installed packages to be UPGRADED:
...
curl: 7.43.0_2 -> 7.44.0
ca_root_nss: 3.19.2 -> 3.19.3
apache24: 2.4.16 -> 2.4.16_1

Installed packages to be REINSTALLED:
...
p5-DBD-Pg-3.5.1 (direct dependency changed: postgresql93-client)

The process will require 9 MiB more space.
43 MiB to be downloaded.

Proceed with this action? [y/N]: y
...
Fetching curl-7.44.0.txz: 100% 1 MiB 1.4MB/s 00:01
Fetching ca_root_nss-3.19.3.txz: 100% 334 KiB 341.7kB/s 00:01
Fetching apache24-2.4.16_1.txz: 100% 4 MiB 1.3MB/s 00:03
Fetching postgresql93-client-9.3.9.txz: 100% 2 MiB 2.0MB/s 00:01
Checking integrity... done (1 conflicting)
pkg: Cannot solve problem using SAT solver:
upgrade rule: upgrade local p5-DBD-Pg-3.5.1 to remote p5-DBD-Pg-3.5.1
cannot install package p5-DBD-Pg, remove it from request? [Y/n]: y
pkg: cannot find p5-DBD-Pg in the request
pkg: cannot solve job using SAT solver
Checking integrity... done (0 conflicting)
Conflicts with the existing packages have been found.
One more solver iteration is needed to resolve them.

[steve@nprod:/var/empty]%sudo pkg upgrade
Updating FreeBSD repository catalogue...
FreeBSD repository is up-to-date.
All repositories are up-to-date.
Checking for upgrades (32 candidates): 100%
Processing candidates (32 candidates): 100%
Checking integrity... done (1 conflicting)
pkg: Cannot solve problem using SAT solver:
upgrade rule: upgrade local p5-DBD-Pg-3.5.1 to remote p5-DBD-Pg-3.5.1
cannot install package p5-DBD-Pg, remove it from request? [Y/n]:
pkg: cannot find p5-DBD-Pg in the request
pkg: cannot solve job using SAT solver
Checking integrity... done (0 conflicting)
Your packages are up to date.

And there you have it.

[steve@blackbox:/var/empty]%uname -a
FreeBSD blackbox.cello.com 10.2-RELEASE FreeBSD 10.2-RELEASE #0 r286666: Wed Aug 09 09:55:07 UTC 2015 root@releng1.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64

Cookie management and saving state in Android apps.

I just wrote my first Android app using the ADT plugin for Eclipse. This particular app I wrote interacts with existing web services we deployed on our main production servers. I was having the hardest time maintaining a session state during web service calls on the back-end. All I needed was the following one line of code in my onCreate function of the Activity which calls the web service that sets up the session:

CookieHandler.setDefault(new CookieManager( null, CookiePolicy.ACCEPT_ALL));

Presto! State saved across all subsequent web service calls.