locale dilemma

Found for me a new behavior when installing 11.4… some commands are complaining about my locale setting…

root@t7zone01:~# pkg history
Failed to set locale: unsupported locale setting.  Falling back to C.
pkg: Unable to set locale 'de_AT.UTF-8'; locale package may be broken or
not installed.  Reverting to C locale.

pkg: 'ascii' codec can't encode character u'\xdf' in position 8: ordinal not in range(128)
root@t7zone01:~#
root@t7zone01:~# locale
LANG=de_AT.UTF-8
LC_CTYPE="C"
LC_NUMERIC="C"
LC_TIME="C"
LC_COLLATE="C"
LC_MONETARY="C"
LC_MESSAGES="C"
LC_ALL=
root@t7zone01:~# 
root@dbc01:~# ls /usr/share/locale/
C                 de.UTF-8          de_DE.ISO8859-15  en@boldquot       en_US             it                pt_BR
de                de_DE             de_DE.UTF-8       en@quot           es                ja                zh_CN
de.ISO8859-15     de_DE.ISO8859-1   en                en@shaw           fr                ko                zh_TW
root@dbc01:~# 

Where does that de_AT comes from? During the installation I said I want default “C” nothing else… and its not installed
I found that de_AT on my client! I am running my laptop/mac with de_AT.UTF-8… sitting in Vienna/Austria ๐Ÿ˜‰
Well, Solaris 11.4 comes with OpenSSH, not SunSSH anymore

pressy@PRESSY-MBP:~ # nmap solaris11.3 -p 22 -A
Starting Nmap 7.70 ( https://nmap.org ) at 2019-07-16 17:24 CEST
Nmap scan report for 10.52.72.60
Host is up (0.0035s latency).

PORT   STATE SERVICE VERSION
22/tcp open  ssh     SunSSH 2.4 (protocol 2.0)
| ssh-hostkey:
|   1024 85:d6:64:af:f3:14:1e:4b:86:2a:da:a2:6b:ba:6e:c9 (DSA)
|_  2048 50:bd:1d:d5:98:72:3f:ae:5f:ab:d6:10:a0:aa:8d:82 (RSA)

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 1.62 seconds
pressy@PRESSY-MBP:~ #
pressy@PRESSY-MBP:~ # nmap solaris11.4 -p 22 -A
Starting Nmap 7.70 ( https://nmap.org ) at 2019-07-16 17:25 CEST
Nmap scan report for 10.52.72.201
Host is up (0.0042s latency).

PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 7.7 (protocol 2.0)
| ssh-hostkey:
|   2048 27:ae:7e:e7:5f:70:d0:eb:b9:71:61:f3:eb:c5:bf:7d (RSA)
|_  256 0e:4d:9a:5d:83:00:5d:26:03:e2:1f:8e:3a:2e:ed:f9 (ED25519)

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 0.62 seconds
pressy@PRESSY-MBP:~ #
pressy@PRESSY-MBP:~ # locale
LANG="de_AT.UTF-8"
LC_COLLATE="de_AT.UTF-8"
LC_CTYPE="de_AT.UTF-8"
LC_MESSAGES="de_AT.UTF-8"
LC_MONETARY="de_AT.UTF-8"
LC_NUMERIC="de_AT.UTF-8"
LC_TIME="de_AT.UTF-8"
LC_ALL=
pressy@PRESSY-MBP:~ #

Found a little (for me “new”) settings in my ssh_config that was obviously ignored by SunSSH.

pressy@PRESSY-MBP:~ # grep SendEnv /etc/ssh/ssh_config
	SendEnv LANG LC_*
pressy@PRESSY-MBP:~ # 

OK -> many ways to fix it… but yes, that brought me to the point, how to install my “de_AT” on Solaris 11.4…

root@t7zone01:~# svccfg -s svc:/system/environment:init listprop environment/LANG
environment/LANG astring     C
root@t7zone01:~# nlsadm get-timezone
timezone=Europe/Vienna
root@dbc01:~# pkg search -r de_AT.UTF-8
Failed to set locale: unsupported locale setting.  Falling back to C.
pkg: Unable to set locale 'de_AT.UTF-8'; locale package may be broken or
not installed.  Reverting to C locale.

pkg: 'ascii' codec can't encode character u'\xdf' in position 8: ordinal not in range(128)
root@dbc01:~# export LC_ALL=C
root@dbc01:~# pkg search -r de_AT.UTF-8
INDEX      ACTION VALUE                                  PACKAGE
basename   link   usr/share/sysconfig/help/de_AT.UTF-8   pkg:/system/install/configuration@11.4-11.4.10.0.1.3.0
basename   link   usr/share/locale/de_AT.UTF-8           pkg:/system/locale@11.4-11.4.9.0.1.4.0
basename   file   usr/lib/locale/de_AT.UTF-8/de_AT.UTF-8 pkg:/system/locale@11.4-11.4.9.0.1.4.0
root@dbc01:~# nlsadm install-locale de_AT.UTF-8
Reading package information from IPS publisher's repository (this may take awhile) ...
Locale(s) to install:
 de_AT.ISO8859-15
 de_AT.ISO8859-1
 de_AT.UTF-8

Facet(s) to change:
 facet.locale.de_AT

Additional locales need to be also installed due to the structure of packaging.
Add the locales to the command argument or run with '-f/--force' option to install additional locales
root@dbc01:~#
root@dbc01:~# nlsadm install-locale -f de_AT.UTF-8 de_AT.ISO8859-1 de_AT.ISO8859-15
Reading package information from IPS publisher's repository (this may take awhile) ...
Locale(s) to install:
 de_AT.ISO8859-15
 de_AT.ISO8859-1
 de_AT.UTF-8

Facet(s) to change:
 facet.locale.de_AT

Updating installed packages and facets (this may take awhile) ...
Done
root@dbc01:~#

YES -> that’s it…
BUT….. oh my god… english/german mix on my cli:

root@dbc01:~# pkg history -n 2
START                    OPERATION                CLIENT             OUTCOME
2019-07-15T15:06:48      install                  pkg                Erfolgreich
2019-07-16T09:55:12      change-facet             pkg                Erfolgreich

OK -> so I removed my ssh_config setting on my mac ๐Ÿ˜‰

Have FUN!

RAMBleed on Solaris/SPARC?

Using enterprise class hardware shows once again that you get what you paid for.

A new issue came up in the last days describing attacks against Dynamic Random Access Memory (DRAM) modules that are already susceptible to Rowhammer-style attacks. At the end of the day these security problems are not microprocessor-specific, they leverage known issues in DRAM memory. These attacks only impact DDR4 and DDR3 memory modules, and older generations DDR2 and DDR1 memory modules are not vulnerable to these attacks.
Oracle published an advisory that reported that older and current servers using its SPARC and x86 CPUs aren’t expected to be susceptible to RAMBleed:

RAMBleed

All current and many older families of Oracle x86 (X5, X6, X7, X8, E1) and Oracle SPARC servers (S7, T7, T8, M7, M8) employing DDR4 DIMMs are not expected to be impacted by RAMBleed. This is because Oracle only employs DDR4 DIMMs that have implemented the Target Row Refresh (TRR) defense mechanism against RowHammer. Oracleโ€™s memory suppliers have stated that these implementations have been designed to be effective against RowHammer.

Just to remember once again… ๐Ÿ˜‰

Meltdown@SPARC – NO
Spectre@SPARC – OKnot all variants (HW_BTI & OS fixed)
Foreshadow@SPARC – NO
ZombieLoad@SPARC – NO
RAMBleed@SPARC – OKvery difficult based on TRR DIMMs

Working in an enterprise data center and securing your business critical services might be easier than you thought… work with Solaris on SPARC!

No RISC no fun

SPARC Roadmap 2018

A new roadmap is on the web… Solaris 11.5 as Solaris.next and new Sparc M8+ chips are planned for 2020/21…

Good new for the best operating system on the world ๐Ÿ˜‰

http://www.oracle.com/us/products/servers-storage/servers/sparc/oracle-sparc/sparc-roadmap-slide-2076743.pdf

[UPDATE – 06/2019]

As you might already recognized the official roadmap disappeared from oracle-web… my last discussion with the SPARC product management was “well, no one else publish a roadmap”… I am not happy with that answer, but as it seems Oralce does not say there will be a M8+ right now. Also the naming scheme for 11.5 is in discussion, again regarding re-certification as an argument, so we might see more 11.4 updates rather a 11.5 release. But they promised again that Solaris will be supported at least until 2034 from today and will be developed to meet all necessary features to be the most stable and secure OS for the next decades.

But even if Oracle will not bring a M8+ chip we still have a public roadmap from our Fujitsu friends who build very nice SPARC systems:

https://www.fujitsu.com/global/products/computing/servers/unix/sparc/key-reports/roadmap/

Oracle M8 chip is after 18 months still the fastet processor to handle JAVA workload (see spec.org) and phenomenal fast in database analytic in-memory queries (up to 10 times faster than x86) with their DAX engines.

Fujitsu CPUs compared to M8 does not provide so many cores on the chip but have a better single thread performance than Mx chips.

To finalize it is still a very good idea if you need a highly secure and robust environment to go for SPARC systems. “Endless” OS support (still 15 years, no one else promise that), a great platform supported for the next years and still a roadmap from Fujitsu to reinvest if necessary.

[UPDATE 2020]

I saw these two slides presenting a joined future:

No RISC no fun!