illumos warch for October and November

This issue will cover October and November

illumos can now be a guest in bhyve

Peter Grehan posted to freebsd-virtualization mailing list announcing, that illumos can be a bhyve guest:
This has been tested with SmartOS and also OpenIndiana and OmniOS, though I've not been able to work out how to enable serial console support for the latter two post-install.
Read up original post for some technical details and advice.

Ryan Zezeski on Memory by the Slab: The Tale of Bonwick's Slab Allocator

Ryan Zezeski tells the tale of Jeff Bonwick's Slab allocator. Worth listening to. Link: http://paperswelove.org/2015/video/ryan-zezeski-memory-by-the-slab/

illumos days videos

illumos days 2015 videos have been posted to youtube OomtiTI channel: https://www.youtube.com/watch?v=Al2jqJ_8BcQ&list=PLPs2JDhxyVxPzEkUzQD2-cb-rhVFqX1UV

6123: SMF ipfilter support needs improvement

There is a steady work from Hans Rosenfeld on 6123: SMF ipfilter support needs improvement. Basically, if you have applications that need interaction with a firewall and their configuration is stored in SMF, it should be possible to alter firewall configuration according to the service configuration. Imagine a situation, where starting a service from SMF means opening a port in a firewall or inserting any other rule. When the sservice stops, it should take care of removing that rule.

Ever wanted to run illumos on EC2?

Andrzej Szeszo is having fun with it. Anyone can share their experiences?

OpenZFS on github

Important day in the live of OpenZFS project: The codebase is now live on GitHub.

FreeNAS ZFS worst practices

Ever wanted to give yourself extra headache when using ZFS? Ever wondered how to make you zfs admin life harder? Look no more! Good folks of FreeNAS project give you the knowledge for free! FreeNAS ZFS worst practices.

OpenIndiana Hipster 2015.10 has been published

And it got an announcement on Slashdot. A little bit more in depth text has been published on Phoronix and most details can be grepped from Release Notes.

SmartOS 20151002T091442Z with Intel DC P3700 NVMe

Peter Toth posted a query asking for confirmation if his poor performance using NVMe drivers is to be expected or maybe there's something he can tweak in order to get better transfer.
Saso Kiselkov asked if testing was conducted on multiple threads. Also, answering Richard Elling's query about measurement methods Peter posted longer explanation and also a similar test results on FreeBSD. The closure from Richard Elling seems to be that NVMe driver still needs improvements.

LFR: 6242 sha512 is broken in grub

Toomas Soome commited fix for LFR: 6242 sha512 is broken in grub.

Wjile testing sha256 on rpool dataset Toomas got checksum verification error. After investigation he founf out it was grub sha256 implementation issue. From his summary:
he current SHA512 implementation in grub has 2 major issues - missing type casts of uint8_t data are causing data loss from left shift operation and resulting checksum has wrong byte order. Those two issues are causing immediate failure from reading zfs. The commit 9ce6e318fecae800270f382ed76162508c5d525b to illumos-gate fixes this issue.

WPA2 Enterprise Support in illumos

The topic of WPA2 Enterprise Support in illumos came back for short thread of three messages. Short story is, as Hans Rosenfeld put it:
I've worked on this code last year and I learned the hard way that it is not even close to be in an RTI'able state.

5969: update illumos-gate to use python2.7

Few mails came up in thread about updating illumos-gate to have and use python 2.7. OpenIndiana /dev still relies on python 2.6, so nuking it seems like not an option. A solution proposed by Gordon Ross is to:
In all these cases where illumos-gate builds modules for some external environment (perl, python, etc.) the ideal solution would be to build those modules for _all_ the versions of that external environment that we support. Yes, that's a lot to ask.
It would be great to make the list of versions of such build configurable too.
Simply assuming there will only ever be one version is not really solving anything.

GRUB changes further shrink BE maximum

Following on issues with number of Boot Environments which can be serviced by GRUB being 40, Dan McDonald posted his discovery, that increasing number of features working within GRUB limited the number to 22:
'm now seeing GRUB errors on 22 concurrent boot environments or less.

I know we have lots of new features like new ZFS hashes, but it was bad enough telling my OmniOS r151014 users about a limit of 40. Now a limit of 22?!?

Is there ANYONE in the audience who knows grub well enough to figure out how to access extended memory or otherwise unshackle the menu.list processing from the size of the loaded stage2 image?!? If not, I'm going to attempt it myself.
The above started a thread. After few mails Dan McDonald made a go at removing some filesystems that illumos users he thinks will rarely use (after a quick poll on a mailing list in the thread). Some quick calculations:
JUST eliminating Reiser and FFS is enough to gain back 5350 bytes from the current, most recent stage2, which has a limit of approximlately 22 BEs, or 2560 bytes from the pre-new-hashes push, which was limited to approximately 40 BEs. So if 2800 bytes gives back 18 BEs, then 2560 will give back another 15 or more, I guess.

I'm going to build illumos-omnios with changes to lose Reiser and FFS, to see if I can measure how many BEs I can handle.

And to the advocates --> IMHO ANY FUTURE CHANGES TO GRUB should includes a new size count for "stage2", so we can be ready for more or less BEs.
And results seem to be promising: I'm definitely exceeding the 40-ish that I hit with the grub currently shipping with OmniOS r151014 by eliminating these two.

60 appears to be too much, but 55 works. And that's better than 40, and CERTAINLY better than 22.

I'll draw up the bug report and webrev.

grub & https://www.illumos.org/issues/5943

Toomas Soome posted some musings about ongoing issues with limited GRUB menu entries:
I was thinking loud on irc (and probably bored people to death), but few ideas which did pop into my mind while checking the grub source.

first, to be clear, the grub does read in whole menu.lst file and processing its content against builtins_table, meaning the whole menu will be in memory and all $variables expanded - which in total, will eat quite some bytes per entry.

so the thoughts:

1. strip “standard” kernel/boot archive names and/or point to single instance. save ~ 2x 35bytes per entry.

2. don't expand variables till actually needed. the ZFS-BOOTFS alone will be expanded to something like:

$ eeprom bootcmd bootcmd=/platform/i86pc/kernel/amd64/unix -B zfs-bootfs=rpool/260,bootpath="/pci@0,0/pci15ad,1976@10/sd@0,0:a",diskdevid="id1,sd@n6000c29adc1bcbfc8f255cf90b965193/a"

add boot_archive, add properties like console=ttya etc...

3. don’t read in the whole file for menu; read just titles, only read and expand entry when its needed (edit, boot). there is still danger to fill memory with titles and have nothing left for kernel/archive.

4. read as is, but if memory is full, drop “unneeded” entries but leave at least default entry so we have bootable system. issue an warning about menu file being too large.

5. combination of 4. and 3. read only titles and full default entry as its needed anyhow (most likely).

also note the menu.lst is not necessarily coming from disk/zfs, but perhaps from tftp - however, the size issue is most likely about zfs based menu, as there are the snapshots created.

what is certain, the memory usage should be checked and made sure we have functional grub:)

I have an feeling the last ideas may have the most meat on, but anyhow, I think we can work out the https://www.illumos.org/issues/5943 by implementing at least 4th variant.

Yes, I know with presenting out those ideas I’ll probably receive some pressure to pick this task, but I’d hope to deal with loader project… so feel free to take over:D

How best to fix assignment with NULL?

Interesting thread came about fixing illumos code after chage of NULL definition. Original mail from Gary Mills explains that further. Problems is, after the NULL change compiler complains when the NULL is being assigned to pointer of int derived type, as in the example from mentioned mail:

uint64_t a;
uintptr_t b;
a = NULL;
b = NULL;

Gary proposed few solutions, again cited from his mail:
a = (uint64_t)NULL;
b = (uintptr_t)NULL;

a = (uint64_t)0;
b = (uintptr_t)0;

a = 0;
b = 0;

Few approaches were discussed, be sure to follow the thread to read them all.
All in all, Gary posted what seems to be a consensus about how to treat NULLs:
A few days ago, I asked about assignments of NULL to variables that are integer types used to store pointers, when NULL is `(void *)0'. These people responded:

Josef 'Jeff' Sipek
Paul Dagnelie
Garrett D'Amore

These are my conclusions from their responses:

The expression `a = (uint64_t)NULL;' is incorrect because gcc issues a warning for 32-bit compiles.

A variable of type `uint64_t' is used to contain 32-bit or 64-bit pointers without changing its own length.

Assignment of zero, instead of NULL, is functionally correct. The compiler doesn't issue warnings in this case. Casts of zero to the type of the left-hand side are redundant.

NULL must be cast to an integer type for assignment to an integer variable. A cast to `uintptr_t' is necessary for assignment to a `uint64_t' variable.

New metapackage -> illumos-tools

Dan McDonald posted information about new metapackage in OmniOS:
IF you want to build illumos-omnos or illumos-gate on an OmniOS r151014 or later installation, you can do so now simply by uttering:

pkg install developer/illumos-tools

illumos-tools is a metapackage that brings in all of the required packages one needs to build illumos-gate or illumos-omnios. You can then just download the closed-binaries, git clone your favorite illumos-gate child, construct a .env file and get going.

In the same thread Igor Kozhukhov informed about similar-purpose script he has for dilos:
Just for info: for dilos-illumos builds I have special script with list of packages and steps for build env: tools/bld_pkgs.sh

6339: env file could figure out CODEMGR_WS automatically

Josef "Jeff" Sipek closed 6339: env file could figure out CODEMGR_WS automatically. This makes developers that use git based repo have to define less variables when building. Not full automation, but appreciated.

How to test SPARC packages?

Gary Mills asked how to test SPARC packages. In the thread he got few replies:

Allow ON_CLOSED_BINS to point to a directory with tarballs

Dan McDonald integrated another improvement in illumos build simplification: 6366: Allow ON_CLOSED_BINS to point to a directory with tarballs. Idea is that you don't have to extract closed bins any more before building illumos, you can point variable to a directory containing tarballs. The build process will then as it would have been done normally.

The SMB server how has "extended security"

Gordon Ross posted a summary, how security support has changed in smb and idmap recently. Be sure to read it up, since it changes some AD connectivity/authentication from pre-fixes state significantly. Reproducing here:
Thanks to help from authors (there were many!) and reviewers and advocates, the SMB server can now do normal, Active Directory (AD)-style authentication, using connection-less LDAP queries to find the correct AD server, using Kerberos to authenticate the client, etc. This also closes a four year old bug:
https://www.illumos.org/issues/1087

This push represents quite a bit of work beyond what was in the original OpenSolaris code. The changes add up to over ten thousand lines of new code, or about fifteen thousand changed lines (according to webrev).

One caution: After this, quite a lot of the on-line "advice" you'll find about administering the SMB service is out of date and now wrong. In particular, advice about OpenSolaris and adjusting lmauth_level no longer applies to illumos. Similarly, one should now _disregard_ advice about changes on the Windows side to "dumb down" the security levels it uses to connect to our SMB service, because we now can do full Kerberos authentication etc.

Thanks to Nexenta Systems (www.nexenta.com) for supporting the effort to upstream this major piece of work.

Gordon Ross

On Thu, Oct 22, 2015 at 2:57 PM, Gordon Ross wrote:
> Hi developers,
>
> I plan to RTI the three change sets below soon (probably this weekend).
> If you plan to review them, please finish up, or ask for more time.
>
> 6352 Updated DC locator for SMB and idmap
> https://www.illumos.org/issues/6352
> http://ma.nexenta.com/gwr/dclocate/
>
> 6351 Update smbsrv dtrace scripts and install them
> https://www.illumos.org/issues/6351
> http://ma.nexenta.com/gwr/smbdtrace/
>
> 1122 smbsrv should use SPNEGO (inbound authentication)
> https://www.illumos.org/issues/1122
> http://ma.nexenta.com/gwr/extsec/

6440: ssh packages should be replaceable

Alexander Pyhalov integrated work on 6440: ssh packages should be replaceable. As explained in this thread it is preparatory work to allow SunSSH and OpenSSH to coexist on the same installation.