When setting promiscphys to true for the bhyve brand, we also need to set promisc-filtered to off on the vnic.

I'm not really sure what the proper fix is, do we set it via zadm for the persistant vnics and in the brand for the temporary ones? Or do we just set the linkprop accordingly based on promiscphys before starting bhyve? The later seems more inline to me wrt what a user would expect if he sets promiscphys=true regardless of where the vnic's are coming from.

Currently it's not possible to have a brand automatically create vrrp vnics:

dladm create-vnic -m vrrp -l ixgbe0 -V 98 -A inet -v 110 ldap1vip0

I had a look at shared/vnic.ksh and it seems like it should be possible to add this without too much trouble but I am not sure this is the best approach, I'd like some feedback before further fleshing this out.

I was thinking something along the lines of:

--- a	2021-12-12 22:48:29.000000000 +0100
+++ b	2021-12-12 22:58:04.000000000 +0100
@@ -1,5 +1,5 @@
 function config_vnics {
-        demand_vnics | while read nic global mac vlan addr; do
+        demand_vnics | while read nic global mac vlan addr vrid vridfamily; do
                 [ -n "$global" -a "$global" != "-" ] || continue
                 if [ "$global" = "auto" ]; then
                         if [ "$addr" = "-" ]; then
@@ -15,6 +15,16 @@
                                     "$nic"
                         fi
                 fi
+                if [ "$mac"] = "vrrp" ]; then
+                    [ "$vrid" != "-" ] || \
+                        fail_fatal "Invalid configuration for %s mac cannot be 'vrrp' if no vrid specified!"
+
+                    # fallback to inet for vridfamily if not specified
+                    [ "$vridfamily" = "-" ] && vridfamily="inet"
+
+                    [ "$vridfamily" = "inet" -a "$vridfamily" = "inet6" ] || \
+                        fail_fatal "Invalid configuration for %s vrid_family needs to be either 'inet' or 'inet6'!"
+                fi
                 if dladm show-vnic -p -o LINK $nic >/dev/null 2>&1; then
                         # VNIC already exists
                         continue
@@ -23,6 +33,7 @@

                 opt=
                 [ "$mac" != "-" ] && opt+=" -m $mac"
+                [ "$vrid" != "-" ] && opt+=" -V $vrid -A $vridfamily"
                 [ "$vlan" != "-" -a "$vlan" != "0" ] && opt+=" -v $vlan"
                 if ! dladm create-vnic -l $global $opt $nic; then
                         fail_fatal "Could not create VNIC %s/%s" \

Full function below for easier reading:

function config_vnics {
        demand_vnics | while read nic global mac vlan addr vrid vridfamily; do
                [ -n "$global" -a "$global" != "-" ] || continue
                if [ "$global" = "auto" ]; then
                        if [ "$addr" = "-" ]; then
                                fail_fatal "%s %s" \
                                    "Cannot use 'auto' global NIC" \
                                    "without allowed-address."
                        fi
                        global="`route -n get "$addr" | nawk '
                            / interface:/ {print $2; exit}'`"
                        if [ -z "$global" ]; then
                                fail_fatal \
                                    "Could not determine global-nic for %s" \
                                    "$nic"
                        fi
                fi
                if [ "$mac"] = "vrrp" ]; then
                    [ "$vrid" != "-" ] || \
                        fail_fatal "Invalid configuration for %s mac cannot be 'vrrp' if no vrid specified!"

                    # fallback to inet for vridfamily if not specified
                    [ "$vridfamily" = "-" ] && vridfamily="inet"

                    [ "$vridfamily" = "inet" -a "$vridfamily" = "inet6" ] || \
                        fail_fatal "Invalid configuration for %s vrid_family needs to be either 'inet' or 'inet6'!"
                fi
                if dladm show-vnic -p -o LINK $nic >/dev/null 2>&1; then
                        # VNIC already exists
                        continue
                fi
                log "Creating VNIC $nic/$global (mac: $mac, vlan: $vlan)"

                opt=
                [ "$mac" != "-" ] && opt+=" -m $mac"
                [ "$vrid" != "-" ] && opt+=" -V $vrid -A $vridfamily"
                [ "$vlan" != "-" -a "$vlan" != "0" ] && opt+=" -v $vlan"
                if ! dladm create-vnic -l $global $opt $nic; then
                        fail_fatal "Could not create VNIC %s/%s" \
                            "$nic" "$global"
                fi

                if [ "$mac" = "-" ]; then
                        # Record the assigned MAC address in the zone config
                        mac=`dladm show-vnic -p -o MACADDRESS $nic`
                        [ -n "$mac" ] && zonecfg -z $ZONENAME \
                            "select net physical=$nic; " \
                            "set mac-addr=$mac; " \
                            "end; exit"
                fi
        done
}

This is just a rough untested idea on how I would like to implement it, there is no vrid and vridfamily parsing added higher up to the awk script yet.

1. when mac=vrrp, validate we have a vrid or throw a fatal error
2. ensure vridfamily is set to inet or inet6, fallback to inet if unset
3. inject the -V and -A flags before the -v flag as per the command output (not mentioned in the man page??)

sjorge@saturn:/usr/lib/brand/shared$ dladm create-vnic 2>&1 | grep -B 2 -A 1 vrid
    create-vnic      [-t] -l <link> [-m <value> | auto |
                     {factory [-n <slot-id>]} | {random [-r <prefix>]} |
                     {vrrp -V <vrid> -A {inet | inet6}} [-v <vid> [-f]]
                     [-p <prop>=<value>[,...]] <vnic-link>

Does this approach look good? If so flash this out more (update the awk parsing and such) and give it a spin.

An alternative idea I had was just to be able to feed it a vrrp mac e.g. 0:0:5e:0:1:62 for inet and 0:0:5e:0:2:62 for inet6 and then parse those to extract the vrid and vrid family from them, this is doable because the VRRP mac follow the same format:
0:0:5e:0: prefix, 1 for IPv4 (inet) or 2 for IPv6 (inet6), XX is the vrid in hex, so it's certainly possible to parse the required info from this, but I feel this would make for a lot of complex parsing in ksh which I prefer to avoid, simply creating a vnic with one of those mac addresses is not sufficient to make vrrpadm create-router happy, I tried.

Edit: some more context, https://blackdot.be/2021/12/using-vrrp-inside-a-lipkg-zone-on-omnios/ manually creating the vnic first and just passing it in works as a workaround but I would prefer not to manually have to create any vnics.

The --origin-uri (-O) flag to pkg set-publisher will remove and replace all existing origin type publisher entries from the configuration.

There does not appear to be an analogous flag for replacing all current mirror type publisher entries; --add-mirror (-m) and --remove-mirror (-M) both require understanding the current state before specifying a new one.

Basically it would be good to be able to do something like:

pkg set-publisher \
    -O https://pkg.omnios.org/r151046/core/ \
    -I https://us-west.mirror.omnios.org/r151046/core/ \
    omnios

And end up replacing any existing origin and mirror records for the omnios publisher.

I suspect it would also be good to have a --no-mirrors flag as well, that would remove all mirror entries altogether, in case the new repository doesn't actually come with a mirror anymore; i.e.,

pkg set-publisher \
    -O https://pkg.omnios.org/r151046/core/ \
    --no-mirrors \
    omnios

This would replace all origin entries and remove any mirror entries (if any are present) in one operation.

{
   "autoboot" : "false",
   "bootdisk" : {
      "blocksize" : "4K",
      "path" : "rpool/vms/rcon1/disk0",
      "size" : "10G",
      "sparse" : "false"
   },
   "bootrom" : "BHYVE_RELEASE",
   "brand" : "bhyve",
   "diskif" : "nvme",
   "hostbridge" : "i440fx",
   "net" : [
      {
         "global-nic" : "ixgbe0",
         "mac-addr" : "00:22:06:eb:5c:9f",
         "physical" : "rcon1",
         "vlan-id" : "10"
      }
   ],
   "ppt": [ "ppt0" ],
   "netif" : "virtio-net",
   "ram" : "1G",
   "rng" : "on",
   "vcpus" : "1,sockets=1,cores=1,threads=1",
   "vga" : "off",
   "vnc" : "off",
   "xhci" : "off",
   "zonename" : "rcon1",
   "zonepath" : "/zones/rcon1"
}

root@jupiter:~# zfs list -r rpool/vms
NAME                                  USED  AVAIL  REFER  MOUNTPOINT
rpool/vms                             124G   126G   256K  /zones
... other hvm/zones here ...
rpool/vms/rcon1                      10.6G   126G   224K  /zones/rcon1
rpool/vms/rcon1/disk0                10.6G   136G   112K  -

Having a zvol (bootdisk or regular disks) under the zonepath used to work fine, but this now fails, no 100% sure this is a brand or zadm issue.

It used to work fine before, but now it fails with Zonepath /zones/rcon1 is on a nosuid file system. When the zvol is create it looks like it creates the parent rpool/vms/rcon1 which is mounted on /zones/rcon1, so far so good. However this dataset has setuid set to off with SOURCE set to temporary.

Creating the parent manually first sees to fix this (I set all properties to the values my existing bhyve VM's had on those datasets)

Perhaps somewhere the order in which the zvol vs dataset create got swapped recently.

see: https://illumos.topicbox.com/groups/omnios-discuss/T89e3a22c66b169fb-M18107bcd6dd862e917002f5b/omnios-discuss-kvm-zone-cpu-model-avx-for-mongodb

It would be good to at least have a flag that would allow for idempotent use of pkg install blah, such that if blah is already installed and no action is required we can drive on successfully instead of exiting non-zero. Today, to work around this, folks always have to do something like pkg info -q blah to try and guess if the package is installed before putting it in the list. This is even more tedious if you have a list of multiple packages, as if some of them are not installed we will successfully install the missing ones, but if all of them are installed we fail with the error.

In the pkgfmt(1) manual page, there is at least one misspelling of the command name as pkgfmr.

When TERM=256+color, I've seen exceptions in pkg.
When TERM=dumb, there was no exception.
Logged into the console of omnioscce, I see:

pfexec env TERM='xterm+256color' pkg refresh
Traceback (most recent call last):
File "/usr/bin/pkg", line 5452, in handle_errors
__ret = func(*args, **kwargs)
File "/usr/bin/pkg", line 5354, in main_func
return func(api_inst, pargs)
File "/usr/bin/pkg", line 3449, in publisher_refresh
return __refresh(api_inst, pargs, full_refresh=full_refresh)
File "/usr/bin/pkg", line 3413, in __refresh
immediate=True, pubs=pubs)
File "/usr/lib/python2.7/vendor-packages/pkg/client/api.py", line 2987, in refresh
pubs=pubs, immediate=immediate)
File "/usr/lib/python2.7/vendor-packages/pkg/client/api.py", line 3011, in __refresh
progtrack=self.__progresstracker)
File "/usr/lib/python2.7/vendor-packages/pkg/client/image.py", line 3318, in refresh_publishers
progtrack.refresh_start_pub(pub)
File "/usr/lib/python2.7/vendor-packages/pkg/client/progress.py", line 1220, in refresh_start_pub
self._refresh_output_progress(outspec)
File "/usr/lib/python2.7/vendor-packages/pkg/client/progress.py", line 2850, in _refresh_output_progress
self._pe.cprint(msg, end="", erase=True)
File "/usr/lib/python2.7/vendor-packages/pkg/client/printengine.py", line 155, in cprint
self.erase()
File "/usr/lib/python2.7/vendor-packages/pkg/client/printengine.py", line 139, in erase
self.putp(self.__cr)
File "/usr/lib/python2.7/vendor-packages/pkg/client/printengine.py", line 119, in putp
self._out_file.write(self.__putp_re.sub("", string))
TypeError: expected string or buffer

at printengine.py" line 139, in the call to self.putp(self.__cr)
self.__cr is None even though cr should be defined as \r in xterm+256color.

I set a breakpoing on POSIXPrintEngine.init, and after:
self.__cr = curses.tigetstr("cr")
the value of self._POSIXPrintEngine__cr was None.

So, somehow, it is getting a null value for 'cr' from terminfo.

Setting TERM to dumb is a workaround:

pfexec env TERM='dumb' pkg refresh
Refreshing catalog 'omnios' ... Done

When applying a hotfix from a local archive, pkg will first display the path correctly:

pkg apply-hot-fix -nv --be-name=amd-hma-exclusion amd-hma-exclusion.p5p

Resolved URL to: file:///tmp/amd-hma-exclusion.p5p
Retrieving installed package list...
Scanning package archive...
pkg://omnios/system/kernel/[email protected]:20200828T150837Z will be updated.
...

and then fail, because it broke the URL:

The origin URIs for 'omnios' do not appear to point to a valid pkg repository.
...

pkg publisher

PUBLISHER TYPE STATUS P LOCATION
omnios origin online F file:///tmp/pkg_hfa__o5dv8t4_amd-hma-exclusion.p5p/
omnios origin online F http://pkg.bb-c.de/omnios/034-core/

It will also leave the broken origin in all NGZs that it wants to recurse into.

Hello,

Hope this is the right repo.

I applied a hot fix per andyf's advice. I noticed today when trying to apply the latest OmniOS upgrade that all my NGZs have a lingering file://tmp/... omnios publisher that is invalid:

| WARNING: Errors were encountered when attempting to retrieve package
| catalog information. Packages added to the affected publisher repositories since
| the last retrieval may not be available.
| 
| Errors were encountered when attempting to contact 1 of 2 repositories for publisher 'omnios'.
| 
| Unable to contact valid package repository: file:///tmp/pkg_hfa_2074x57__OS-8027.p5p/
| Encountered the following error(s):
|   file protocol error: code: E_HTTP_NOT_FOUND (22) reason: The path '/tmp/pkg_hfa_2074x57__OS-8027.p5p' does not contain a valid package repository.
| Repository URL: 'file:///tmp/pkg_hfa_2074x57__OS-8027.p5p'.

The GZ does not have that tmp publisher.

Thank you.

I've noticed the bhyve man page and your web site, https://omnios.org/info/bhyve_kvm_brand.html, do not document the vnc=wait setting.

The us-west mirror is apparently down right now, and pkg commands appear to get stuck trying to contact it:

DOWNLOAD                                PKGS         FILES    XFER (MB)   SPEED
ooce/server/nginx                        0/2          0/27      0.0/0.7      --

It appears the system will wait rather a long time for a connection timeout, and may keep trying even after the first few tries fail. Because --disable works at the publisher level, rather than the mirror level, one must remove the mirror configuration altogether to bypass the issue.

The pkg command should probably:

• reduce the connection timeout to something sensible like 10-20 seconds
• remember that it failed at least once during this session and not continue to get stuck using it

Consider a large package that has many loosely related drivers:

• pkg:/[email protected]
  • driver flotsam
  • driver jetsam
  • driver lagan
  • driver derelict

We'd like to be able to take the derelict driver out into a new package, pkg:/driver/derelict, while leaving the others alone for now. The end result should look like:

• pkg:/[email protected]
  • driver flotsam
  • driver jetsam
  • driver lagan
• pkg:/driver/[email protected]
  • driver derelict

Distributions generally have a metapackage that contain a list of driver packages that are relevant to the install media or system they are producing; ideally this need not be all drivers. As part of building new illumos packages, a distribution could include (if they wish!) a depend type=require action in their metapackages and the driver would then be explicitly included in media. Because pkg:/barge does not depend on the new pkg:/driver/derelict, new distribution releases are able to exclude the driver in question if it is not relevant to them, thus reducing the size of the software in their base install.

Unfortunately, this falls down for updating existing systems. If you had pkg:/[email protected] previously, you would have had (and could have been depending upon!) the driver derelict shipped in that package. Once your system updates to pkg:/[email protected], that driver is no longer in that package, and will be removed from the disk! If you needed that driver to boot, your system would not boot any longer.

The classical strategy for dealing with this is to make the old package, which is being split up, depend on the new package; i.e.,

• pkg:/[email protected]
  • driver flotsam
  • driver jetsam
  • driver lagan
  • require /driver/derelict
• pkg:/driver/[email protected]
  • driver derelict

This is regrettable, because it is not possible, then, to install barge without getting derelict, thus ultimately defeating the point of splitting up the packages in the first place.

Another option is to split up barge even more completely and turn the old package into a meta-package itself; e.g.,

• pkg:/[email protected]
  • require /driver/derelict
  • require /driver/flotsam
  • require /driver/jetsam
  • require /driver/lagan
• pkg:/driver/[email protected]
  • driver flotsam
• pkg:/driver/[email protected]
  • driver jetsam
• pkg:/driver/[email protected]
  • driver lagan
• pkg:/driver/[email protected]
  • driver derelict

Distribution meta-packages would then be altered not to install pkg:/barge at all, and instead install the subset of the new packages which are relevant. End users could ultimately uninstall pkg:/barge at their leisure, provided they don't uninstall whichever of the drivers are useful to them, and also don't use the relatively recent pkg autoremove functionality which uninstalls packages that were not themselves explicitly marked as manually installed by the operator.

This is not ideal, though, for all cases; e.g., if you're trying to remove portions of a package that is itself a legitimate package that needs to continue to exist; e.g., /system/kernel.

What I think would be neat instead is a new action type: depend type=upgrade which would, when put on the package pkg:/barge:

• look at the pre-installation contents of the image; if pkg:/barge was present:
  • look for a matching depend type=upgrade action in the prior version of pkg:/barge
    • if found, do nothing
    • if not found, treat this as a depend type=require action _only for this install activity (and mark it as manually installed iff pkg:/barge was already manually installed)
• if pkg:/barge was not previously installed in the image, do nothing

This would afford us a one-time installation of pkg:/driver/derelict, on upgrade of pkg:/barge across the transition where it was split out, that would not keep bringing it back from the dead if the user decided themselves to uninstall it.

An illumos contributor was recently confused by a message output from our build that asked them to run pkgfmt without the -c or -d options to reformat a manifest file. Unfortunately it was not immediately obvious that the tool operates by default (it seems) in the V2 format mode, which we don't use in illumos. You can override the format in use with the PKGFMT_OUTPUT environment variable, as the build does, but it seems like there is also an undocumented -f flag for this?

It'd be good to document the flag and the environment variable, and likely to specifically call out in the manual page that illumos only uses the V1 output format.

root@jupiter:/zones/hydrogen/root/tmp# tail zone.log
[Tue Jun 22 13:36:33 CEST 2021] Waiting for bhyve to exit
[Tue Jun 22 13:36:34 CEST 2021] Waiting for bhyve to exit
[Tue Jun 22 13:36:35 CEST 2021] Waiting for bhyve to exit
[Tue Jun 22 13:36:36 CEST 2021] Waiting for bhyve to exit
[Tue Jun 22 13:36:37 CEST 2021] Waiting for bhyve to exit
[Tue Jun 22 13:36:38 CEST 2021] Waiting for bhyve to exit
[Tue Jun 22 13:36:39 CEST 2021] Waiting for bhyve to exit
[Tue Jun 22 13:36:40 CEST 2021] Waiting for bhyve to exit
[Tue Jun 22 13:36:41 CEST 2021] Waiting for bhyve to exit
[Tue Jun 22 13:36:42 CEST 2021] Waiting for bhyve to exit
root@jupiter:/zones/hydrogen/root/tmp# mount | grep hydrogen
/zones/hydrogen on rpool/vms/hydrogen read/write/setuid/devices/nonbmand/exec/xattr/atime/dev=415000b on Wed Jun 16 21:48:38 2021
/zones/hydrogen/root/dev on /dev read/write/setuid/devices/dev=89c0007 on Tue Jun 22 13:38:45 2021
/zones/hydrogen/root/lib on /lib read only/setuid/nodevices/nosub/dev=4150002 on Tue Jun 22 13:38:45 2021
/zones/hydrogen/root/sbin on /sbin read only/setuid/nodevices/nosub/dev=4150002 on Tue Jun 22 13:38:45 2021
/zones/hydrogen/root/usr on /usr read only/setuid/nodevices/nosub/dev=4150002 on Tue Jun 22 13:38:45 2021
/zones/hydrogen/root/var/run on swap read/write/setuid/nodevices/xattr/size=50m/zone=hydrogen/dev=8b4001d on Tue Jun 22 13:38:45 2021
/zones/hydrogen/root/proc on proc read/write/setuid/nodevices/zone=hydrogen/dev=8a4000a on Tue Jun 22 13:38:45 2021
/zones/hydrogen/root/etc/mnttab on mnttab read/write/setuid/nodevices/zone=hydrogen/dev=8b0000b on Tue Jun 22 13:38:45 2021
/zones/hydrogen/root/etc/svc/volatile on swap read/write/setuid/nodevices/xattr/size=10m/zone=hydrogen/dev=8b4001e on Tue Jun 22 13:38:45 2021

It writes to this file 1x second, and that is not on tmpfs!

Though you can indicate to wait by setting the vnc attribute using full options such as unix=/tmp/vm.vnc,wait, may I suggest another mode for vnc: off, on, wait,options where wait is the same as unix=/tmp/vm.vnc,wait.

Thank you.

Hello,

I've noticed some modifications that may need fix-ups to comply with section 3.3 of CDDL, "You may not remove or alter any copyright ... notices contained within the Covered Software, or any notices of licensing or any descriptive text giving attribution to any Contributor ...."

"Covered Software means (a) the Original Software, or (b) Modifications, or (c) the combination of files containing Original Software with files containing Modifications, in each case including portions thereof."

In #203 and #204:

• src/brand/common.ksh, src/brand/poststate, and src/brand/prestate had notices of licensing removed and replaced with an alternative version
• src/brand/shared/firewall.ksh and src/brand/shared/vnic.ksh had source code moved from src/brand/common.ksh but without copying the notices of licensing or attribution to contributors from the original file

In #208:

• src/brand/Makefile.common had source code moved from src/brand/Makefile but without copying the notices of licensing from the original file
• src/brand/etc/Makefile, src/brand/ipkg/Makefile, src/brand/pkgsrc/Makefile had source code moved from src/brand/Makefile but without copying the notices of licensing or attribution to contributors from the original file

Greetings,

I've hit an issue with cloning ipkg zones running a development build of illumos. I've narrowed this issue down to /usr/lib/brand/ipkg/system-configure. That file appears to come from this repo hence the issue report here.

When I tried to clone a zone from a development build of Illumos-gate, I would get an error saying Zone: unconfigure failed. After a bit of digging I found that this was coming from /usr/lib/brand/ipkg/{clone,system-unconfigure}. I added the -x ksh flag to the top of each of these files to get output and replaced the zlogin redirect within system-unconfigure from /dev/null to a file in the /tmp directory so I could actually see what's going on. The output of those failed runs with -x set is available here.

What's happening here is in system-unconfigure a sed is running on /etc/ssh/sshd_config but /etc/ssh does not exist so the command is failing and derailing the whole zone clone.

As a quick workaround which allows the clone to succeed, I did the following

diff --git a/system-unconfigure.orig b/usr/lib/brand/ipkg/system-unconfigure
index 681a25a..48f8c21 100755
--- a/system-unconfigure.orig
+++ b/usr/lib/brand/ipkg/system-unconfigure
@@ -191,7 +191,9 @@ reset_init_default
 blank_root_pw
 clear_logs
 disable_ldap
-reset_ssh_config
+if [[ -d $ALTROOT/etc/ssh ]]; then
+    reset_ssh_config
+fi
 
 # Vim hints
 # vim:ts=4:sw=4:et:fdm=marker

However, it's not clear to me if this is a reasonable thing to do, or if it's a treatment of a symptom that's ignoring a deeper issue.

An example is isc-dhcp, which has /usr/sbin/dhcpd. If this package be installed in a sparse zone, then pkg install reports no error, but /usr/sbin/dhcpd is not installed because filesystem /usr is shared and read-only in the zone.

At the very least, pkg install should emit a warning for the omitted file, but really, pkg install should fail because the package has not been installed.

Right now, if you list the contents of a package or set of packages with a filter, and that filter does not match any actions that exist within the package, pkg contents fails with a generic exit status:

$ pkg contents -t depend -a type=optional -H -o fmri SUNWcs
pkg: contents: no matching actions found in the listed packages
$ echo  $?
1

It seems useful to be able to distinguish the "no matching actions found in the listed packages" case from other errors without parsing the human-readable error message.

It might even make sense to add a new flag (perhaps -q) to just squelch this error altogether and exit 0 in this case.

Couldn't find where this package is coming from, so might be the wrong repo.

I added this to /etc/sudo.conf

Plugin sudoers_policy sudoers.so ldap_conf=/etc/sudo.conf.ldap

I had this as sudo.conf.ldap

URI             ldap://ldap.acheron.be
BASE            dc=acheron,dc=be
SUDOERS_BASE    ou=sudoers,dc=acheron,dc=be
BINDDN          cn=proxyagent,dc=acheron,dc=be
BINDPW          xxxx
SSL             start_tls

This works fine on SmartOS but fails with:

sjorge@ldap1:/$ sudo -l
sudo: start_tls specified but LDAP libs do not support ldap_start_tls_s() or ldap_start_tls_s_np()
sudo: ldap_sasl_bind_s(): Confidentiality required

The following does work:

URI             ldaps://ldap.acheron.be
BASE            dc=acheron,dc=be
SUDOERS_BASE    ou=sudoers,dc=acheron,dc=be
BINDDN          cn=proxyagent,dc=acheron,dc=be
BINDPW          xxxx
TLS_CERT        /var/ldap/cert7.db

Given it needs a cert7.db to work, I'm guessing it is using the illumos LDAP and not openldap libraries.
They do not seem to expose start_tls.

However the manpage (sudoers.ldap) does mention starttls support, I think updating the manpage to not mention it is probably the correct fix, unless we want to pull in openldap but I don't think we want that....

manpage fragment:

     SSL start_tls
           If the SSL parameter is set to start_tls, the LDAP server
           connection is initiated normally and TLS encryption is begun before
           the bind credentials are sent.  This has the advantage of not
           requiring a dedicated port for encrypted communications.  This
           parameter is only supported by LDAP servers that honor the
           start_tls extension, such as the OpenLDAP and IBM Tivoli Directory
           servers.

While waiting on the freeradius package I started looking at some other things on my TODO list...
I setup 2 VMs with bhyve that each get a USB controller.

However on the VM with ppt0 sees the actual device.

zadm configuration

{
   "acpi" : "on",
   "autoboot" : "false",
   "bootargs" : "",
   "bootdisk" : {
      "blocksize" : "4K",
      "path" : "rpool/vms/rcon1/disk0",
      "size" : "10G",
      "sparse" : "false"
   },
   "bootorder" : "cd",
   "bootrom" : "BHYVE_RELEASE",
   "brand" : "bhyve",
   "diskif" : "nvme",
   "fs-allowed" : "",
   "hostbridge" : "i440fx",
   "hostid" : "",
   "ip-type" : "exclusive",
   "limitpriv" : "default",
   "net" : [
      {
         "global-nic" : "ixgbe0",
         "mac-addr" : "00:22:06:eb:5c:9f",
         "physical" : "rcon1",
         "vlan-id" : "110"
      }
   ],
   "netif" : "virtio-net",
   "pool" : "",
   "ppt" : [
      "ppt0"
   ],
   "ram" : "1G",
   "rng" : "on",
   "scheduling-class" : "",
   "type" : "generic",
   "vcpus" : "1,sockets=1,cores=1,threads=1",
   "vga" : "off",
   "vnc" : "off",
   "xhci" : "off",
   "zonename" : "rcon1",
   "zonepath" : "/zones/rcon1"
}

{
   "acpi" : "on",
   "autoboot" : "false",
   "bootargs" : "",
   "bootdisk" : {
      "blocksize" : "4K",
      "path" : "rpool/vms/rcon2/disk0",
      "size" : "10G",
      "sparse" : "false"
   },
   "bootorder" : "cd",
   "bootrom" : "BHYVE_RELEASE",
   "brand" : "bhyve",
   "diskif" : "nvme",
   "fs-allowed" : "",
   "hostbridge" : "i440fx",
   "hostid" : "",
   "ip-type" : "exclusive",
   "limitpriv" : "default",
   "net" : [
      {
         "global-nic" : "ixgbe0",
         "mac-addr" : "00:22:06:ae:a3:64",
         "physical" : "rcon2",
         "vlan-id" : "110"
      }
   ],
   "netif" : "virtio-net",
   "pool" : "",
   "ppt" : [
      "ppt1"
   ],
   "ram" : "1G",
   "rng" : "on",
   "scheduling-class" : "",
   "type" : "generic",
   "vcpus" : "1,sockets=1,cores=1,threads=1",
   "vga" : "off",
   "vnc" : "off",
   "xhci" : "off",
   "zonename" : "rcon2",
   "zonepath" : "/zones/rcon2"
}

ppt devices

{
        "devices": [
                {"dev":"/dev/ppt0","path":"/pci@5e,0/pci8086,2032@2/pci12d8,8608@0/pci12d8,8608@1/pci1912,15@0","vendor-id":"1912","device-id":"15","subsystem-vendor-id":"1912","subsystem-id":"15","revision-id":"2","label":"Renesas Technology Corp. uPD720202 USB 3.0 Host Controller"},
                {"dev":"/dev/ppt1","path":"/pci@5e,0/pci8086,2032@2/pci12d8,8608@0/pci12d8,8608@5/pci1912,15@0","vendor-id":"1912","device-id":"15","subsystem-vendor-id":"1912","subsystem-id":"15","revision-id":"2","label":"Renesas Technology Corp. uPD720202 USB 3.0 Host Controller"},
                {"dev":"/dev/ppt2","path":"/pci@5e,0/pci8086,2032@2/pci12d8,8608@0/pci12d8,8608@7/pci1912,15@0","vendor-id":"1912","device-id":"15","subsystem-vendor-id":"1912","subsystem-id":"15","revision-id":"2","label":"Renesas Technology Corp. uPD720202 USB 3.0 Host Controller"},
                {"dev":"/dev/ppt3","path":"/pci@5e,0/pci8086,2032@2/pci12d8,8608@0/pci12d8,8608@9/pci1912,15@0","vendor-id":"1912","device-id":"15","subsystem-vendor-id":"1912","subsystem-id":"15","revision-id":"2","label":"Renesas Technology Corp. uPD720202 USB 3.0 Host Controller"},
                {"dev":"/dev/ppt4","path":"/pci@5e,0/pci8086,2030@0/pci8086,37c0@0/pci8086,37c5@3/pci15d9,37d2@0","vendor-id":"8086","device-id":"37d2","subsystem-vendor-id":"15d9","subsystem-id":"37d2","revision-id":"9","label":"Intel Corporation Ethernet Connection X722 for 10GBASE-T"},
                {"dev":"/dev/ppt5","path":"/pci@5e,0/pci8086,2030@0/pci8086,37c0@0/pci8086,37c5@3/pci15d9,37d2@0,1","vendor-id":"8086","device-id":"37d2","subsystem-vendor-id":"15d9","subsystem-id":"37d2","revision-id":"9","label":"Intel Corporation Ethernet Connection X722 for 10GBASE-T"}
        ]
}

resulted bhyve.cfg's

#
# Generated from zone configuration
#
acpi_tables=false
memory.size=1G
memory.wired=true
x86.strictmsr=true
x86.vmexit_on_hlt=true
uuid=2ac52335-162b-c06b-d9c0-e0eff49d4b59
smbios.manufacturer=OmniOS
smbios.product=OmniOS HVM
smbios.version=1.0
smbios.serial=2ac52335-162b-c06b-d9c0-e0eff49d4b59
smbios.sku=001
smbios.family=Virtual Machine
cpus=1
sockets=1
cores=1
threads=1
lpc.bootrom=/usr/share/bhyve/firmware/BHYVE_RELEASE.fd
lpc.com1.path=/dev/zconsole
pci.0.0.0.device=hostbridge
pci.0.0.0.model=i440fx
pci.0.1.0.device=lpc
pci.0.4.0.device=nvme
pci.0.4.0.path=/dev/zvol/rdsk/rpool/vms/rcon1/disk0
pci.0.6.0.device=virtio-net
pci.0.6.0.backend=dlpi
pci.0.6.0.vnic=rcon1
pci.0.9.0.device=passthru
pci.0.9.0.path=/dev/ppt0
pci.0.10.0.device=virtio-rnd
name=rcon1

# Generated from zone configuration
#
acpi_tables=false
memory.size=1G
memory.wired=true
x86.strictmsr=true
x86.vmexit_on_hlt=true
uuid=17f57668-b2b9-c188-dac6-e44919140731
smbios.manufacturer=OmniOS
smbios.product=OmniOS HVM
smbios.version=1.0
smbios.serial=17f57668-b2b9-c188-dac6-e44919140731
smbios.sku=001
smbios.family=Virtual Machine
cpus=1
sockets=1
cores=1
threads=1
lpc.bootrom=/usr/share/bhyve/firmware/BHYVE_RELEASE.fd
lpc.com1.path=/dev/zconsole
pci.0.0.0.device=hostbridge
pci.0.0.0.model=i440fx
pci.0.1.0.device=lpc
pci.0.4.0.device=nvme
pci.0.4.0.path=/dev/zvol/rdsk/rpool/vms/rcon2/disk0
pci.0.6.0.device=virtio-net
pci.0.6.0.backend=dlpi
pci.0.6.0.vnic=rcon2
pci.0.9.1.device=passthru
pci.0.9.1.path=/dev/ppt1
pci.0.10.0.device=virtio-rnd
name=rcon2

And here we see our problem! The non working VM has:

pci.0.9.1.device=passthru
pci.0.9.1.path=/dev/ppt1

There is nothing in function 0 (0.9.0) so bhyve ignores this device as it always needs to start at function 0.

At present, we have two distinct operations:

• pkg install, which can add packages to a system, or change the installed version to a specific (perhaps older!) version or even a version from a specific other publisher
• pkg uninstall, which removes packages from the system

Sometimes, when trying to move between production and development bits, it seems that it can be impossible to get from the current state to an intended target state because these two distinct operations may require the transition through an illegal state to get to the legal target state. For example:

• a new package (say, newthing) was added to a development version of illumos-gate, which is depended upon by SUNWcs, and version-locked through osnet-incorporation
• we want to go back to regular illumos packages, so we use a fully-qualified FMRI for osnet-incorporation
• there is no acceptable version of newthing that can be installed, now, because it only exists in the version of the OS bits that we already have

What we would like to be able to do is something like:

pkg modify -v +osnet-incorporation@$oldversion -newthing

This would attempt, as a single operation, to change the osnet-incorporation version (which would also end up changing the version of most OS packages like SUNWcs) and concurrently remove newthing from the image. The target state should then be legal, and there should be no need to move through an invalid intermediate state to get there.

The manual doesn't mention the abort operation. It does mention an exit operation that seems perhaps a superset, but then does go on to talk about the behaviour of -O and -P in the case of an abort operation.

If abort isn't obselete in favour of exit(?) it should be documented

This seems to happen when looking at package information summery.

Seems to match the following bug in OpenIndiana: https://www.illumos.org/issues/12742
fixed by the following commit: OpenIndiana/pkg5@8b58c72

Merging arm64-gate to illumos-gate this morning, I hit upon changes to pkg:/system/ficl that completely mis-sorted the manifest.
I think this is because the conditions for $(i386_ONLY) are followed by spaces, and so they get sorted to the top as if they were different actions file dir etc. They shouldn't, pkgfmt should eat that whitespace or something.

I am aware that this is likely at best difficult and at worst impossible to coordinate an update to fix, given that illumos-gate enforces this and distribution-drift would be difficult to deal with, but thought it should be recorded.

for posterity, what pkgfmt does is this

#
# The default for payload-bearing actions in this package is to appear in the
# global zone only.  See the include file for greater detail, as well as
# information about overriding the defaults.
#
$(i386_ONLY) dir  path=usr/bin group=bin
$(i386_ONLY) dir  path=usr/bin/$(ARCH32) group=bin
$(i386_ONLY) file path=usr/bin/$(ARCH32)/ficl-sys group=sys mode=0555
$(i386_ONLY) file path=usr/bin/ficl-sys group=sys mode=0555
set name=pkg.fmri \
    value=pkg:/system/[email protected],$(PKGVERS_BUILTON)-$(PKGVERS_BRANCH)
set name=pkg.summary value="FICL Forth Implementation"
set name=pkg.description value="Forth Inspired Command Language"
set name=info.classification value=org.opensolaris.category.2008:System/Core
set name=variant.arch value=$(ARCH)
dir  path=usr group=sys
dir  path=usr/lib group=bin
dir  path=usr/lib/$(ARCH64) group=bin
file path=usr/lib/$(ARCH64)/libficl-sys.so.4.1.0 group=sys mode=0755
file path=usr/lib/libficl-sys.so.4.1.0 group=sys mode=0755
license lic_CDDL license=lic_CDDL
license usr/src/common/ficl/LICENSE license=usr/src/common/ficl/LICENSE