Solarismen

You were the best foster dog ever... The time with you was short, too short, but filled with joy!

Canine degenerative myelopathy sucks.

The following patch is needed for mariadb-10.1.22 and later on Solaris 11.3:

Update 29.04.2017: A more complete description and solution is presented at:
https://jira.mariadb.org/browse/MDEV-12310
diff -ur mariadb-10.1.22~/mysys/mysys_priv.h mariadb-10.1.22/mysys/mysys_priv.h --- mariadb-10.1.22~/mysys/mysys_priv.h 2017-03-11 20:09:10.000000000 +0000 +++ mariadb-10.1.22/mysys/mysys_priv.h 2017-04-28 15:48:49.811392259 +0000 @@ -108,7 +108,7 @@ void my_error_unregister_all(void); -#if !defined(O_PATH) && defined(O_EXEC) / FreeBSD / +#if !defined(O_PATH) && defined(O_EXEC) && !defined(__sun__) / FreeBSD / #define O_PATH O_EXEC #endif
Otherwise mariadb would abort on startup with:
ERROR: 1030 Got error 8 "Exec format error" from storage engine MyISAM

I am using a very old Linksys router as a WLAN-AP and a switch for older 100 MBit devices. When I changed my network layout (due to swtiching rooms for my home office), this router was no longer connected directly to my Fritz!Box (Internet router) but via another switch (which is not IGMP V3 ready).

When I now watched TV on my PC (T-Entertain, using vlc) the multicast IP-TV-traffic went all over my switch, all ports, the Linksys router and was finally flooding the WLAN. I can perfectly live with the 10 Mbit or so IP-TV traffic flowing over my cable ethernet - for the WLAN, however I needed to find a solution.

[1] outlines two solutions, one via "unbridging" the WLAN and the other using ebtables to filter the multicast traffic. I did not like the former, because that meant that the Linksys router would need to take over DHCP tasks for the unbridged WLAN segment (DHCP needs broadcasts).

The latter variant turned out not to work, because the ebt_pkttype kernel module is not included in any stable release of dd-wrt for this old router. I have no idea why, and [2] has a lengthy discussion about possible workarounds, but this was a show-stopper for this variant as well.

But why do they use the pkttype plugin? One can specify source and destination MAC addresses using just the ebtables and ebtable_filter modules (which are available on my router) and there are even broadcast and multicast aliases for this command, see the man page at [3].

Admittedly, the way these aliases are defined, the multicast alias does also match broadcast packets, which is not what we desire (see above). Nothing prevents us, however, from using a hand-crafted multicast filter which just filters out the IPTV packets. This turns out to be 01:00:5e:00:00:00/01:00:5e:00:00:00. For further information refer to [4].

The only necessary configuration change is thus to insert the following commands into the startup commands at Administration->Commands:
insmod ebtables insmod ebtable_filter ebtables -A FORWARD -o eth1 -p IPv4 -d 01:00:5e:00:00:00/01:00:5e:00:00:00 -j DROP
Note that this does only filter on the eth1 interface (WLAN, see [5]) and the multicast packets are not filtered on the cable-based ports 1-4, but this is perfectly fine for me.

Update 04.04.2017: Dammit! My solution also filtered out some IPv6 multicast packets, in particular ICMPv6 neighbour solicitations. The filter needs to be restricted to IPv4 packets only (already applied above).

When I migrated from apache with mod_php to nginx with php-fpm a few days ago, php dumped core on me if it was stopped immediately after having been started. This is due to https://bugs.php.net/bug.php?id=66694. The same bug is also filed under #68349.

Basically, port_getn claims to have events ready to be processed, when in reality, there are none. There are quite a few patches for this problem floating around, all of which are too complicated for my taste.

The following very small patch worked fine for me:
diff -ur php-7.0.13~/sapi/fpm/fpm/events/port.c php-7.0.13/sapi/fpm/fpm/events/port.c --- php-7.0.13~/sapi/fpm/fpm/events/port.c 2016-11-08 16:07:40.000000000 +0000 +++ php-7.0.13/sapi/fpm/fpm/events/port.c 2016-11-12 12:47:24.964771094 +0000 @@ -138,7 +138,7 @@ for (i = 0; i < nget; i++) { / do we have a ptr to the event ? / - if (!events[i].portev_user) { + if (events[i].portev_source == 0 || !events[i].portev_user) { continue; }
The idea is to check whether a proper event source value is set for any events returned by port_getn.

After re-flashing my Moto G 2015 with CM 13, no IPv6 address was assigned to it for mobile data, neither on 2G, 3G or 4G. The APN i was using was "internet.telekom", and indeed the default setting is to obtain an IPv4 address only. However, even setting "APN protocol" and "APN roaming protocol" to "IPv4/IPv6" and rebooting did not help. WTF!!

The solution was to delete the APN completely and re-create it.

Unfortunately, I have not checked what exactly this changes in /etc configuration files, but as an easy solution it was good enough for me.

Today I learned the hard way about some magic ffmpeg does when encoding with the libx264 codec. Apparently, when you use a "-preset" higher than the "medium" default, the H.264 level gets upped to 5.0. This makes my Samsung TV UE-40F6340 SSXZG refuse to play the resulting file.

To work around this problem, explicitly specify "-level 4.1" (which is the highest supported level as per the Samsung Manual). Of course, the frame rate continues to be limited to 30 fps in progressive mode.

These are the settings I use now:
(...) -c:0 libx264 -preset slower -level 4.1 -g 25 -bf 2
I specify "-g 25" to make the video more easily seekable and "-bf 2" to facilitate YouTube uploads (2 consecutive B-Frames is YouTube's recommendation).

Apply this patch for openssl 1.0.2e to store a proper library run-path for libcrypto.so in libssl.so:
diff -ur openssl-1.0.2e~/Makefile.org openssl-1.0.2e/Makefile.org --- openssl-1.0.2e~/Makefile.org 2015-12-03 15:04:23.000000000 +0100 +++ openssl-1.0.2e/Makefile.org 2015-12-31 19:26:56.574207607 +0100 @@ -350,7 +350,7 @@ build-shared: do_$(SHLIB_TARGET) link-shared do_$(SHLIB_TARGET): - @ set -e; libs='-L. $(SHLIBDEPS)'; for i in $(SHLIBDIRS); do \ + @ set -e; libs='-L. -R$(INSTALL_PREFIX)$(INSTALLTOP)/$(LIBDIR) $(SHLIBDEPS)'; for i in $(SHLIBDIRS); do \ if [ "$$i" = "ssl" -a -n "$(LIBKRB5)" ]; then \ libs="$(LIBKRB5) $$libs"; \ fi; \ @@ -372,7 +372,7 @@ echo 'Description: OpenSSL cryptography library'; \ echo 'Version: '$(VERSION); \ echo 'Requires: '; \ - echo 'Libs: -L$${libdir} -lcrypto'; \ + echo 'Libs: -L$${libdir} -R$${libdir} -lcrypto'; \ echo 'Libs.private: $(EX_LIBS)'; \ echo 'Cflags: -I$${includedir} $(KRB5_INCLUDES)' ) > libcrypto.pc @@ -386,7 +386,7 @@ echo 'Description: Secure Sockets Layer and cryptography libraries'; \ echo 'Version: '$(VERSION); \ echo 'Requires.private: libcrypto'; \ - echo 'Libs: -L$${libdir} -lssl'; \ + echo 'Libs: -L$${libdir} -R$${libdir} -lssl'; \ echo 'Libs.private: $(EX_LIBS)'; \ echo 'Cflags: -I$${includedir} $(KRB5_INCLUDES)' ) > libssl.pc

Apply this patch to gcc 4.9.3 to store proper library run-paths for libgcc_s.so in libgfortran, libgomp, libitm and libstdc++:

gcc-4.9.3.diff

gcc-5.3.0.diff

Apply this patch to compile kamailio 4.3.4 on Solaris 11 with full IP V6 support:

kamailio-4.3.4.diff

I configured in.ndpd (svc:/network/routing/ndp:default) to generate privacy-enhanced ipv6 addresses (RFC 4941) by putting "ifdefault TmpAddrsEnabled true" into /etc/inet/ndpd.conf. The auto-configured address derived from the interface's MAC address continues to exist. To my surprise, the system continues to use this (non-privacy-enhanced) address by default!

I found no other way to make solaris use the temporary, privacy-enhanced address than to patch in.ndpd as follows:
--- in.ndpd.orig.dis 2015-11-07 10:56:48.776716882 +0100 +++ in.ndpd.dis 2015-11-07 12:19:59.009907616 +0100 @@ -1,4 +1,4 @@ -disassembly for in.ndpd.orig +disassembly for in.ndpd section .plt @@ -14442,7 +14442,7 @@ prefix_update_k+0x157: 33 d2 xorl %edx,%edx prefix_update_k+0x159: 83 c8 00 orl $0x0,%eax prefix_update_k+0x15c: 74 05 je +0x5 <prefix_update_k+0x163> - prefix_update_k+0x15e: ba 08 00 00 00 movl $0x8,%edx + prefix_update_k+0x15e: ba 0c 00 00 00 movl $0xc,%edx prefix_update_k+0x163: 83 ec 0c subl $0xc,%esp prefix_update_k+0x166: 6a 00 pushl $0x0 prefix_update_k+0x168: 6a 00 pushl $0x0
This adds the "PREFERRED" flag to the "TEMPORARY" address generated by in.ndpd:
net0: flags=120002000841<UP,RUNNING,MULTICAST,IPv6,PHYSRUNNING> mtu 1492 index 2 inet6 fe80::219:99ff:****:84d5/10 net0:1: flags=120002080841<UP,RUNNING,MULTICAST,ADDRCONF,IPv6,PHYSRUNNING> mtu 1492 index 2 inet6 2003:48:2937:5000:219:99ff:****:84d5/64 net0:2: flags=120c02080841<UP,RUNNING,MULTICAST,ADDRCONF,IPv6,PREFERRED,TEMPORARY,PHYSRUNNING> mtu 1492 index 2 inet6 2003:48:2937:5000:70b7:8159:937c:f526/64
If you know a better way to make the privacy-enhanced address the default one, please leave a comment!

For your convenience, I have prepared patched versions (with an "ashift" setting of 12) of the original zpool program for Solaris 11 11/11 and Solaris 10 8/11 (s10u10).

It has been produced by binary patching, following the idea presented here and here.

This is how to permanently change your hostname in Solaris 11:
root@vbox3:/tmp# svccfg <<EOM select /system/identity:node #listprop config setprop config/nodename="newhost" setprop config/loopback="newhost" refresh EOM
And this is how to permanently change your static IP-Address in Solaris 11, if you are not using NWAM:
root@vbox3:/tmp# svcs svc:/network/physical:nwam STATE STIME FMRI disabled Sep_22 svc:/network/physical:nwam root@vbox3:/tmp# ipadm show-addr ADDROBJ TYPE STATE ADDR lo0/v4 static ok 127.0.0.1/8 net0/v4 static ok 192.168.3.17/24 lo0/v6 static ok ::1/128 net0/v6 addrconf ok fe80::a00:27ff:febd:7496/10 root@vbox3:/tmp# ipadm delete-addr net0/v4 root@vbox3:/tmp# ipadm create-addr -T static -a 192.168.3.18/24 net0/v4 root@vbox3:/tmp# ipadm show-addr ADDROBJ TYPE STATE ADDR lo0/v4 static ok 127.0.0.1/8 net0/v4 static ok 192.168.3.18/24 lo0/v6 static ok ::1/128 net0/v6 addrconf ok fe80::a00:27ff:febd:7496/10 root@vbox3:/tmp# exit

Solaris 11 has arrived for "early adopters", and I am one of those. As far as I can see, nonthing has changed on the "ashift" front. Pools created on a WD EARS disk by the standard zpool program still have an "ashift" value of 9.

So, here comes the patch for "zpool" for Solaris 11 EA (snv_173):
--- zpool_snv173.save.dis 2011-09-17 14:30:53.911407633 +0200 +++ zpool_snv173.dis 2011-09-17 15:14:23.263512388 +0200 @@ -13444,13 +13444,12 @@ 805e72c: ff b5 4c fb ff ff pushl -0x4b4(%ebp) 805e732: e8 c5 5d ff ff call 80544fc 805e737: 83 c4 10 add $0x10,%esp - 805e73a: 85 c0 test %eax,%eax - 805e73c: 74 1a je 805e758 - 805e73e: 83 ec 04 sub $0x4,%esp - 805e741: 68 0b 02 00 00 push $0x20b - 805e746: 68 4c 5f 06 08 push $0x8065f4c - 805e74b: 68 d0 5c 06 08 push $0x8065cd0 - 805e750: e8 17 5a ff ff call 805416c <__assert@plt> + 805e73a: 68 00 00 00 00 push $0x0 + 805e73f: 68 0c 00 00 00 push $0xc + 805e744: 68 d0 5c 06 08 push $0x8065cd0 + 805e749: ff b5 4c fb ff ff pushl -0x4b4(%ebp) + 805e74f: e8 a8 5d ff ff call 80544fc + 805e754: 90 nop 805e755: 83 c4 10 add $0x10,%esp 805e758: 83 ec 08 sub $0x8,%esp 805e75b: 68 44 5e 06 08 push $0x8065e44

It is a straightforward adaptation of the same patch for NexentaStor 3.1.0. You can find the binary here. If you want, you can check its (and my) integrity by doing a "cmp -lc zpool zpool-s11ea".

I am currently experimenting with the Community Edition of NexentaStor. If I am not mistaken, NexentaStor does not have special provisions for disks with a logical sector size of 512 Bytes and a physical sector size of 4096 Bytes (like e.g. the WDXXEARS).

I am a bit fed up chasing down the appropriate source for the "zpool" utility, inserting one line (to set "ashift" to 12) and then recompiling it.

This time (for NexentaStor 3.1.0) I decided to patch the binary. Thus, I do not need to care from which source exactly they produced the "zpool" utility.

It goes like this:
--- zpool_nxs310.save.dis 2011-07-30 13:47:58.675595763 +0200 +++ zpool_nxs310.dis 2011-07-30 15:44:50.378893898 +0200 @@ -12667,13 +12667,12 @@ 805d901: ff b5 5c fb ff ff pushl -0x4a4(%ebp) 805d907: e8 28 69 ff ff call 8054234 <nvlist_add_uint64@plt> 805d90c: 83 c4 10 add $0x10,%esp - 805d90f: 85 c0 test %eax,%eax - 805d911: 74 1a je 805d92d <make_leaf_vdev+0x265> - 805d913: 83 ec 04 sub $0x4,%esp - 805d916: 68 d9 01 00 00 push $0x1d9 - 805d91b: 68 00 5f 06 08 push $0x8065f00 - 805d920: 68 10 5f 06 08 push $0x8065f10 - 805d925: e8 8a 66 ff ff call 8053fb4 <__assert@plt> + 805d90f: 68 00 00 00 00 push $0x0 + 805d914: 68 0c 00 00 00 push $0xc + 805d919: 68 10 5f 06 08 push $0x8065f10 + 805d91e: ff b5 5c fb ff ff pushl -0x4a4(%ebp) + 805d924: e8 0b 69 ff ff call 8054234 <nvlist_add_uint64@plt> + 805d929: 90 nop 805d92a: 83 c4 10 add $0x10,%esp 805d92d: 83 ec 08 sub $0x8,%esp 805d930: 68 f8 5e 06 08 push $0x8065ef8

By overwriting a conditional call to "assert" which is not really needed (if you know what you are doing), one is able to sneak in another call to "nvlist_add_uint64" for the "ashift" value. The "ashift" string comes from 0x8065f10, where previously the string for the "assertion failed" message was located. I am using a hardcoded value of 12 for "ashift" (the "push 0xc").

You can find the binary here.

If you want, you can check its (and my) integrity by doing a "cmp -lc zpool zpool-nxs310".